RE: [NSIS] review - some security comments on documents

["Hancock, Robert" <[e-mail]>]

Michael,

Thanks for these comments. I'll try to address those which affect
the framework and NTLP (my main focus).

NSLP authors should definitely read this (it is a request for input
for NTLP development).

On the document structure, I think everyone (including the authors)
would accept the structure we have for the 'informationals' is not
ideal. It's something that is too late to change now, but might be
avoided in the future if the IETF had better defined working processes
(although that might be a double-edged sword, of course). If we have
managed to set ourselves up to design the 'right' protocols, I think
that's the best we can do (and I think we have, maybe with one
exception you point out).

The primary open security issue - as it affects the NTLP, and as
maybe should have been explained more in the f/w but weren't - is 
how the trust and security models should be reflected in the actual 
operation of the protocol. 

Specifically, the NTLP draft currently says (mainly in section 7):
- there is some stuff about DoS attacks and routing integrity
attacks, which have to be handled (and handled non-cryptographically)
in the NTLP (in fact, I regard this as the main security service
provided by the NTLP)
- if you want channel protection, use existing security protocols
- BUT it doesn't say how those protocols should be invoked in
detail (or, really, at all).

The problem is that the trust/security models IMHO can't be fully
defined by the NTLP but are signalling application specific (and 
probably in fact also deployment specific). This issue is (implicitly)
defined as open in section 8.6 of the NTLP draft. Therefore:

Maybe what we need to do is to get the NSLP authors to say how their
trust/security models imply that channel security protocols should
be invoked, and then make sure that the NTLP can be used compatibly
with those requirements (and still maintain the DoS/routing integrity
protection which is its major goal).

I'm fairly certain in my own head, however, that the NTLP needs to be
flexible (i.e. not constrain) what trust/security models can be used.
To draw a comparison, 3436 and 3554 contain basically no discussion
of such issues; I think the NTLP needs to go a bit further, but not
very far.

robert h.

PS you also raise a couple of points about IP layer issues (RAO
processing, IP protocol number). Basically, I don't think there is a
'right' answer - all we can do is gather all the information we
can and make a (hard) judgement call. However, my impressions are:

- if RAO processing with some discrimination can't be done on the
fast path, we are stuffed anyway. I think the way the RAO has been
defined is a perfect fit to our requirements, and if people haven't
implemented it there isn't much we can do.

- I don't see much difference either way between "RSVPv2" and "UDP
to the RSVP port" from a complexity perspective. The motivation for
UDP comes mainly from NAT handling issues (maybe this should be
explained a bit more in section 8.2).

