RE: [NSIS] ntlp drafts differences

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

hi hannes,

it would certainly be interesting to know why RSVP 2747 is specified
that way. (A naive assumption would be that a receiver could generate
a PathErr with the appropriate error code. I don't see how doing that
would open up new security issues compared to those that already exist,
but I haven't thought about it very hard.)

r.

> -----Original Message-----
> From: Tschofenig Hannes [mailto:[e-mail]]
> Sent: Thursday, July 31, 2003 12:19
> To: Hancock, Robert; 'Thanh Tra LUU'; Kappler Cornelia
> Cc: [e-mail]
> Subject: RE: [NSIS] ntlp drafts differences
> 
> 
> hi robert, 
> 
> thanks for pointing to this issue. 
> 
> i think that it is important to differentiate between 
> 
> a) how rsvp handles it today and 
> b) would are possible ways todo it. 
> 
> ad a)
> as described in the rsvp security properties draft, an rsvp 
> message gets
> DROPPED when cryptographic verification fails. hence there is no error
> message which would allow the previous node to discover the next hop. 
> 
> ad b) 
> it is certainly true that you can modify the path message to 
> achieve the
> desired behavior. 
> 
> with regard to standard security mechanisms it is clear that 
> ipsec cannot be
> used to protect this message. but even there you can reuse 
> existing security
> mechanisms (to some extend) to support exising authentication and key
> exchange mechanisms (as described in 
> draft-tschofenig-rsvp-doi-00.txt).
> 
> there are other implications with regard to addressing which are not
> immediately relevant for security (hence i do not describe them). 
> 
> ciao
> hannes
> 
> > -----Original Message-----
> > From: Hancock, Robert [mailto:[e-mail]]
> > Sent: Thursday, July 31, 2003 11:38 AM
> > To: Tschofenig Hannes; 'Thanh Tra LUU'; Kappler Cornelia
> > Cc: [e-mail]
> > Subject: RE: [NSIS] ntlp drafts differences
> > 
> > 
> > hi all,
> > 
> > On this security front, there seems to be a choice between
> > a) Find out (insecurely) who your downstream peer is, then send
> > them a (secured) signalling message directly.
> > b) Send a (secured) signalling message which only the right
> > downstream peer can receive correctly, and get an error message
> > if it ended up at the wrong place.
> > 
> > Are there fundamental differences in what security can be 
> > achieved between these two methods?
> > They seem to me to provide
> > equal opportunities for securing the signalling data (and for
> > getting this wrong), and equal opportunities for preventing
> > DoS attacks (and getting this wrong). The threats are the same,
> > they just apply at different stages in the message flow. 
> > Or, is there something subtle I am missing?
> > 
> > (The main difference is in when in the message sequence the 
> > reaction to a route change takes place, but I don't see this as
> > a security issue. Indeed, some people think it is a non-issue.)
> > 
> > cheers,
> > 
> > r.
> > 
> > > -----Original Message-----
> > > From: Tschofenig Hannes [mailto:[e-mail]]
> > > Sent: Tuesday, July 29, 2003 10:24
> > > To: 'Thanh Tra LUU'; Kappler Cornelia
> > > Cc: [e-mail]
> > > Subject: RE: [NSIS] ntlp drafts differences
> > > 
> > > 
> > > hi, 
> > > 
> > > ~snip~
> > > > 
> > > > > - Whether a NE know its next hop peer.
> > > > > In Melindas NTLP, the NE just knows its previous peer. 
> > The next NE
> > > > peer is discovered by a PATH-like message and 
> > subsequently addressed
> > > > implicitly.
> > > > > In Hennings NTPL, the NE may request to be informed of 
> > the next NE
> > > > peer's address.
> > > > > To my knowledge, knowing the address of the next NE peer is
> > > > necessary for channel security which we require to at least be
> > > > possible (Requirements ID 5.7.5). So to me this looks like 
> > > a necessary
> > > > feature.
> > > > >
> > > > > And that's it...!?
> > > > 
> > > > It is possible that a NE does not know the next node to send a
> > > > message. By examining the RSVP-HOP (previous hop) object 
> > > and INTEGRITY
> > > > object, a NE can know which NE has sent this message and 
> > > which key is
> > > > used (following the security association between them). 
> > > Maybe I don't
> > > > understand clearly what you mean " next NE peer is necessary for
> > > > channel security ".
> > > 
> > > 
> > > the problem occurs with rsvp path-alike messages. you send a 
> > > message and do
> > > not really know which node is actually going to intercept it.
> > > 
> > > if you know it by some means - e.g. routing table (which is 
> > already a
> > > discovery mechanism - assuming you additionally know that the 
> > > next node will
> > > be nsis aware) then you can select the proper security 
> > > association (and
> > > key). still something can go wrong and the message ends up at 
> > > the wrong node
> > > which will drop the incorrectly protected signaling message 
> > > and you will not
> > > receive an error message.
> > > 
> > > 
> > > i guess everyone will tell you that securing discovery 
> > > messages is hard. 
> > > 
> > > ~snip~
> > > 
> > > 
> > > ciao
> > > hannes
> > > 
> > > _______________________________________________
> > > nsis mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > > 
> > 
> > --
> > Registered Office: Roke Manor Research Ltd, Siemens House, 
> > Oldbury, Bracknell,
> > Berkshire. RG12 8FZ
> > 
> > The information contained in this e-mail and any attachments 
> > is confidential to
> > Roke Manor Research Ltd and must not be passed to any third 
> > party without
> > permission. This communication is for information only and 
> > shall not create or
> > change any contractual relationship.
> > 
> 

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