IRO: IPsec Route Optimization (for MIPv6)


Disclaimer: in this page, I consider the data traffic exchanged between the MN and its HA is IPsec protected (tunnel mode). The signaling traffic is obviously (as requested by the specification) protected using IPsec in transport mode. I also consider that basic (unprotected) Route Optimization as defined in RFC3775 is not used. Basically, all communications between a MN and its (non-HA) peers are either:

Purpose and scope of the work described on this page are the following:

Table of Content


Getting rid of HAO/RH2 extensions in MIPv6 traffic

Current situation

The format of the IPsec-protected Binding Update (BU) message sent by the MN to its HA from a foreign network to register its new CoA is provided below:

Binding Update

The Binding Update message is sent using the current CoA of MN (address in source address field of the IPv6 header). The HoA is found in the Home Address Option in the Destination Option Header extensions following the IPv6 header. The Binding Update message (Mobility Header type 5) is IPsec-protected. It contains an AltCoA option which provides the current CoA of the MN. Unlike the version found in the IPv6 header, this one undergo IPsec protection and cannot be tampered with en route.

After reception and processing of the BU, the HA replies with an IPsec protected Binding Acknwoledgement (BA) message. The format of the message is provided below:

Binding Acknowledgement

The Type2 Routing Header contains the final destination of the packet, i.e. the HoA. The destination address of the packet (the one in the IPv6 header) is the MN's CoA.

Purpose of RH2 and HAO

HAO and RH2 are included in MIPv6 signaling traffic from/to the Mobile Node in order to:

Drawbacks of RH2/HAO

Here is a list of some of the drawbacks associated with the use of RH2/HAO by MIPv6:

Removing RH2/HAO from MIPv6 traffic

Based on previous points and some additional tests performed on the field, I decided to work on the removal of RH2/HAO from MIPv6 traffic. I implemented the changes in Linux kernel (IPsec stack and MIPv6 code) and in UMIP

For the output path, the explicit inclusion of RH2/HAO in the packet (after a switch of HoA and provided CoA) which was previously done is simply replaced by a replacement of the HoA (found in the IPv6 header after IPsec processing) by provided CoA.

For the input path, instead of using specific handlers to process HAO and RH2 extensions in incoming traffic and provides feedback on addresses (as ancillary data of incoming messages received on sockets), the XFRM stack is modified in order to handle ESP packets with addresss which do not patch SP/SA information.

Implementation for Linux kernel and UMIP

If you want to test the feature, patched kernel tarballs (2.6.34 or and a patched version of UMIP (tarball and .deb) are provided below:

I make the hypothesis you already have a working setup, i.e. a MN and a HA configured to work together. After having recompiled a kernel from the tarball above (no additional option needed), install it and reboot. You can then install the patched version of UMIP (patches are in debian/patches folder and are applied automatically when Debian rules files is called).

Then, you simply need to modify the configuration files on the MN and the HA in the following way. If 2001:db8::1 is your MN's HoA and 2001:db8::2 is your HA's address:

After having installed the updated version of UMIP, you can take a look at the man page for additional information on the option.

IPsec Route Optimization

Work in progress!. This section will be dedicated to the design and implementation of the secure Route Optimization described in IRO draft