Subject: RE: [NSIS] Reliability and Security

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 2 Oct 2003 19:11:04 +0100

hi hannes,

> -----Original Message-----
> From: Tschofenig Hannes [mailto:[email-masked]]

> sorry for the late reply - i had to rejoin the army (=> no 
> wlan coverage in
> the austrian mountains :-)). 

so we shall maybe see some more firepower applied to the NSIS
security issues ;-)

> 
> thank you for your response. i also like your text but it does not
> completely address my issues. i know that there are several ways to
> implement the "Bypassing Intermediate Nodes" procedure. an 
> interesting draft
> by bob lindell and bob braden have already discussed these 
> issues some time
> ago (see draft-lindell-waypoint-00.txt). ping pan addressed 
> the performance
> implications in his work (e.g. see 
> <draft-pan-nsis-rsvp-transport-01.txt>). 

i think there is a fairly well defined question about how to enforce
'complete' bypass for e2e addressed packets while still using fast-path 
processing. my assumption at the moment is that if this is wanted, 
then something based on Router Alert is the right way to go - provided
the values in the option field are sensible assigned, RA is very simple
to process and there doesn't seem to be a good alternative (as you 
know, I don't like using the TTL as a scoping mechanism). i don't believe
there are specific security issues here.

> 
> for security (and in particular for security association 
> establishment) the
> following issues are of importance: 
> 
> - node A has to learn that a security association has to be 
> established to
> some node C. 
> node A and C support NSLP X; node B only NSLP Y
> how and when is this information obtained?

my view here is that - provided the packet is marked
in such a way that NSLP B can tell by packet inspection
that it has no interest - then this situation between
A and C should be handled as though node B was not there
at all, i.e. it should take no part at all in the signalling
exchange. how A and C negotiate their relationship is of course
open, but adding B doesn't make it a different question.

> 
> - at which layer are messages protected? (ntlp/nslp)

i believe that the NTLP should offer a channel security
mechanism supporting confidentiality, integrity etc. 
and allowing the re-use of standard mutual authentication
between A and C. whether the NSLP chooses to depend on this
or do something extra/instead is up to the NSLP designers.

the hard problem arises where we would like node B to do 
something to the message but not to have complete access to
it (e.g. to translate addresses or to mutate a measurement
field). one way to do this would be for the NTLP channel security
mechanism between A and C to protect only some of the payload. 
i think anything more complex than that will be over-complex; in
particular, if you want different levels of protection for different
parts of the message then nodes A, B and C will all have to implement
the NSLP and the NSLP will have to define the different protection
levels beyond what can be done by the NTLP.

> 
> we have seen a number of protocol proposals in the past. 
> there it can easily
> be seen that differences exist which have an impact on security. it is
> important to make the default mode of operation very clear 
> and precise.

quite true.

r.

> ciao
> hannes

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 3 Oct 2003 18:31:03 +0200

hi robert, 

thanks for your comments.

> so we shall maybe see some more firepower applied to the NSIS 

i have never seen it that way? 

> interesting 
> > draft by bob lindell and bob braden have already discussed these
> > issues some time
> i think there is a fairly well defined question about how to 
> enforce 'complete' bypass for e2e addressed packets while 
> still using fast-path 
> then something based on Router Alert is the right way to go - 
> provided the values in the option field are sensible 
> assigned, RA is very simple to process and there doesn't seem 
> to be a good alternative (as you 
> know, I don't like using the TTL as a scoping mechanism). i 
> don't believe there are specific security issues here.

i agree that the router alert option is a good choice. with regard to the
discovery there is still some degree of freedom here. 

> exchange. how A and C negotiate their relationship is of 
> course open, but adding B doesn't make it a different question.

this mechanism can be provided by a separate discovery mechanism. i don't
know what the status of the current ntlp discussions with regard to the
path-coupled discovery is. 

> or do something extra/instead is up to the NSLP designers.

this answeres a question to you in a previous mail. 

> field). one way to do this would be for the NTLP channel 
> security mechanism between A and C to protect only some of 
> the payload. 

this is one possibility. another one would be to treat this node as a node
with a virtual nslp implementation (which effectively does nothing except
for changing the fields). 

with some security mechanisms (such as ipsec or tls) you cannot skip an
intermediate node. 

if you have nslp implementation X on node A and C then you need to address
these nodes directly - without an intermediate node B. i am not saying that
we should tailor our solution to support these protocols. i rather would
like to point to the security implications to this design decision. 

> i think anything more complex than that will be over-complex; 
> in particular, if you want different levels of protection for 
> different parts of the message then nodes A, B and C will all 
> have to implement the NSLP and the NSLP will have to define 
> the different protection levels beyond what can be done by the NTLP.
> 
> > 

ciao
hannes

> r.
> 
> > 
> > ciao
> > hannes
> 
> --
> 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: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 7 Oct 2003 10:06:53 +0200

Hi Hannes and Robert

Please see some comments in line
> discovery there is still some degree of freedom here.

Georgios>> Router alert option is a good choice but for the moment I think
that
it should be seen as one of the possible options. Probably, there are also
other options
 that could be used.
Therefore, for the time being I would appreciate to let it open.

> path-coupled discovery is.

Georgios>> I think that in many situations this can be done by network
configuration.
For example, a domain administrator can configure a node as an interior node
that
should operate as your node B.

> this answeres a question to you in a previous mail.

Georgios>> We have to discuss more on this issue.

> > > important to make the default mode of operation very clear

Georgios>> I also agree!

Best regards,
Georgios