2.6.4 IKEv2 Mobility and Multihoming (mobike)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-13

Chair(s):
Paul Hoffman <paul.hoffman@vpnc.org>
Jari Arkko <Jari.Arkko@ericsson.com>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Russell Housley <housley@vigilsec.com>
Mailing Lists:
General Discussion: mobike@machshav.com
To Subscribe: mobike-request@machshav.com
In Body: https://www.machshav.com/mailman/listinfo/mobike
Archive:
Description of Working Group:
The IKE Mobility working group will focus on the extensions to the IKEv2 protocol required to enable its use in the context where there are multiple IP addresses per host (multihoming, SCTP) or where the IP addresses changes in the control of the IPsec host (mobility and roaming).

The main scenario is making it possible for a VPN user to move from one address to another without re-establishing all security associations, or to use multiple interfaces simultaenously, such as where WLAN and GPRS are used simultaneously. It is also intended that the extensions produced by the WG would address specific needs related to other work in IETF, such as modification of SCTP end points without renegotiation of the security associations or the movement of IKEv2-based secure connections to enable Mobile IP signaling to take place.

An explicit non-goal is the construction of a fully fledged mobility protocol. In particular, the WG shall NOT develop mechanisms for the following functions:

o Hiding of mobility from transport layer protocols or applications (beyond what already exists through the use of the tunnel mode). In this respect MOBIKE is different from Mobile IP, HIP, and other mobility protocols.

o IP address changes done by third parties (NATs, firewalls etc). In particular, MOBIKE shall not replace or modify IKEv2 NAT traversal function. MOBIKE handles IP address changes initiated by one of the endpoints of the security associations. NAT traversal handles other address changes. MOBIKE should not be tightly coupled with the NAT traversal function, but it is necessary to specify in which cases (if any) they can be used together, and how they interact.

o Opportunistic authentication or other tools for the reduction of configuration effort. The mechanisms specified in this WG are to be designed for the traditional VPN use case only.

o Any optimization of packet routing paths due to mobility.

o Load balancing. Multihoming is supported only in the sense of failing over to another interface; sending traffic over multiple addresses using the same SA is not supported.

o Use of IKEv1.

Work Items

The goals of the MOBIKE working group are to address the following issues:

(1) IKEv2 mobile IP support for IKE SAs. Support for changing and authenticating the IKE SA endpoints IP addresses as requested by the host.

(2) Updating IPsec SA gateway addresses. Support for changing the IP address associated to the tunnel mode IPsec SAs already in place, so that further traffic is sent to the new gateway address.

(3) Multihoming support for IKEv2. Support for multiple IP addresses for IKEv2 SAs, and IPsec SAs created by the IKEv2. This should also include support for the multiple IP address for SCTP transport. This should also work together with the first two items, i.e those addresses should be able to be updated too.

(4) Verification of changed or added IP addresses. Provide way to verify IP address either using static information, information from certificates, or through the use of a return routability mechanism.

(5) Reduction of header overhead involved with mobility-related tunnels. This is a performance requirement in wireless environments.

(6) Specification of PFKEY extensions to support the IPsec SA movements and tunnel overhead reduction.

Goals and Milestones:
Feb 04  Publish first draft on
Jun 04  Submit IKEv2 Address Update document to IESG for Proposed Standard RFC
Jun 04  Publish first draft on
Sep 04  Submit Reduced Tunnel Overhead Mode for IPsec to IESG for Informational RFC
Sep 04  Publish first draft on
Dec 04  Submit PFKEY Extension for Address Updates document to IESG for Informational RFC
No Current Internet-Drafts
No Request For Comments

Current Meeting Report

IKEv2 Mobility and Multihoming WG

IETF 59, 2004-03-01 09:00-
Emerald Room, Lotte Hotel, Seoul, South Korea

Chairs: Jari Arkko & Paul Hoffman
Secretaries: Pasi Eronen & Lauri Tarkkala
http://www.vpnc.org/ietf-mobike/

1. Agenda bashing by chairs

Jari bashed the agenda.

2. WG Status by chairs

- WG just approved, this is the first meeting.
- Pasi Eronen is the secretary. Will take minutes and track issues.
- Internal and external document reviewers recruited.
- Document editor(s) will be chosen when we have documents to edit.
- xml2rfc used as the tool for documents.
- No WG documents yet. Three individual submissions. Some missed the draft submission deadline, available from WG website.
- Expect one WG document for protocol. This is to become a standard track for RFC. Decide later what to do with design documents (possibly appendix in protocol document), but it is very important to discuss the design issues.
- Finish first work item before starting others.
- New WG gets to decide how to do things; we do some things differently that other WGs, but chairs are open to suggestions. This is not IPSEC WG part 2 or any mobility WG part 2.
- We want to make sure we get this right, so we need coordinating with others; but we want to finish this some day.

