One document matched: draft-laganier-mext-dsmipv6-ipsec-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
<!ENTITY rfc3776 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3776.xml'>
<!ENTITY rfc4877 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml'>
<!ENTITY rfc4301 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
<!ENTITY rfc5555 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5555.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="pre5378Trust200902">
<front>
<title abbrev="(DS)MIPv6 with Unmodified IPsec">
(Dual Stack) Mobile IPv6 Implementation with unmodified IPsec
</title>
<author initials="J." surname="Laganier" fullname="Julien Laganier">
<organization abbrev="QUALCOMM Inc.">
QUALCOMM Incorporated
</organization>
<address> <postal>
<street>5775 Morehouse Dr
</street>
<city>San Diego</city>
<region>CA</region>
<code>92121</code>
<country>USA</country>
</postal>
<phone>+1 858 658 3538</phone>
<email>julienl@qualcomm.com</email>
</address>
</author>
<date year="2009"/>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<!-- <section title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
</section>
-->
<section title="Introduction">
<t>
Mobile IPv6 (MIPv6) <xref target="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.
</t>
<t>
Dual Stack Mobile IPv6 (DSMIPv6) <xref target="RFC5555"/> specifies
extensions to Mobile IPv6 (MIPv6) <xref target="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:
<list>
<t> 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.</t>
<t>The tunnel between the MN and the HA can be over either of IPv4 or IPv6.</t>
<t>The tunnel between the MN and the HA can transport both IPv4 and IPv6
packets.</t>
</list>
</t>
<t>
<xref target="RFC3775"/> specifies that MIPv6 uses IPsec <xref target="RFC4301"/> to secure
signaling between the MN and the HA. Additionaly, <xref target="RFC3776"/> and
<xref target="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.
</t>
<t>
It's been argued in the past and in some documents, such as <xref
target="RFC3776"/>, <xref target="RFC4877"/>, and <xref
target="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 <xref target="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.
</t>
<!--
<vspace blankLines="1"/>
This document extends the current SEND specification with support for Proxy ND.
From this point on we refer to such extension as "Secure Proxy ND Support for
SEND".
</t>
-->
</section>
<section title="Terminology">
<t>
TBD <!--
<list style="hanging">
<t hangText="HoA6"><vspace blankLines="1"/>
A node authorized to either modify or generate a SEND message without knowing
the private key related to the source address of the ICMPv6 ND message.
</t>
<t hangText="Proxied IPv6 address"><vspace blankLines="1"/>
An IPv6 address that doesn't belong to the Secure Proxy ND and for which the
Secure Proxy ND is advertising. </t>
</list>
-->
</t>
</section>
<section title="Proposed Generic MIPv6/DSMIPv6 Implementation Architecture">
<t>
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.
</t>
<t>
The layout of the proposed generic architecture with native and
bump-in-the-stack IPsec implementations is represented in
<xref target="fig-native"/> and <xref target="fig-bits"/>,
respectivelly.
</t>
<t>
<figure title="Native IPsec" anchor="fig-native">
<artwork align="center">
<![CDATA[
+--------------------------------------------+
| |
| +--------------+ +-----------------+ |
| | ULPs | | (DS)MIPv6 | |
| | | | protocol | |
| | | | |<-----+
| | | | | | |
| +--------------+ +-----------------+ | |
| | |
+--------------------------------------------+ |
| | |
| +--------------+ IP Layer | |
| | | | |
| | Native | | |
| | IPsec | | |
| | | | |
| +--------------+ | |
| | |
+------------+---------------+---------------+ |
| | | (DS)MIPv6 | |
| Netif 1 | Netif 2 | tunnel |<--+
| driver | driver | interface |
+------------+---------------+---------------+
]]>
</artwork>
</figure></t>
<t>
<figure title="Bump-in-the-stack IPsec" anchor="fig-bits">
<artwork align="center">
<![CDATA[
+--------------------------------------------+
| |
| +--------------+ +-----------------+ |
| | ULPs | | (DS)MIPv6 | |
| | | | protocol | |
| | | | |<-----+
| | | | | | |
| +--------------+ +-----------------+ | |
| | |
+--------------------------------------------+ |
| | |
| +--------------+ IP Layer | |
| | IPsec | | |
| | | | |
| | | | |
| | | | |
| +--------------+ | |
| | |
+--------------------------------------------+ |
| | |
| Bump-in-the-stack IPsec | |
| | |
+------------+---------------+---------------+ |
| | | (DS)MIPv6 | |
| Netif 1 | Netif 2 | tunnel |<--+
| driver | driver | interface |
+------------+---------------+---------------+
]]>
</artwork>
</figure></t>
<t>
The funtional break-down between the two modules is explained in the following two sub-sections.
</t>
<section title="DSMIPv6 protocol module">
<t>
The (DS)MIPv6 protocol module is responsible for the following functions:
<list style="symbols">
<t> 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. </t>
<t> Decapsulation of the packets that it receives from the
IP stack.</t>
<t> Processing, Sending and Receiving Signaling
Packets</t>
</list>
</t>
</section>
<section title="DSMIPv6 tunnel interface module">
<t>
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:
<list style="symbols">
<t>
Handling outbound IP packets sourced from the IPv4 or IPv6 Home Address for transmission as per the (DS)MIPv6 specifications.
</t>
<t> Handling of inbound IP packets received after
decapsulation by the MIPv6 protocol module.
</t>
</list>
</t>
</section>
</section>
<section title="Discussing Requirements on IPsec Implementations">
<section title="Req. #1: MIPv6 Outbound Processing on the Home Agent">
<section title="Requirement">
<t>
The specification of the use of IPsec to protect MIPv6 <xref
target="RFC3776"/> outlines the requirement on changing
the destination of IPsec packets sent from the agent to the
Mobile Node:
<list>
<t>
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.
</t><t>
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.
</t>
</list>
</t>
</section>
<section title="Discussion">
<t>
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.
</t>
</section>
</section>
<section title="Req. #2: MIPv6 Tunnel Interface Specific Security Policy Database Entries">
<section title="Requirement">
<t>
The specification of the use of IPsec to protect MIPv6 <xref
target="RFC3776"/> outline the requirements to have SPD
entries that are specific to tunnel interface:
<list>
<t>
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.
</t>
</list>
This is confirmed by the inclusion of the interface specific SPD entries
to protect return routability messages:
<list>
<t>
<figure>
<artwork align="center">
<![CDATA[
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
]]>
</artwork>
</figure>
</t>
</list>
As well as payload packets:
<list>
<t>
<figure>
<artwork align="center">
<![CDATA[
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
]]>
</artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="Discussion">
<t>
The author found that the use of IPsec to protect MIPv6 <xref
target="RFC3776"/> in itself does not require policy
entries specific to a tunnel interface. The publication of the
revised IPsec architecture <xref target="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 <xref target="RFC4877"/> where the
tunnel interface selector has been removed from the SPD entry
used to specify protection of Return Routability procedure:
<list>
<t>
<figure>
<artwork align="center">
<![CDATA[
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
]]>
</artwork>
</figure>
</t>
</list>
But to an incomplete extent since SPD entries for protection of
payload packets still select traffic based on the tunnel interface:
<list>
<t>
<figure>
<artwork align="center">
<![CDATA[
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
]]>
</artwork>
</figure>
</t>
</list>
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:
<list>
<t>
<figure>
<artwork align="center">
<![CDATA[
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
]]>
</artwork>
</figure>
</t>
</list>
</t>
</section>
</section>
<section title="Req. #3: DSMIPv6 Outbound Processing on the Mobile Node">
<section title="Requirement">
<t>
The DSMIPv6 specification <xref target="RFC5555"/> states that
changes to the outbound processing of the Mobile Node IPsec
implementation might be required:
<list>
<t>
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.
</t>
</list>
</t>
</section>
<section title="Discussion">
<t>
The author found that the DSMIPv6 specification <xref
target="RFC5555"/> in itself does not require changes
to the IPsec implementation compared to that of MIPv6 <xref
target="RFC3775"/>.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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:
<list>
<t>
DSMIPv6-IPsec API: As outlined in the revised
IPsec Architecture <xref target="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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
</section>
<section title="Req. #4: DSMIPv6 Inbound Processing on the Home Agent">
<section title="Requirement">
<t>
The DSMIPv6 specification <xref target="RFC5555"/> states that
changes to the inbound processing of the Home Agent IPsec
implementation might be required:
<list> <t>
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.
</t>
</list>
</t>
</section>
<section title="Discussion">
<t>
The author found that the DSMIPv6 specification <xref
target="RFC5555"/> in itself does not require changes
to the IPsec implementation compared to that of MIPv6 <xref
target="RFC3775"/>.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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:
<list>
<t>
DSMIPv6-IPsec API: As outlined in the revised
IPsec Architecture <xref target="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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
</section>
</section>
<!--
<section title="Packet Formats">
<section title="Binding Updates and Acknowledgements">
</section>
<section title="Return Routability Signaling">
</section>
<section title="Prefix Discovery">
</section>
<section title="Payload Packets">
</section>
</section>
<section title="Requirements">
<section title="General Requirements">
</section>
<section title="Policy Requirements">
</section>
<section title="IPsec Protocol Processing Requirements">
</section>
<section title="Dynamic Keying Requirements">
</section>
</section>
<section title="Configuration">
<section title="Peer Authorization Database Entries">
</section>
<section title="Security Policy Database Entries">
<section title="Binding Updates and Acknowledgements">
</section>
<section title="Return Routability Signaling">
</section>
<section title="Prefix Discovery">
</section>
<section title="Payload Packets">
</section>
</section>
<section title="Security Association Negotiation Using IKEv2">
</section>
<section title="Movements and Dynamic Keying">
</section>
</section>
<section title="Processing Steps within a Node">
<section title="Mobile Node Processing" anchor="mn">
<section title="MN sends Binding Update to the Home Agent over IPv4" anchor="bumn4">
<t> Step 1. At the mobile node, Mobile IPv6 module first
produces the following packet: </t>
<figure><artwork>
IPv6 header (source = hoa_6,
destination = ha_6)
Mobility header
Binding Update
IPv4 CoA option (coa_4)
</artwork></figure>
<t> Step 2. This packet is matched against the IPsec SPD on the
mobile node and we make a note that IPsec must be applied and which SPI spi_a is to be used, as agreed during the IKEv2 exchange.
</t>
<t>
Step 3. Finally, IPsec headers are added and the necessary
authenticator values are calculated:
</t>
<figure><artwork>
IPv6 header (source = hoa_6,
destination = ha_6)
ESP header (SPI = spi_a)
Mobility header
Binding Update
IPv4 CoA option (coa_4)
</artwork></figure>
<t> Here spi_a is the SPI value that was agreed upon in an earlier IKE negotiation.
</t>
<t>
Step 4. Before sending the IPv6 packet, it is encapsulated in IPv4 and UDP.
</t>
<figure> <artwork>
IPv4 header (source = coa_4,
destination = ha_4)
UDP header (source port = mn_port,
destination port = 4191)
IPv6 header (source = hoa_6,
destination = ha_6)
ESP header (SPI = spi_a)
Mobility header
Binding Update
IPv4 CoA option (coa_4)
</artwork></figure>
<t> Here sport is a source port assigned locally to the DSMIPv6 module.</t>
</section>
</section>
<section title="Home Agent Processing" anchor="ha">
<section title="Binding Update from the Mobile Node over IPv4" anchor="buha4">
<t>Step 1. The following packet is received at the home agent, and passed to the DSMIPv6 module because it is received on UDP port number 4191:</t>
<figure> <artwork>
IPv4 header (source = nat_4,
destination = ha_4)
UDP header (source port = nat_port,
destination port = 4191)
IPv6 header (source = hoa_6,
destination = ha_6)
ESP header (SPI = spi_a)
Mobility header
Binding Update
IPv4 CoA option (coa_4)
</artwork></figure>
<t> Step 2. The DSMIPv6 module removes the IPv4 and UDP headers and makes a note of the source IPv4 address and port number. The resulting IPv6 packet as depicted below is then passed to the IPv6 stack:</t>
<figure> <artwork>
IPv6 header (source = hoa_6,
destination = ha_6)
ESP header (SPI = spi_a)
Mobility header
Binding Update
IPv4 CoA option (coa_4)
</artwork></figure>
<t> Step 3. The IPv6 stack passes the packet to the IPsec module that begins with processing the ESP header, resulting in the following cleartext Binding Update:</t>
<figure><artwork>
IPv6 header (source = hoa_6,
destination = ha_6)
Mobility header
Binding Update
IPv4 CoA option (coa_4)
</artwork></figure>
<t> Step 4. IPsec processing proceeds with verifying that this
packet matches the policy required for this security
association (source = hoa_6 address, destination = ha_6,
proto = MH, MH type = BU). XXX TBD does the packet matches
the security policy, and the SPD entry matched links to that
security association?</t>
<t> Step 5. The Binding update is returned to the IPv6 stack that passes it to the DSMIPv6 module for DSMIPv6 processing.</t>
<t> Step 6. The DSMIPv6 module compares the IPv4 Care-of Address contained in the Binding Update with the source IPv4 address of the outer header to perform NAT detection, as described in Section XXX of RFC5555.</t>
<t> Step 6. If there are any security associations in the security
association database for the protection of return routability or
payload packets for this mobile node, those security associations are
updated with the new care-of address.</t>
</section>
</section>
<section title="Binding Acknowledgement to the Mobile Node over IPv4" anchor="baha4">
<t> Step 1. At the home agent, Mobile IPv6 module first
produces the following packet: </t>
<figure><artwork>
IPv6 header (source = ha_6,
destination = hoa_6)
Mobility header
Binding Acknowldegment
[IPv4 Address Acknowledgment option (hoa_4)]
[NAT Detection option]
</artwork></figure>
<t> Step 2. This packet is matched against the IPsec SPD on the
home agent and we make a note that IPsec must be applied and which SPI spi_b is to be used, as agreed during the IKEv2 exchange.
</t>
<t>
Step 3. Finally, IPsec headers are added and the necessary
authenticator values are calculated:
</t>
<figure><artwork>
IPv6 header (source = ha_6,
destination = hoa_6)
ESP header (SPI = spi_b)
Mobility header
Binding Acknowledgment
[IPv4 Address Acknowledgment option (hoa_4)]
[NAT Detection option]
</artwork></figure>
<t> Here spi_b is the SPI value that was agreed upon in an earlier IKE negotiation.
</t>
<t>
Step 4. Before sending the IPv6 packet, it is encapsulated in IPv4 and UDP.
</t>
<figure> <artwork>
IPv4 header (source = ha_4,
destination = nat_4)
UDP header (source port = 4191,
destination port = nat_port)
IPv6 header (source = ha_6,
destination = hoa_6)
ESP header (SPI = spi_b)
Mobility header
Binding Acknowledgment
[IPv4 Address Acknowledgment option (hoa_4)]
[NAT Detection option]
</artwork></figure>
<t> Here nat_port is the same as the source port number in the BU that triggered this BA.</t>
</section>
<section title=" Binding Acknowledgement from the Home Agent over IPv4" anchor="bamn4">
<t>Step 1. The following packet is received at the mobile node, and
passed to the DSMIPv6 module because it is received on UDP port
number sport:</t>
<figure> <artwork>
IPv4 header (source = ha_4,
destination = coa_4)
UDP header (source port = 4191,
destination port = mn_port)
IPv6 header (source = ha_6,
destination = hoa_6)
ESP header (SPI = spi_b)
Mobility header
[IPv4 Address Acknowledgment option (hoa_4)]
[NAT Detection option]
</artwork></figure>
<t> Step 2. The DSMIPv6 module removes the IPv4 and UDP headers and makes a note of the source IPv4 address and port number. The resulting IPv6 packet as depicted below is then passed to the IPv6 stack:</t>
<figure> <artwork>
IPv6 header (source = ha_6,
destination = hoa_6)
ESP header (SPI = spi_b)
Mobility header
[IPv4 Address Acknowledgment option (hoa_4)]
[NAT Detection option]
</artwork></figure>
<t> Step 3. The IPv6 stack passes the packet to the IPsec module that begins with processing the ESP header, resulting in the following cleartext Binding Update:</t>
<figure><artwork>
IPv6 header (source = ha_6,
destination = hoa_6)
Mobility header
[IPv4 Address Acknowledgment option (hoa_4)]
[NAT Detection option]
</artwork></figure>
<t> Step 4. IPsec processing proceeds with verifying that this
packet matches the policy required for this security
association (source = hoa_6 address, destination = ha_6,
proto = MH, MH type = BU). XXX TBD does the packet matches
the security policy, and the SPD entry matched links to that
security association?</t>
<t> Step 5. The Binding update is returned to the IPv6 stack that passes it to the DSMIPv6 module for DSMIPv6 processing.</t>
<t> Step 6. The DSMIPv6 module is informed of the presence of a NAT or not via the NAT Detection option.</t>
<t> Step 7. If there are any security associations in the security
association database for the protection of return routability or
payload packets for the mobile node, those security associations are
updated with the new care-of address.</t>
</section>
<section title="Prefix Solicitation Message to the Home Agent">
<t> This procedure is similar to the one presented in <xref target="bumn4"/></t>
</section>
<section title="Prefix Solicitation Message from the Mobile Node">
<t> This procedure is similar to the one presented in <xref target="buha4"/></t> </section>
<section title="Prefix Advertisement Message to the Mobile Node">
<t> This procedure is similar to the one presented in <xref target="baha4"/></t> </section>
<section title="Prefix Advertisement Message from the Home Agent">
<t> This procedure is similar to the one presented in <xref target="bamn4"/></t> </section>
<section title="Payload Packet to the Home Agent">
<t> This procedure is similar to the one presented in <xref target="bumn4"/></t> </section>
<section title="Payload Packet from the Mobile Node">
<t> This procedure is similar to the one presented in <xref target="buha4"/></t> </section>
<section title="Payload Packet to the Mobile Node">
<t> This procedure is similar to the one presented in <xref target="baha4"/></t> </section>
<section title="Payload Packet from the Home Agent">
<t> This procedure is similar to the one presented in <xref target="bamn4"/></t> </section>
<section title="Establishing New Security Associations">
</section>
<section title="Rekeying Security Associations">
</section>
<section title="Movements and Dynamic Keying">
</section>
</section>
<section title="Implementation Considerations">
<section title="IPsec">
</section>
<section title="IKE">
</section>
<section title="Bump-in-the-Stack">
</section>
</section>
-->
<!--
<figure title="PSO layout" anchor="pso_option_type_layout">
<artwork align="center">
<![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
-->
<section title="Security Considerations">
<t>There are no security considerations.
</t>
</section>
<!--
The mechanism described in this document introduce a new Proxy Signature Option
(PSO) allowing a Secure
Proxy ND to generate or modify a SEND message for a proxied address. A
node will only accept such a message if it includes a valid PSO
generated by an authorized Secure Proxy ND.
</t>
<t>
If, on the other hand, a message does not include a PSO, then the Secure Proxy
ND support doens't introduce any further security issues since this
specification does not modify the SEND processing rules if an ICMPv6 ND message
does not contain a PSO. Thus, the same security considerations than that of
SEND applies (cf. Section 9 of the <xref target="RFC3971"> SEND
specification</xref>.) </t>
</section>
<section title="IANA Considerations">
<t>
IANA is requested to allocate:
<list>
<t>
A new IPv6 Neighbor Discovery Option types for the PSO, as TBA. The value need
to be allocated from the namespace specified in the IANA registry IPv6 NEIGHBOR
DISCOVERY OPTION FORMATS located at
http://www.iana.org/assignments/icmpv6-parameters.
</t>
<t>
A new 128-bit value under the CGA Message Type <xref
target="RFC3972"/> namespace, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804.
</t>
</list>
</t>
</section>
-->
</middle>
<back>
<references title="Informative References">
&rfc2119;
&rfc4301;
&rfc3775;
&rfc3776;
&rfc4877;
&rfc5555;
<!--
<reference anchor='SENDEKU'>
<front>
<title>Authorization Certificates for Routers and Proxies</title>
<author initials='S' surname='Krishnan' fullname='Suresh Krishnan'>
<organization />
</author>
<date month='October' day='30' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value=' draft-krishnan-cgaext-send-cert-eku-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-krishnan-cgaext-send-cert-eku-00.txt' />
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:39:20 |