RE: [NSIS] ntlp drafts differences

[Tschofenig Hannes <[e-mail]>]

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