210 likes | 352 Views
Mobility Protocol Options for IKEv2 (MOPO-IKE). Pasi Eronen. 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
E N D
Mobility Protocol Options for IKEv2 (MOPO-IKE) Pasi Eronen MOBIKE WG, IETF 62
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
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
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
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
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
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
MOPO-IKE vs. the issue list • Match with closed issues • Positions taken in open issues MOBIKE WG, IETF 62
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
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
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
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
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
Issue 10 (closed) • “Changing addresses vs. changing paths” • Updating address lists is separate from actually moving the traffic (changing path) MOBIKE WG, IETF 62
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
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
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
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
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
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
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