March 7, 2005MOBIKE WG, IETF 621 Mobility Protocol Options for IKEv2 (MOPO-IKE) Pasi Eronen

March 7, 2005MOBIKE WG, IETF 622 Basic approach: “initiator decides” Responder sends its list of addresses to the initiator Initiator decides which pair is used for IPsec SAs and tells the responder –If there is any reason to change the path (e.g., new interface, DPD failing, etc.) initiator handles it –NAT Traversal can be enabled or disabled when changing path

March 7, 2005MOBIKE WG, IETF 623 IKE_SA_INIT: …, N(MOPO_SUPPORTED), … INFORMATIONAL: …, N(NAT_DETECTION_*_IP), … IKE_SA_INIT: …, N(MOPO_SUPPORTED), … INFORMATIONAL: …, N(CHANGE_PATH), N(NAT_DETECTION_*_IP), … Host A IKE_AUTH: … VPN gateway B Gateway saves the new address (from the IP header) and updates the IPsec SAs …time passes… Host A gets a new IP address and decides to move the VPN traffic there IPsec traffic IKE_AUTH: …

March 7, 2005MOBIKE WG, IETF 624 IKE_SA_INIT: … INFORMATIONAL: …, N(NAT_DETECTION_*_IP), … IKE_SA_INIT: … INFORMATIONAL: …, N(CHANGE_PATH), N(NAT_DETECTION_*_IP), … Host A IKE_AUTH: … IKE_AUTH: …, N(ADDITIONAL_ADDRESS=2001:DB8::1), … VPN gateway B Host A moves to IPv6 network, and decides to use B’s IPv6 address instead of 6to4 or something …time passes… Gateway saves the new addresses (from the IP header) and updates the IPsec SAs IPsec traffic

March 7, 2005MOBIKE WG, IETF 625 More features… Separate path test (“ping”) message to handle partial connectivity / failures in the “middle” –Simplifies protocol –No need to support window size >1 Return routability test using informational exchange + cookie

March 7, 2005MOBIKE WG, IETF 626 INFORMATIONAL: …, N(CHANGE_PATH), N(NAT_DETECTION_*_IP), … Host A Background: A has addresses A1/A2, B has B1/B2 VPN gateway B INFORMATIONAL: … A decides to try some other pair PATH_TEST: … OK, works IPsec traffic Host A decides to do dead peer detection (Note added after presentation) The figure has an error, the 1st informational exchange is retransmitted before the CHANGE_PATH message can be sent.

March 7, 2005MOBIKE WG, IETF 627 Still more features… Also supports the case where responder’s set of addresses changes –Responder can send a new address list –For this purpose, the initiator also sends its list of addresses to the responder –If the responder’s addresses do not change, this list is never used for anything –This is the only feature that does not fully work with all types of stateful packet filters and NATs

March 7, 2005MOBIKE WG, IETF 628 MOPO-IKE vs. the issue list Match with closed issues Positions taken in open issues

March 7, 2005MOBIKE WG, IETF 629 Closed issues Issue 2: no special support for simultaneous movement: OK Issue 4: MOBIKE support signaled using Notify payloads: OK Issue 5: no “zero address set” functionality: OK Issue 7: first document considers tunnel mode only: OK

March 7, 2005MOBIKE WG, IETF 6210 More closed issues Issue 9: assumes 2401bis: OK Issue 12: interaction with other protocols doing RR is beyond our scope: OK Issue 13: IPv4/v6 movement works: OK Issue 15: RR done by adding “cookie” payload to informational exchange: OK

March 7, 2005MOBIKE WG, IETF 6211 Issue 3 Interaction with NAT traversal: does moving to behind NAT, from behind NAT, or from one NAT to another work? –Everything works if the responder’s addresses don’t change (and initiator is the one behind the NAT) –Changing responder’s addresses works in some cases, too (depends on exact type of NAT and other details)

March 7, 2005MOBIKE WG, IETF 6212 Issue 6 “When to do return routability checks?” –After updating the SAs or any time after that, if required by local policy –Version –02 does not mandate any particular policy: next version will probably say that default policy should be “do RR after updating the SAs, if not done for this address in this IKE_SA before” Does not prohibit fancier policies like “don’t do RR for addresses contained in the certificate”

March 7, 2005MOBIKE WG, IETF 6213 Issue 8 “Scope of SA changes: do we need per- IPsec SA granularity, or is it acceptable to use separate IKE SAs when needing this?” –If you want different IPsec SAs to use different addresses, you need several IKE SAs

March 7, 2005MOBIKE WG, IETF 6214 Issue 10 (closed) “Changing addresses vs. changing paths” –Updating address lists is separate from actually moving the traffic (changing path)

March 7, 2005MOBIKE WG, IETF 6215 Issue 11 “Window size vs. retransmissions and DPD” –Works with window size 1 –Even if something happens (e.g. interface goes down) when changing paths –(Separate path test exchange not constrained by the window)

March 7, 2005MOBIKE WG, IETF 6216 Issue 16 “Can the protocol recover from situations where the only sign of problems is lack of packets from the other end?” –“Lack of packets” means “no IKEv2 replies” –Works (because of the separate path test exchange) –Even if the IKEv2 request was about changing paths

March 7, 2005MOBIKE WG, IETF 6217 Issue 17 (closed) “If both parties have several addresses, do we assume that all pairs have connectivity between them?” –No, full connectivity is not assumed. –Since MOPO-IKE handles issue 16, this is easy: no big difference between “planned lack of connectivity” and “failure in the middle” –Determining connectivity works even if the need to do it arises unexpectedly

March 7, 2005MOBIKE WG, IETF 6218 Issue 19 “Should IPsec traffic in both directions use the same pair of addresses (in stable situations)?” –If the initiator wants it so (=usually yes) –Allows working with stateful packet filters and NATs

March 7, 2005MOBIKE WG, IETF 6219 Open things in MOPO-IKE Level of support for responder address changes with NATs –Some cases simply can’t be made to work (with existing NATs) –Some cases work easily without really needing anything extra –Still other cases can be made to work with extra effort and added protocol complexity Current approach: don’t care about responder address changes with NATs  don’t handle the difficult cases

March 7, 2005MOBIKE WG, IETF 6220 Conclusions & moving forward Some folks are really interested in shipping implementations of MOBIKE –Do not care about protocol details as long as it works (with some definition of “working”) and is simple enough to implement A protocol for handling just the initiator mobility case would be really simple, but we decided to include multihoming aspects too “Initiator decides” makes the former case simple while still handling the latter

March 7, 2005MOBIKE WG, IETF 6221 Conclusions & moving forward Our goal should be to get the protocol done to enable interoperable implementations –Not solve all possible problems in one shot (“Make it as simple as possible, but not simpler”) –Not make the protocol perfect or explore all possible alternatives before deciding (Good enough is better than perfect)