Subject: [NSIS] Reliability and Security

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 17 Sep 2003 12:47:07 +0200

1. Introduction

During this year of work at the NSIS working group it was often argued that
the two layer split can lead to a signaling message communication as shown
in Figure 1 (see Figure 1 in [Han]). An NSIS message with "NSLP  A" content
is intercepted at nodes which do not understand the application specific
information (e.g. NE 2  which does not even implement any NSLP components or
NE 3 which implements a different NSLP). 

               +------+    +------+    +------+    +------+ 
               |  NE1 |    |  NE2 |    |  NE3 |    |  NE4 | 
               |+----+|    |      |    |+----+|    |+----+| 
               ||NSLP||    |      |    ||NSLP||    ||NSLP|| 
               || A  ||    |      |    || B  ||    || A  || 
               |+----+|    |      |    |+----+|    |+----+| 
               |  ||  |    |      |    |      |    |  ||  | 
               |+----+|    |+----+|    |+----+|    |+----+| 
           ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== 
               |+----+|    |+----+|    |+----+|    |+----+| 
               +------+    +------+    +------+    +------+ 
                                      
               Figure 1: Signaling with Heterogeneous NSLPs 

This functionality is due to a lack of a discovery procedure whereby NSLP A
messages would only be  intercepted at NE 1 and NE 4. This does not sound
like a problem at the first place although some  performance issues have
been raised. 

2. The Problem

The design decision to support such a signaling architecture leads to a
number of complications - two of  them are mentioned in this mail (possibly
there are more than those two).

a) Reliability

As discussed in [Han] it seems that the introduction of these NSLP unaware
nodes along the path together  with reliability (and other transport
protocol specific features) at the NTLP layer might not lead to  unexpected
results. It seems that some additional functionality has to be provided
between neighboring NSLP  peers. This introduces additional complexity which
is difficult to support with existing protocols. 

b) Security

While discussing the possible security mechanisms at the NTLP and the NSLP
(for different applications; QoS  and NATFW) it seems to be obvious that
signaling messages need some sort of protection. 

Securing messages at the NTLP allows to reuse existing mechanisms and to
benefit from established security  associations between neighboring NTLP (to
amotize authentication and key establishment). Similar to the  problem of
addressing reliabilty a question requestion regarding security has to be
raised: 

Is the effect of securing multiple neighboring NTLP peers the same as
providing security between  neighboring NSLPs? (The same question can be
formulated with respect to reliability.)

With relationship to Figure 1 this means: 

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. 

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

3. Conclusion

This is a short summary and an attempt to ask some members of the working
group who have an opinion on  reliability to also raise their opinion on
security issues.  

Furthermore, there is a question whether a more sophisticated discovery
mechanism (at the NTLP) should be  created to prevent or limit signaling
message effects as shown in Figure 1.

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/msg03106.html,
(Sep. 2003). 

ciao
Hannes

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 17 Sep 2003 13:31:33 +0200

Hello Hannes,

a few thoughts...

[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]).
|
|3. Conclusion
|
|This is a short summary and an attempt to ask some members of 
|the working
|group who have an opinion on  reliability to also raise their 
|opinion on
|security issues.  
|
|Furthermore, there is a question whether a more sophisticated discovery
|mechanism (at the NTLP) should be  created to prevent or limit 
|signaling
|message effects as shown in Figure 1.
|
|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
|

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 17 Sep 2003 13:59:20 +0200

Hello Hannes,

sorry, I've hit the wrong keys earlier. So I bother you again... 

[snip]
|Is 
|

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 23 Sep 2003 16:21:55 +0200

Hi Robert, 

your text-proposal is ok with me.

Regards, Rüdiger

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Wed, 24 Sep 2003 11:01:13 +0200

Hi Robert,

I like the idea of restricted protocol operation, which really allow more lightweight implementation of our applications.

Best regards, Attila

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]]
> Sent: Tuesday, September 23, 2003 3:01 PM
> To: 'Geib, Ruediger'; [email-masked]; [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  |
>             || 1  ||    |      |    || 2  ||    || 1  ||
> 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,
> >