2.6.8 IKEv2 Mobility and Multihoming (mobike)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN 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: 2005-01-24


Paul Hoffman <paul.hoffman@vpnc.org>
Jari Arkko <Jari.Arkko@piuha.net>

Security Area Director(s):

Russell Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

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-02.txt

    No Request For Comments

    Current Meeting Report

    IKEv2 Mobility and Multihoming WG

    IETF 62, 2005-03-07 09:00-11:30
    Salon G, Hilton Minneapolis, Minneapolis, Minnesota

    Chairs: Jari Arkko and Paul Hoffman
    Scribes: Maureen Stillman and Kristian Slavov (during meeting), Pasi Eronen (based on recording)

    Minute editor's (Pasi Eronen) note: these minutes include mainly the comments, questions and answers from the meeting, but do not repeat the presentation slides. The timestamps refer to the raw recording of the meeting, ietf62-ch5-mon-am.mp3.

    1. Agenda and document status by chairs


    Francis Dupont: My draft about transport is not to apply MOBIKE to transport, but rather describe all things you can do once MOBIKE is more defined.

    2. Design of the MOBIKE Protocol by Hannes Tschofenig


    Jari: The presentation starts with several examples, but let's have the discussion only when we get to the issue slides.

    Terminology and scope of MOBIKE work 23:05 comment from Francis

    Issue discussion starts (30:00)

    Paul: Only about 20 issues, half closed now. We'll discuss only open issues during this meeting. Decisions are made on the mailing list, not here or today.

    Issue 20 (38:30-)

    Pasi: The differences between these options happen only if both ends have several addresses.

    Jari: I like the initiator decides approach, one reason is that when you have lots of clients connecting to a single gateway, it's easier if the gateway does not do complex things and the intelligence is in clients.

    Bill Sommerfeld: I assume this is the IKE level initiator, not phase 2 initiator?

    Paul: Yes. This is a good question that recently came up in IKEv2 bakeoff: there are two initiators, the initiator of any given exchange, and the original initiator who started the first IKE exchange. But yes, we're talking about the IKE initiator, not exchange initiator here.

    Francis: I don't understand what's the real difference between primary address (editor's note: later called "option 5") and initiator decides? Initiator decides is only for mobile to gateway case, primary address is more general?

    Hannes/Francis: (more discussion about this topic)

    Francis: It seems initiator decides won't with two multihomed gateways, because it makes one of the two peers more special than the other.

    Pasi: It does work, both ends can change addresses, but changing addresses is separated from selecting which of the available combinations to use. In option 2, each peer selects which of its own addresses gets used, but this does not work, because we already decided that we don't assume all combinations work.

    Paul: So of these options, only option 3 makes one side more special.

    Francis: We have to discuss this on the list, I don't quite see what's the difference between the proposals.

    Bill: If one of responder's addresses stops working, responder can tell initiator, and initiator picks a new pair? I think that's the right way to go, especially if you have a stateful firewall.

    Paul: We will discuss NATs more later, but we should not pick any proposal that completely breaks if there's a stateful firewall.

    Jari: The difference between options 1 and 3, in option 1 both peers make two decisions: what their own addresses are, and what pair to use for traffic. In option 3, peers still decide their own addresses, but initiator decides which pair to choose.

    Francis: Option 2 is obviously broken. You should use primary address given by the peer as destination, but choose source address yourself, like source address selection in IPv6 (editor's note: later posted to mailing list as "option 5").

    Issues 18/6/15 about return routability (54:00-)

    Paul: If address is in the certificate, it's not very relevant especially if it's an address range.

    Tero: Most certificates don't have address ranges, only individual addresses.

    Jari: Two different situations we are guarding against: complete outsiders where cookie-based test helps; the remaining stuff is about whether we trust the IKEv2 peer or not. In typical VPN case, we do, but in BTNS or opportunistic IPsec cases we might not trust the authenticated peer very much. So making this configurable might be good.

    Hannes: In mobile IP there are no return routability mechanisms between mobile node and home agent.


    Francis: We have to be more accurate when we talk about testing "before starting to use" or after; use for IKE or IPsec?

    Paul: We're probably talking about IPsec, it's hard to bomb someone with IKE traffic.

    Jari: Yes, this is for IPsec packets.

    Issue 11 about window size (61:30-)

    Francis: This is a bit related to the previous issue. I believe you don't need window size more than 1, you can retry the dead peer detection using the new address.

    Charlie: It would be better to retransmit one message than to take advantage of a larger window size, since the protocol can't make progress unless all messages are acknowledged eventually.

    Pasi: Retransmitting previous message works fine if the message was dead peer detection, but gets complicated if the message was something whose processing on the receiving end depends on the IP addresses in the IP header. Basically, MOBIKE messages for changing paths. This is the tricky case, you've started to move the traffic, but interface goes down before you've finished.

    Jari: If we are in the middle of an exchange, and something bad happens, we cannot do another mobike message exchange since the previous packet is blocking it.

    Paul: From the bakeoff, a number of implementors are not planning to do window size greater than one.

    Issue 19 (67:50-)

    3. MOPO-IKE by Pasi Eronen


    Example about path test message (75:00)-

    Paul: This is important issue, do we want to know the status of all address pairs all the time, or it is enough to know one pair that works.

    Tero: What happens to the original information exchange? Do we retransmit that using the new addresses?

    Pasi: Good catch, the slide has a mistake. Yes, we retransmit it using the new addresses before sending the change path message.

    Tero: If we are going to retransmit the original message anyway, why do we need a separate path test message?

    Pasi: It works fine if the message was dead peer detection. One case where a separate message helps is if you want to test the old path to see if it has come back up before you decide to move the traffic, and without disrupting the traffic on the working path.

    Tero: I'm not sure a separate message is needed.

    Pasi: It may be possible to avoid it, but probably complicates the protocol.

    Jari: What happens if the message was a MOBIKE message about changing paths, instead of dead peer detection or creating a child SA?

    Pasi: In MOPO-IKE it actually works, because the IP addresses are not inside the IKE payload, but in the IP header.

    Return routability (83:45-)

    Raj Patil: Is this to address same threats as in MIP?

    Pasi: No, this is a different threat; MIP does not do return routability between MN and HA, because that threat was not considered important. Here it's not considered very important either, but we do it anyway because it's easy.

    Raj: What do you get by doing it?

    Pasi: If I connect to my VPN gateway, I can't claim to be somewhere that I'm not. Basically, authenticated client can't do denial of service (on itself, really) so easily.

    Jari: MIP does not do the test between MN and HA, but perhaps it should have done. For VPNs, this does not matter that much, but for some future zero-config things, we might not be able to trust the other party that much.

    Conclusions and moving forward (91:30-)

    Jari: Interest usually comes with a window of opportunity, it does not last forever. I agree that we should pick a good enough solution rather than wait for a perfect one.

    4. NAT-related issues from design presentation by Hannes Tschofenig


    UDP encapsulation (100:10-)

    Jari: Is UDP encapsulation dictated by policy or detection of NAT?

    Hannes: You might want UDP encapsulation even if no NAT was detected, if you have a stateful packet filtering firewall.

    Pasi: In normal IKEv2 NAT traversal, client can claim to be behind a NAT even if it isn't. This might be useful if a stateful firewall wants to match incoming and outgoing packets, and it can't do that with plain ESP.


    Pasi: Is there a need for more complex policies that NAT-T on/off?

    Hannes: Related to NAT prevention, if you are certain that you're not behind a NAT, you could use information from IKE payload instead from IP header.

    Paul: Is that even allowed in IKEv2 NAT-T?

    Pasi: NAT prevention is something you can do if you don't support NAT-T.

    Tero: For example, if you have two multihomed VPN gateways, and you know there never are NATs, you can disable NAT traversal and, in addition to that, authenticate the IP address changes. So you want to move the information from IP header, which is not protected, inside the payload.

    Hannes: Another issue is whether we do NAT detection each address pair.

    Pasi: Yes, we don't have global NAT present/not present flag, but flag for each address pair.

    Paul: Why would you not do it, if you have the capability?

    Responder behind NAT (108:50-)

    Paul: BEHAVE WG is also working on NATs, but from a different point of view.

    Pasi: Much of the work in BEHAVE is for people who build NATs, but we're not building NATs, but rather working with existing NATs.

    Hannes: They also have terminology about classification of NATs that we could use.

    Francis: Two concerns about NAT traversal. We already have NAT-T in IKEv2 which works well. And there is lots of IPR about that.

    Paul: If you know about any IPRs about the things we're working on, it's your responsibility to notify IETF. IETF web pages have instructions.

    Francis: I know only the IPRs which are already on the web page.

    Pasi: Since MOPO-IKE reuses IKEv2 NAT traversal, same IPRs obviously continue to apply. But it's good to keep implementing NAT-T optional, so that you can implement MOBIKE without NAT-T if you want.

    James Kempf: Would it be sensible to have NAT support in a separate draft?

    Paul: Maybe, but maintaining many documents is a pain.

    James: If NAT-T is holding up implementations then we should move it to another draft.

    Pasi: All the implementors I have heard of want NAT traversal, and will not implement this without NAT support.

    Jari: Agree with Pasi on that issue. About splitting the document, base IKEv2 spec already has NAT-T in the same document; we're trying to work with that, not respecify it.

    Hannes: In basic IKEv2 NAT-T you do NAT detection in the beginning, here we should do also when moving.


    Jari: Next steps; it seems on most issues we have a common understanding, so we'll try to get decisions made on the mailing list.

    Paul: If you have opinions about these issues, please post on the mailing list, even if you have not been active in the mailing list before. Even saying "yes, I agree" or "no, I disagree" is helpful.

    (end at 123:10)


    Agenda and Document Status
    Design of the MOBIKE Protocol
    Mobility Protocol Options for IKEv2 (MOPO-IKE)