Subject: RE: [NSIS] Legacy NAT traversal for NSIS

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 4 Jul 2006 08:40:47 +0100

hi,

> -----Original Message-----
> From: Saikat Guha [mailto:[email-masked]] 
> Sent: 03 July 2006 16:11
> To: Hancock, Robert
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: [NSIS] Legacy NAT traversal for NSIS
> 
> 
> On Mon, 2006-07-03 at 15:22 +0100, Hancock, Robert wrote:
> > my biggest question about the approach is that the discussion
> > is mostly about a flow which goes through the legacy NAT in the 
> > internal->external direction (same as the initial Query for the
> > signalling). how does one handle a flow in the other direction? 
> > it's a different flow, so either one needs a technique to get the
> > Query through the NAT the other way, or to rely on the upstream 
> > encapsulation. Each has its tricky side. This has struck me in 
> > the past as the hardest part of the problem.
> 
> Are you referring to an inbound GIST flow to a NAT'ed peer that is not
> expecting it, or an inbound flow in response to an outbound flow.
> (apologies for not having enough GIST context).

both

> 
> If it is the former, i.e. an out-of-the-blue inbound GIST flow to a
> NAT'ed peer, then you would need legacy NAT traversal involving some
> sort of a rendezvous service to get that peer to know when to 
> punch open
> holes in its NAT.

yes, but that is not uncommon today. (trivial example: i run a
webserver behind my NAT and configure the NAT to forward port 80
to a particular internal address.)

> 
> If it is the latter, i.e. inbound flow in response to an 
> existing flow,
> then the NAT'ed peer may be able to receive the new flow as-is (for
> certain types of NATs), or be required punch the holes for 
> the new flow
> by using the existing flow as the rendezvous channel.

it's not so much a problem for the NAT, since the inbound/outbound
flows are almost certainly pinned to go through the same NAT (on
topology and addressing grounds). the problem is that we now have
to consider the inbound/outbound flow paths on the external side 
of the NAT, which are very likely to see different GIST nodes 
because of routing asymmetry. how does the (new) GIST node for the
inbound flow know to use an existing tunnel?

r.

> -- 
> Saikat

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

---

From: "Pashalidis, Andreas" <[email-masked]>
Date: Wed, 5 Jul 2006 16:29:30 +0200

Hello all,

Many thanks to those who provided feedback on our "legacy NAT traversal
for GIST" document.
I take it that sufficient interest exists for the document to be
submitted to the WG.

> the past as the hardest part of the problem.

Surely the problem you mention is the trickiest one. Consider this: 
For the (internal->external) direction the solution works as follows.
Signalling causes a UDP NAT binding to be installed, which is then
used to tunnel data traffic over. If the same "technique" was to
be applied in the (external->internal) direction, then we would
require that *first* there is a data flow, which (by some out-of-scope
means) has caused a NAT binding to be installed at the NAT. 
Subsequently (and only subsequently) we could use that very NAT
binding for the tunnelling of signalling traffic. In other words, the
"solution"
would only work if signalling is initiated *after* the data is already
flowing.

Of course there may be other ways to solve the (external->internal)
direction problem, but these may result in GIST to rely on some external
services (while it could very well do without them). I am not sure
whether 
or not the WG desires reliance on external services in certain
hard-to-solve
NAT traversal instances. Having said that, this may very well acceptable
if made optional.
Moreover, I am not sure whether or not it is
worth the effort to enable (external->internal) direction legacy NAT
traversal
within GIST (given that legacy NAT traversal is, by its nature, a "best 
effort" service, and a mid-term "solution" anyway).

It would be nice to know what people think regarding the above
questions. 

> some more detailed comments:

> section 2: you refer to the GIST spec for NI/NR/DS/DR but
> actually that document doesn't define or use the terms. in particular,
> I think of NI/NR as NSLP layer terminology which might not be
> appropriate here.

Thanks for pointing this out. 

> section 4 bullet 2: i don't see the need for precise matching
> of packets to interfaces. wouldn't arriving on the correct
> 'side' of the NAT be enough?

A multi-homed NAT may have multiple interfaces and "sides". A given
interface may have one or more IP addresses. A GIST peer 
should send a message B to the NAT's address (as opposed to directly to
the GIST peer
that is behind the NAT). It is therefore expected that the GIST peer
uses
the NATs IP address that it saw in a previous message A - in fact, the
document
mandates this behaviour. If the message B arrives on an interface that
is different
from the interface where A was sent from, this would probably mean that
the peer
used the wrong IP address. This should not happen, right? 

> section 4 bullet 3: strictly, GIST can indicate a possible 
> routing change in some of these circumstances (e.g. if inbound/
> outbound interfaces change, or a TTL changes). i don't think this
> changes the argument however.

Absolutely; thanks for pointing this out. I changed "Thus, under
"normal" path coupled signalling, it is not
an error condition [...]" to "Thus, under "normal" path coupled
signalling, it is not
always an error condition [...]". I hope this removes the error.

> page 7 last bullet: the phrasing of this condition might need
> to be refined if you consider the upstream query as well.

Absolutely.

> general question: how should the upstream node handle refreshing
> Queries? i guess it should generate 'normal' queries (with the 
> RAO included and not tunnelled), but then there would be
> a question of whether it should use the existing UDP source
> port or a new one (thus creating a new binding at the NAT).

This is a good question. I would say that the same NAT binding should be
used for the whole
duration of the signalling session and - for that matter - the existence

of the data flow. Switching the signalling to a new NAT binding would
also require switching the data flow to that binding (which could
break the application). (Having said that, the session ID could be used
to map refreshing queries to existing UDP tunnels.) Another
argument is that it may be undesirable that many NAT bindings exist
for a single data flow / signalling session pair.

