Subject: RE: [NSIS] Reliability and Security

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 1 Oct 2003 16:31:49 +0200

hi robert, 

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

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

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?

- 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

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]]
> Sent: Tuesday, September 23, 2003 3:01 PM
> To: 'Geib, Ruediger'; Tschofenig Hannes; [email-masked]
> Subject: RE: [NSIS] Reliability and Security
> 
> 
> dear colleagues,
> 
> there is actually a really hard set of questions here. as well
> as the security and transport issues hannes mentions (of which
> my favourite is actually congestion/flow control), there is
> also a more basic point about fast-path bypassing of NSIS
> messages inside aggregation regions, which we can't ignore. 
> 
> there is also the problem of how to achieve this in the case where the
> intermediate node wants to some nearly-minimal processing on 
> some bits of the signalling message payload (e.g. address 
> translation, or some of the tricks that the RMD people want
> to play when using reservation-based PHRs).
> 
> about the only thing I am certain of here is that fw-03 is
> wrong on the matter. i have written some replacement text for
> fw-04 partially based on fw-03 section 3.2.1. it is attached 
> below. (basically it says there are some problems the NTLP
> designers will have to worry about...)
> 
> cheers,
> 
> r.
> 
> ==============================================================
> 3.x.x	Bypassing Intermediate Nodes
> 
> Because the NSIS problem includes multiple signaling
> applications, it is very likely that a particular NSLP will
> only be implemented on a subset of the NSIS-aware nodes on a
> path, as shown in Figure 5. In addition, a node inside an
> aggregation region will still wish to ignore signaling
> messages which are per-flow, even if they are for a
> signaling application which the node is able to process in
> general.
> 	
>             +------+    +------+    +------+    +------+
>             |  NE  |    |  NE  |    |  NE  |    |  NE  |
>             |+----+|    |      |    |+----+|    |+----+|
>             ||NSLP||    |      |    ||NSLP||    ||NSLP||
>             || 1  ||    |      |    || 2  ||    || 1  ||
>             |+----+|    |      |    |+----+|    |+----+|
>             |  ||  |    |      |    |      |    |  ||  |
>             |+----+|    |+----+|    |+----+|    |+----+|
>         ====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
>             |+----+|    |+----+|    |+----+|    |+----+|
>             +------+    +------+    +------+    +------+
> 
> Figure 5: Signaling with Heterogeneous NSLPs
> 
> Where signaling messages traverse such NSIS-aware
> intermediate nodes, it is desirable to process them at the
> lowest level possible (in particular, on the fastest path).
> In order to offer a non-trivial  message transfer service
> (in terms of security, reliability and so on) to the peer
> NSLP nodes, it is important that NTLP at intermediate nodes
> is as transparent as possible, that is, it carries out
> minimal processing. In addition, if intermediate nodes have
> to do slow-path processing of all NSIS messages, this
> eliminates many of the scaling benefits of aggregation,
> unless tunneling is used.
> 
> Considering first the case of messages sent with the router
> alert option, there are two complementary methods to achieve
> this bypassing of intermediate NEs:
> 
> *) At the IP layer, a set of protocol numbers can be used,
> or a range of values in the router alert option. In this
> way, messages can be marked with an implied granularity, and
> routers can choose to apply further slow-path processing
> only to configured subsets of messages. This is the method
> used in [3175] to distinguish per-flow and per-aggregate signaling.
> 
> *) The NTLP could process the message but determine that
> there was no local signaling application it was relevant to.
> At this stage, the message can be returned unchanged to the
> IP layer for normal forwarding; the intermediate NE has
> effectively chosen to be transparent to the message in question.
> 
> In both cases, the existence of the intermediate NE is
> totally hidden from the NSLP nodes. If later stages of the
> signaling use directly addressed messages (e.g. for reverse
> routing), they will not involved the intermediate NE at all,
> except perhaps as a normal router.
> 
> There may be cases where the intermediate NE would like to
> do some restricted protocol processing, for example:
> *) Translating addresses in message payloads (compare
> section 4.6.1); note this would have to be done to messages
> passing both directions through a node.
> *) Updating signaling application payloads with local status
> information (e.g. path property measurement inside a domain).
> If this can be done without fully terminating the NSIS
> protocols, this would allow a more lightweight
> implementation of the intermediate NE, and a more direct
> 'end-to-end' NTLP association between the peer NSLPs where
> the signaling application is fully processed. On the other
> hand, this is only possible with a limited class of possible
> NTLP designs, and makes it harder for the NTLP to offer a
> security service (since messages have to be partially
> protected). The feasibility of this approach will be
> evaluated during the NTLP design.
> 
> ======================================================
> 
> > -----Original Message-----
> > From: Geib, Ruediger [mailto:[email-masked]]
> > Sent: Wednesday, September 17, 2003 12:59
> > To: [email-masked]; [email-masked]
> > Subject: RE: [NSIS] Reliability and Security
> > 
> > 
> > Hello Hannes,
> > 
> > sorry, I've hit the wrong keys earlier. So I bother you again... 
> > 
> > [snip]
> > |Is 
> > |
> > |     NE 1 <NTLP-Security> NE 2 <NTLP-Security> NE 3 
> > |<NTLP-Security> NE 4
> > |
> > |the same as 
> > |      
> > |     NE 1 <NSLP-Security> NE 4
> > |?      
> > |
> > |My perception is that it is not necessarily the same, as 
> > also argued in
> > |[Han] concerning reliability.
> > 
> > I share your view, this isn't the same. And your conclusion 
> > is correct:
> > 
> > |If the working group thinks that this is not the same then 
> > it would be
> > |necessary to provide additional security between neighboring 
> > |NSLP peers. 
> > |
> > |As a consequence a discovery mechanism is needed at the NSLP 
> > |to learn the next NSLP node along the path. This is 
> necessary to be 
> > |able to secure signaling messages efficiently (i.e. using 
> symmetric 
> > |cryptography). Hence avoiding the discovery procedure at the NTLP 
> > |was not really beneficial.
> > |Without efficient mechanism it is likely that the mechanisms 
> > |would not be used at all. 
> > |
> > |Securing signaling messages at the NTLP and the NSLP might 
> > |seem to be an overkill to some people. Securing  signaling 
> messages 
> > |only at the NSLP layer does not seem to be sufficient as recently 
> > |discussed (see NSIS ML discussion [NSIS-ML]).
> > 
> > Looks as if there's no solution for having a flexible architecture 
> > combined with security across NTLP and NSLP.
> > 
> > I don't think that we must protect NSLP messages. To protect 
> > against "simple" NSLP DoS attacks then the first NTLP node would 
> > have to check whether the sender of an NTLP message is allowed 
> > to signal for a specific NSLP (given that he's allowed to 
> use NTLP). 
> > This would hold even if this NSLP isn't supported locally. Some 
> > policy communication is required then. 
> > 
> > But no matter how the solution looks like: two peering nodes 
> > shouldn't have to support completely separate security instances 
> > per NTLP/NSLP stack as a consequence of NTLP only handling messages 
> > with specific NSLPs. 
> > 
> > Regards, Rudiger
> > 
> > |4. Reference
> > |
> > |[Han] R. Hancock: "Reliability Functions in the NSIS 
> Transport Layer
> > |Protocol",  <draft-hancock-nsis-reliability-00.txt>,  (work in 
> > |progress),
> > |August 2003
> > |
> > |[NSIS-ML] IETF NSIS Mailing List, "[NSIS] ntlp security 
> > |thoughts, Date: Sun,
> > |13 Jul 2003 14:47:51 +0200",  Available at:
> > |http://www1.ietf.org/mail-archive/working-groups/nsis/current/m
> > |sg03106.html,
> > |(Sep. 2003). 
> > |
> > |
> > |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
> > 
> 
> --
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 2 Oct 2003 09:05:42 +0200

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

