Subject: RE: [NSIS] GIMPS connection mode and intermediaries

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 28 Jan 2004 09:30:18 +0100

Robert,

|==> overall we can allow ourselves to restrict the required GIMPS
|functionality to the 'no intermediaries' case [RG: for "C" mode"].

Yes, that's a reasonable conclusion.

Regards, Rüdiger

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

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Wed, 28 Jan 2004 11:19:37 +0100

Hi Robert,

I think in case of a) it is not an issue. We are considering to use two kind of signaling in a stateless domain: edge-to-edge, probably in 'C' mode, and intradomain signaling in 'D' mode. I think the first one is not needed to intercept.

In connection with intermediaries, my question is if GIMPS supports a routing alert functions with which a QSpec can be reached fast, without going through all protocol stacks. (Thinking of first of all of our RMD-like NTLP stateless operation.)

Best regards, Attila

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Hancock, Robert
> Sent: Tuesday, January 27, 2004 5:46 PM
> To: Nsis (E-mail)
> Subject: [NSIS] GIMPS connection mode and intermediaries
> 
> 
> 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.

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 29 Jan 2004 10:22:14 +0100

hi all,
 
a small clarification to avoid confusion: in the intermediary discussion
there was often the question whether a nat/firewall nslp (or other nslps)
could reuse existing infrastructure by utilizing NTLPs along the paths (even
if they do not support the desired NSLP).

this might have the advantage of reusing existing security associations and
transport layer connections. the disadvantage is that you have the known
problems with intermediaries (reliability), you might need additional
security mechanisms between nslps (over a number of ntlp hops) and
additional latency issues. 

figure 1 tries to describe the two options graphically: 

 Host A                                   NAT Box
Host B
 NAT/FW -- NSLP X ---- QoS NSLP ------- NAT/FW NSLP ------- QoS NSLP -----
NAT/FW
 NSLP       NTL         NTLP            NTLP                NTLP
NSLP 
 NTLP       NE1         NE2             NE3                 NE4
NE5

Figure 1: Signaling message flow

if we want to signal an NSLP (e.g., NAT/FW) which is sparsely distributed
along the path (i.e., only a few devices are NATs/Firewalls compared to QoS
NSLP - hopefully) then there are two possible cases: 

a) skip NSLPs which do not implement the desired NSLP (in our example the
end host is interested in signaling a NAT/FW NSLP)
(possible improvement to get rid of the nasty intermediaries)

for figure 1 this would mean that Host A addresses the message to NE 3 (the
nat box). discovery would have to skip NE 1 and NE 2 since they have nothing
todo with nat/firewall signaling. 

b) incept and process signaling message at every intermediate node 
(current proposal in the gimps draft)

for figure 1 this would mean that the message is addressed towards NE 1,
again processed by NE 2 and finally by NE 3 which is the NAT box and so on. 

if you establish, for example, a tcp connection between neighboring nodes
(NE 2 and NE 3) then you can certainly reuse more transport layer
connections (and security associations) than in case (a) where you establish
a new transport layer connection between end hosts (e.g., Host A) and NE 3. 

ciao
hannes

> From: Marcus Brunner [mailto:[email-masked]]
> Sent: Thursday, January 29, 2004 9:41 AM
> To: Hancock, Robert; Nsis (E-mail)
> Subject: Re: [NSIS] GIMPS connection mode and intermediaries
> 
> 
> 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.
> 
> 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: "Hancock, Robert" <[email-masked]>
Date: Thu, 29 Jan 2004 14:52:51 -0000

hi all,

a clarification to the clarification:

> From: Tschofenig Hannes [mailto:[email-masked]]

> figure 1 tries to describe the two options graphically: 
[slightly redrawn to avoid line breaks]

> 
>  Host A                      NAT Box              Host B
>  NAT/FW--NSLP X--QoS NSLP--NAT/FW NSLP--QoS NSLP--NAT/FW
>  NSLP     NTL     NTLP      NTLP          NTLP     NSLP 
>  NTLP     NE1     NE2       NE3           NE4      NE5
> 
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

not really? see below

> again processed by NE 2 and finally by NE 3 which is the NAT 

what (i hope) actually happens (in the current draft) is that 
*any* D mode message from Host-A is given the destination address 
of NE5. In D mode, messages are never addressed to NE1 or NE3.

all these messages will be seen (to some extent) at the GIMPS layer
of all intermediate nodes (although 'seen' may mean no more
than 'is ignored by the RAO processing rules which GIMPS has
configured locally'.)

which address Host A later knows (e.g. for a C mode connection)
is *entirely* dependent on how much e.g. NE1 or NE2 decide they
want to take part in the signalling for that flow and signalling
application. both scenarios (a) and (b) are possible; in fact,
I would say (a) is more likely than (b), but what actually happens
is determined by policy.

> a new transport layer connection between end hosts (e.g., 

this is quite true. whether this is a good idea depends 
strongly on a more detailed scalability analysis (see
previous email to marcus). there are architectural objections
to doing this so we need some way to balance this against
any scalability gain.

cheers,

r.