2.6.8 IKEv2 Mobility and Multihoming (mobike)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional MOBIKE Web Page

Last Modified: 2004-09-23


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>


Pasi Eronen <pasi.eronen@nokia.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

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

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

(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

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

(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 61, 2004-11-09 17:00-18:00
    Military room, Hilton Washington, Washington, D.C.

    Chairs: Jari Arkko & Paul Hoffman
    Scribes: Thomas Henderson
    Minutes edited by: Pasi Eronen

    1. Agenda bashing by chairs

    Paul announced that he's searching for an editor for the design draft.

    2. Introduction to multihoming, address selection, failure detection, and recovery by Jari Arkko

    Jari explained how IPv6, DCHP, DNA etc together provide a set of addresses and some local information about the operational status.

    He went on to explain how multihoming involves not just a working/not working address but also address pairs

    Jari suggested some design rules, including the one that MOBIKE should rely on other parts of the stack to provide for the local information, such as usable addresses (which is very different from testing that a certain path works)

    (discussion was postponed to next item)

    3. MOBIKE division of work by Pasi Eronen

    (picking up in middle of Pasi's presentation)

    - Mobike specs need "story" of how the whole thing works
    - to convince the reader that it actually works
    - but not much more-- MOBIKE is about standardization, not software design

    Connectivity assumptions
    - assume that A and B don't have full information about the connectivity
    - full information requires a message pair between A and B
    - this has to be an IKEv2 message
    - unless we modify ESP
    - this could be existing or new message type

    Failure detection - IKEv2 already has DPD
    - host can get failure information from other sources as well
    - no big difference between lack of connectivity and a long network failure
    - if we handle one, the other is handled as well

    Paul Hoffman: Want to explain where mailing list has gone when we have gone away from basics. A lot of proposals "you can do this and you can tell what happens" comes from between red lines between A and B. That's nice and may be true, but doesn't cause interoperabilty. We should focus on the red line near B. If we get away from nearness to A, we get away from "it would have been nice if previous WG did such and such". We need to focus this group on that problem if we get done.

    James Kempf: Agree-needs to be end-to-end authentication. Concern: mobile IP, had to define optional interface between IPsec module and mobile IP module-- a little concerned that something is being missed that might require this interface.

    Jari: Can use IPsec for different purposes-- is that out of scope?

    James: That interface came out of an interaction between IPsec and mobile IP because of performance concerns. By saying any suggestion is out of scope, may run into a performance issue related to the API.

    Pasi: We had this WG item PFKEY updates-- no one worked on that. Clearly, getting something to work requires adding something in yellow box.

    Jari: Talked about a document about how IKEv2 and MOBIKE can be used in conjunction with other protocols.

    Vijay Devarapalli. Glad we had this discussion.

    Charlie Kaufman: Confused.. beginning to think group is solving different problem. Had assumed we had a mobility story that was OK and IPsec story that was OK, and we needed to glue together. Now, I think we are trying to construct a workable mobility model (even if we were not negotiating any crypto). Is this what you are trying to do? Is this building on top of perfectly fine mobility, or not?

    Paul: We are assuming that there is a mobility environment--not that it is perfectly fine. We are not mandating a particular mobility solution. We are using IKE to protect against some of the mobility attacks.

    Jari: We have several mobility stories in IETF. Some depend on IPsec, like mobile IP, to secure its signaling.

    Charlie: Would it work without IPsec but with security problems?

    Paul: Yes, but from IETF perspective, then it doesn't work.

    Pasi: Assuming that nowadays, a lot of times when you move, you do have the keys, but you need to rebuild the VPN from scratch. We are solving a very small problem-- not attempting to be a general mobility solution.

    Hannes: Surprised that many people got lost with a simple problem. Mobile IP stuff-- in some environments, why do you want to use MobIKE, on top the binding update, some naive reader might wonder why you use Mobile IP at all?

    Jari: Mobile IP does more.

    Paul: Don't want to discuss this in our documents. Not precluding any future working groups from doing that. This is to say: "this does work and it does work securely, and to write out the security properties."

    Hannes: PFKey issue-- we have done some of that and it works-- not a big deal.

    Paul: Sounds like that might be a very short thing.

    Pasi: Current PFKEY doesn't describe how implementations actually work.

    Paul: (?)

    Mohan Parthasarathy (?): A and B connected by IPsec tunnel mode-- don't understand that. I don't know what it means to work with SCTP multihoming then.

    Pasi: Concern on mailing list that we will deal with tunnel mode first.

    Jari: We haven't dealt with all of the issues there yet.

    Francis Dupont: Mobile IP and MOBIKE are two incompatible solutions for the same problem. hard to use both at same time.

    Ashutosh Dutta: Is there a list of scenarios written down? Such as, mobile is multihomed, move to external network? I think you are mostly talking about starting from outside-- it works OK there. It is harder when you start from internal.

    Jari: If you have that situation, might or might not work. Not in our scope.

    Pasi: If you are not using IPsec inside, and you are outside, no, we are not handling that case.

    Paul: We are not going to go there, unless you have a protocol proposal that doesn't affect our main protocol (to extend it). We are not going to try to solve every possible mobility scenario. But we might consider extending our charter downstream once we accomplish our primary goal.

    Pasi: I actually think, we should do this, then PFKEY, and go home.

    (back to Jari's slides)

    Greg: i) how do we know that a problem exists? Our experience is that you need a bunch of mechanisms from layer-2 up to potentially application layer signaling. What would be helpful for me to understand is some sort of OSI map, and that we are doing this much of it.

    Pasi: Application service layer is up to IKE.

    Greg: We set up large IPsec VPN, and people want to use a whole bunch of different things to determine whether to take which tunnel paths, how to define when an interface is no good anymore.

    Jari: Which ones of this layer are mandatory to implement in the context of MOBIKE? I think we can't mandate this. But I think we need to assume dead peer detection, or some things have gone away.

    Paul: If IKE module can take hints to do that, nothing in protocol to say "don't think you're mobile only from the IKE info."

    Gregory: Was expecting a slide to show those boundaries, would like to know where those boundaries are.

    Michael Richardson: We might take info from below, not above?

    Paul: No, I said it was easier to take from below than from above.

    Subir Das: Is it correct that I move to another link and inform. Does Mobike validate that path or reachability?

    Pasi: At some point, there will be IKE message somewhere-- if it doesn't get through, it doesn't work (implicit path validation). IKEv2 has DPD on that link anyway.

    Gregory: Clarify-- "we do not want want to reinvent DHCP" Today we have configuration payload..

    Jari: Yes, but that is inside the tunnel.

    Paul: Can you see a scenario for changing the inner configuration?

    Gregory: Come from outside to inside (now on an inside address).

    Jari: Doesn't necessarily work if you disable or enable IPsec on these movements-- we are out of scope there.



    Introduction to multihoming, address selection, failure detection, and recovery
    MOBIKE division of work