Upload
rodney-wilcox
View
219
Download
1
Embed Size (px)
Citation preview
March 7, 2005 MOBIKE WG, IETF 62 1
Mobility Protocol Options for Mobility Protocol Options for IKEv2 (MOPO-IKE)IKEv2 (MOPO-IKE)
Pasi Eronen
March 7, 2005 MOBIKE WG, IETF 62 2
Basic approach: Basic approach: “initiator decides”“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, 2005 MOBIKE WG, IETF 62 3
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, 2005 MOBIKE WG, IETF 62 4
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, 2005 MOBIKE WG, IETF 62 5
More features…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, 2005 MOBIKE WG, IETF 62 6
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, <A1,B2> 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, 2005 MOBIKE WG, IETF 62 7
Still more features…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, 2005 MOBIKE WG, IETF 62 8
MOPO-IKE vs. the issue listMOPO-IKE vs. the issue list
• Match with closed issues
• Positions taken in open issues
March 7, 2005 MOBIKE WG, IETF 62 9
Closed issuesClosed 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, 2005 MOBIKE WG, IETF 62 10
More closed issuesMore 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, 2005 MOBIKE WG, IETF 62 11
Issue 3Issue 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, 2005 MOBIKE WG, IETF 62 12
Issue 6Issue 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, 2005 MOBIKE WG, IETF 62 13
Issue 8Issue 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, 2005 MOBIKE WG, IETF 62 14
Issue 10 (closed)Issue 10 (closed)
• “Changing addresses vs. changing paths”– Updating address lists is separate from
actually moving the traffic (changing path)
March 7, 2005 MOBIKE WG, IETF 62 15
Issue 11Issue 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, 2005 MOBIKE WG, IETF 62 16
Issue 16Issue 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, 2005 MOBIKE WG, IETF 62 17
Issue 17 (closed)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, 2005 MOBIKE WG, IETF 62 18
Issue 19Issue 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, 2005 MOBIKE WG, IETF 62 19
Open things in MOPO-IKEOpen 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, 2005 MOBIKE WG, IETF 62 20
Conclusions & moving forwardConclusions & 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, 2005 MOBIKE WG, IETF 62 21
Conclusions & moving forwardConclusions & 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)