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

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 3 Jul 2006 15:22:24 +0100

hi,

i think this topic is certainly necessary to discuss, and this
is an interesting approach.

essentially, the way i would see it is that you use a UDP tunnel
between GIST peers to traverse the dumb NAT so it can do basically
nothing to the traffic/signalling stream, and instead have proper
GIST-aware NAT functionality at the nodes either side. this sounds
architecturally neat (in so far as that phrase could be applied
to NATs...), and relatively robust.

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.

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.

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?

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.

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

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

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.

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.

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

cheers,

robert h.

> -----Original Message-----
> 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
> >>
> > 
> > 
> > _______________________________________________
> > 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: Saikat Guha <[email-masked]>
Date: Mon, 03 Jul 2006 16:11:03 +0100

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

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.

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.