Subject: [NSIS] Jari Arkko: DISCUSS: draft-ietf-nsis-ntlp

From: <[email-masked]>
Date: Fri, 15 Sep 2006 16:18:47 +0300

Here's a DISCUSS from Jari about GIST.  Robert is traveling, but it
would be good to discuss this in the WG to find out ways to address his
DISCUSS.

John 

>-----Original Message-----
>From: ext Jari Arkko [mailto:[email-masked]]
>Sent: 14 September, 2006 16:01
>To: [email-masked]
>Cc: [email-masked]; [email-masked];
>[email-masked]
>Subject: DISCUSS: draft-ietf-nsis-ntlp
>
>Discuss:
>>   Legacy NATs:  GIST messages will generally pass through NATs, but
>>   unless the NAT is GIST-aware, any addressing data carried in the
>>   payload will not be handled correctly.  There is a dual problem of
>>   whether the GIST peers either side of the boundary can work out
>>   how to address each other, and whether they can work out what
>>   translation to apply to the signaling packet payloads.  The
>>   fundamental problem is that GIST messages contain three or four
>>   interdependent addresses which all have to be consistently
>>   translated, and existing generic NAT traversal techniques such as
>>   STUN [23] or TURN [24] can process only two.  Appropriate
>>   behaviour for a GIST-aware NAT is discussed in Section 7.2.
>...
>>   GIST messages must carry packet addressing and higher layer
>>   information as payload data in order to define the flow signalled
>>   for.  (This applies to all GIST messages, regardless of
>how they are
>>   encapsulated or which direction they are travelling in.)  At an
>>   addressing boundary the data flow packets will have their headers
>>   translated; if the signaling payloads are not translated
>>   consistently, the signaling messages will refer to incorrect (and
>>   probably meaningless) flows after passing through the boundary.  In
>>   addition, GIST handshake messages carry additional addressing
>>   information about the GIST nodes themselves, and this must also be
>>   processed appropriately when traversing a NAT.
>
>I do not understand all the implications of running GIST over a 
>non-modified NAT. If the implications are benign, please explain why 
>that is the case. If they are serious, the protocol should fail 
>gracefully upon detecting a NAT. Without additional information I worry

>that the design is brittle enough that it may cause harm to the 
>senders, receivers, GIST nodes, or worse, outsiders when a GIST unaware

>NAT causes the address information to become invalid.
>
>
>

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

---

From: "Pashalidis, Andreas" <[email-masked]>
Date: Mon, 18 Sep 2006 14:15:20 +0200

Hello,

In response to the message below I would like to point out that the ID
http://tools.ietf.org/wg/nsis/draft-pashalidis-nsis-gist-legacynats-00.t
xt 
addresses (at least some of) the issues that are raised in that message.
That is, the ID contains a description of how GIST nodes can discover
the
existence of legacy NAT(s) and how to cope with them. 

Best Regards,
Andreas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Freitag, 15. September 2006 15:19
To: [email-masked]; [email-masked]
Subject: [NSIS] Jari Arkko: DISCUSS: draft-ietf-nsis-ntlp 

John

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 20 Sep 2006 16:17:58 +1000

Jari, all,

I think there is probably an issue here which can be fixed.

A little background: during the development of the spec, we have
steadfastly avoided trying to address the problem of getting NSIS
to work through legacy NATs. That's at least partly because it
seems like a nearly impossible problem, and also a major activity
even to analyse all the cases (although Andreas' draft is a very
promising approach).

However, there has been a baby/bathwater effect, in that we don't
talk about how to 'fail safely' when we encounter a legacy NAT.
Actually I think the protocol can already be implemented to do
this, but the relevant guidance is not explicit. Here is how I
always assumed it would be done, taking the path coupled MRM 
(actually the hardest one) as an example:

=================================================================

case 1: querying node on the internal side of the NAT

Here, the initial Query is sent from the flow source address, but
the NLI will contain the Querying node address. Both will be 
'private' (internal side) addresses, and usually they will be
different (S=0 in the common header). The IP source address will
be translated but not the NLI. The consequence is that the
Response will be sent to a meaningless internal address and
probably not even make it out of the node in the first place.
It certainly won't make it back to the Querying node. There
are then two subcases:

a) retransmitted Queries also have S=0. None will get replies.
Eventually the Querying node will give up and believe it is
the last GIST node on the path - which is essentially correct
behaviour.

b) some retransmitted Queries have S=1, so the Querying node
address is used as the signalling source address (this is what
the spec says SHOULD happen). Now the Responding node will 
be able to compare the NLI and IP source and see they are 
different where they should be the same. At this point it
should send an error; a good possibility is code 9 subcode
4 (untranslated object), although maybe a dedicated error
would be better. the Error will be routable towards the NAT
since it now has a valid destination address. there are then 
two further subcases:

i) the NAT is unable to forward the message (note that the
IP source address of the incoming message does not match
the IP destination of the outgoing one, so some types of 
NAT will I guess discard it). Same as case (a) above.

ii) the NAT is able to forward the message. The Querying node
will receive the error and give up immediately, so it is the
same result as case (a) but more prompt.

case 2: querying node on the external side of the NAT

here, I am not sure how much detail to go into, since the
processing depends so much on how the NAT has been configured.
But basically, if the Query gets through, the Response can
be correctly routed back through the NAT relatively easily.
However, the S flag will always be set on the Response
and the Querying node will detect that a NAT has been 
traversed and can give up again.

========================================================

This is not the whole story (there are several corner cases).
However, it would strike me as a reasonable approach. If we
cannot get the messages correctly through the NAT, the only
solution is to give up, which the above procedures do
fairly rapidly. More generally, rather than 'give up', 
the solution could be 'invoke some legacy NAT traversal
mechanism' but I think that would best be defined in separate
documents. Note also that if the MRI doesn't include addressing
information, it is actually possible to operate perfectly
through a legacy NAT following the above procedures, and that 
could also be made more explicit.

Should text along these lines be included in the draft? Is
more functionality required than this minimal level?

cheers,

robert h.

> Sent: 15 September 2006 23:19

---

From: Jari Arkko <[email-masked]>
Date: Wed, 20 Sep 2006 15:16:15 +0300

Robert Hancock wrote:

>If we
>documents.
Agreed -- I certainly do not require you to design the NAT
traversal so that this would actually WORK. All that is
needed from my perspective is the ability fail gracefully
and without causing damage to others.

But I have a question about your procedure. Does it allow
the response to be sent to the by-mistake-not-translated
address? I think it would be better if you didn't do that, and
actually detected when translation has occurred.

--Jari

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 20 Sep 2006 23:19:58 +1000

hi jari,

> actually detected when translation has occurred.

it depends on what's in your armoury of NAT detection mechanisms.
if the only method is comparison between header addresses and
addresses in the payload, then the answer is "sometimes".

what you need to do is find something in the payload which should 
match either the source or destination address. the NLI is 
guaranteed to match the source address if S=1 which is nearly 
guaranteed to be true for some Queries and all Responses. the 
only other addressing field is the MRI, which might or might not
be useful depending on the routing method; there would be
quite a lot of different cases to specify even given the
current two MRMs, and i'm pretty sure some would fail (and
we don't know what the future will bring in this area).

if we really want guaranteed NAT detection, i think the only
reasonably simple way to do it is to include a full copy of
the header in the payload. Even then we have to accept that
some messages will get sent that may not arrive, because we
have no way to know if the Error (which is useful) will
actually get back through the NAT.

this seems to me like a rather narrow tradeoff: the cost is
not that great, but neither is the benefit. i'm not sure how
to make that call.

cheers,

r.