| TOC |
|
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2010.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
It's been argued in the past and in some documents, such as RFC 3776, RFC 4877 and RFC 5555, that an IPsec implementation needs to be modified to afford security services to MIPv6 and DSMIPv6. This document shows that it is possible to implement MIPv6 and DSMIPv6 in a way that does not require change to a native or Bump-in-the-stack (BITS) IPsec implementation conformant to RFC 4301.
1.
Introduction
2.
Terminology
3.
Proposed Generic MIPv6/DSMIPv6 Implementation Architecture
3.1.
DSMIPv6 protocol module
3.2.
DSMIPv6 tunnel interface module
4.
Discussing Requirements on IPsec Implementations
4.1.
Req. #1: MIPv6 Outbound Processing on the Home Agent
4.1.1.
Requirement
4.1.2.
Discussion
4.2.
Req. #2: MIPv6 Tunnel Interface Specific Security Policy Database Entries
4.2.1.
Requirement
4.2.2.
Discussion
4.3.
Req. #3: DSMIPv6 Outbound Processing on the Mobile Node
4.3.1.
Requirement
4.3.2.
Discussion
4.4.
Req. #4: DSMIPv6 Inbound Processing on the Home Agent
4.4.1.
Requirement
4.4.2.
Discussion
5.
Security Considerations
6.
Informative References
§
Author's Address
| TOC |
Mobile IPv6 (MIPv6) [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) specifies a protocol which allows nodes to remain reachable while moving to different location of the IPvv6 Internet. Each mobile node is identified by a so-called home address that is independent from its current point of attachment. A mobile node also has a so-called care-of address at which it is reachable and which reflects its current point of attachment. MIPv6 allows a mobile node to register with its home agent and correspondent nodes the binding between its IPv6 Home Address and IPv6 Care-of Address so that they are able to route appropriately packet they wish to send to its Home Address.
Dual Stack Mobile IPv6 (DSMIPv6) [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) specifies extensions to Mobile IPv6 (MIPv6) [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) that allow a Mobile Node (MN) and Home Agent (HA) to operate in a Dual Stack manner with support for both IPv4 and IPv6:
The Mobile Node (MN) can register with its Home Agent (HA) bindings with IPv4 Home Addresses and Home Prefixes in addition to the IPv6 Home Address and Home Prefix.
The tunnel between the MN and the HA can be over either of IPv4 or IPv6.
The tunnel between the MN and the HA can transport both IPv4 and IPv6 packets.
[RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) specifies that MIPv6 uses IPsec [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) to secure signaling between the MN and the HA. Additionaly, [RFC3776] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.) and [RFC4877] (Devarapalli, V. and F. Dupont, “Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture,” April 2007.) discusses in more depth these requirements , illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
It's been argued in the past and in some documents, such as [RFC3776] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.), [RFC4877] (Devarapalli, V. and F. Dupont, “Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture,” April 2007.), and [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.), that an IPsec implementation needs to be modified to afford security services to MIPv6 and DSMIPv6. This document shows that it is possible to implement MIPv6 and DSMIPv6 in a way that does not require change to a native or Bump-in-the-stack (BITS) IPsec implementation conformant to [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.). Such an implementation would rely on either of 1) API to IPsec to query for the correspondance between a SPD entry and a SPI, or 2) heuristics and locking strategies.
| TOC |
TBD
| TOC |
The proposed generic architecture that allows implementing (DS)MIPv6 without requiring modifications to a native or bump-in-the-stack IPsec implementation involves separating the implementation into two modules. A (DS)MIPv6 protocol module sits on top of the IP layer and originates and receives (DS)MIPv6 signaling. Underneath the IP layer is a (DS)MIPv6 tunnel interface that is in charge of encapsulation and decapsulation of packets, and is interfaced with the (DS)MIPv6 module.
The layout of the proposed generic architecture with native and bump-in-the-stack IPsec implementations is represented in Figure 1 (Native IPsec) and Figure 2 (Bump-in-the-stack IPsec), respectivelly.
+--------------------------------------------+
| |
| +--------------+ +-----------------+ |
| | ULPs | | (DS)MIPv6 | |
| | | | protocol | |
| | | | |<-----+
| | | | | | |
| +--------------+ +-----------------+ | |
| | |
+--------------------------------------------+ |
| | |
| +--------------+ IP Layer | |
| | | | |
| | Native | | |
| | IPsec | | |
| | | | |
| +--------------+ | |
| | |
+------------+---------------+---------------+ |
| | | (DS)MIPv6 | |
| Netif 1 | Netif 2 | tunnel |<--+
| driver | driver | interface |
+------------+---------------+---------------+
| Figure 1: Native IPsec |
+--------------------------------------------+
| |
| +--------------+ +-----------------+ |
| | ULPs | | (DS)MIPv6 | |
| | | | protocol | |
| | | | |<-----+
| | | | | | |
| +--------------+ +-----------------+ | |
| | |
+--------------------------------------------+ |
| | |
| +--------------+ IP Layer | |
| | IPsec | | |
| | | | |
| | | | |
| | | | |
| +--------------+ | |
| | |
+--------------------------------------------+ |
| | |
| Bump-in-the-stack IPsec | |
| | |
+------------+---------------+---------------+ |
| | | (DS)MIPv6 | |
| Netif 1 | Netif 2 | tunnel |<--+
| driver | driver | interface |
+------------+---------------+---------------+
| Figure 2: Bump-in-the-stack IPsec |
The funtional break-down between the two modules is explained in the following two sub-sections.
| TOC |
The (DS)MIPv6 protocol module is responsible for the following functions:
| TOC |
The (DS)MIPv6 tunnel interface is assigned with the Home Addresses available to the Mobile Node: an IPv6 Home Address, and possibly an IPv4 Home Address. The (DS)MIPv6 tunnel interface is responsible for the two following functions:
| TOC |
| TOC |
| TOC |
The specification of the use of IPsec to protect MIPv6 [RFC3776] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.) outlines the requirement on changing the destination of IPsec packets sent from the agent to the Mobile Node:
We have chosen to require an encapsulation format for return routability and payload packet protection which can only be realized if the destination of the IPsec packets sent from the home agent can be changed as the mobile node moves. One of the main reasons for choosing such a format is that it removes the overhead of twenty four bytes when a home address option or routing header is added to the tunneled packet. Such an overhead would not be significant for the protection of the return routability packets, but would create an additional overhead if IPsec is used to protect the tunneling of payload packets to the home agent. This overhead may be significant for real-time traffic. Given that the use of the shorter packet formats for any traffic requires the existence of suitable APIs, we have chosen to require support for the shorter packet formats both for payload and return routability packets.
In order to support the care-of address as the destination address on the mobile node side, the home agent must act as if the outer header destination address in the security association to the mobile node would have changed upon movements. Implementations are free to choose any particular method to make this change, such as using an API to the IPsec implementation to change the parameters of the security association, removing the security association and installing a new one, or modification of the packet after it has gone through IPsec processing. The only requirement is that after registering a new binding at the home agent, the next IPsec packets sent on this security association will be addressed to the new care-of address.
| TOC |
The author found that the modification of the packet after it has gone through IPsec processing is a straightforward way of realizing the requirement which does not require change to the IPsec implementation. Packets sent to a MN HoA destination can be recognized by the tunneling code after IPsec processing and thus the destination address can be replaced by the CoA.
| TOC |
| TOC |
The specification of the use of IPsec to protect MIPv6 [RFC3776] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.) outline the requirements to have SPD entries that are specific to tunnel interface:
We have chosen to require policy entries that are specific to a tunnel interface. This means that implementations have to regard the Home Agent - Mobile Node tunnel as a separate interface on which IPsec SPDs can be based. A further complication of the IPsec processing on a tunnel interface is that this requires access to the BITS implementation before the packet actually goes out.
This is confirmed by the inclusion of the interface specific SPD entries to protect return routability messages:
mobile node SPD OUT: - IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA SA3 mobile node SPD IN: - IF interface = IPv6 tunnel from home_agent_1 & source = any & destination = home_address_1 & proto = MH THEN USE SA SA4
As well as payload packets:
mobile node SPD OUT: - IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = X THEN USE SA SA7 mobile node SPD IN: - IF interface = IPv6 tunnel from home_agent_1 & source = any & destination = home_address_1 & proto = X THEN USE SA SA8
| TOC |
The author found that the use of IPsec to protect MIPv6 [RFC3776] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.) in itself does not require policy entries specific to a tunnel interface. The publication of the revised IPsec architecture [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) provides a mean to select traffic based on mobility headers type that makes it possible to use host-wide security policy database entries rather than interface specific SPD entries. This is partly acknowledge in [RFC4877] (Devarapalli, V. and F. Dupont, “Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture,” April 2007.) where the tunnel interface selector has been removed from the SPD entry used to specify protection of Return Routability procedure:
mobile node SPD-S: - IF local_address = home_address_1 & remote_address = any & proto = MH & local_mh_type = HoTi & remote_mh_type = HoT Then use SA ESP tunnel mode Initiate using IDi = user_1 to address home_agent_1 home agent SPD-S: - IF local_address = any & remote_address = home_address_1 & proto = MH & local_mh_type = HoT & remote_mh_type = HoTi Then use SA ESP tunnel mode
But to an incomplete extent since SPD entries for protection of payload packets still select traffic based on the tunnel interface:
mobile node SPD-S: - IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = X Then use SA ESP tunnel mode Initiate using IDi = user_1 to address home_agent_1 home agent SPD-S: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = X Then use SA ESP tunnel mode
There is no need to select based on the tunnel interface since the non-payload MIPv6 packets have been selected already my the other SPD entries. Therefore one can use an host-wide SPD entry that comes last in the SPD to select based on the use of the home address as source or destination to catch the payload packets:
mobile node SPD-S: - IF source = home_address_1 & destination = any & proto = X Then use SA ESP tunnel mode Initiate using IDi = user_1 to address home_agent_1 home agent SPD-S: - IF source = any & destination = home_address_1 & proto = X Then use SA ESP tunnel mode
| TOC |
| TOC |
The DSMIPv6 specification [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) states that changes to the outbound processing of the Mobile Node IPsec implementation might be required:
In order to be able to send the binding update while in an IPv4-only network, the mobile node needs to use the new IPv4 care-of address in the outer header, which is different from the care-of address used in the existing tunnel. This should be done without permanently updating the tunnel within the mobile node's implementation in order to allow the mobile node to receive packets on the old care-of address until the binding acknowledgement is received. The method used to achieve this effect is implementation dependent and is outside the scope of this specification. This implies that the IP forwarding function (which selects the interface or tunnel through which a packet is sent) is not based solely on the destination address: some IPv6 packets destined to the home agent are sent via the existing tunnel, while BUs are sent using the new care-of address. Since BUs are protected by IPsec, the forwarding function cannot necessarily determine the correct treatment from the packet headers. Thus, the DSMIPv6 implementation has to attach additional information to BUs, and this information has to be preserved after IPsec processing and made available to the forwarding function or to DSMIP extensions included in the forwarding function. Depending on the mobile node's implementation, meeting this requirement may require changes to the IPsec implementation.
| TOC |
The author found that the DSMIPv6 specification [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) in itself does not require changes to the IPsec implementation compared to that of MIPv6 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.).
Regarding the outbound MN processing, the ability to send the binding update from a new IPv4 care-of address in the outer header different from the care-of address used for tunneling payload packets can be achieved entirely within the forwarding function of the DSMIPv6 tunneling code and does not necessarily require attaching additional information attached to BUs and this information to be preserved after IPsec processing and made available to the forwarding function or to DSMIP extensions included in the forwarding functions.
If the DSMIPv6 tunnel is modeled as a virtual interface, it will receive from a BITS IPsec implementation ESP protected BUs and data packets. While it is true that these packets can possibly be encrypted and thus their content not being accessible to the DSMIPv6 tunnel, one should note that the binding updates and payload packets are protected with different security associations. The binding updates are protected with a transport mode security association, while the payload packets are protected with a tunnel mode security association. These security associations have different SPIs, thus the forwarding function can distinguish between ESP protected binding updates and payload packets based on SPIs, in spite of the packets being possibly encrypted.
There are various means through which the DSMIPv6 tunneling code can determine whether an ESP packet sent from the MN to the HA is a BU or a data packet. Two techniques that do not require attaching and preserving meta-data to a packet throughout IPsec processing are outlined below:
DSMIPv6-IPsec API: As outlined in the revised IPsec Architecture [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.), "For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache", thus the DSMIPv6 tunneling code can query the IPsec subsystem to obtain the SPI used to protect BUs and can distinguish those from data packets.
Heuristic and locking: The data packets are many and were sent for a certain period of time to the old CoA and using the same SPI. In contrast, a single BU is sent once in a while and uses a different SPI. Based on this difference in terms of temporal sending pattern, the tunneling code can infer which ESP packet contains a BU or a BA, and which ESP packet contains a data packets. When the DSMIPv6 implementation is about to send a BU, the tunneling code can detect which single packet uses an SPI different from the others: this is the BU.
| TOC |
| TOC |
The DSMIPv6 specification [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) states that changes to the inbound processing of the Home Agent IPsec implementation might be required:
Upon receiving the binding update message encapsulated in UDP/IPv4, the home agent processes it as follows. In order to allow the DSMIPv6 implementation in the home agent to detect the presence of a NAT on the path to the mobile node, it needs to compare the outer IPv4 source address with the IPv4 address in the IPv4 care-of address option. This implies that the information in the outer header will be preserved after IPsec processing and made available to the DSMIPv6 implementation in the home agent. Depending on the home agent's implementation, meeting this requirement may require changes to the IPsec implementation.
| TOC |
The author found that the DSMIPv6 specification [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) in itself does not require changes to the IPsec implementation compared to that of MIPv6 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.).
Regarding inbound HA processing, the ability to detect NAT by comparing the outer IPv4 source address with the IPv4 address in the IPv4 care-of address option does not require the information in the outer header to be be preserved throughout IPsec processing.
When the DSMIPv6 tunnel receives the UDP encapsulated packets, although the BUs can possibly be encrypted by ESP and thus their content innaccessible to the DSMIPv6 code at this stage, the DSMIPv6 code has the ability to perform NAT detection nevertheless. This ability relies on the ability to distinguish BU performing NAT detection from other messages, to record the source IPv4 address and UDP port number used in the encapsulation headers, and to reassociate them with the packet after IPsec processing occured. If the message is a BU, the outer IPv4 address can be recorded, the packet passed to the IPsec implementation for ESP processing, and when the decapsulated BU is passed back to DSMIPv6, the DSMIPv6 code handling the BU can compare the IPv4 CoA contained in the packet with the outer header IPv4 address that was previously recorded.
There are various means through which the DSMIPv6 tunneling code can determine whether an IPv4-UDP encapsulated ESP packet sent from the MN to the HA is a BU performing NAT detection or not. Two techniques that do not require attaching and preserving meta-data to a packet throughout IPsec processing are outlined below:
DSMIPv6-IPsec API: As outlined in the revised IPsec Architecture [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.), "For each of the selectors defined in Section 4.4.1.1, the entry for an inbound SA in the SAD MUST be initially populated with the value or values negotiated at the time the SA was created", thus the DSMIPv6 tunneling code can query the IPsec subsystem to obtain the traffic selector for the ESP SPI, and determine whether the packet is a BU or not. If it is a BU its source IPv4 address and port number can be recorded with the binding cache entry for the IPv6 HoA used in the traffic selector before the packet is passed to the IPsec BITS.
Heuristic and locking: NAT detection occurs at initial attach and after handover via sending a BU encapsulated in UDP and IPv4. Thus, in the case of a NAT detection BU the source IPv4 address in the outer IPv4 header will differ from the IPv4 CoA previously recorded in the binding cache entry for the MN. When that is the case, it can be determined that the packet is either a NAT detection BU or garbage, and its source IPv4 address and port number can be recorded before the packet is passed to the IPsec BITS.
| TOC |
There are no security considerations.
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3775] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004 (TXT). |
| [RFC3776] | Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” RFC 3776, June 2004 (TXT). |
| [RFC4301] | Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” RFC 4301, December 2005 (TXT). |
| [RFC4877] | Devarapalli, V. and F. Dupont, “Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture,” RFC 4877, April 2007 (TXT). |
| [RFC5555] | Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” RFC 5555, June 2009 (TXT). |
| TOC |
| Julien Laganier | |
| QUALCOMM Incorporated | |
| 5775 Morehouse Dr | |
| San Diego, CA 92121 | |
| USA | |
| Phone: | +1 858 658 3538 |
| Email: | julienl@qualcomm.com |