Mobile IPv6 related specifications in an IPsec/IKE context (overview and comments)

A little tour of MIPv6 specs in an IPsec/IKE context (and vice versa).

Goals

On this page, I provide a list of reference documents that might be of interest for a reader trying to understand how MIPv6 can be used in IPsec/IKE environments.

Keep in mind that the interests and lacks of those documents are commented based on the way they help in the use of IPsec/IKE with MIPv6.

Also note that some comments expressed here are subjective even if they are backed up by the time spent reading the documents, implementing them and trying to improve the way MIPv6 and IPsec/IKE interact on real world implementations.

IMHO, they simply stress the fact that MIPv6 has been developed to benefit from IPsec when the assumption on its usability and availability in common environments could be done, but not for large scale deployments in IPsec/IKE-protected environments.

Interesting documents

RFC 3775 ("Mobility Support in IPv6")

Mobile IPv6 specification document (165 pages).

It defines the operation of HA, MN and CN, along with the format of messages (including specific IPv6 extension headers). Route Optimization mechanism for direct communications between MN and CN is also covered.

As stated in the document, the mobile node and the home agent MUST use an IPsec SA to protect the integrity and authenticity of the BU and BA.. Some other signaling traffic are also expected to be protected by IPsec.

IPsec protection of data traffic between the MN and its HA is not made mandatory, though. In the document, when IPsec protection is expected, static keying MUST be supported and dynamic keying (using IKE) MAY be supported.

Between MN and CN, IPsec is usually not expected to be usable when direct communications take place. Specific mechanisms are defined to provide some level security by protecting the setup of Route Optimization (RO), mainly proof of address of ownership. This does not means that IPsec cannot be implemented between two MN or a MN and its CN, but it is kind of out of the scope of the specification.

Regarding IPsec, the document provides expectations of support, some initial descriptions of interactions between MIPv6 and IPsec stacks (Section 11.3.2). In practice, its companion document on the topic (RFC 3776, see below) covers IPsec-related questions for the protection of MIPv6 signaling between a MN and its HA.

Comments:

IPsec requirement:
The fact that MIPv6 specification mandates the use of IPsec for the protection of the signaling traffic between the MN and its HA is in fact quite logical. The relationships between the MN and its HA (they belong to the same trust domain) and the direct availability of IPsec (mandated by IPv6 specification) explain the choice. The prerequisites associated with the deployment of dynamic keying explain why only static keying has been made mandatory. Simply put, the specification goes pretty much as far as possible without making too strong assumptions. For instance, the decision to design a specific mechanism providing some (simple) protection of Route Optimization between MN and CN is easily explained by the a priori lack of trust relationship between those two entities (they do not belong to the same trust domain).
IKE version
Regarding IKE, at the time when MIPv6 was standardized (June 2004, including RFC 3776 described below), IKEv2 was still in draft at the IETF (RFC 4306 was published in December 2005). For that reason, all the comments associated with the used of dynamic keying for the negotiation of SA protecting MIPv6 traffic apply to IKEv1. RFC 4877, published in April 2007 normalizes "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture". The document is analyzed below.
Lack of a communication mechanism between MIPv6 and IPSec/IKE:
There are many places in RFC 3775 where MIPv6 operations expect some specific actions to be performed by the IPsec stack (and IKE). In practice, the specification does not defines any specific mechanism to synchronise the operations of MIPv6 with those of IPsec (and IKE). Even if some external proposals (MIGRATE, ...) have been made to normalize such extensions, the item has never been considered by the working group as a primary concern. The result is that the use of MIPv6 in IPsec/IKE environments is not well defined.
Useless Key Managament Mobility Capability (K-bit):
MIPv6 specification defines a specific flag in BU and BA messages exchanged between MN and HA to theoretically allow them to advertise the level of mobility support their key management protocol implementations (i.e. IKE daemon) support. In practice, even if the specificationn of this flag looked like a good idea, it is useless in practice, for many different reasons. First, because their is no defined interface between the IKE daemon and MIPv6, their is no automatic way for the MIPv6 module to be aware of the level of support and/or configuration of the IKE daemon that will handle the negotiation of SA (if any). In practice, this implies that the MIPv6 module must be manually configured to advertise a correct value. Furthermore, because the exchange of the flag between the peer happens at the MIPv6 level, some synchronization and/or interaction between the MIPv6 module and the local IKE daemon are required before/on movement to follow the expectations of the remote peer. Again, because no interface between MIPv6 and IPsec/IKE is currently standardized, this is simply a broken feature. Another argument against the K-bit is simply related to the following fact: an vanilla (i.e. unpatched/unmodified) IKE implementation is not able to bootstrap, i.e. perform the initial negotiation of transport mode SA that will protect the exchange of BU and BA. This is covered in more details below when discussing MIGRATE mechanism but simply put, the use of IKE with MIPv6 de facto requires modifications of the IKE implementation to support MIPv6. K-bit would only be useful between MN and HA with IKE implementation modified to support only bootstrapping and not movement, which is pointless considering that an all-in-one solution (MIGRATE) for that purpose is available. Our (subjective) view on that is simply that some update of MIPv6 specification should make the support of movement by IKE mandatory when used with MIPv6.
Use of IPsec/IKE between MN (i.e. IPsec RO)
Mobile IPv6 has never been designed to support direct communications between Mobile Nodes belonging to a common trust domain. In practice, the hypothesis that lead to the design of RO and asssociated RRP mechanism are simply the lack of existing trust relationship between the peers.

