Subject: RE: [NSIS] Reliability and Security

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 23 Sep 2003 14:00:54 +0100

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
> 

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 24 Sep 2003 09:47:16 +0200

Hi Robert

I agree with your proposed text!

Best regards,
Georgios

----- Original Message -----
From: "Hancock, Robert" <[email-masked]>
To: "'Geib, Ruediger'" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, September 23, 2003 3:00 PM
Subject: RE: [NSIS] Reliability and Security