Skip to main content

Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
RFC 4621

Revision differences

Document history

Date Rev. By Action
2018-12-20
08 (System)
Received changes through RFC Editor sync (changed abstract to 'The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol …
Received changes through RFC Editor sync (changed abstract to 'The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).

This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded. This memo provides information for the Internet community.')
2015-10-14
08 (System) Notify list changed from mobike-chairs@ietf.org to (None)
2013-02-23
(System) Posted related IPR disclosure: SSH Communications Security Corporation's Statement about IPR related to RFC 4621
2006-11-08
08 (System) Request for Early review by SECDIR Completed. Reviewer: Sandra Murphy.
2006-08-10
08 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2006-08-10
08 Amy Vezza [Note]: 'RFC 4621' added by Amy Vezza
2006-08-09
08 (System) RFC published
2006-05-22
08 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-05-15
08 Amy Vezza IESG state changed to Approved-announcement sent
2006-05-15
08 Amy Vezza IESG has approved the document
2006-05-15
08 Amy Vezza Closed "Approve" ballot
2006-05-12
08 (System) Removed from agenda for telechat - 2006-05-11
2006-05-11
08 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza
2006-05-11
08 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert
2006-05-11
08 Brian Carpenter
[Ballot comment]
Observation from Erik Nordmark:

> FWIW draft-ietf-mobike-design-08.txt section 5.6 seems to imply that
> MOBIKE can be extended to deal with transport mode. …
[Ballot comment]
Observation from Erik Nordmark:

> FWIW draft-ietf-mobike-design-08.txt section 5.6 seems to imply that
> MOBIKE can be extended to deal with transport mode. That claim was
> removed from mobike-protocol (since the combination PAD and inner IP
> address authorization doesn't exist for transport mode), so presumably
> it makes sense to fix that text in mobike-design as well.
2006-05-11
08 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2006-05-10
08 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to Yes from Undefined by Lisa Dusseault
2006-05-10
08 Lisa Dusseault
[Ballot comment]
This is a useful introductory document to MOBIKE.  If there is sufficient energy to expand on a couple things, then I hope these …
[Ballot comment]
This is a useful introductory document to MOBIKE.  If there is sufficient energy to expand on a couple things, then I hope these suggestions will be helpful in pinpointing what an introductory-level reader can get confused by :)

The acronym MN is never expanded, nor is NAT-T (neither are those expanded in RFC 4301 or 4306)
The acronym SPI is not expanded in this doc though it is in IKEv2.

I found the first mention of Notify as a negative comparison "... a more efficient format than the Notify payload is needed..." to be confusing, since before this Notify is not mentioned.

The return routability section is hard to understand.  Is it really about authorizing peer address changes or only about return routability checks? (I think the former so the title is misleading).  Some sentences are incomplete ("In this case A protection against an internal attacker, i.e. the authenticated peer forwarding its traffic to the new address, would not provided. ").  Some paragraphs ask questions and don't answer them.
2006-05-10
08 Lisa Dusseault [Ballot Position Update] New position, Undefined, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-05-10
08 Jari Arkko [Ballot Position Update] New position, Recuse, has been recorded for Jari Arkko by Jari Arkko
2006-05-10
08 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded for Ross Callon by Ross Callon
2006-05-10
08 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Undefined by Cullen Jennings
2006-05-10
08 Cullen Jennings
[Ballot comment]
First of all, I'm not sure if this is a WG document or not because the WG seems to be closed. I'm wondering …
[Ballot comment]
First of all, I'm not sure if this is a WG document or not because the WG seems to be closed. I'm wondering how we will deal with the changes that may come up in review. Given the protocol document has already been approved, I think this is all "not critical" and don't care if any of the following items are addressed or if anyone ever sends me an email on any of them. I did try and read this carefully but it is a lot to grock and it may be that all the things I bring up below are answered in the document and I just missed it.

The term address confuses me in the document - I am never sure if it means an ip address or the pair of ip address and port. For example, imagine I have a notebook computer in an enterprise that is behind a NAT and it has a wired and an 802.11 connection. The port will change but the IP address will not. Does all of this work in this case?

The discussion about return route-ability and uses of certificates with multiple IPs is interesting. However, in 5.5.3 I don't actually understand the approach taken. I don't understand how the random cookie works - is this something both sides know before the address change then use to validate the new address? Or is this something sent back and forth on the new address after than change? Why is the cookie needed given an ike transaction takes place? I don't understand why this would be made optional. The argument that we are no worse that NAT-T is, well, pretty sad given we could be better than that. I'm not claiming there is a problem in the final protocol here - I'm just not understanding what is probably one of the key parts of this document. Jari explained this to me  so I do get it now but I'm not sure someone reading the document would.

I think this document needs a normative reference to NAT-T RFC 3947. I could not make sense of it without reading this.

In section 5.2.2 I think the term symmetric NAT is pretty vague and could be much more specifically described as "Address or Port Depended Filtering" as defined in the behave stuff.

A boxes and arrows style message flow of a transition from one address to another would have helped make this understandable.

In section 6.2, I'm concerned about if it is possible to get the full address list. Say I had a notebook computer with wired address 10.0.0.1 behind nat 1.1.1.1 and the notebook computer also had a wireless interface with address 192.168.0.2 behind nat 2.2.2.2. Clearly I have 4 addresses - however the far end is going to at frist think I have three, 10.0.0.1, 192.168.0.2, and 1.1.1.1. Then when switching to wireless, it will get updated to 10.0.0.1, 192.268.0.2 and 2.2.2.2. The 1.1.1.1 which is the current one in use gets dropped from the list. Is this right? Will this cause any harm? What does this list get used for?

The term "bombing" get introduced with no definition - I understand it but I don't know how common a term it is.
2006-05-10
08 Cullen Jennings [Ballot Position Update] New position, Undefined, has been recorded for Cullen Jennings by Cullen Jennings
2006-05-10
08 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2006-05-10
08 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu
2006-05-09
08 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2006-05-09
08 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-05-09
08 Yoshiko Fong ANA Comments:

As described in the IANA Considerations section, we understand this document to have NO
IANA Actions.
2006-05-01
08 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2006-05-01
08 Russ Housley Ballot has been issued by Russ Housley
2006-05-01
08 Russ Housley Created "Approve" ballot
2006-05-01
08 (System) Ballot writeup text was added
2006-05-01
08 (System) Last call text was added
2006-05-01
08 (System) Ballot approval text was added
2006-05-01
08 Russ Housley State Changes to IESG Evaluation from AD Evaluation by Russ Housley
2006-05-01
08 Russ Housley Placed on agenda for telechat - 2006-05-11 by Russ Housley
2006-04-20
08 Russ Housley State Changes to AD Evaluation from Publication Requested by Russ Housley
2006-03-21
08 Russ Housley [Note]: 'PROTO Shepherd: Paul Hoffman <phoffman@vpnc.org>' added by Russ Housley
2006-03-21
08 Russ Housley Draft Added by Russ Housley in state Publication Requested
2006-03-03
08 (System) New version available: draft-ietf-mobike-design-08.txt
2006-01-30
07 (System) New version available: draft-ietf-mobike-design-07.txt
2006-01-09
06 (System) New version available: draft-ietf-mobike-design-06.txt
2005-12-02
05 (System) New version available: draft-ietf-mobike-design-05.txt
2005-10-21
04 (System) New version available: draft-ietf-mobike-design-04.txt
2005-07-20
03 (System) New version available: draft-ietf-mobike-design-03.txt
2005-02-21
02 (System) New version available: draft-ietf-mobike-design-02.txt
2005-01-03
01 (System) New version available: draft-ietf-mobike-design-01.txt
2004-06-28
00 (System) New version available: draft-ietf-mobike-design-00.txt