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

March 7, 2005 MOBIKE WG, IETF 62 1

Mobility Protocol Options for Mobility Protocol Options for IKEv2 (MOPO-IKE)IKEv2 (MOPO-IKE)

Pasi Eronen


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


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: …


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


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


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.


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


MOPO-IKE vs. the issue listMOPO-IKE vs. the issue list

• Match with closed issues

• Positions taken in open issues


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


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


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)


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”


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


Issue 10 (closed)Issue 10 (closed)

• “Changing addresses vs. changing paths”– Updating address lists is separate from

actually moving the traffic (changing path)


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)


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


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


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


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


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


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)

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

Documents

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