Subject: RE: [NSIS] Reliability and Security

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 6 Oct 2003 09:02:28 +0200

Hi Hannes,

if I understood you right, here you address the 
issue of adjacent NTLP nodes both supporting the 
same NSLP. It would of course be great if in 
this case NSLP would not need to run security 
features already provided by NTLP.

This requires NTLP to be aware of NSLP adjacencies 
and required protection as you describe. 

If this doesn't require complicated specification, 
it may be a useful feature.

Regards, Rüdiger

|-----Original Message-----
|From: Hannes Tschofenig [mailto:[email-masked]]
|Sent: Friday, October 03, 2003 6:14 PM
|To: Geib, Rüdiger
|Cc: [email-masked]
|Subject: RE: [NSIS] Reliability and Security
|
|
|hi ruediger, 
|
|thank you for your reponse. 
| 
|i see two basic approaches: 
| 
|a) the ntlp does not contain a discovery procedure which 
|allows to learn the next ntlp node which supports nslp X. 
| 
|b) the ntlp supports such a discover procedure. 
| 
|in case (a) you can never be sure that a node implementing 
|nslp X has access to authentication information (since 
|another nslp could be somewhere in the middle). in this case 
|you would have to do a discovery at the nslp layer to learn 
|the next nslp aware node to (possibly) secure nslp messages 
|between these two nodes (if necessary). 
|
|in case of (b) you would know that the next node you are 
|addressing is actually a node which supports nslp X. 
|
|from a security point of view i have the following impression: 
| 
|- you need to provide some security at the ntlp layer. 
|- you need to provide some security at the nslp layer
|at the nslp additional security protection should be done 
|only for certain objects if there is a good reason (e.g. some 
|reasons have been described in the nat/firewall case). 
|- but if you have a configuration like the one described in 
|figure 1 then you might not want to secure messages at the 
|ntlp and at the nslp (particularly if this is the default 
|signaling case).
|i am not saying that performance should  be considered first 
|but it should
|also be considered. 
| 
|        +------+                            +------+
|        |  NE  |                            |  NE  |
|        |+----+|                            |+----+|
|        ||NSLP||       NSLP Security        ||NSLP||
|        || 1  || - - - - - - - - - - - - -  || 1  ||
|        |+----+|                            |+----+|
|        |  ||  |                            |  ||  |
|        |+----+|       NTLP Security        |+----+|
|    ====||NTLP||============================||NTLP||====
|        |+----+|                            |+----+|
|        +------+                            +------+
|               figure 1: nslp & ntlp security
|
|thanks again, ruediger, for pointing to the issues. i will 
|try to write a short summary on the different options we have. 
| 
|ciao
|hannes
|> 
| 
|> > 
|> > Hannes,
|> > 
|> > 
|> > What are the options we have?
|> > 
|> > - NTLP and NSLP security are combined. This would result 
|> >   in chains of trust. Complex.
|> > - NTLP has no security, security is done by NSLP. Bad idea, 
|> >   DoS attacks should be inhibited at the lowest possible 
|> >   level.
|> > - NTLP and NSLP have separated security mechanisms. Not very 
|> >   nice if operators must locate errors. If possible, 
|> >   separate instances of the same security mechanism.
|> > - If you look at the example I've added below, NSLP may 
|> >   benefit from chains of trust. Is there a smart way of 
|> >   organising them?
|> > - We'll have to agree which protection is required at what 
|> >   level (I'm e.g favouring NTLP with authentication only).
|> > - There may be more options. Let's try to classify solutions 
|> >   in terms of security, complexity and scaleability.
|> > 
|> > The WG must take decisions and opinions will be split.
|> > But I think it's time to make some progress on the security 
|> > issue.
|> > 
|> > Regards, Rüdiger
|> > 
|> > 
|> > |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?
|> > 
|> > wouldn't your example have to be extended to nodes X,
|> > Y and Z all support NSLP A and peer in the order shown.
|> > The are separated by an unknown number of NTLP hops. In 
|> > some cases, it may be desireable for NSLP Z to directly 
|> > signal to NSLP X.
|> > 
|> > |- at which layer are messages protected? (ntlp/nslp)
|> > |
|> > |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.
|> > |
|> > |ciao
|> > |hannes
|> > 
|> > _______________________________________________
|> > 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: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 19 Oct 2003 12:26:22 +0200

hi ruediger, 

sorry for the late resonse. 

> features already provided by NTLP.

you are fully right with your observation. i argue that this is the default
case at 
trust boundaries. typically would you place a firewall at a trust boundary
and the 
same is true for qos nodes (they first nodes start the edge and not in the
middle of 
the network). 

based on rsvp and the two security mechanisms offered there (rsvp integrity
object and the user identity representation) i observed that it is very
useful to combine the two mechanisms e.g. windows 2000 uses kerberos for
user identity representation (inside the 
policy_data object and reuses the key for the integrity object. this make
simply sense. 

> it may be a useful feature.

ciao
hannes

> |> > Y and Z all support NSLP A and peer in the order shown. The are 
> |> > separated by an unknown number of NTLP hops. In some 
> cases, it may 
> |> > be desireable for NSLP Z to directly signal to NSLP X.
> |> > 
> |> > |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.
> |> > |
> |> > |ciao
> |> > |hannes
> |> >