Subject: [Mobike] Issue 24: NAT prevention details (was: Review of draft-ietf-mobike-protocol-00)

From: <[email-masked]>
Date: Tue, 12 Jul 2005 13:01:53 +0300

Lakshminath Dondeti wrote:
> 
> <LD> The labels NAT_PREVENTION, NAT_PREVENTED are confusing.
> For a little while I thought they are the same, but realize
> they are different.  NAT_PREVENTION seem to mean that the
> sender is guaranteeing/indicating that there is no NAT.
> Perhaps, NAT_NOTSUPPORTED or NAT_ABSENT or something like that
> might be more appropriate.  Instead of NAT_PREVENTED,
> NAT_PRESENT or NAT_DETECTED might be more appropriate.  The
> Initiator then can compare its claim from its state that
> NAT_ABSENT against NAT_PRESENT to detect that its claim is
> incorrect.  </LD>

Hmm... here the sender of the NAT_PREVENTION payload (initiator)
is informing the responder that its policy is not to use paths
that contain NATs. If the responder notices that a NAT is
present anyway, the request fails with error code NAT_PREVENTED.

But maybe we could figure out better names for these payloads.
How about "NAT_PREVENTION_FAILURE" instead of "NAT_PREVENTED"?
It would perhaps tell more clearly that it's an error
indiciation?

Or NO_NAT_POLICY and NAT_POLICY_ERROR?

Best regarts,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 12 Jul 2005 11:06:19 -0400

+++++++++

Best regarts,
Pasi
++++++++++

The above suggestions sound more intuitive.  The sender is trying to establish/enforce its local policy of NO_NATs in the way and the receiver helps by saying I detected none, or there was a NAT and therefore your policy cannot be supported.

We might wait a little to see if others might have suggestions too (Andreas had some thoughts).

thanks,
Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Jul 2005 11:25:28 +0300

> present anyway, the request fails with error code NAT_PREVENTED.

NAT_PREVENTED would say that you somehow managed to get rid of the
NAT... If you can get that one working in a way, that it will actually
remove the physical NAT, som people would be more than happy :-)

> It would perhaps tell more clearly that it's an error

NAT_PREVENTION_FAILURE indicates that you failed to prevent nat... 

> Or NO_NAT_POLICY and NAT_POLICY_ERROR?

Hmm... NO_NAT_BY_POLICY or something like that could be possible...
but perhaps having word POLICY there is too dangerous...
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 14 Jul 2005 16:41:20 -0400

On Wed, 2005-07-13 at 04:25, Tero Kivinen wrote:
> NAT... 
How about "NAT_DETECTED" or "UNEXPECTED_NAT_DETECTED" ?

						- Bill

---

From: Jari Arkko <[email-masked]>
Date: Sat, 30 Jul 2005 18:06:28 +0300

I agree that the naming needs to change. Maybe

initiator -------------DISALLOW_NAT------------------------------->
              <-----------UNEXPECTED_NAT_DETECTED-------responder

I'm also wondering about this text in Section 2.7:

   If the values do match, the responder initializes (local_address,
   local_port, peer_address, peer_port) in the to-be-created IKE_SA with
   values from the IP header.  The same applies if neither
   NAT_PREVENTION nor NAT_DETECTION_*_IP payloads were included, or if
   the responder does not support NAT Traversal.

which would seem to indicate that if you don't include any
NAT-D payloads you get NAT-prevention by default... perhaps
this would be the right way to signal DISALLOW_NAT -- but
how would you do the comparison then?

--Jari