3. IKEv2 Address Management by Francis Dupont

Goals:
- Multi-homing
- Mobility
- New transports (SCTP, ...)
- Security, flexibility, simplicity

Non-Goals:
- NAT traversal

Devices:
- Peer addresses as IKE SA parameters
- Special handling/clarification of transport mode
- Peer address sets
- Explicit peer address update

Security aspects:
- No 3rd party bombing
- Change in transit
- Return routability check
- Binding with certificates

Address sets:
- Initiated in second exchange, can be changed at any time
- Validated against authentication
- Ordering can carry some meaning, but probably is not very useful and only adds complexity

Proxy mode:
- When traffic selector (TS) doesn't match the peer address, follow the TS
- Security issue: proper authz is needed
- Proposal: accept it when the TS is in the address set
- Transport mode SAs are not concerned when peer address changes?
- This "proxy mode" is a required feature for Mobile IPv6 support (to do transport mode SA for home address when peer address is CoA)

Peer address update:
- Change the endpoint addresses of IPSec or IKE SAs
- List of SAs to update, or an 'all SAs' flag
- Possible return routability check
- New payload similar to DELETE

Conclusion:
- Requirements
- Mechanisms (managing peer address sets and updating SAs)
- Policies (what kind of verification you need for addresses, i.e. RR or certificates or something else)
- Nothing about header compression
- BTW, Jan Vilhuber has a draft about header compression in IPsec (draft-vilhuber-hcoesp-00)
Paul: Header compression is in the charter, but far down the line, and it is not work that the WG will be looking at any time soon.

4. MOBIKE Protocol by Tero Kivinen

Quickly written as starting point for discussion, will be submitted after I-D editor accepts submissions again

Basic Design:
- Tries to use as much of IKEv2 as possible
- Notify payloads for address updates
- IKEv2 dead-peer-detection for return routability checks
- Tie IKE SA and IPSec SA address movements together

Multihoming Rules:
- Use preferred address as long as it works
- If it fails, take next one; try the most preferred address again after some event
- Do return routability check once per new address
- concentrates on the usability

Direct Indication of Change:
- Other end sends address update notification
- Authenticated
- If new preferred address is known and working, move traffic immediately
- If new preferred address is unknown, move traffic immediately, and start return routability checks (some might want to delay moving).
- If new address is known and was not working last time, delay moving of traffic and move it only after verifying that address works now.

Indirect indication of change
- Peer receives some indirect indication that address might not work, this might be ICMP, or other end starts using different address than before, or no packets from other end.
- Do not act directly, but start DPD

Dead Peer Detection:
- IKEv2 dead-peer-detection used for return routability checks and to verify addresses
- If indirect notification, start with currently in use address
- If direct notification start with most preferred address
- Send some DPD packets, if no reply move to next address
- Keep same IKEv2 message id (because of window size)
- Every time new address is tried the retransmission timers are reset
- If no response, we have to delete IKE SA because we might be out of sync for message IDs--but we can retransmit many times and wait quite long

Address Notify Protocol
- Informational exchange, notify payloads
- Message id used to order the request
- Must not send address notifications in ACK packets, must send them in separate exchange
- When IKE SA is updated, all IPsec SAs follow it
- If you want separately move them, create two IKE SAs

Zero Address Set:
- Optional feature, which might be taken in
- Basically a disconnect message

Summary:
- Simple protocol, no new payloads, no new exchanges, uses IKEv2 features
- Use IKEv2 DPD for return routability checks and for verifying that address works.

Stephen Kent: How is failure detected in an IPSec connection ?

Gregory: Why not use Delete Notification for IKE SA instead of zero address sets ? (Discussion deferred by WG Chair)

Francis Dupont: A payload is needed, because payloads can be marked as critical (IKEv2 payload bit).

Pasi Eronen: IKEv2 spec has a method for signalling the other end which extensions are supported.

5. MOBIKE Design by Tero Kivinen

Paul: Please have open mind and forget the details of these protocols. The protocol we end up with might not look like either of these.
Introduction:
- Want to change IP-address of the IKE and IPSec SAs without rekey
- 2 basic scenarios: roaming laptop, multihomed SGW
- We are trying to fix problems that occur locally (e.g. local network connection breaks), not route around problems in core network
- One end is static, not trying to solve two simultaneously moving laptops moving together