RFC 3776 (Using IPsec to Protect Mobile IPv6 Signaling Between MN and HA)

As stated in its abstract, the document discusses in more depth than RFC 3775 how MIPv6 uses IPsec to protect signaling between the HA and the MN. Those discussions also include Dynamic Keying. Note that this Standards Track document does not cover the details of IPsec protection of data traffic tunneled between the MN and the HA.

As for RFC 3775, only IKEv1 (RFC 2409) is discussed (in the context of the old IPsec Security Architecture, i.e. RFC 2401). RFC 4877 updates the content of RFC 3776 for IKEv2 and the new IPsec Security Architecture (RFC 4301).

A strentgth of the document is the care that has been taken in all the hairy details. For instance:

Bootstrapping: as discussed in the introduction, when IKE is used to establish security associations between the MN and the HA, "great care is needed".
Packet format: the document goes in the details of packet format and precisely explain how ESP header, MIPv6 specific IPv6 extensions header (RH2, HAO in DestOpt) and MIPv6 Upper Layer protocol header (MH) should be used together for the different kinds of signaling traffic. This includes both wire format and how things can happen in stacks.
Alternat Care-of Address Option: the reasoning behind the inclusion of the option in the BU sent by the MN (so that it is protected by IPsec) is commented in Section 3.1. Note that Jarri Arkko has issued a draft to in order to update RFC 3775 to have the content of the AltCoA Option checked against the content of the source address found in the IPv6 header.
Home Network vs. Foreign Network discrimination: when useful examples are provided for both cases.
Care taken in documenting things that remains stable and things that changes, most notably with regard to addresses (HoA vs CoA):
- BU/BA (section 3.1): because those signaling messages are protected by IPsec in transport mode, and the associated SA/SP never reference the CoA but the HoA, they do not need to be updated. Note that this does not mean that movement is transparent for the IKE deamon when dynamic keying is used. On the contrary, some care (and a mechanism not covered in the document, like MIGRATE) is needed to make things work smoothly.
- HoTI/HoT (section 3.2): for those messages, protected using IPsec in tunnel mode, movement requires changes in the SP and SA (endpoints updates).
- MPS/MPA:
- Data packets: those will use IPsec in tunnel-mode. On movement, just like for HoTI/HoT, the references to the CoA in SP/SA must be updated so that the tunnel endpoints do match the new CoA.
because BU/BAthe document discusses protection of transport mode, the addresses of the MN in the SP and SA are the HoA and never the CoA. But
Distinctions between HA and MN specific needs: for instance with regard to the source address check at the end of section 3.2.

