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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 29 Jan 2004 09:58:07 -0000

hi marcus,

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: Thursday, January 29, 2004 08:41
> 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. 

i think the strictly correct statement is 'one C mode connection
per pair of communicating middleboxes'. if the Internet traffic is 
dominated by e.g. people running kazaa behind NATting-ADSL routers
I agree this would end up as one C mode/flow; N communications
between two corporate sites would probably need only one C mode
connection.

of course, the scalability issue is one we always have to worry
about. my naive instinct is that the first case will apply mainly
to little NATs, and big NATs are mainly covered by the second,
but the dial-access (or mobile access) cases are probably hard.

in any case, the underlying question is whether the state 
involved in a C mode connection is much more, much less, or
about the same as required to manage the NAT processing for 
that flow itself. do you think it could be more?

> Plain GIMPS 
> nodes would 
> help with this problem.

could you elaborate?

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

true (for C and D mode, and true regardless of whether the
NAT is NTLP aware or not).

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

probably true (certainly true in C mode; whether or not it is
true in D mode depends on the source addressing used - see
open issue 3 section 8.3 of the GIMPS draft and provide comments...)

> But the change of 
> the flow-id 
> (data stream we are signalling for) is unpredictable.

this is not my assumption. in a sane world
*) a GIMPS unaware NAT should not change the flow ID at all,
since it is just payload data.
[i am aware of NATs which look for things like IP addresses
in arbitrary payloads and attempt to rewrite them; I regard
being broken by such a NAT as a feature, not a bug ;-).]
but then the next GIMPS peer should detect the presence of
the NAT (see above) and then try to work out what to do about
it (as discussed a bit in Cedric's document).

*) a GIMPS aware NAT should change the flow ID in a way to
be defined by the GIMPS spec, for which at the moment I
see several possibilities:
 - use existing bindings if they apply to that flow
 - if there is no applicable existing binding, create one, or
 - if there is no applicable existing binding, return an error
   to the peer (this would be one of a large class of "I couldn't
   handle that flow ID errors")

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

it matters to the GIMPS D mode implementation. it should not
matter to the overall function split between C and D mode,
and it should not matter to NSLPs.

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

this is one solution. but it means that every NAT must be
aware of every NSLP, which strikes me as a huge deployment
issue for new NSLPs.

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

the solution might be less complex to describe, but the
bad implications for C mode functionality are just as severe.

r.

> Marcus

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

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 29 Jan 2004 16:19:00 +0100

> but the dial-access (or mobile access) cases are probably hard.

I don't see the problem with the home networking, because they do not have 
that many connections running. So it really almost end-to-end. I see the 
problem more in the number of c-mode endpoints on a NAT for lets say a big 
company network, where the NAT is handling a high number of communications 
with different partner -> different NATs. Or the GPRS networks (where many 
run NATs) and having a large number of flows.

> that flow itself. do you think it could be more?

I assume this depends on the used c-mode transport protocol, so for example 
TCP end-point state. For the NAT typically not the state but the fast 
search in the state tables is the problem.

> could you elaborate?

If there are GIMPS-aware nodes in the network, the chances are higher that 
you can reuse the GIMPS transport protocol for parts of the signaling path.
[...]

> it (as discussed a bit in Cedric's document).

yes. Does GIMPS keep the previous nodes IP address in its payload?

>  - if there is no applicable existing binding, create one, or

This one of these 2 actions are performed in the NAT/FW NSLP spec 00 (no 
problem to move them to NTLP

> and it should not matter to NSLPs.

Sure, I was not referring to any d-mode at all in that mail.
D-mode might be a prblem anyway when you run an "intelligent" NAT.

Marcus