2.6.8 IKEv2 Mobility and Multihoming (mobike)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.vpnc.org/ietf-mobike -- Additional MOBIKE Web Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-24

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: https://www.machshav.com/mailman/listinfo.cgi/mobike
Archive: https://www.machshav.com/pipermail/mobike/
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:
May 04  Submit Reduced Tunnel Overhead Mode for IPsec to IESG for Informational RFC
May 04  Publish first draft on 'PFKEY Extension for Address Updates' (issue 6 above).
Aug 04  Submit PFKEY Extension for Address Updates document to IESG for Informational RFC
Oct 04  Publish first draft on 'IKEv2 Address Update', covering issues 1 to 4 from the above list.
Feb 05  Submit IKEv2 Address Update document to IESG for Proposed Standard RFC
Feb 05  Publish first draft on 'Reduced Tunnel Overhead Mode for IPsec' (issue 5 above).
  • - draft-ietf-mobike-design-00.txt
  • No Request For Comments

    Current Meeting Report

    IKEv2 Mobility and Multihoming WG

    IETF 60, 2004-08-02 19:30-
    Seabreeze room, Sheraton San Diego Hotel & Marina, San Diego, CA

    Chairs: Jari Arkko & Paul Hoffman
    Scribes: Wassim Haddad, Hannes Tschofenig, Tero Kivinen, and Gabriel Montenegro
    Minutes edited by: Pasi Eronen

    1. Agenda bashing by chairs

    2. MOPO-IKE by Pasi Eronen

    Pasi presented draft-eronen-mobike-mopo-00 (see slides). Discussion was postponed to item 4.

    3. IKEv2 address management by Francis Dupont

    Francis presented draft-dupont-ikev2-addrmgmt-05 (see slides).

    4. Design discussion by Tero Kivinen

    Basic scenarios:
    - Roaming laptop
    - Multihoming SGW
    - Can be combined

    Francis: You should add something about SCTP as well.

    Tero: We'll hopefully be useful for SCTP.

    Cheryl Madson?: So no mobile networks like NEMO?

    Paul and Tero: Not in base document.

    3rd party bombing
    How much protection we offer against 3rd party bombing?
    - almost none
    - limited
    - partial
    - full
    - do we care if A is the attacker?

    Pasi: Comment about terminology: I would not call it "almost none" but "reasonably good for most situations". Also "full" is not really full, it's only the best we can do.

    Hannes Tschofenig: The fact that you might want to consider A as an attacker might be artificial. You can also do this attack with some other protocol.

    Tero: We are trying to fix this problem even if other protocols have it.

    Jari: There are different types of attacks. We want to avoid amplification attacks. Whether we see A as an attacker is another issue, depends where you SA comes from, if you machine has a virus, and so on.

    Tero: IKEv2 NAT traversal allows you to keep the stream flowing forever.

    Jari: What is the difference between "almost none" and "limited"?

    Tero: In "limited" the attacker has to be close to both target C and A.

    Jari: If A is the attacker, there is no difference

    Tero: right.

    Jari?: I like the partial one.

    NATs and MOBIKE
    - Related to 3rd pary bombing issue
    - Can't have full 3rd party bombing protection and still work with NATs.
    - Only partial protection possible in this case
    - Full protection might be downgraded
    - Does limited/partial offer that much compared to almost none?
    - Should we upgrade protection offered by IKEv2 NAT-T to partial/limited?
    - Implicit address update is not manded in IKEv2, only SHOULD
    Problems with multihoming and NAT
    Case 1. The host behind NAT is not multihoming and the other end is multihoming
    - Option 1: Recovery is limited and done only by the host behind NAT.
    - Option 2: The host behind NAT must send keepalives to all possible path combinations, and keep the mappings in NAT active all the time
    Case 2: The host behind NAT is multihoming, with some of the interfaces using NAT and some not.
    - Same problems with interfaces using NAT
    - No problems with interfaces not using NAT, can use normal MOBIKE methods.

    Hannes: These issues are only with some types of NATs.

    Tero: Symmetric NAT are seldom used, we have to solve the NAT issue and the NAPT issue.

    Pasi and Hannes: MIDCOM has terminology for four different types of NAPTs, they make a difference here.

    NAT-T and MOBIKE options
    1. Always use NAT-T
    - No multihoming in server
    - No protection against 3rd party bombing
    2. NAT-T and MOBIKE are separate
    - If you move to NAT-T, just create new IKE SA which uses NAT-T
    - MOBIKE will have the active attack detecter which notices there is a NAT between.
    3. NAT-T and MOBIKE are combined
    - Modify NAT-T and/or create combination using NAT-T and MOBIKE.
    Pasi: I would phrase this a bit differently: can you enable or disable NAT traversal without creating a new IKE SA? If you can, that's option 3. Option 2 also combines NAT-T and MOBIKE since MOBIKE will include NAT detection payloads.

    Jari: Option 1 can't be used if two multihomed SGWs are talking to each other.

    Tero: I don't think there are NATs between to SGWs.

    Combined NAT-T and MOBIKE
    Do NATs only appear when IP address or link status changes?
    Do we want to switch back from NAT-T to MOBIKE?
    - Save bandwidth
    - Better protection against 3rd party bombing
    - Attacker can force to use NAT-T
    IKEv2 NAT-T is not enough for us
    - Can be enabled only at beginning
    - Implicit address update not mandatory
    - RR checks not mandatory
    - No detection of NAT disappearing

    Recovery from problems
    - Which problems we try to recover
    - Only local problems (IP address changes, link down, network card removed)
    - Also problems in the network (link breaking down somewhere along the path, routing infrastructure problems, etc.)
    - Do we need to act on information that no packets are received from other end?
    - Related to NAT-T as there only initiator can fix things

    Hannes: It seems you do not like to deal with problems in the network.

    Pasi: We have two kinds of local problems: one where you get some kind of trigger for L2 or something, and second where you only see lack of packets. I think we should handle both.

    Jari: Personal data point: half of the time when having connectivity problems I don't see any local indication. We should handle this.

    Tero: yes.

    Bill: You need to consider both types. (Example how Solaris multipathing handles both kinds)

    Pasi: there is the worst case where you need to test all possible paths to find the local problem.

    Scope of SA Changes: do all IPsec SAs move together with a common IKE SA?

    Francis: This is like SCTP: multiple streams, one IKE SA to manage all things between two peers.

    Pasi: No scenario currently being considered requires this functionality, for simplicity just move everything at the same time

    Tero: Ok.

    Francis: I disagree with Pasi, it is a typical example of what I call SCTP model multihoming: one IKE SA with multiple IPsec SAs using different addresses.

    Bill: Maybe we should consider "forking" IKE SA, could be useful in other problems too.

    Hannes: Do you support NAT for multihoming scenarios? When do you plan to make a decision?

    Paul: We cannot make a decision here,

    Pasi: I disagree, NAT issues were already discussed at Seoul, and even Minneapolis.

    Hannes: (point to 3GPP-WLAN interworking)

    Simultaneous movement
    - Real simultaneous movement where rendezvous server is needed are outside of the scope.
    - If we want to recover from some link failures, we will see "virtual simultaneous movements"
    - I.e. both ends IP-addresses change at the same time (but to already known addresses)

    IPv4 versus IPv6
    - Everything should still work.
    - We are not discussing of changing the traffic selectors here.

    Possible simplifications
    - SGW has only one address
    - SGW's addresses are static/mostly static
    - No NATs on SGW side
    - Allow client to use NAT-T only when not multihoming; i.e. only allow one interface is NAT-T is used.
    - If initiator is behind NAT, it takes care of recovery
    - Initiator always takes care of recovery

    Hannes: Do you mean that if I have a laptop with two interfaces then I have to turn off the interface which is not behind a NAT?

    Tero: If there is a NAT there then you only disable that interface,

    Pasi: There are two kinds of simplifications here: design decisions that are visible to the user, and protocol internal decisions not visible to the user.

    Hannes: Have we agreed that the protocol supports NAT?

    Tero: No, we have not decided that yet

    Paul: It is trending that way

    Pasi: Could you hold a hum to get some sort of consensus and then get a confirmation on the mailing list?

    Paul: I prefer to take it to the mailing list , a hum does not have any validity because there are too much new things here

    Hannes and Pasi: NAT and some other issues have been known for some time, already discussed at Seoul, and even Minneapolis.

    5. Using MOBIKE over NATs by Mohan Parthasarathy

    Mohan presented draft-mohanp-mobike-nat-00 (see slides).

    Hannes: There is some related work in MIDCOM WG, i.e getting the NAT address using DHCP.

    Bill and Steven Bellovin: It would be good to have some answer to the UNSAF questions from RFC 3424.

    6. Wrap up by chairs

    (minutes from this section are grouped by topic, not necessarily chronological)

    - Example protocols were discussed
    - Proposals are evolving and getting ideas from each other
    - New and updated proposals welcome

    Preventing bombing attacks
    - Discussed the different attacks and assumptions
    - One key question is if the authenticated entitiy can be an attacker
    - Different levels of protection are possible.
    - There was some support for two of the schemes ("almost none" and "partial")

    Jari: There was also some support for "full"

    Francis: I support "full".

    Pasi: no need to fix this in protocol; can support both full and partial depending on deployment requirements.

    Interworking with NATs
    - Affected by the bombing issue
    - Three options for NAT support:
    1. Just use NAT-T
    2. NAT-T and MOBIKE are separate, use exactly one
    3. Some level of NAT-T/MOBIKE integration
    - more discussion needed
    - We need to agree on NAT terminology.

    Recovering from local vs. path failures
    - Some support for being able to recover from both

    Scope of SA changes
    - Disagreement on whether all or only some are moved

    Mohan: Francis mentioned something about address selection?

    Francis: RFC 3554 (IPsec for SCTP) is very unclear about multiple addresses in SADB entries.

    Pasi: I don't think any document defines anything about multiple outer addresses.

    Simultaneous movements
    - Real simultanous movements out of scope, but "virtual" simultaneous movements needs to be handled

    - Should work

    - Some simplfiying assumptions are probably going to be needed

    Moving forward on the design issues:
    - Discussion & consensus calls on the list

    Paul: To update milestones in charter, let's concentrate on IKEv2 address update draft, and move others (PFKEY and reduced tunnel overhead) to later

    Pasi: Once we agree on most important design decisions, all protocols should look about the same, or at least the differences are not important. I think we can have a WG protocol document soon after the decisions.

    Hannes, James and Paul: (talked about selecting an editor, or forming a design team, and some bad experiences about design teams.)

    Hilarie: Will there be a separate threat document?

    Paul: It will be incorporated into the design draft.

    Hilarie: If the authors are not clear about the attacks, it would be difficult to address them in the protocols.

    Tero: Most authors have thought about the attacks.

    Jari: Only because the authors have the threats in their mind does not need that they agree on them.

    Pasi: We do have one other threat in addition to 3rd party bombing. An attacker should not be able to close an IKE SA by modifying just a single IKE packet. If attacker can modify all packets, he can of course DoS.

    Paul: Do we have this in some protocol?

    Tero: Yes, mine.



    IKEv2 peer address management
    Mobike Protocol Design
    Using MOBIKE over NATs