Subject: [NSIS] GIMPS connection mode and intermediaries

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 27 Jan 2004 16:45:30 -0000

dear all,

This is the first of two mails which proposes the elimination
of some options in the GIMPS (proposed solution for NTLP) design
space; it's intended to find out if there is any objection to
removing these options (i.e. are people happy to live with the
resulting limitations on GIMPS functionality).

All of the following refers to
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-00.txt

BACKGROUND: GIMPS has a datagram ("D") mode (basically unsecured 
UDP transport) and a connection ("C") mode (which can use connection
oriented transport protocols like TCP, SCTP, DCCP and channel
security mechanisms like IPsec, TLS - details TBD). C-mode is 
supposed to be used between adjacent peers for a given signalling
application, where that signalling application needs industrial-strength 
transport or security services.

C-mode is simple and easy where there is no need to do anything
to the signalling messages between the NSLP peers; you just use
the "raw" C-mode encapsulation defined in 5.3.2 of the draft. However, 
there are some cases where "intermediaries" between the NSLP peers want
to do something to the messages, and there the situation gets 
much more messy. A description of how messy it gets is given in
the slides from Minneapolis (start at
http://www.ietf.org/proceedings/03nov/slides/nsis-1/sld10.htm)
and one possible solution is outlined in section 5.3.3 of the draft.

We'd like to head towards an alternative solution, namely banning
intermediaries in C-mode altogether.

WHY DID WE EVER WANT THEM? The concept of intermediary functionality
seems quite general, but in practice there have IIRC only ever
been two concrete applications:

a) RMD-like functions in the QoS-NSLP (you want C-mode between the
edge nodes of a network, but you want interior nodes to access
the signalling messages to update information about resource
availability by looking at per-flow messages). This was partly
in the background in the wg -00 draft (and several previous 
individual submissions).

b) Signalling through a NAT which doesn't support the NSLP in
question (the NAT wants to modify the addressing information which 
defines what flow is being signalled for, but doesn't want to
modify or even understand any of the other information; see
further discussion in section 5.3 of
http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txts 
and 4.5, 4.6 of 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-00.txt
and to a lesser extent
http://www.ietf.org/internet-drafts/draft-aoun-nsis-nslp-natfw-migration-00.txt)

WHAT COULD WE DO INSTEAD? 

(a) Our sources in the QoS-NSLP activity suggest that the favoured
approach is now to use separate sessions for the direct edge-edge 
signalling and edge-interior-edge signalling. The first would be
simple C-mode and the second in D-mode. The edge nodes would have
to correlate the two (but this is true in any aggregation-like
scenario).
==> we don't need to worry about (a) any more.

(b) For the NAT case, rather than translating the content of C-mode
messages as they go backwards and forwards through the NAT, we 
should require that the GIMPS instances in the NSLP peers discover
during initial message exchanges that a NAT is present and what
it will do to packet headers; GIMPS then includes the pre- and
post-translation flow-ids in C-mode messages, invisibly for the NAT.

Host A ---- NSLP ------- NAT ------- NSLP ----- Host B
            NTLP                     NTLP
             NE1                      NE2

C mode messages from NE1 to NE2 would say, at the GIMPS level, "this
is a message about a flow which I see as being defined by flow-id-1
but you see as being about flow-id-2". This approach was mentioned 
in the past at various meetings and is also hinted at in the NATFW 
drafts, but has not been intensively discussed.
[Note: for the purpose of this discussion, it doesn't really matter
if the NAT is GIMPS aware or not. Either way, we are saying that 
once GIMPS discovery is complete and C-mode is being used, the NAT 
has nothing to do with the payloads of signalling messages.]

[We do need to do more thinking about how GIMPS works out how the
NAT is there and what it is doing, but that seems unavoidable in 
any approach and also seems soluble.]

==> if we go this way, we don't need to care about (b) either

==> overall we can allow ourselves to restrict the required GIMPS
functionality to the 'no intermediaries' case.

Comments welcome,

robert h.

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 27 Jan 2004 18:24:18 +0100

Hi Robert

Please note that the concept of intermediary functionality
is also needed in all scenarios that use the
RSVP aggregation concept, where edges (i.e., Aggregators/Deaggregators) and
interior (intermediate) nodes are used.  In particular the interior nodes
must
not process the E2E RSVP messages. Thus these interior nodes have to be
bypassed.

Therefore, in addition to the binding functionality we also need to have
something similar to the RSVP_E2E_IGNORE  (RFC3175) functionality.

Best Regards,
Georgios

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 29 Jan 2004 09:40:33 +0100

Robert,

The NAT case is flawed and there is a third case for intermediaries. See 
inline.

[...]

Case c) is the use of intermediaries due to scalability problems of the 
C-mode. This specifically holds for NAT FW NSLP, but also for other sparsly 
deployed NSLPs.

In the NAT/firewall NSLP case with C-mode we would realistically end-up 
with one connection per flow. This is because in most realistic cases at 
the beginning and the end of a path some NATs and firewalls are sitting, 
but non  in the middle of the Internet. So assuming that each flow 
originating at one place is very diverse in which direction it goes, there 
is basically a C-mode NTLP connection per-flow. Plain GIMPS nodes would 
help with this problem.

> has nothing to do with the payloads of signalling messages.]

this does not work.

If the NAT is NTLP unaware it will naturally change the IP address and 
potentially even the port numbers of the transport protocol used between 
the NTLP peers. So it allows to get NTLP signaling through. The other end 
would most likely be able to detect that there is a NAT, if NTLP has 
information about it last peer included. But the change of the flow-id 
(data stream we are signalling for) is unpredictable.

And it does matter whether the NAT is GIMPS aware or not.

I see 2 solutions
1) we forget that GIMPS is carrying flow-information. This implies that NAT 
must be NSLP away and you can avoid the intermediaries.

2) we keep NAT intermediaries (probably when the functionality is focused 
to NATs only, this might help to get a less complex solution, because you 
do not need to think about general intermediaries.

Marcus

---

From: "Sung Hyuck Lee" <[email-masked]>
Date: Thu, 29 Jan 2004 18:16:25 +0900

Dear all,

We submitted the following draft concerning mobility-related issues in NSIS:

http://www.ietf.org/internet-drafts/draft-manyfolks-signaling-protocol-mobility-00.txt

The goals of this draft are to analyze the effects of mobility in NTLP/NSLP 
and give some guidelines about how to tackle  various issues caused by 
mobility (as well as generic route change) in the Internet signaling protocols.  

This draft discussed the following issues in NTLP/NSLP layers:

   - analysis of various mobility scenarios in NSIS signaling and statement
     problems
   - Crossover node discovery and Path update caused by mobility and 
     route change
   - Dead peer discovery
   - Case examples of NSIS signaling according to handover cases
   - Interaction with mobility signalings (e.g., HMIPv6, FMIPv6, CARD, and CTP)
   - Uni- and bi-directional state establishment, State Management, and
     State establishment in network mobility as additional issues
   - Security considerations in various scenarios such as MN as sender/receiver,     
     multihoming scenarios, using context transfer, proxy scenario, and AAA.

There are also some issues which need to be discussed in the next version 

   - Multihoming related issues
   - Both End-Hosts are Mobile 
   - Split of NSIS functionality
   - Open questions in each section

 All comments are welcome

Regards,

Sung-Hyuck

	ìŠÉšŠX§‚X¬¶{"²'~Šà†Ûi³ÿðÃ
bz×è®æj)fjåŠËbú?žÈ¬