Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 19 Feb 2003 12:08:13 +0100

hi marcus!

please see my comment inline:

> 
> > I believe we have a roughly agreed working assumption (NB 
> no claim of an
> > official WG consensus) that the NTLP operates only between 
> adjacent NEs
> > ('hop-by-hop'), whereas any larger scope issues (including 
> e2e aspects)
> > are left to the NSLP.
> >
> 
> I wonder what this assumption implies.
> E.g., does it mean that an acknowledgment of successful state 
> setup always 
> has to travel back the reverse path?

that is not necessarily implied. 

from a practical point of view it is, however, highly suggest. if you
transmit messages from intermediate nodes along the path to the initiator
directly then they have to experience some sort of security protection. this
prevents that someone on the internet floods you with bogus messages which
trigger some action from your side. 

please take a look at "Generalized MPLS Signaling - RSVP-TE Extensions"
document. there they define a notify message which is transmitted from an
intermediate node to the end host. as described in the security section (by
steve bellovin) this requires a different security protection (ipsec is
suggested there). 

hence in practice you only have two options: 

a) you transmit notifies on a regular basis between the nodes which
justifies the ipsec establishment (which is not cheap)
b) you only transmit notifies which do not require protection (i.e. they are
unimportant - no action caused). 

ciao
hannes

  IMHO it must NOT be 
> excluded that an 
> acknowledgement directly gets back to the NSIS Initiator 
> along a potential 
> different path. (And I am aware of the security problems, and 
> reliability 
> problems of that, but I would like to see this solved 
> end-to-end as much as 
> possible.)
> 
> In general I like to see the end-to-end argument applied for 
> signaling as 
> much as possible. See more on the issue of transport functionality.
> 
> Marcus
> 
> 
> _______________________________________________
> 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: Marcus Brunner <[email-masked]>
Date: Wed, 19 Feb 2003 12:29:38 +0100

> directly then they have to experience some sort of security protection.
> this prevents that someone on the internet floods you with bogus messages
> which trigger some action from your side.

The example I have been using is not from intermediate nodes but from the 
other end (typically the NSIS responder).

> intermediate node to the end host. as described in the security section
> (by steve bellovin) this requires a different security protection (ipsec
> is suggested there).
>
> b) you only transmit notifies which do not require protection (i.e. they
> are unimportant - no action caused).

And some of us want to run the protocol in narrow scoped environments.

And typically you might already have a security association between the 
endpoints, which could be used again here.

Marcus

>> much as possible. See more on the issue of transport functionality.

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
personal home page: http://www.brubers.org/marcus