Should the refreshing query should also be tunnelled over UDP or not?
Maybe a refreshing query should be sent exactly as the "first" query,
i.e normally.
In other words, the NAT would have to be re-discovered. However, the
downstream peer could shortcut the process by sending a RESPONSE over 
the existent messaging association, right? Re-discovering the NAT 
seems to be necessary in case a previously unknown (or rebooted) peer
identifies itself as a new downstream peer...

> page 8: i'm not sure about extending the stack proposal this
> way, but it's not a critical issue for the basic form of the
> solution.

I am not sure either. This was done in order to avoid changes to GIST
message formats.
The semantics of such a message seem unambiguous to me...

> page 9 first para: the packet analysis rules are not quite
> perfect. for example, a Query would be identified as a data
> packet, as would any GIST message if the GIST node in question
> was also the flow endpoint. however, the standard GIST rules
> should be able to cover these cases.

Right. Thanks for pointing this out, too. 

> page 9, penultimate paragraph: i think full NAT processing 
> (whatever that means) is required here, including e.g. source
> port remapping, checksum fixups and so on, not just source
> address rewriting. (consider the case of two nodes behind the
> same NAT.)

Will do. Thanks again.

Best Regards,
Andreas

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 01 July 2006 20:32
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] Legacy NAT traversal for NSIS
> 
> 
> Hi John,
> Hi Saikat,
> 
> thanks for the feedback. I definitely think that we should 
> explore the 
> usage of these protocols in context with GIST for legacy NAT 
> traversal.
> 
> Ciao
> Hannes
> 
> [email-masked] wrote:
> > Hi Saikat,
> > 
> > You're observations are right - if we want, we can run GIST over
> > any 'standard' NAT traveral mechanisms (TERADO, STUN, TURN). 
> > 
> > I think working through this would be a useful exercise.
> > 
> > John
> > 
> > 
> >>On Mon, 2006-06-19 at 15:22 +0200, Pashalidis, Andreas wrote:
> >>
> >>>Is anyone interested to make NSIS work through legacy NATs ?? (i.e.
> >>>NSIS-unaware NATs)
> >>>
> >>>Under the following link a preliminary document (in I-D format) can
> > 
> > be 
> > 
> >>>found that describes a solution approach.
> >>>
> >>
> >>http://www.tschofenig.priv.at/TEMP/draft-pashalidis-nsis-gist-legac
> >>ynats-00.
> >>
> >>>txt
> >>>
> >>>In an exremely small nutshell: the idea is to tunnel both 
> signalling 
> >>>and data traffic over a single UDP NAT binding.
> >>
> >>I haven't gone through the document throughly, but the 
> >>underlying transport you propose reminds me of TEREDO (which 
> >>is <any transport> over IPv6 over UDP over IPv4, where the UDP 
> >>over IPv4 is punched through legacy NATs with the help of 
> >>STUN/TURN/ICE etc.) One could potentially run GIST over TEREDO 
> >>and keep the signaling and data channel separate in
> >>IPv6 land even though they use the same NAT binding in IPv4 land.
> >>
> >>Alternatively, TURN (public-data-relay protocol for traversing 
> >>the worst of NATs) now has some lightweight framing 
> >>capability; the framing in TURN could potentially be extended 
> >>to carry any in-band signals including GIST. 
> >>
> >>--
> >>Saikat
> >>
> > 
> >

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 7 Jul 2006 11:32:21 +0100

hi,

below.

r.

> From: Pashalidis, Andreas [mailto:[email-masked]] 
> Sent: 05 July 2006 15:30
> To: Hancock, Robert; Hannes Tschofenig; [email-masked]
> Cc: [email-masked]

i'll try a rephrasing of my question, since i can't tell whether this
is an answer or not ;-)

consider the following case:

   Source <--> GN1 <--> NAT <--> GN2 <--> Dest

we have an application session (e.g. the VoIP call) initiated by 
Source. In your solution, you assuming GIST signalling initiated
also by Source, with the Query causing state installation at the
NAT. The tunnel then handles data (in fact, voice) packets heading
from Source to Dest.

so far, so good.

but what about the packets from the same call going from Dest to
Source? (assuming that Dest is talking back to Source, of course).
there is no reason to believe that they will be routed back 
through GN2 (routing asymmetry), so some other node will be the
GIST initiator sending a Query towards the NAT. and for the data
traffic hitting the NAT, there is no reason to believer (if it
goes through the NAT at all) that it will go through GN1.

> effort" service, and a mid-term "solution" anyway).

it is a good question. one can imagine defining an approach looking
like a classical virtual server for GIST behind the firewall, but
it rapidly starts to look like full-blown off-path signalling which
will be very hard unless strict topological assumptions are made.

> used the wrong IP address. This should not happen, right? 

sending a packet to an IP address does not guarantee that it arrives
on the interface that this IP address is bound to. that is a question
of local topology and routing protocol operation. (routers usually
advertise all their reachable prefixes which effectively includes
all their interface addresses out of all of their interfaces. 
obviously this rule is modified for NATs, but it is still quite possible
for an interface IP#1 which is bound to one interface to be advertised
as reachable via another interface.)

> identifies itself as a new downstream peer...

if you send a normal query then you still have to be careful to re-use
the existing source port (that the first query was sent from). this just
needs a bit of clarification.

normally, tunnelling queries is a really bad idea: the point of a Query
is to discover the network topology (including changes in it), and by 
tunnelling it you insulate the Query from the topology. in this case you
have basically created a static overlay, and you probably don't care 
about topology changes in the first place. so routing state refresh
times
could be long ...

> The semantics of such a message seem unambiguous to me...

what if someone later defines "rate-limited UDP" as a possible MA
protocol
for signalling but not data traffic?