Subject: RE: [NSIS] RE: Security Threats for NSIS & RSVP Security Properti es documents

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 23 May 2003 11:01:36 +0100

dear all,

I think we should see this document as logically similar to the
requirements document, i.e. covering the NSIS problem as a whole at
some high level, rather than trying to include all protocol design
goals as well. Otherwise it will never be finished.

There remains the question of where to discuss and document layer split
and other issues. One logical place would be the framework, which (I think)
is going to define the layer split from other perspectives. However, it
already has some assertions on this (crudely, NTLP security is about 
protecting information in transit, NSLP security is about protecting
operational aspects of the signalling application). I'm not sure it's possible
to say something which will be useful in the long term without something
more concrete to do security analysis on (e.g. we should write a good
applicability statement for a concrete NTLP, and make sure it is designed
from the start with security issues in mind rather than having them only
thought about in later stages).

My suspicion is that most security issues are intra- rather than inter-layer.
The main inter-layer point would be that because of the existence of
NSLP-unaware intermediate nodes terminating the NTLP, NTLP security is basically
pointless, at least from a purist's perspective. However, there seems to have
been fairly clear w.g. consensus up to now that we don't want to engineer the
NTLP to prevent this (FW section 3.2.1) circumstance arising, so we will just 
have to live with that.

r.

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: 22 May 2003 15:49
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] RE: Security Threats for NSIS & RSVP Security
> Properties documents 
> 
> 
> I continue to think this is an excellent document, but the
> layer split issues are sometimes not completely obvious and
> at some point in the not-too-distant future we're going to
> need to have a thorough discussion of where different
> protections need to be made available, and to what extent
> security concerns should drive certain layer split
> decisions.  Also, different types of applications will have
> different threat models and different needs (for example,
> the concerns in a discovery protocol will be different from
> the concerns in a reservation protocol).  Clearly those can
> only be properly discussed in the context of the application
> protocols themselves, but at any rate I think there may be a
> need to beef out the layer split and transport layer
> discussions.
> 
> But generally I think the document is ready for last call
> (although there may be some formatting issues in the
> references, formfeeds, etc).
> 
> Melinda
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 23 May 2003 13:07:16 +0200

hi robert, 

thank you for your comment. i agree with you that it might be very difficult
to incorporate the two layer split into the rsvp security properties
document. 

~ snip ~
> NTLP to prevent this (FW section 3.2.1) circumstance arising, 

i was always in favor to prevent this as discussed in the mailing list.
there should at least a way to provide the capability to skip certain nodes
(even rsvp has this functionality). 

for a security point of view it matters in the following case:

Node     A               B                C 
NSLP     X               Y                X & Y

assumption: all three entities belong to a different administrative domain. 

if a signaling message with nslp payload X (e.g. firewall signaling) is sent
to node B where the security of the NTLP is terminated then you have a
problem. 

if node B and node C belong to the same adm. domain then it does not really
matter (except for identity management). this functionality is actually also
provided by rsvp with the identity rep. as a end host you do not really know
which entity authenticates you (first rsvp node, pdp, etc.). 

ciao
hannes