Subject: RE: [NSIS] ntlp drafts differences

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 29 Jul 2003 11:23:34 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 31 Jul 2003 10:37:54 +0100

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:[email-masked]]
> Sent: Tuesday, July 29, 2003 10:24
> To: 'Thanh Tra LUU'; Kappler Cornelia
> Cc: [email-masked]
> Subject: RE: [NSIS] ntlp drafts differences
> 
> 
> hi, 
> 
> ~snip~
> >

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 31 Jul 2003 13:18:57 +0200

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

> From: Hancock, Robert [mailto:[email-masked]]
> Sent: Thursday, July 31, 2003 11:38 AM
> To: Tschofenig Hannes; 'Thanh Tra LUU'; Kappler Cornelia
> Cc: [email-masked]
> --
> 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.
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 31 Jul 2003 13:43:07 +0200

Robert

|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.

Without being a security expert:
b) would base discovery on prior topology awareness or 
error messages? If error messages would require changes on 
existing security protocols while they could remain unchanged 
to support a), the latter is my preferred choice.

Regards, Rüdiger

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 31 Jul 2003 13:15:36 +0100

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.

> Sent: Thursday, July 31, 2003 12:19
> To: Hancock, Robert; 'Thanh Tra LUU'; Kappler Cornelia
> Cc: [email-masked]