Comments:

FIXME
FIXME

FIXME

draft-sugimoto-mip6-pfkey-migrate-04 (PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE)

Extends standard PF_KEY framework in order for the MIPv6 module to be able to interaction with the IPsec stack and the IKE daemon.

Even if RFC 3775 and RFC 3776 expect some specific actions to be performed by the IPsec stack and the IKE daemon when those are used in a Mobile IPv6 environment, no specific mechanism is defined to allow the MIPv6 module to warn/control them.

This fourth version of MIGRATE draft extends PF_KEY framework by defining a new message (MIGRATE) and a new extension (SADB_X_EXT_PACKET). Those are used by the MIPv6 module to interact with the IPsec and the IKE daemon. The document provides for instance the missing interface required to allow both the IPsec SA to survive movement, the initial IKE negotiation to be performed between the MN and it HA, and the update of IKE_SA by the IKE daemon upon movements.

Comments:

Complexity associated with SADB_X_EXT_PACKET:
From a theoretical standpoint, the idea of the SADB_X_EXT_PACKET proposed by Francis Dupont in the draft is a good one, because it mades available the whole context (the triggering packt) to the IKE daemon, allowing more specific actions to be taken by the Key Manager. For the specific case of a triggering BU received by the IKE daemon, specific code is expected to allow the daemon to select the CoA as the source address to negotiate SA instead of the HoA. From a more global standpoint, such an extension could possibly allow PFP mechanism to be implemented.

But in practice, the implementation of the mechanism is in fact more complex than one would expect. For instance, in Linux kernel, the whole packet expected to be carried by the extension is not available at the time when the ACQUIRE message is broadcasted to registered Key Managers. The associated patch for the extension I maintained for quite some time for Linux kernel had to specifically reconstruct the packet with a fake IPv6 header and extension headers. The associated patches I maintained for racoon had to specifically treat the packet and parse it completely just to access the CoA from the AltCoa Option. In the end, this lead to a lot of both kernel and userland code which was extremely painful to maintain in both cases.
IKE_SA update is only a side effect of tunnel mode SA existence

draft-ebalard-mext-pfkey-enhanced-migrate-00

In order to solve the technical issues associated with current design described in previous item , I proposed some changes to Sugimoto-san, Nakamura-san and Francis. A review by Sugimoto-san showed that proposed changes were fine from a technical standpoint. At the beginning (a long time ago), I expected the changes to make thei way to 05 version of the draft but the lack of feedback from Francis (SADB_X_EXT_PACKET was its proposal) and the fact that 04 version of the draft expired lead me to publish an informational document as a follow-up to MIGRATE.

Simply put, the proposal only keeps the MIGRATE part of 04 version (removing SADB_X_EXT_PACKET) and further extends it with a simple container (SADB_X_EXT_KMADDRESS). This new container explicitely provides the source and destination addresses to be used by IKE for negotiating SA with its peer.

FIXME

RFC 4877 (Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture)

RFC 3776 commented above was based on IKEv1 (RFC 2409) and the "old" IPsec Architecture (RFC 2401). RFC 4877 describes MIPv6 operation with the revised IPsec Architecture (RFC 4301) and IKEv2 (RFC 4302)

Many parts of the initial document have been adjusted to support the changes introduced by RFC 4301 and the improvements/changes brought by IKEv2. Those are basically listed in the introduction of the document.

But some additional mechanisms/capabilities have been added, among which some are worth commenting. For instance, Section 9 of the document introduces a feature that HA and MN may support (as stated at the end of Section 4.1): the dynamic remote configuration of the Home Address.

It is interesting to note the collusion that is made in section 4.1 providing the requirements for the mechanism:

   o  The home agent and the mobile node MAY support remote
      configuration of the home address as described in Section 9.  When
      the home agent receives a configuration payload with a CFG_REQUEST
      for INTERNAL_IP6_ADDRESS, it must reply with a valid home address
      for the mobile node.  The home agent can pick a home address from
      a local database or from a DHCPv6 server on the home link.

