Subject: [IPsec] Issue #41 Interaction of MOBIKE with 'simple' IKE mobility

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Sep 2008 15:28:44 +0300

> >     o  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.
> 
> This paragraph should here point out that MOBIKE changes this behivor,
> and point to the MOBIKE documents for more information.
> 
> ===Not done, but will most likely be. Supply exact text and discuss on
> the mailing list.

New text:

   o  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 do not support other methods of recover (i.e.
      MOBIKE), and 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. When IKEv2 is used with MOBIKE,
      the dynamically updating the addresses described above,
      interfares with the MOBIKE's way of the recovering from the same
      situation, so this method MUST NOT be used when MOBIKE is used.
      See MOBIKE (RFC4555) section 3.8 for more information.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 23 Sep 2008 16:37:34 +0200

>       interfares with the MOBIKE's way of the recovering from the same

        ^^^^^^^^^^                          ^^^ 

         interfer?                          to be removed?

>       See MOBIKE (RFC4555) section 3.8 for more information.

Cheers,

a+

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Sep 2008 16:04:59 -0700

>       See MOBIKE (RFC4555) section 3.8 for more information.

This works for me. How do other MOBIKE folks feel?

--Paul Hoffman, Director
--VPN Consortium