One document matched: draft-laganier-mext-dsmipv6-ipsec-01.txt
Differences from draft-laganier-mext-dsmipv6-ipsec-00.txt
Network Working Group J. Laganier
Internet-Draft QUALCOMM Inc.
Intended status: Standards Track October 26, 2009
Expires: April 29, 2010
(Dual Stack) Mobile IPv6 Implementation with unmodified IPsec
draft-laganier-mext-dsmipv6-ipsec-01
Status of this Memo
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 29, 2010.
Copyright Notice
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
Laganier Expires April 29, 2010 [Page 1]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
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.
Laganier Expires April 29, 2010 [Page 2]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
Abstract
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Proposed Generic MIPv6/DSMIPv6 Implementation Architecture . . 6
3.1. DSMIPv6 protocol module . . . . . . . . . . . . . . . . . 7
3.2. DSMIPv6 tunnel interface module . . . . . . . . . . . . . 8
4. Discussing Requirements on IPsec Implementations . . . . . . . 9
4.1. Req. #1: MIPv6 Outbound Processing on the Home Agent . . . 9
4.1.1. Requirement . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Req. #2: MIPv6 Tunnel Interface Specific Security
Policy Database Entries . . . . . . . . . . . . . . . . . 10
4.2.1. Requirement . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Req. #3: DSMIPv6 Outbound Processing on the Mobile Node . 12
4.3.1. Requirement . . . . . . . . . . . . . . . . . . . . . 12
4.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Req. #4: DSMIPv6 Inbound Processing on the Home Agent . . 14
4.4.1. Requirement . . . . . . . . . . . . . . . . . . . . . 14
4.4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Informative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Laganier Expires April 29, 2010 [Page 3]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
1. Introduction
Mobile IPv6 (MIPv6) [RFC3775] 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] specifies extensions to
Mobile IPv6 (MIPv6) [RFC3775] 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] specifies that MIPv6 uses IPsec [RFC4301] to secure
signaling between the MN and the HA. Additionaly, [RFC3776] and
[RFC4877] 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], [RFC4877], and [RFC5555], 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]. 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.
Laganier Expires April 29, 2010 [Page 4]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
2. Terminology
TBD
Laganier Expires April 29, 2010 [Page 5]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
3. Proposed Generic MIPv6/DSMIPv6 Implementation Architecture
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 and
Figure 2, respectivelly.
+--------------------------------------------+
| |
| +--------------+ +-----------------+ |
| | ULPs | | (DS)MIPv6 | |
| | | | protocol | |
| | | | |<-----+
| | | | | | |
| +--------------+ +-----------------+ | |
| | |
+--------------------------------------------+ |
| | |
| +--------------+ IP Layer | |
| | | | |
| | Native | | |
| | IPsec | | |
| | | | |
| +--------------+ | |
| | |
+------------+---------------+---------------+ |
| | | (DS)MIPv6 | |
| Netif 1 | Netif 2 | tunnel |<--+
| driver | driver | interface |
+------------+---------------+---------------+
Figure 1: Native IPsec
Laganier Expires April 29, 2010 [Page 6]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
+--------------------------------------------+
| |
| +--------------+ +-----------------+ |
| | 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.
3.1. DSMIPv6 protocol module
The (DS)MIPv6 protocol module is responsible for the following
functions:
o Encapsulation of the packets it is passed by the IP stack.
Encapsulation and decapsulation of data payload packets is done by
addition and removal of an IPv6, IPv4, or IPv4 + UDP headers.
Encapsulation of signaling packets sent natively over IPv6
involves replacing the IPv6 Home Address present in the the source
or destination address field with an IPv6 Care-of Address and
inserting a Home Address option, or inserting an IPv4 header, and
possibly a UDP header as well when a NAT is detected.
Laganier Expires April 29, 2010 [Page 7]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
o Decapsulation of the packets that it receives from the IP stack.
o Processing, Sending and Receiving Signaling Packets
3.2. DSMIPv6 tunnel interface module
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:
o Handling outbound IP packets sourced from the IPv4 or IPv6 Home
Address for transmission as per the (DS)MIPv6 specifications.
o Handling of inbound IP packets received after decapsulation by the
MIPv6 protocol module.
Laganier Expires April 29, 2010 [Page 8]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
4. Discussing Requirements on IPsec Implementations
4.1. Req. #1: MIPv6 Outbound Processing on the Home Agent
4.1.1. Requirement
The specification of the use of IPsec to protect MIPv6 [RFC3776]
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.
4.1.2. Discussion
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.
Laganier Expires April 29, 2010 [Page 9]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
4.2. Req. #2: MIPv6 Tunnel Interface Specific Security Policy Database
Entries
4.2.1. Requirement
The specification of the use of IPsec to protect MIPv6 [RFC3776]
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:
Laganier Expires April 29, 2010 [Page 10]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
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
4.2.2. Discussion
The author found that the use of IPsec to protect MIPv6 [RFC3776] in
itself does not require policy entries specific to a tunnel
interface. The publication of the revised IPsec architecture
[RFC4301] 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] 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:
Laganier Expires April 29, 2010 [Page 11]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
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
4.3. Req. #3: DSMIPv6 Outbound Processing on the Mobile Node
4.3.1. Requirement
The DSMIPv6 specification [RFC5555] 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
Laganier Expires April 29, 2010 [Page 12]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
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.
4.3.2. Discussion
The author found that the DSMIPv6 specification [RFC5555] in itself
does not require changes to the IPsec implementation compared to that
of MIPv6 [RFC3775].
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:
Laganier Expires April 29, 2010 [Page 13]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
DSMIPv6-IPsec API: As outlined in the revised IPsec Architecture
[RFC4301], "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.
4.4. Req. #4: DSMIPv6 Inbound Processing on the Home Agent
4.4.1. Requirement
The DSMIPv6 specification [RFC5555] 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.
4.4.2. Discussion
The author found that the DSMIPv6 specification [RFC5555] in itself
does not require changes to the IPsec implementation compared to that
of MIPv6 [RFC3775].
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
Laganier Expires April 29, 2010 [Page 14]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
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], "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.
Laganier Expires April 29, 2010 [Page 15]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
5. Security Considerations
There are no security considerations.
Laganier Expires April 29, 2010 [Page 16]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
6. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
Laganier Expires April 29, 2010 [Page 17]
Internet-Draft (DS)MIPv6 with Unmodified IPsec October 2009
Author's Address
Julien Laganier
QUALCOMM Incorporated
5775 Morehouse Dr
San Diego, CA 92121
USA
Phone: +1 858 658 3538
Email: julienl@qualcomm.com
Laganier Expires April 29, 2010 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 03:06:39 |