2.7.9 IKEv2 Mobility and Multihoming (mobike)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. 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-10-03


Paul Hoffman <paul.hoffman@vpnc.org>
Jari Arkko <jari.arkko@ericsson.com>

Security Area Director(s):

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

Security Area Advisor:

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

Done  Publish first draft on 'IKEv2 Address Update', covering issues 1 to 4 from the above list
Sep 2005  Submit IKEv2 Address Update document to IESG for Proposed Standard RFC
Jan 2006  Submit Reduced Tunnel Overhead Mode for IPsec to IESG forInformational RFC
Jan 2006  Publish first draft on 'PFKEY Extension for Address Updates' (issue 6 above)
May 2006  Publish first draft on 'Reduced Tunnel Overhead Mode for IPsec' (issue 5 above)
May 2006  Submit PFKEY Extension for Address Updates document to IESG for Informational RFC


  • draft-ietf-mobike-design-04.txt
  • draft-ietf-mobike-protocol-05.txt

    No Request For Comments

    Current Meeting Report

    IETF-64 meeting of the MOBIKE (IKEv2 Mobility and Multihoming) WG
    Wednesday, November 9th, 2005
    Chairs: Paul Hoffman and Jari Arkko
    Notes takers: Pete McCann and Shinta Sugimoto (merging and edits by Jari Arkko)
    Mailing list and issue tracker: http://www.vpnc.org/ietf-mobike
    Presentations: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64
    Part I
    Remaining Protocol WGLC Issues
    Design Draft Update
    Next steps
    Part II
    Extensions and new work
    Trigger API for MOBIKE
    Transport Mode Usage Issues
    WG Document Status (presented by Jari Arkko)
    New revision of design document was published.  Still some work but it
    is getting close to done.
    Most of the effort recently has been discussing protocol document - it
    went through WGLC. The plan is to get issues resolved and send it up
    to IESG.
    Related Work, WG members were requested to read and review
    - mip4-mobike-connectivity-00.txt
    - Transport mode extension
    - pfkey-extension
    - trigger-api
    MOBIKE Protocol Document Status (presented by Pasi Eronen)
    WGLC ended on Oct 19th.
    Approx 16 people commenting, filed as 29 issues in the tracker.  Most
    if not all issues were clarifications that did not change the
    Version 05 submitted on October 24th
    Version 06.a snapshot on Monday (link sent via e-mail)
    A lot of mailing list traffic in October, right before the cut-off.
    Editorial issues handled in version -05
        Issue 47 More comments from Mohan
        Issue 48 Editorial comments from James
        Issue 49 Editorial comments from Maureen
        Issue 50 More editorial comments from Maureen
        Issue 53 Editorial comments from Pete
        Issue 62 Editorial comments from Francis
        Issue 65 Editorial comments from Jari
        Issue 66 Imprecise NAT explanation
        Issue 67 Certain vs. possible changed address
        Issue 69 RR requirements
    Other issues handled in version -05
        Issue 44 NAT mapping changes and rekeying
        Issue 55 MOBIKE scope and limitations
        Issue 61 Version number, again
        Issue 57 Question about initiator decides
        Issue 63 Extensibility and payload
    Issues handled in version 06.a
        Issue 45 Clarifications to security considerations
        Issue 46 Questions about additional addresses
        Issue 58 Deleting addresses
        Issue 72 More editorial comments from Tero
        Issue 59 Editorial comments from Tero
        Issue 54 Editorial comments Marcelo
        Issue 64 Editorial comments and questions from Stephane
        Issue 56 Ingress filtering compatibility
        Issue 68 Conformance requirements
    Open issues:
        Issue 52 Security of address updates
        Issue 60 Addresses in IKE_SA_INIT/AUTH
        Issue 71 Failing RR
    Pasi went through the issues that deserved more discussion:
    Issue 44 - How to detect NAT mapping changes
      Rekeying the IKE_SA can lead the initiator to believe NAT mappings
      have changed.  Noted in document
    Issue 55 - MOBIKE scope and limitations
      Re-writing sections 1.2 (Scope and Limitations) and 3.1 (Initial IKE
    Issue 61 - Version number, again
      Now says MOBIKE_SUPPORTED data field is set empty when sending, but
      ignored when receiving. Allows for future extensibility and version
    Issue 57 - Question about "initiator decides"
      Not reopening old issue. Hopefully design document answers the part
      about "why".
    Issue 63 - Extensibility and payload
      Comment about what extensions we might want to do in the future. Pasi
      chose not to put this in the protocol document, might go into the
      design doc
    Issue 56 - Ingress filtering compatibility
      -06.a now sasy explicitly that MOBIKE sends reply to same
      address/port from which the request came
    Issue 68 - Conformance requirements
      Clarified in -06.a, but discussion continued; Pasi thinks it is now
    Issue 51 - SPI Collisions
      Implementation Considerations - IP address is not a good identifier
      for a host. Not necessarily unique (NATs). Does not identify single
      host over time (DHCP). Can change (MOBIKE). Ownership not
      necessarily authenticated.
      For these reasons (remote IP, remote SPI) is not a good identifier
      for outbound IPSec SAs
    Issue 70 Non-SAD updates
      Jari: should highlight the bad implications of SPI collisions. If
      implementations don't implement 2401 correctly, traffic might be
      sent over the wrong SA and using the wrong keys
      This will be a part of the implementation considerations.  This is a
      bug based on interpretation of RFC2401, but Mobike could make it
      worse.  2401bis has this right (but many implementation details are
      beyond the scope of the spec).
      Added "Implementation Considerations" appendix to point out that
      implementors should be extra careful in this area
      No objections.
    Issue 52 - Security of address updates
      Questions/comments about the security considerations text from
      Tuomas Aura. Raised before NO_NATS_ALLOWED was made mandatory
      (unless doing NAT-T).  Suggested heuristics to guess NAT status from
      Pasi's proposal: Do not add address-based heuristics: better to
      detect NATs using NAT_DETECTION_*_IP. It seems no changes needed.
      No objections.
    Issue 60 - Addresses in IKE_SA_INIT/AUTH
      Current text: responder takes addresses from IEK_SA_INIT exchange,
      except when doing NAT-T (change to port 4500). When doing NAT-T,
      initiator could move to port 4500, thus, addresses taken from 1st
      Tero's proposal: use 1st IKE_AUTH even when not doing NAT-T. Side
      benefit is that NO_NATS_ALLOWED can be moved to IKE_AUTH.
    Issue 71 - Failing RR
      Problem: Initiator requests moving traffic to new address (sends
      UPDATE_SA_ADDRESSES) but responder requires return routability, but
      the new path has already failed, then responder does not get a reply
      When there's no attack, either of these should happen: Initiator
      notices the situation and can change to some other address
      (preferable) or Responder changes back to the previous address (doesn't
      work in all situations).
      Tero's proposal: clarify text about triggering dead peer detection
      We might trigger DPD if they don't have the addresses we're
      Mohan: How would it receive the packet?
      Pasi: responder is sending packets 
      Picture of call flow discussed.
      Updated IKE SA but hasn't moved the traffic
      If the new path fails at exactly the right time, it could happen
      Jari: What happens with the failing RR exchange?  If you do that to
      the 2nd address, it works.  You have to do another one, can't use
      the same nonce.  Pasi: when initiator notices the new path doesn't
      work, it retries Do a return routability on the old path
      Tero Kivinen: If the address is changed, then must start over
      return-routability. Jari: After this explanation, I am happy with
      prooposed solution
      Mohan: if responder is going to do return routability, does he
      update the sa with the remote address? Pasi: yes
      No objections.
    Next steps
      Close remaining issues.  Send to AD evaluation in 1-2 weeks.
      Jari: Should take it to the list.  In the room people don't have objections.
      Pasi: Would not like this to be another WGLC.  Jari: Last calls are
      just that: they are not recurring.
      Stephane Beaulieu: Are we automatically changing to 4500? Pasi: yes,
      if both implementations support NAT-T. Stephane Beaulieu: There are
      a couple of places in the draft that contradict that.
    Design Draft (Tero Kivinen)
    Only 2 people have read it (including Tero).
    Question: Do we need to send this at the same time as the protocol
    draft?  Jari: it is enough to have some version of it available by the
    time IESG evaluates protocol document. Tero would like to have them at the
    same time, will clarify the background.
    Introduction and terminology
      Tero thinks the introduction is good enough, and does not require
      more work Do we need the terminology section at all?  Can we get rid
      of some terms?  (one of Pasi's questions) Keep some terms?
      Jari: It may be possible to remove some terms, but might imply that
      remaining terms need to change.  "Working address pair" implies L2
      telling you it is ok.  Hannes: Added many terms in a previous
      version to make things clear.  What is a path, what is an
      operational path.  Jari's document on shim6 was quite useful.  We
      should leave many of those terms.  Synchronize them with the main
      protocol document if they are not synchronized.
      Tero: Quite a lot of terms are used in only 1 or 2 places.  Agree
      they do make some things easier to understand.
      The design draft lists the basic scenarios, where the protocol
      should work In case we remove some terms this might need some
      Mostly ok no changes needed
    Design Considerations
      Some sections had quite a big re-write: 
      - Choosing addresses
      - NAT Traversal
      Some might still need some work
      - Return routability
      - IPSec Tunnel and Transport mode
      Should be ok:
      - Scope of SA changes
      - Zero address set functionality
    Protocol Detail Issues
      New or rewritten:
      - Updating address list
      - Path testing and window size
      Should be ok:
      - Indicating support for mobike
      - Message presentation
    Additional Sections
      Do we need more text on simultaneous movement?
      Jari: Part of the process is about having the right set of things to
      talk about Let's make it too small rather than too lengthy Tero: in
      this text there were cases of simultaneous movement
    Old sections rewritten to other sections
      - Changing a preferred address and multi-homing support
      - Storing a single or multiple addresses
    Add text about issue 71 probably in RR
      Might still need some work (Terminology, scenarios, scope, and perhaps
      some new sections)
      Most of the text should be ready. Are we ready to WGLC now?  Maybe
      it would make people read it.
      Jari: I hope the question applies after you have updated the doc?
      Tero: Yes.
      Jari: Would be good to get it done in the same timeframe as the
      protocol doc
      Hannes: Because this document is a justification for the work, would be good to
      get input from outside the group to verify that.
      Pasi: Agree/disagree.  We need to make sure the design document
      explains the design in a reasonable way, so that we have some
      archival doc.  We don't want to open it up to people outside the
      working group to reset our design process.
      Jari: Right we are not redesigning anything, we are documenting the design.
      Tero: If someone suggests a new option, we might revise the design
      document to say why not.
      Jari: actually disagree: it is important that we scope the discussion tightly.
      There are an infinite number of things we could have done, do we really want
      to add an explanation for each one?  This should just document what the thinking
      was.  It may not even have consensus given a new set of people.  Of course
      if we get new information like "this is a bad idea" maybe in some cases we
      can include that but we should be careful.
      Mohan: As Pasi said, it's too late to change the protocol document.
      Hannes: I was misunderstood I was only talking about editorial changes
      Someone: I found the document quite helpful. Terms were useful too.
      Tero: That's good the one person that read it found it helpful
      Jari: Looks like consensus among the people who have read it (1
    Future extensions
    Jari: Some discussion seemed to use the phrase "open issue #x".  If we
    decide to do something new, it will be for a particular purpose not to
    revisit the protocol design choices.
    Application Programming Interface to a Trigger Database for MOBIKE (Hannes Tschofenig)
    MOBIKE has to maintain an address list for all available interfaces
    Many events for changing the address set are outside the scope of
    MOBIKE, e.g., 802.21. These information have to be combined with higher
    layer information
    Scope of the MOBIKE work discussed.
    Proposal related to Mobile IP, NSIS, whatever other internal host component.
    - Define an API to insert these information (so-called triggers) into a DB.
    - Triggers can be provided to MOBIKE and other higher layer protocols.
    - Offered services are quite similar to MIH, but can be extended for
      other protocols PF_TRIGGER IF is analogye to PF_KEY (based on BSD
      routing socket API).
    MaureenStillman: are you talking about using what was talked about in
    MIPSHOP?  Info, Command, Event?  Your word "database" = information
    service?  Hannes: There is probably room for terminology. Only talking
    about API.  What is there in the end host is someone else's
    business. Maureen: So why do you need a trigger database, why can't
    you talk an MIH event?  Hannes: DB is just conceptual, you could put
    this in one box if you want. Could have used better terms. Didn't want
    to stick exactly with the .21 work: there is not a strict dependency.
    Jari: I have a similar question: don't fully understand.  Today we
    already have some interfaces like IP can tell the application.  Are
    you proposing an overall API that can cover & Transfer information for
    all possible things like ND, DNA, .21, etc?  Or what? Hannes: That's right.
    Mohan: Linux has netlink sockets.  Hannes: Very much related, but it
    is an enhancement there might be more information.  How do we deliver
    information to upper layers? Mohan: Depending on what information.
    Pasi: This is collecting information from different places, when
    should MOBIKE change from one address to another, isn't this exactly
    what Mobile IP has to do as well? Hannes: True, have mentioned it in
    Mobile IP as well.  Not aware that they are working on a specific
    solution as well.  NSIS has similar problems.  Pasi: some OSes have
    API that have mobility today.  Linux/symbian/windows have something
    already existing.  Hannes: It is a problem that many vendors come up
    with different solutions.
    Bill Sommerfield: Not familiar with everything in MIH 802.21, seems in
    the same space as existing PF_ROUTE interface.  This deals with
    manipulating IP routing as well as get info about interfaces up/down.
    It might be interesting to integrate with PF_ROUTE. Hannes: That has
    been suggested.  We tried it with PF_KEY.
    Greg Daley: The space is worthwhile, you are doing a disservice by
    using the term trigger (remember trigtran?)  Information flow isn't
    direct to MOBIKE.  A database seems like a passive entity.  You need
    an active entity to control what is being passed up.  If you say
    database it is just a repository.  Draft-iab-link-information is very,
    very careful about which info to pass up and what to do with it.
    Hannes: I know the document.  Agree that we probably didn't use the
    best terminology it came from EU-funded project.  Because we used
    PF_KEY ... you can register to get some events back.  Greg: It
    becomes a path/route/connectivity change service, might be coming
    through DNA.  (plug)
    Someone: Agree should be done.  Relationship to past work in mobile
    IP, some people have been working on PF_MOBILITY.  Others are thinking
    about it, may be commonality.
    Mohan: Quick check 3549 already discusses netlink services available
    in linux. Greg Daley: I used 3549 netlink sockets to implement DNA.
    Hannes: If someone is interested in further discussion please comment.
    MOBIKE Extensions for PF_KEY (Hannes Tschofenig)
    Extensions to PF_KEY: PF_KEY interface to access SAD (RFC 2367) does
    not have dynamic address update supported. This is one of the core
    features in MOBIKE, and a new message has to be defined.
    Access to SPD, which is not supported in current version of PF_KEY
    Needed for example in transport mode for traffic slector updates
    Question: extend PF_KEY vs. define a new interface for SPD?
    Algorithm IDs have to be specified. Some extensions are needed.
    Conclusion: Extension to PF_KEY is needed. Procedure on PF_KEY
    extension is difficult.  RFC 2367 is not what is used today, more than
    just updating to RFC 2367 with regard to MOBIKE functionality is
    Someone: PF_KEY is interface to keys, would prefer a new interface.
    Pasi: If you are using Linux IPSec, it doesn't necessarily use PF_KEY.
    There is PF_KEY emulator.  What's in the RFC doesn't do half of what
    people want.  Hannes: Then what should we do?  Let vendors do whatever
    they want?
    Jari: Main question is not just what the IETF wants to do in this
    space, does anyone care?  Tried to do something about it 10 years ago,
    no one cared.  What's important is whether people who implement this
    would ever use what we defined.  If we have implementers coming in
    telling us they want a new interface, we should think about that.  We
    have PF_KEY extension in the charter, personally think it needs to be
    done with a bigger PF_KEY effort if any.
    Bill Sommerfield: Historically, every so often, there is some energy
    spun up, but no one gets around to writing PF_KEYv3 document.  Jari:
    Not enough, someone would have to use it.  Bill: Right, problem is
    getting all the various cats herded.  Would be interested, but there
    is too much other work.
    Tero: most implementers are going to use their own APIs anyway.  If we have a 
          workable PF_KEY stuff, then there would be emulation layers like Linux 2.6.
          We did have a PF_KEY emulation layer about 10 years ago, it was removed
          because nobody used it.
    Transport mode discussion (Mohan Partsarathy)
    Summary of what happened on the mailing list
    There are 4 different things:
    - SCTP
    - Mobile IPv6
    - IP-in-IP tunnel + transport mode SA
    - TCP/UDP + transport mode SA
    SCTP case
      SCTP (RFC 2960) supports multi-homing. SCTP just picks one address. It
      also returns a transport address list that can be used by ULP.
      Destination (and source address) of a packet can change due to various reasons
        - Apps can change the primary path at any time
        - Retransmission SHOULD use a different destination address from last time
        - SACKs to duplicate data may be transmitted using different address from the source
        - HEARTBEATS
      SCTP dynamic Address Configuration
      (draft-ietf-tsvwg-addip-sctp-12.txt) is sitting in RFC editor's queue.
      SCTP usage in IKEv1
        RFC 3554 describes SCTP usage with IPSec for IKEv1. Not a commonly used feature.
      SCTP in IKEv2
        Presumably would use MOBIKE.
      SCTP and MOBIKE usage:MOBIKE allows only initiator to change the
      addresses of the SA. MOBIKE uses only one pair at a time. Issues:
        - Similar problem exists in shim6 WG (shim6-SCTP interaction)
        - Either side of the SCTP association can change the path anytime
        - conflicting with MOBIKE?
        - SCTP HEARTBEAT vs. IKEv2 PATH_TEST conflict?
    Mobile IPv6 use case
      MN HA use transport-mode SA for protecting the BU and BAcks.  Use
      case 1 (Francis' draft): Use MOBIKE to add the home address as
      alternate address (using ADDITION_ALADDRESS_IPv6 Notification)
      Use case 2: MIPv6 has built-in support for this.
    Use of IPSec Transport mode for dynamic routing (RFC3884)
      This use case was closed as Issue 7. IKEv2 supports transport mode
      for tunnels. MOBIKE support should be similar to NAT-T support for
      IPSec protected IP-IP/L2TP tunnel.
      Mobility case: Do we update the tunnel endpoints and traffic
      selectors if mobility is needed?
      Tero: As a designed of NAT-T, whether works with transport mode is an accident.
      Mohan: The whole point of L2TP over IP was this.
      Jari: Seems like L2TP inside is just another protocol, issues with
      NAT-T and transport mode is going to be quite similar.
      Multi-homing support case: There are two possible models: Model 1 -
      Single IP-IP tunnel. Model 2 - Multiple IP-IP tunnel.  Routing
      protocols making their own decisions, MOBIKE doing its own thing.
      Potentially a bad interaction similar to SCTP?
      Pasi: Since IKEv2 doesn't create or manage IP-in-IP tunnels, MOBIKE
      shouldn't do that either.  If there is a need to create a tunnel,
      MOBIKE is not the way to do that.  Mohan: If I have a manually
      configured tunnel, IKE would still work for the outer addresses.
      Pasi: If my IP address changed, and I can fix using MOBIKE, doesn't
      mean the IP tunnel moves.
      Mohan: ...  Pasi: If MOBIKE change the address in transport mode,
      MOBIKE mods the traffic selectors, they no longer match the IP-in-IP
      packets.  We need to modify both the TS in the SA and the part that
      handles the tunnel.  For SCTP this could work in theory because it
      has a mechanism.  Mohan: But if you don't change it it will still
      work.  Pasi: The part that does IP-in-IP still uses the same
      address, doesn't match the TSs of the SA.  In transport mode you
      only have address in one place.
      Conclusion: IPSec acts like a  "shim" layer in the context of multi-homing.
      - SCTP: ?
      - MIPv6: Nothing special needed in MOBIKE itself
      - IP-IP tunnel + transport mode: RFC 3884 use case may be more common.
      Interaction with routing layer needs to be studied.
      - TCP + transport mode: Does not seem to be an interesting case?
      Jari: Is there anyone who would use any of these cases?  Maybe there's not a lot
      to be done? No one speaking.
      Maureen Stillman: problem is that there are not SCTP people here.  We need to
      get more information. Promises to ask.
      Jari: Right. Thank you.
    End of the meeting


    agenda and document status
    protocol issues
    design draft issues
    transport issues