There is a mix here in MIPv6 and IKE vacabulary: discussed payloads are part of IKE exchanges; they are sent by the IKE daemons on the MN and the HA. The result is that the problems of the interactions between MIPv6 and IKE daemons are avoided, as if they were a unique entity. Among the questions that a developer will certainly ask are:

How does the MIPv6 module request the IKE daemon to ask for a HoA?
How does the MIPv6 module is expected to suggest a Home Address as described in Section 9? Or is it configured in the IKE modue?
How does the IKE daemon eventually returns the HoA to the MIPv6 module?
...

Note that you will not find any discrimination in Section 9. To finish the comments on that topic of Home Address assignment using IKE, here is quote from Section 7.2.1 which (IMHO) introduce the complexity of using IKE for Home Address assignement:

   In the examples shown above, the home address of the mobile node
   might not be available all the time.  For instance, the mobile node
   might not have configured a home address yet.  When the mobile node
   acquires a new home address, it must either add the address to the
   corresponding SPD entries or create the SPD entries for the home
   address.

   The home agent should have named SPD entries per mobile node, based
   on the identity of the mobile node.  The identity of the mobile node
   is stored in the "Name" selector in the SPD [5].  The home address
   presented by the mobile node during the IKE negotiation is stored as
   the remote IP address in the resultant IPsec security associations.
   If the mobile node dynamically configures a home agent and the home
   address, the home agent may not know which mobile nodes it is
   supposed to be serving.  Therefore, the home agent cannot have SPD
   entries configured per mobile node.  Instead, the home agent should
   have generic SPD entries to prevent mobility header traffic that
   requires IPsec protection from bypassing the IPsec filters.  Once a
   mobile node authenticates to the home agent and configures a home
   address, appropriate SPD entries are created for the mobile node.

To sum up the way I understand things:

IKE is expected to get the information from MIPv6 module that it needs to asks for a HoA,
There should be some way for the MIPv6 module on the MN to pass a hint on the HoA to the IKE module,
The IKE module should be able to start an exchange even though it is not triggered by a packet requesting protection (like a BU),
The IKE module should be able to provide the address retrieved from the IKE daemon on the HA to the MIPv6 module
Some entity (IKE or MIPv6 module) should update the SPD entries with the HoA (possibly using MIGRATE ?)
The IKE deamon on the HA should end up creating a temporary PAD entry linking the peer identity and the new address
....

I'd like to see that in a real world implementation. I also think that there is no way that two implementation of an IKE daemon and a MIPv6 module work together out of the box with the obvious lack of interface created by the collusion between IKE and MIPv6 operations in reference documents.

Leaving that point, just like it is the case for RFC 3776, the document still discusses the K-bit feature (Section 4.4 and 7.4) which I consider useless and broken for the reasons pointed out by Sebastien in its draft.

Goals

Interesting documents

RFC 3775 ("Mobility Support in IPv6")

RFC 3776 (Using IPsec to Protect Mobile IPv6 Signaling Between MN and HA)

draft-sugimoto-mip6-pfkey-migrate-04 (PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE)

draft-ebalard-mext-pfkey-enhanced-migrate-00

RFC 4877 (Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture)

RFC 4640 (Problem Statement for Bootstrapping Mobile IPv6 (MIPv6))

RFC 5026 (Mobile IPv6 Bootstrapping in Split Scenario)

RFC 2401 (Security Architecture for the Internet Protocol), RFC 2402 (AH), RFC 2406 (ESP)

RFC 2408 (ISAKMP), RFC 2409 (IKE), RFC 2412 (The OAKLEY Key Determination Protocol)

RFC 4301 (Security Architecture for the Internet Protocol), RFC 4302 (AH), RFC 4303 (ESP)

RFC 4306 (IKEv2), RFC 4307 (Cryptographic Algorithms for Use in the IKEv2)

RFC 4555 (IKEv2 Mobility and Multihoming Protocol (MOBIKE))

draft-ietf-mip6-nemo-v4traversal-06