Subject: Re: [Mobike] issue 34 proposal

From: "Stephane Beaulieu (stephane)" <[email-masked]>
Date: Tue, 27 Sep 2005 16:12:46 -0400

> 
>  In your previous mail you wrote:
> 
>    If no RR test (with NATD payloads) is done *before* switching, then
>    consider me opposed to this solution.
>    
> => 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, I'd
want to send an IKE packet (with NATD payloads) to the peer to make SURE
he can both recv/send packets from/to that address before I start using
it.  Yes this adds a little extra latency (1 round trip).  But this
leaves no doubt that the peer is at least reachable on that address.

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

> 
> Regards
> 
> [email-masked]
> 
> PS: BTW I believe the ESP detection is the right mechanism 
> for the implicit update of NAT-T.
> 
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Wed, 28 Sep 2005 08:52:24 +0200

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

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

=> 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-masked]>

    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