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:
- protected by IPsec in tunnel mode between the MN and the HA
- E2E protected using the IPsec Route Optimization mechanism described in IRO draft
Purpose and scope of the work described on this page are the following:
- Simplify on-wire format of MIPv6 traffic: the goal is to limit traffic between the MN and its HA/peers to IPsec and IKE only. The main aspect of that work is the removal of RH2 and HAO in signaling packets exchanged between a MN and its HA/peers.
- Replace the initial Route Optimization mechanism defined in RFC3775 based on stronger hypothesis:
- Ability and wilingness for the MN to use IPsec with its peers (credentials available on both sides)
- Route Optimization is enabled only for previous peers, i.e. the ones for which IPsec is used. Said differently, common unprotected Route Optimization is not an option for IRO-enabled MN.
Table of Content
Changelog
- 18 June 2010: Initial version
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:
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:
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:- explicitly provide the real source/destination of the traffic (the HoA)
- prevent this traffic to be dropped by ingress filtering rules: the source/destination of the packet (in the IPv6 header) are always compatible with the prefix of the foreign network.
- to prevent the use of a full tunneling mechanism (a complete IPv6 header, i.e. 40 bytes) and reduce the size of the packet: both the RH2 and the Destination Option Header carrying a HAO consume only 24 bytes.
Drawbacks of RH2/HAO
Here is a list of some of the drawbacks associated with the use of RH2/HAO by MIPv6:- Additional complexity associated with the mechanism: at least under Linux (but I suspect this is the same on most systems), supporting RH2 and HAO is quite complex.
- Firewalls: in IPv6 environments, one can expect firewall to let IPsec (ESP) and IKE (500/udp) traffic pass through by default. But the inclusion of HAO and RH2 changes everything. For instance, even if this is probably not widely known, Cisco PIX firewalls basically drop IPv6 traffic including Routing Headers. This behavior is hardcoded and cannot be modified. . This basically means that all the networks in which Cisco PIX firewalls have been deployed break IPv6 mobility. There may be other devices which act in the same kind of way. It should also be noted that even though RH2 are different from RH0, the deprecation of RH0 may have resulted in some additional filtering of RH2.
- HAO and RH2 carry redundant information: BU and BA are always IPsec protected. The associated transport mode SP and SA reference the HoA as source/destination address of the packet. The address is available on both sides (on the HA and the MN) and is also carried in the packet, in an indirect fashion: the SPI found in the ESP header provides a direct access to the HoA both on the MN and the HA. Said differently: the SPI is sufficient to get access to the HoA (the real source/destination of the packet) and the use of RH2/HAO only duplicate information. The main arguments to support this design decision are the following (not backed by me):
- having the information available explictly in the packets may allow some kind of filtering in the network.
- the mechanism simplifies implementation by avoiding modifications of the IPsec stack (in order to access the HoA from the SPI): this is clearly implementation dependant and there are various proofs that the IPsec stack needs to be modified anyway to support 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 UMIPFor 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 2.6.35.5) 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:
- Add IRO 2001:db8::1; in your HA configuration file.
- Add IRO 2001:db8::2; in your MN configuration file.
After having installed the updated version of UMIP, you can take a look at the man page for additional information on the option.
댓글 없음:
댓글 쓰기