Protocol:
- Notifying the other end of IP-address list changes
- Update the IKE SA endpoint address based on the notifications
- Automatically switching to use new IP address if old one does not work anymore
- Updating the tunnel mode IPSec SA selectors.
- RR checks of new addresses if needed

Multihoming Support:
- Multihoming support consist of rules how to use IP address lists
- When to move to new address?
- When to do return routability checks?

Direct indication of address change:
- Directly from the other end
- Authenticated
- List of addressed in most preferred order
- Is there maximum size of that list

Pasi Eronen: Do we need these address lists at all? A lot of the functionality can be done without them.

Tero: Yes, some things can be done.

Francis: In IKEv2 everything is authenticated.

Tero: Not actually, lots of indirect indications are not authenticated.

Francis: Indirect indications are not useful, because peer is aware of things. We do not need automatic things, only specific, because that is simpler.

Paul: Protocol simpler? Administration simpler? Or security? Simpler where?

Francis: Put control in the moving side. For static side you need only passive processing of notifications.

Tero: Yes, it is simpler if we don't have to do DPD for multiple address. But we do not know which end is going to detect and attempt to solve this problem. In this case, we need lists because the sender does not know which IP is no longer working.

Paul: Reasonable thing to discuss.

Pasi: We already have unauthenticated information in basic IKEv2, in NAT Traversal [basically IP addresses and ports]

Tero: NAT traversal is beyond charter.

Pasi: Charter does not allowing changes to NAT-T, but it does not say that we should not support NAT-T. I want to have both.

Paul: Good point, we should take NATs in to account.

Tero: If starting behind NAT with NAT-T enabled then moving out and back from NAT works with IKEv2 NAT-T. Currently moving from not-behind a NAT to behind a NAT is not supported with only MOBIKE. This would require switching from MOBIKE to NAT-Traversal. But no way to separate NAT modifying a packet or attacker modifying a packet.

Henrik Levkowetz: If we don't work with NATs, this won't be very useful.

Indirect Indication of Address Change:
- Indirect indication. The local end notices something that causes it to believe that causes it to believe something along the path has changed.
- Not needed if moving point always notifies

Dead-Peer-Detection:
- In MOBIKE context verify which IPs still work
- Should have much longer timeouts, should try to all possible IP addresses before marking peer dead.
- Can be done simultaneously for each IP-addresses, but could cause problems (some IKE implementations retransmit only once for a burst of packets)

Return Routability Checks:
- Try to verify that the other peer can be reached using the IP-address given.
- Can use same messages as DPD

James Kempf: If Mobile IP is being used simultaneously, return routability checks would redundant. Could we pass information from there?

Paul: Would that be a layering violation?

James: Signalling efficiency is important. But it's worthwhile at looking at this, otherwise people might not take it seriously from deployment viewpoint.

Pekka Nikander: At multi6 there was idea called SLAP, now draft called CLP which discusses how to share RR tasks between protocols and more.

Charlie Perkins: Is it already layering violation to do RR checks at all? And 2nd question, do you have any performance requirements?

James Kempf: Since RR is useful in many contexts, maybe separate RR to another protocol.

Tero: I don't know if we have any performance requirements. And we try to stay away from routers, but e.g. SGW is kind of router.

Paul: Not in charter (performance reqs).

Tero: Scenario laptop to corporate VPN, user doesn't notice when something happens, order of tens of seconds, but not two minutes. This is not about <1s recovery time.

Lauri Tarkkala: RR we are doing more than RR, also checking that valid IKE SA exists at the other address (also SPIs etc)

Tero: DPD and RR are different things, but we can use same messages in IKE ...

Lauri: DPD again, we need special MOBIKE handling for all IKEv2 exchanges, not just DPD exchanges, because any exchange in IKEv2 can be DPD exchange

Stephen Kent: agree with Lauri and disagree with Charlie: We are doing RR in secure fashion, not vulnerable to MITM attacks, so a separate "RR protocol" is probably not a good idea.

Paul: We need to capture these kinds of discussions in the design document, so we can find out why we did things. Please send to mailing list.

Charlie Perkins: I would correct something that was said about MIP return routability. A home agent discovery is authenticated

Stephen Kent: I did not say anything about Mobile IP return routability, just generic return routability.

Jari Arkko: I do not think we can have a generic return routability module. There are different RR mechanisms in different protocols, because we need them to do different things.

Exchanges:
- Informational Exchange: Already defined in IKEv2, All implementations have code to generate and parse them
- Own MOBIKE specific exchange: Not restricted to 2 packets, Might be able to combine RR with address update.

