Subject: [Mobike] issue 34 proposal

From: Jari Arkko <[email-masked]>
Date: Wed, 07 Sep 2005 13:05:18 +0300

This is a suggestion for a potential resolution of issue 34.
First, it seems that issue 34 is really about two separate
problems:

   Part a: How do we survive NAT reboots? ESP vs. IKE update?
   Part b: Do we have a separate path test message or not?

For part a, we have discussed probing frequencies and hardware
issues. List discussion on the probing seems to converge to
the conclusion that IKE-based messages for this purpose would
be OK. I'm not sure if we have come to any conclusion on the
hardware/implementation problem issues: There's a difference
where IKE-based messaging does not need hardware support
for ESP address changes. On the other hand we're not quite
sure if lack of hardware support is an issue for the ESP-based
approach either -- hardware evolves while deployment of new
features is ongoing. And as we are talking about a special case
to begin with, it may not be critical to have this support in
all devices at all times.

For part b, we have discussed whether the separate message
is easier to describe or not, and whether the separate message
can be sent in cases where additional IKE messages would have
to be delayed due to the usual IKE processing rules (e.g., when
connectivity breaks during an already ongoing movement operation).
In the latter discussion, it seems that we came to the conclusion
that if this happens, the worst that can happen is delay of
one roundtrip.

Based on the above I'd like to suggest that we pick
IKE based messages for NAT reboot/change detection,
and IKE messages for the path testing. Comments?

I asked Pasi to write some text for this, see below.

2.X Changes in NAT Mappings

   IKEv2 performs Dead Peer Detection (DPD) if there has recently been
   only outgoing traffic on all of the SAs associated with the IKE_SA.

   In MOBIKE, these messages can also be used to detect if NAT
   mappings have changed (for example, if the keepalive internal is
   too long, or the NAT box is rebooted).  More specifically, if both
   peers support both this specification and NAT Traversal,
   NAT_DETECTION_*_IP payloads MAY be included in any INFORMATIONAL
   request; if the request includes them, the responder MUST also
   include them in the response (but no other action is taken, unless
   otherwise specified).

   When the original initiator is behind a NAT, it SHOULD include
   these payloads in DPD messages, and compare the received
   NAT_DETECTION_DESTINATION_IP payload with the value from the
   previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT
   response).  If the values do not match, the IP address and/or port
   seen by the responder has changed, and the initiator SHOULD send
   UPDATE_SA_ADDRESSES as described in Section 2.3.

   When MOBIKE is in use, the host not behind a NAT SHOULD NOT use the
   dynamic updates specified in [IKEv2] Section 2.23 (where the peer
   address and port is updated from the last valid authenticated
   packet).  This ensures that both peers have a consistent view of
   when addresses are to be changed, and prevents conflicts between
   MOBIKE-originated updates and NAT-T dynamic updates.  It also means
   that an INFORMATIONAL exchange that does not contain
   UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be
   used for, e.g., testing whether a particular path works.

(And remove Section 2.5 about separate PATH_TEST exchange.)

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 10:28:08 +0200

In your previous mail you wrote:

   
   
=> note that I disagree.

Regards

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Sep 2005 12:23:34 +0300

>=> note that I disagree.
Ok. Can you expand the above a bit with
some reasons and/or alternative proposals?

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 8 Sep 2005 15:19:12 +0300

> and IKE messages for the path testing. Comments?

I am in favor of this approach... (as people already probably know :-)

>    UPDATE_SA_ADDRESSES as described in Section 2.3.

Note, that original initiator can also save one round trip (and one
exchange) if he adds both NAT_DETECTION_*_IP and UPDATE_SA_ADDRESSES
notifies to the DPD messages. If the addresses have not changed then
the UPDATE_SA_ADDRESSES is no-op thus only wasting 8 bytes in the
DPD. If the addresses have changed because of the NAT mapping
disappearing, then it saves the one round trip and makes the recovery
faster.

I think it is already allowed in the protocol, as it does say that we
proces UPDATE_SA_ADDRESSES notification in any INFORMATIONAL exchange,
but it might be good to notify this possibility here too. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 15:44:26 +0200

=> I am for making the standard mechanism for IKEv2/NAT-T (update
by ESP) simply mandatory in MOBIKE environments (option 1bis).
This is not against the charter (no new things for NAT-T) and
can be considered as a MOBIKE profile compatible with the
"mainstream" IKEv2.

Regards

PS: I don't buy the hardware argument (nor such hardware :-).
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Sep 2005 17:04:21 +0300

>can be considered as a MOBIKE profile compatible with the
I agree that none of the alternatives break our
charter. But can you explain more about why you
think 1bis is better than the other options? Or
is your argument that it is a smaller impact to
NAT-T than the other options?

>PS: I don't buy the hardware argument (nor such hardware :-).
Heh :-)

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 17:52:27 +0200

>can be considered as a MOBIKE profile compatible with the
   I agree that none of the alternatives break our charter.

=> I am not so sure...

   But can you explain more about why you
   think 1bis is better than the other options?

=> because someone who wants to deal with a NAT loosing its state
will simply implement the ESP update as it is recommend by the IKEv2
spec, with or without MOBIKE.

   Or is your argument that it is a smaller impact to
   NAT-T than the other options?
   
=> it has no impact, it is just a profile. It says if you have both
MOBIKE and NAT-T then you must have a good NAT-T, not the minimal one.

Regards

PS: BTW an advantage of 1bis is it doesn't mismatch with current NAT-T
recommendations, i.e., ESP update and >=2 can be a bit hard to live
together.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike