Re: issue 34 proposal

 In your previous mail you wrote:

   > => we are speaking about ESP so I don't understand the "with 
   > NATD payloads" (BTW with NATD payloads only the real source 
   > can put a fake address as they are protected).
   
   What I'm saying is that if I detect a NAT change at the ESP layer

=> how NAT-T/implicit update (ESP detection is a part of it) and
MOBIKE/explicit update can interfere is a closed point (which both
has no interest for me and does what you like).

   >    In fact, I'm beginning to think that ESP detection might cause more
   >    problems than it solves...
   >    
   > => ESP detection is in IKEv2, if you believe it you should 
   > have objected during the IKEv2 last call.
   
   I think we must be talking about different things.  I see nothing in the
   ikev2-17 that describes how NAT decisions are made using ESP packets.

=> it is at the end of 2.23 page 39:

      There are cases where a NAT box decides to remove mappings that
      are still alive (for example, the keepalive interval is too long,
      or the NAT box is rebooted). To recover in these cases, hosts that
      are not behind a NAT SHOULD send all packets (including
      retransmission packets) to the IP address and port from the last
      valid authenticated packet from the other end (i.e., dynamically
      update the address). A host behind a NAT SHOULD NOT do this
      because it opens a DoS attack possibility. Any authenticated IKE
      packet or any authenticated UDP encapsulated ESP packet can be
      used to detect that the IP address or the port has changed.

      Note that similar but probably not identical actions will likely
      be needed to make IKE work with Mobile IP, but such processing is
      not addressed by this document.

   All I see is text describing how to use ISAKMP NAT-D payloads to detect
   if a NAT box is present in the network.  The draft is rather large, so I
   may have missed it.  Can you point me to some text that describes how
   ESP pkts are used to detect a NAT, or a NAT mapping change?
   
=> now you have the text about NAT mapping change detection, including
IKE, ESP and implicit update. And in a past message in this list you
have the decision (and proposed text) about application of this in
a mixed NAT-T/MOBIKE context:
    References: <[email protected]>

    Based on discussion, it appears that most people prefer
    the following:

       1) NAT-detection payload -based NAT reboot/change detection
       as a complement to existing source address -based
       mechanisms. This mechanism would be used if MOBIKE
       is on, because otherwise MOBIKE probing would become
       harder.

       Detection would be done by including NAT detection
       payloads in dead peer detection messages.

       Existing source address -based detection is still allowed in
       limited manner:  "MUST NOT do automatic update with
       IKEv2 packets when MOBIKE is used (breaks the probing),
       but you MAY do it for ESP packets."

       2) Use IKE messages for the path testing that is needed
       in MOBIKE.

    I (Jari) have specifically left out the conclusion about whether
    to do return routability after a NAT change is detected.
    I'm hoping its covered by the policy that we already have
    for return routability usage. If people disagree about this
    we'll open a separate issue on it.

Regards

[email protected]