---

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

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

---

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

Hi Hannes, hi Robert

my clarifications on three of my remarks in line.

Regards, Rüdiger

[RG] - NTLP and NSLP have separated security mechanisms. Not very 
[RG]   nice if operators must locate errors. If possible, 
[RG]   separate instances of the same security mechanism.

[rh] i don't really see the problem here. provided the failing 
[rh] layer reports errors in a helpful way, what do you see going wrong?

[HT]i don't see this as a problem too. you have to be more specific 
[HT]here to address your concern.

Operating networks is simplified if the overall number of operational 
protocol stacks and mechanisms is minimised. It would be less desirable
if NTLP operates security protocol A, while NSLP1 operates B and 
NSLP2 C and so on.
The ideal solution is they all using the same basic security mechanism. 
Which may not be applied to full extent for NTLP, as there e.g. 
authorisation isn't required. 
 
[RG] - If you look at the example I've added below, NSLP may 
[RG]   benefit from chains of trust. Is there a smart way of 
[RG]   organising them?

[rh] i'm sorry but i didn't really follow it. the node names and 
[rh] nslp names seem to get swapped between hannes and your text?

[HT] please clarify. 

Captiol letters: nodes with the same NSLP, 
->- signaling relations:

A ->- B ->- C

for some reason, A and C may benefit from a direct signaling 
relation (if e.g. an earlier signaled "NSLP tunnel" allows 
them to administrate dedicated resources). 

A ->->- C.

B's interaction with signaling isn't required. Does NSIS allow 
for this? And if yes, how's authentication arranged between 
A and C?

[RG] - We'll have to agree which protection is required at what 
[RG]    level (I'm e.g favouring NTLP with authentication only).
[rh] if you mean 'authentication and key exchange which enables 
[rh] message protection (integrity, confidentiality) but no 
[rh] authorisation aspects' then I agree also (and this is also 
[rh] what the framework says).

I'd look at authentication and integrity as mandatory NTLP 
features. Would optional confidentiality on NTLP level be 
suitable?