--------------------

Lakshminath Dondeti (2005-07-08)

  replies with "HDR(A,0), N(NAT_PREVENTED)" and does not create any
  state.

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

--------------------

Mohan Parthasarathy (2005-07-11):

- Section 2.7 - NAT Prevention stuff..
       This specification addresses the issue as follows.  When an IPsec SA
        is created, the tunnel header IP addresses (and port if doing UDP
        encapsulation) are taken from the IKE_SA, not the message IP header.
        The NAT_PREVENTION payload is used to guarantee that NATs have not
        modified the address used in IKE_SA.  However, all response messages
        are still sent to the address and port the corresponding request came
        from.  

  If we are reached the stage of creating the IPsec SA and we have used NAT_
  PREVENTION, the IP header and value carried in the NAT_PREVENTION
  payload is same. So, just taking from the IP header should be fine. Is this
  talking about not updating from the IP header of the IPsec packets (as
  required by standard NAT-T) in general ?   

--------------------

Pasi Eronen (2005-07-12):

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?

--------------------

Andreas Pashalidis (2005-07-12):

Regarding the naming of labels.
IMHO, one cannot "prevent" a NAT (from being on a path).
What one can do is *detect* the presence of a NAT, and,
then, possibly *avoid* it (or, more precisely, avoid the
continuation of the session).

In terms of policies, one cannot have a policy that "prevents"
NATs (from being present on a path). Instead, one can have 
a policy that mandates the *avoidance* of paths on which
NATs have been detected.

I believe that naming the labels using the above terms 
is more intuitive than using the term "prevention".

--------------------

Lakshminath Dondeti (2005-07-12):

+++++++++
Or NO_NAT_POLICY and NAT_POLICY_ERROR?

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

--------------------

Tero Kivinen (2005-07-13):

> that contain NATs. If the responder notices that a NAT is
> 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 :-)

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

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

--------------------

Bill Sommerfeld (2005-07-14):

How about "NAT_DETECTED" or "UNEXPECTED_NAT_DETECTED" ?

--------------------

Jari Arkko (2005-07-30):

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?

--------------------

IETF63 MOBIKE WG minutes:

24 NAT prevention needs clarification and a better name
   
   Jari A.: Let's make some progress here by coming with some
   decisions and we can get those confirmed on the list.
             
   Francis D: dependency on 22

--------------------

Jari Arkko (2005-08-23):

Issue 24: This is a duplicate of issue 22.

--------------------

(Issue list editor's note: See also issue 22 for discussion about
this topic.)

--------------------

Shinta Sugimoto (2005-08-30):

- Section 2.7 (NAT prevention), I also felt that better naming is
  needed for NAT_PREVENTED. Taking look at issue #24, I tend to agree
  that NAT_PREVENTED should be replaced with something like
  NAT_PREVENTION_FAILURE from which one can easily understand
  that it's an erroneous state (or failure case).

--------------------