Subject: [Mobike] issue 34 -- ESP vs. IKE based NAT reboot detection

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Aug 2005 16:04:35 +0300

I'd like to open discussion on this issue. Please read
the slides and notes from

 http://www3.ietf.org/proceedings/05aug/slides/mobike-2.pdf
 http://www.machshav.com/pipermail/mobike/2005-August/000912.html

and post your thoughts on this issue. As far as I can
determine, we are primarily discussing two alternatives:

Alt 1: The approach in -01 which retains what IKEv2 does
when NAT mappings change. I.e., there's a SHOULD in the
IKEv2 spec that allows implementations to update mappings
based on what they see happening for the UDP-encapsulated
ESP packets.

Alt 3: Tero's approach, which says not to use this feature
in IKEv2 when MOBIKE is employed, and instead relies on
periodic IKE probes.

Based on the discussion in IETF-63, it seems that both
approaches work, but the tradeoffs are mainly in the
area of ease of implementation vs. pressure to decrease
probing/keepalive intervals.

We do know that there are some (even if few) implementations
of IKEv1/v2 that employ the ESP-based check. Similarly, some other
implementations aren't doing it.

Note also that we need to keep in mind what the requirement
level for this feature is or will be. If its not a MUST, this means
that whatever bad effect there may be (implementation diffuculties
or additional messaging), you do NOT have to suffer from that
unless you also need to support this feature.

--Jari

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 17 Aug 2005 19:23:21 -0400

> in IKEv2 when MOBIKE is employed, and instead relies on

Assume you're implementing both IKEv2 NAT traversal as well as mobike,
with mobike use being optional.

Either alternative presumably needs a notification from ESP to key
management that NAT-level "motion" has been detected, but alternative 3
also seems to require a "mode bit" in ESP indicating when you should let
ESP handle the address updates and when it should ignore them.

I'd rather avoid that complexity.

						- Bill

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Aug 2005 09:51:51 +0300

>with mobike use being optional.
A likely case.

>ESP handle the address updates and when it should ignore them.
Yes.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 18 Aug 2005 18:38:38 -0700

> management that NAT-level "motion" has been detected, but alternative 3.
>
Why does alternative 3 require this notification ?

> I'd rather avoid that complexity.
Is this not a per-SA bit ? If MOBIKE is used and the bit indicates such, then
don't update the SA and don't send the trigger to IKE if you use alt.3. If NAT
traversal is used and MOBIKE is not used, then update and send trigger.
Why is it complex ? I am missing something.

thanks
mohan

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Aug 2005 13:29:06 +0300

> ESP handle the address updates and when it should ignore them.

Not in the ESP, as the ESP is not the one who is going to make the
change anyways. When the ESP notifies the addresses are changed it
need to notify about that to the IKE, and at least in our case the IKE
(usermode policymanager) would be doing that kind of decisions when
to change and how to change, i.e. it would be then sending
notification back to the ESP to ask it to modify the outer addresses.

In case mobike, the usermode policymanager would not send those
notifications, and with normal IKEv2 NAT-T it could send those
(depending on the policy).

If the NAT-T updating is supported, then the change needs to be done
in both ESP and IKE SAs regardless which one of those detect the
change (and depending on the policy). I am pretty much sure that there
are people who want to disable that, or do it only partially (i.e.
only update port, but not address etc) and all this depends on policy.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike