1 / 21

Mobility Protocol Options for IKEv2 (MOPO-IKE)

MOPO-IKE (MOBIKE) is a protocol that enables mobility support for IKEv2, allowing users to change their network addresses or paths without interrupting IPsec security associations. This document discusses the basic approach and additional features of MOPO-IKE, including support for NAT traversal and handling simultaneous movement.

bradleywest
Download Presentation

Mobility Protocol Options for IKEv2 (MOPO-IKE)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Mobility Protocol Options for IKEv2 (MOPO-IKE) Pasi Eronen MOBIKE WG, IETF 62

  2. 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 MOBIKE WG, IETF 62

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

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

  5. 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 MOBIKE WG, IETF 62

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

  7. 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 MOBIKE WG, IETF 62

  8. MOPO-IKE vs. the issue list • Match with closed issues • Positions taken in open issues MOBIKE WG, IETF 62

  9. 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 MOBIKE WG, IETF 62

  10. 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 MOBIKE WG, IETF 62

  11. 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) MOBIKE WG, IETF 62

  12. 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” MOBIKE WG, IETF 62

  13. 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 MOBIKE WG, IETF 62

  14. Issue 10 (closed) • “Changing addresses vs. changing paths” • Updating address lists is separate from actually moving the traffic (changing path) MOBIKE WG, IETF 62

  15. 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) MOBIKE WG, IETF 62

  16. 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 MOBIKE WG, IETF 62

  17. 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 MOBIKE WG, IETF 62

  18. 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 MOBIKE WG, IETF 62

  19. 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 MOBIKE WG, IETF 62

  20. 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 MOBIKE WG, IETF 62

  21. 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) MOBIKE WG, IETF 62

More Related