Number of payloads:
- One payload containing everything: More compressed format, More complicated format
- Multiple payloads: Easier to parse (can use IKEv2 code to parse the list), easier to add extension data, some implementations might have limit of max number of payloads

Payloads:
- Notify payloads
- MOBIKE specific payload

Full list of incremental updates:
- When sending IP-address update notifications
- Full list of IP-addresses:
- Easier to handle
- No synch problems
- Restricts the number of IP-addresses
- Incremental changes
- Strict ordering restrictions
- More complicated

Scope of SA Changes:
- How to update the IPSec SA IP-address when IKE SA IP-address change:
- Automatic
- Fast, easy, simple
- Everything moves
- Manual:
- Need separate protocol, payloads etc
- Allows moving only parts of the traffic to new IP-addresses
- Needs per IPSec SA IP-address list

Pasi Eronen: Is there a difference in functionality if we could have redundant IKE SA's ?

Tero: Some overhead for creating second IKE SA, but not that much. But this is one thing we have to decide.

Gregory: "Manual" option probably won't be needed, because you need some sort of policy saying which to move when.

Paul: Same thing occured elsewhere, don't have policy to tell what to do.

Francis: I think it is useful to move separate SAs.

Tero continued about "Zero address set"

Pasi: I oppose any kind of TCP ACK spoofing as part of this protocol.

Tero: I agree.

Bill Sommerfeld: You can adjust TCP stuff, for instance disable TCP keepalives, to keep them alive for hours or days. So don't specify MitM against TCP in the document.

Return Routability Checks:
- When to do them?
- Everytime we change address?
- Only when we start to use new address not used before?
- Never?

Francis: The question is purely policy one, so should be postponed.

Pasi: IKEv2 NAT-T never does RR for any addresses.

Tero: True, but the problem is self-fixing in IKEv2 because the correct address is restored when some more traffic comes through.

Pasi: Not if the attacker is the real client.

Tero Kivinen: This is the problem Francis was describing.

Charlie Perkins: If the address is dynamically allocated, you have to keep track of lifetime info.

Tero: Yes, but the other end doesn't know the lifetime.

Summary:
- We need to decide on some of those issues before we can really describe the protocol
- Different scenarios and usage types affects some of the choices.
- Lots of decisions, e.g. do we need to support laptops/gws having hundreds of addresses?

Pasi: One thing mentioned earlier, but lost somewhere. IKEv2 works with NAT-Ts because IP addresses are not sent inside the UDP payload. MOBIKE will break this and we will have problems. Is the intent that MOBIKE and NAT-T are exclusive ?

Jari Arkko: Yes

Pasi Eronen: Does the WG feel this way?

Tero Kivinen: Not sure whether MOBIKE and NAT can be well integrated.

Hannes Tschofenig: There are scenarios where you need this, we might want to think about it.

Paul Hoffman: We will.

James Kempf: If this is too difficult to do this on the first round. It is acceptable to delay it.

Francis: The scenarios for NAT-T/MOBIKE cases must be documented.

Henrik Levkowetz: The usefulness will be severely lower if NAT-T/MOBIKE is not supported. If you want to get this deployed, you need that.

6. Way forward

- Read design document, read protocols. Submit design issues to mailing list.
- Design issues will be tracked on website. Hopefully design draft will be updated.
- At least one more round of individual submissions; Tero should submit his when submissions open.
- Then close discussion and arrive at a WG document (timeframe ~ 1 month).
- Get the Address Update protocol done before taking up other work items.

Gabriel Montenegro: Is there some applicapability/non-applicapability statement ? (w.r.t. mobile IP). Any idea on how to not duplicate stuff in other protocols?

Jari: Charter already says we are not going to define fully fledged mobility protocol, we have very limited scope and less features than e.g. MIP.

Charlie: Is it possible to identify modular capabilities in MIP and MOBIKE, so that if you pick some set of modules you get MOBIKE, if you pick others you get MIP.

Paul: Nothing against that, if someone wants to do the design document from that perspective.

Charlie: In case mobility, there's tunneling agent (home agent), here you have VPN gateway tunneling; do you want to merge some features into big box; if you have two boxes you want them to operate together smoothly. This is worthwhile thinking while moving along.

Paul: If you are inspired to do something very similar to Paul/Tero, speak to them. If you are inspired to do something difficult, please submit individual draft, but try to do within one month.

Pasi: Will post issues in issue tracker about the design decisions, but only most important issues first. Please email if I forget something.

(end)

Slides

Agenda
Document and WG Status
IKEv2 Address Management
Mobike Protocol
Mobike Protocol Design
Wrap-up