> -----Original Message-----
> From: Michael Richardson 
> [mailto:[e-mail]]
> Sent: Monday, February 09, 2004 02:39
> To: [e-mail]
> Subject: [NSIS] review - some security comments on documents
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> I was asked to review the requirements, framework and theats 
> documents,
> from a security perspective. To be clear my background is 
> Firewalls, IPsec,
> key management, and I spent some time trying to build 
> programmable fast
> path policy-based classifiers.  I was also involved in the 
> Security Policy
> Protocol (SPP) as a firewall vendor - i.e. trying to solve the problem
> of getting IPsec through firewalls before the term NAT was around. 
> 
> REQUIREMENTS
> 
> My general comment is that this protocol is too general. A 
> key symptom of
> this is that the requirements are not prioritized. The key thing is,
> when compromises need to be made, on what basis will the 
> compromise be made?
> 
> Since security is a major requirement, and there are multiple 
> operational
> requirements which are very hard to secure, how will things bend?
> 
> FRAMEWORK
> 
> The framework document excited me. I thought, this is going to be some
> sophisticated protocol - end to end, plus hop-to-hop, with 
> mutable objects,
> and immutable objects, and some way to insert and delete objects while
> avoiding unwanted manipulation by intermediate nodes. In the end, the
> framework document actually specified far more requirements than the
> requirements document. Most of the additions are very 
> specific security
> requirements. 
> 
> While I understand why there are two documents from a strict 
> work-flow 
> point of view, I think it may be simpler to have one 
> document, perhaps 
> one that isn't quite as big.
> 
> THREATS
> 
> The threats document needs work. I was expecting a 
> threat-model. What things
> need to be defended against. Well, again the protocol is too 
> general to do
> this, so the document is a bit of a mismash of different things. 
> 
> Who do we need to trust to make this protocol work? 
> 
> {And, is that a realistic business model? If not, can we 
> change the trust
> model to one what matches reality?}
> 
> {Please don't tell me that the IETF doesn't do business 
> models. We do. "Best
> effort zero-settlement" has been the business model for most of the
> Internet. Our current protocols current support that model. 
> QoS proposes
> different business models, so we need to know who pays, who gains, and
> where is the possible fraud. We need to know this so that we 
> can find out if
> the security protects these relationships.) 
> 
> A key thing that concerned me is that NSLP objects could be 
> inserted/deleted,
> reordered, or even replayed, by NE that are participating in 
> the hop-by-hop
> security.  End-to-end integrity would protect the objects, 
> but not their
> existence. NSTL/NSLP need an NXT-like (DNSSEC) object which is always
> present, so that the receiver can know if objects were 
> removed/inserted.
> 
> A major threat that I see is CPU exhaustion of the slow-path. 
> Specifically,
> NSTL's section 8.4 - the system MUST aggregate well. But more 
> than that,
> it must DEFEND that aggregation at the edges. 
> 
> I want to suggest that there are strong arguments for having 
> an integrity
> protocol where one can examine the contents of the message 
> first, (since
> that is often rather cheap to do) determine if it actually 
> changes state,
> and only if the message needs to be acted on, THEN confirm 
> the integrity
> of the message. AH, btw, is one integrity protocol that 
> permits this. If
> one needs hop-by-hop privacy, then one has to provision the 
> decryptor to run
> at anticipated wire-speed to be able to examine the packets, but the
> authenticator, (which might even be public key based) does not need to
> run at that speed.
> 
> I also want to suggest that the security and trust model be 
> fully developed
> before any other details are filled on.
> 
> The threats document also seems to have been written in 
> isolation from the
> framework and requirements document. I think it should parallel the
> requirements, explaining why there is a requirement, for instance, for
> hop-by-hop security, or end-to-end object integrity, etc..
> 
> OTHER DOCUMENTS
> 
> I was not asked specifically to review the nstl-00 or 
> application specific
> documents, but I did take a look at them. 
> 
> I think that the NSTL is the key to the security. While I am 
> very impressed
> with this -00 document, I think it is wrong to start with 
> packet formats,
> and whether or not TLS, UDP, IPsec, is useable. 
> 
> Please start with the public keys - when will they be used, 
> how/if will they
> be strongly authenticated, etc.  Maybe that goes into the 
> framework document.
> 
> The QoS document claimed that all of this would be offloaded 
> to some AAA
> protocol -- I think that this is a cop out. I need to know how the AAA
> will provide the integrity protection, the authentication and 
> authorization
> that is required.
> 
> Section 7 of NSTL basically reads as "just use IPsec".
> NOT ENOUGH. Think about the relationships and where the keys 
> will come from.
> IKE is signaling. Maybe using signalling to secure signaling 
> is the wrong 
> choice. Maybe not.
> 
> Please find and read draft-ietf-ipsp-spp-01.txt.
> 
> I read: "An alternative approach would be to use raw IP with the RSVP
> protocol numbers and a new RSVP version number."
> This may also conserve/preserve silicon!
> 
> I have a question from ignorance of deployed hardware:
> Are RAO filters really available in production fast-path 
> silicon? I know that
> some silicon vendors can cope, because they are 
> programmable/configurable,
> but what about those that aren't? 
> 
> In the NAT-FW document, it says: 
> 3.2
>    "Discovering security gateways, which was also mentioned as an
>     application for NSIS signaling, for the purpose of 
> executing an IKE
>     to create an IPsec SA, is already solved without requiring NSIS."
> 
>    really? I didn't know that it was solved. Do tell!
> 
> The QoS and NAT-FW document is clearly too preliminary for me 
> to be able to
> evaluate whether or not the requirements or features of the 
> framework have
> been satisfied by this protocol. In particular, no statements 
> are made about 
> the trust relationships, or who may edit what mutable fields, 
> etc. I was
> hoping that there might be enough meat here to saw whether or not the
> framework requirement were useful/complete. 
> 
> OTHER:
> 	are there really RMF's capable of managing the resources for all
> 	paths through a network? I thought that the ATM folks 
> tried to do
> 	this and failed, and this was one of the reasons that ATM didn't
> 	get the deployment that was originally envisioned?
> 
> ]       ON HUMILITY: to err is human. To moo, bovine.         
>   |  firewalls  [
> ]   Michael Richardson,    Xelerance Corporation, Ottawa, ON  
>   |net architect[
> ] [e-mail]      
http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQCbyqoqHRg3pndX9AQFR/AQAsIXy5Ekd75e9BAWMqX1DdxeZKICdI8fi
2+SX3nd34LzTMI5kTsBtCm5Pohl2Gn0B8s3jFkIeZ5qClCZp/Q7yEqz0+52vjJoJ
vwPNNvbJM31bpdY8hlY4ajA9OkNlYCfnexfoMr6G6I0hqpHlwnpDCs+ykK9d8M19
pu0UFTKR09A=
=nK5K
-----END PGP SIGNATURE-----

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis