One document matched: draft-ebalard-mext-pfkey-enhanced-migrate-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="info" docName="draft-ebalard-mext-pfkey-enhanced-migrate-00" ipr="full3978">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<front>
<title abbrev="PF_KEY Extension for Mobile IPv6"> PF_KEY Extension
as an Interface between Mobile IPv6 and IPsec/IKE </title>
<author initials="A." surname="Ebalard" fullname="Arnaud Ebalard">
<organization abbrev="EADS">EADS Innovation Works</organization>
<address>
<postal>
<street>12, rue Pasteur - BP76</street>
<city>Suresnes</city>
<code>92152</code>
<country>France</country>
</postal>
<phone>+33 1 46 97 30 28</phone>
<email>arnaud.ebalard@eads.net</email>
</address>
</author>
<author initials="S." surname="Decugis" fullname="Sebastien Decugis">
<organization abbrev="NICT">National Institute of Information
and Communications Technology </organization>
<address>
<postal>
<street>4-2-1, Nukui-Kitamachi,</street>
<city>Koganei, Tokyo</city>
<code>184-8795</code>
<country>Japan</country>
</postal>
<email>sdecugis@hongo.wide.ad.jp</email>
</address>
</author>
<date month="August" year="2008"/>
<area>Internet</area>
<!-- <workgroup>Network Working Group</workgroup> -->
<keyword>Mobile IPv6</keyword>
<keyword>IKE</keyword>
<keyword>IPsec</keyword>
<keyword>PF_KEY</keyword>
<abstract>
<t> This document describes the need for an interface between
Mobile IPv6 and IPsec/IKE and show how the two protocols can
interwork. An extension of the PF_KEY framework is proposed
which allows smooth and solid operation of IKE in a Mobile IPv6
environment.</t>
<t> This document is heavily based on a previous draft [MIGRATE]
written by Shinta Sugimoto, Masahide Nakamura and Francis
Dupont. It simply reuses the MIGRATE mechanism defined in the
expired document, removes a companion extension
(SADB_X_EXT_PACKET) based on implementation feedback
(complexity, limitations, ...) and fills the gap by very simple
changes to MIGRATE mechanism. This results in a more simple and
consistent mechanism, which also proved to be easier to
implement. This document is expected to serve as a continuation
of [MIGRATE] work. For that reason, the name of the extension
has been kept.</t>
<t> PF_KEY MIGRATE message serves as a carrier for updated
address information for both the in-kernel IPsec structures
(SP/SA) and those maintained by the key managers. This includes
in-kernel SP/SA endpoints, key manager maintained equivalents
and addresses used by IKE_SA (current and to be negotiated). The
extension is helpful for assuring smooth internetworking between
Mobile IPv6 and IPsec/IKE for the bootstrapping of mobile nodes
and their movements. </t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="include" anchor="introduction">
<t>In <xref target="RFC3775">Mobile IPv6</xref>, the Mobile Node
(MN) and the Home Agent (HA) use some IPsec Security
Associations (SAs) in tunnel mode to protect some mobility
signaling messages, mobile prefix discovery and optionally
payload traffic. Since the MN may change its attachment point
to the Internet, it is necessary for it to update the tunnel
endpoint address of its IPsec SAs. This indicates that
corresponding entries in IPsec databases (Security Policy (SPD)
and SA (SAD) databases) should be updated when MN performs movements.</t>
<t>In a Mobile IPv6 environment, a key manager also needs to be
notified when the SPD and SAD are updated. More generally, it
needs to be provided with updated addresses for already
negotiated and future IKE_SA. Because of its role and unlike
common applications, key managers have to take part to the
mobility process they secure: they need to be aware of address
changes.</t>
<t>This document describes the need for an interface between
Mobile IPv6 and IPsec/IKE and shows how the two protocols can
interwork. An extension to the <xref target="RFC2367">PF_KEY
framework</xref> which allows smooth and solid operation of IKE
in a Mobile IPv6 environment is defined in the document. The
extension is called PF_KEY MIGRATE and serves as a carrier for
the necessary information for both the in-kernel IPsec stack and
the key managers.</t>
<t>For the IPsec stack, this allows migrating the endpoint
addresses of the IPsec SAs (and associated SP). For the key
managers, this allows the mirrored structures to be updated (SAD
and SPD). This also allows the addresses of already negotiated
and associated IKE_SA to be migrated, and to make specific
addresses available for negotiations of future IKE_SA. This set
of operations performed by the KM on its internal structures is
initiated by the MIPv6 process.</t>
<t>With the extension, the bootstrapping of the MN appears as a
common operation for IKE, by having the right addresses needed
for the negotiation available prior to the reception of the
ACQUIRE message.</t>
<t>The extension is helpful for assuring smooth interworking
between Mobile IPv6 and IPsec/IKE and achieving performance
optimization.</t>
<t> As stated in the abstract, this document is heavily based on
the content of a previous
draft <xref target="MIGRATE">MIGRATE</xref>.
This expired memo served as the basis for this work both from
technical and editorial standpoints. Numerous technical
discussions with some of its authors took place while working on
this memo.</t>
</section>
<!--
================================================================
Terminology
================================================================
-->
<section title="Terminology" toc="include" anchor="terminology">
<t> In this document, the term IKE implicitly stands for both
IKEv1 <xref target="RFC2409"/> and IKEv2
<xref target="RFC4306"/>. IKEv2 terminology is used
preferentially when describing actions performed by the key
manager but they also apply to the IKEv1 counterparts. For
instance, when actions occur on IKE_SA, they also apply to Phase
1 for IKEv1, except otherwise specified. Key manager is used as
a more generic term in the memo to refer to the IKE daemon.</t>
</section>
<!--
================================================================
Needs for Interactions between Mobile IPv6 and IPsec/IKE
================================================================
-->
<section title="Needs for Interactions between Mobile IPv6 and IPsec/IKE" toc="include" anchor="needs">
<t> The section 4.4 of <xref target="RFC3776">RFC 3776</xref>
specifies the rules which apply to IKE for MNs and HAs. The
first requirement is to run IKE over the Care-of Address (CoA)
because the Home Address (HoA) is usable only after the home
registration but not yet in the bootstrapping phase, when
Transport mode IPsec SA are commonly negotiated to protect
BU/BA.</t>
<t> A tunnel IPsec SA pair protects some signaling messages and
optionally all the traffic between the MN and HA. The initial
SPD entry uses the HoA for the MN endpoint address and updates
this address to the new CoA at each movement. A tunnel SA pair
is created on demand and is updated too. The <xref
target="RFC3775">RFC 3775</xref> assumes there is an API which
performs the update in the SPD and SAD on both the MN and HA,
and notify the IKE daemon. This document is mainly about this
API.</t>
<t> Mobile IPv6 may need to make an access to the SPD not only
for updating an endpoint address but also for deleting/inserting
a specific SPD entry. When the MN performs Foreign-to-Home
movement, IPsec SAs established between the MN and HA should be
deleted, which means that the SPD entry should have no effect
anymore. On the other hand, when the MN performs Home-to-Foreign
movement, the IPsec SAs should be restored. Hence security
policy entries that are associated with tunnel mode SAs may
dynamically be added/removed (enabled/disabled) in along with
MN's movements.</t>
<t> It should be noted that <xref target="RFC3963">NEMO Basic
Support</xref> has similar requirements for the Mobile Router
(MR) and MR's HA (MRHA). In NEMO, the MR works just like a MN
registering its location information to the MRHA and establishes
a tunnel (IP-in-IP or IPsec tunnel). When an IPsec tunnel is
established between MR and MRHA, the MR serves as a Security
Gateway for the nodes connected to the mobile network. The MR is
responsible for handling its tunnel endpoint properly.</t>
</section>
<!--
================================================================
Requirements
================================================================
-->
<section title="Requirements" toc="include" anchor="requirements">
<t> Despite the need for an interface between Mobile IPv6 and
IPsec/IKE, it should be kept simple. Following are the
requirements for the interface from a software engineering point
of view.<vspace blankLines="1"/>
<list style="symbols">
<t> Necessary modifications to the existing software, namely
Mobile IPv6 and IPsec/IKE, in order to realize proposed
mechanisms, should be kept minimum.</t>
<t> Proposed mechanism should not be platform dependent. The
mechanism should be based on technology which is commonly
available on various platform. This seems to be essential for
achieving high portability of the implementation which
supports proposed mechanisms.</t>
</list>
</t>
</section>
<!--
================================================================
PF_KEY MIGRATE
================================================================
-->
<section title="PF_KEY Extensions for Mobile IPv6: PF_KEY MIGRATE Message" toc="include" anchor="migrate">
<t> In order to fulfill the needs and requirements described in
<xref target="needs"/> and <xref target="requirements"/> we
propose to extend the PF_KEY framework so that Mobile IPv6 and
IPsec/IKE can interact with each other. The new message
dedicated to that function is called MIGRATE. A new simple PF_KEY
structure (sadb_x_kmaddress) is also defined to be used by
MIGRATE to serve the purpose of IKE_SA update.</t>
<section title="Overview" toc="include" anchor="overview">
<section title="System Overview" toc="include" anchor="bigpic">
<t> The MIGRATE message is used for providing
updated information to its two targets, the kernel IPsec
stack and the key manager (when used). The figure below
illustrates how Mobile IPv6 and IPsec/IKE components
interact with each other using PF_KEY MIGRATE message in a
dynamic keying scenario. On left top is a Mobile IPv6 entity
(it may be possible that Mobile IPv6 component is completely
implemented inside the kernel). In any case, Mobile IPv6
should be the one which issues the MIGRATE message. On right
top is an IKE daemon which is responsible for establishing
SAs required for Mobile IPv6 operation. In a manual keying
scenario, the difference is mainly that there is no IKE
daemon running on the system. </t>
<figure>
<artwork name="Figure A"><![CDATA[
+-------------+ +------------+
| | | |
| Mobile IPv6 | | IKE Daemon |
| | | |
+-------------+ +------------+
| 1. PF_KEY A 4. Update SPD & SAD
| MIGRATE | 5. Update IKE_SA
+-----------+ +-----------+
| |
Userland V |
==========================[PF_KEY Socket]========================
Kernel | |
+----------+ +----------+
| 2. Update | 3. Update
V SPD V SAD
+-----------+ +------------+
| | | |
| SPD | | SAD |
| | | |
+-----------+ +------------+
]]></artwork>
</figure>
<t> In the kernel, the primary role of PF_KEY MIGRATE
message is to migrate endpoint addresses of SA pairs, which
results in requesting IPsec to update its databases (SPD and
SAD). Even if tunnel mode is the primary target for MIPv6,
MIGRATE is not limited to that mode (See <xref
target="applicability"/>). Then, after proper processing by
the kernel, the MIGRATE message is sent to all open
sockets. A listening key manager processes it, which results
in a possible update of its internal structures. The
specific actions are introduced on the following
figure. </t>
<figure>
<artwork name="Figure B"><![CDATA[
MIPv6 ---------------- kernel -------------------> IKE
process
1) update of SP 1) Update of SA and SP
endpoints and endpoints (in image)
associated SA. 2) Update of src and dst
@ in SPD image for
future SA negotiation
3) Update of IKE_SA src
and dst @ associated
with provided SA
]]></artwork>
</figure>
<t> In more details, the processing of a MIGRATE message is
done in following steps:<vspace blankLines="1"/>
<list style="symbols">
<t> Mobile IPv6 issues a PF_KEY MIGRATE message to the
PF_KEY socket. </t>
<t> The operating system (kernel) validates the message
and checks if corresponding security policy entry exists
in SPD. </t>
<t> When the message is confirmed to be valid, the SPD
entry is updated according to the MIGRATE message. If
there is any target SA found that is also target of the
update, it should also be updated. </t>
<t> After the MIGRATE has beensuccessfully processed
inside the kernel, it is sent to all open PF_KEY
sockets. </t>
<t> The IKE daemon receives the MIGRATE message from its
PF_KEY socket and validates it. </t>
<t> The key manager starts by updating the SP entries
described in the message with the updated endpoint
information. It also updates in its SPD image the local
and remote addresses to be used for future negotiation
of SA associated with those SP (addresses used by future
IKE_SA). Then, it updates the SA related information:
the endpoints of already negotiated SA and the local and
remote values of associated IKE_SA. </t>
</list>
</t>
<t> Note that the way IKE maintains its local copy of SPD
(the SPD image) is an implementation specific issue since
there is no standard interface to access SPD. Some IKE
implementations may continuously monitor the SPD inside the
kernel. Some IKE implementation may expect notifications from
the kernel when the SPD is modified. In either way, the
proposed mechanism gives a chance for IKE to keep its SPD
image up-to-date which is significant in Mobile IPv6
operation. </t>
</section>
<!--
Bootstrapping
-->
<section title="Bootstrapping" toc="include" anchor="bootstrapping">
<t> In the bootstrapping stage of Mobile IPv6, the MN and the
HA need to establish IPsec SA to protect signaling messages of
Mobile IPv6 such as BU and BA. When IKE is used to establish
and maintain the SA pairs, the IKE negotiation is the very
first transaction made between the MN and the HA. </t>
<t> As mentioned in <xref target="RFC3776"/>, some care is
needed for the address management of the IKE negotiation in
Mobile IPv6 environments. In particular, IKE negotiation to be
made to establish a transport mode IPsec SA pair is tricky
because the local IKE_SA address and the SA endpoint on the MN
side (the Home Address) are different. This is because the
home address cannot be used prior to the initial home
registration. Even if the SADB_X_EXT_KMADDRESS extension
defined in this memo enables the MIPv6 module to notify
the IKE module about the IKE endpoint, address selection is
left outside the scope of the document. In practice, a
suitable candidate for the IKE endpoint is the primary
CoA.</t>
<t> A simple solution to have the key manager be aware that a
different address must be used for the negotiation of SA is to
have it record this address within its mirrored SPD entries as
soon as it becomes available. With that information, it is
able to inflect its usual processing where it selects by default
the source address of the SA for the negotiation (i.e. as
local address of the IKE_SA). By having the MIGRATE message
emitted by the Mobile IPv6 process before the emission of the
BU, the address is already available to the key manager when
the ACQUIRE message is received. </t>
<t> Even if the bootstrapping process initially appears
differently than the usual process, having the internal
structure of the key manager explicitly record the address (to
be used for the negotiation of the SA for a specific SP)
allows to keep things simple. The only requirement is that the
MIGRATE message be emitted by the Mobile IPv6 process before
it sends its Binding Update. </t>
</section>
<!--
Movement
-->
<section title="Movement" toc="include" anchor="movement">
<t> Next, we will see how migration takes place in along with
home registration. The figure below shows sequence of mobility
signaling and PF_KEY MIGRATE messages while the MN roams
around links. It is assumed that in the initial state the
tunnel endpoint address for a given MN is set as its home
address. In the initial home registration, the MN and HA
migrate the tunnel endpoint address from the HoA to CoA1. It
should be noted that no migration takes place when the MN
performs re-registration since the care-of address remains the
same. Accordingly, the MN performs movement and changes its
primary care-of address from CoA1 to CoA2. A PF_KEY MIGRATE
message is issued on both MN and HA for each direction. When
the MN returns to home, migration takes place updating the
endpoint address with the MN's home address. </t>
<t> With regard to the timing of issuing the MIGRATE message
on the MN side during a handover, it must occur immediately
before the emission of the binding update performing the home
registration (as for bootstrapping). It is possible that
ESP-protected (IPsec tunneled) user traffic be sent from the
new CoA which is not known to the HA yet. As the HA processes
the packets under IPsec, and as far as it finds a valid SA,
then those packets will be authenticated regardless of their
source IP address. In the end, there is no security issue in
updating the IPsec SA endpoint while sending the BU and no
reason not to do it. Furthermore, this may help the MN to
minimize the packet loss of its outbound traffic during the
handover.</t>
<figure>
<artwork name="Figure C"><![CDATA[
MN HA
| |
~ ~
Movement->|
MIGRATE ->| BU (Initial home registration) |
(HoA->CoA1)|----------------------------------------->|
| BA |<- MIGRATE
|<-----------------------------------------| (HoA->CoA1)
| |
~ BU (Home re-registration) ~
|----------------------------------------->|
| BA |
|<-----------------------------------------|
| |
~ ~
| |
Movement->| BU (Home registration) |
MIGRATE ->| BA |
(CoA1->CoA2)|----------------------------------------->|
| |<- MIGRATE
|<-----------------------------------------| (CoA1->CoA2)
| |
~ ~
Movement->| BU (Home de-registration) |
MIGRATE ->| BA |
(CoA2->HoA)|----------------------------------------->|
| |<- MIGRATE
|<-----------------------------------------| (CoA2->HoA)
| |
]]></artwork>
</figure>
</section>
<!--
IKE_SA Update
-->
<section title="IKE_SA Update" toc="include" anchor="ikesaupdate">
<t> The bootstrapping process described in
<xref target="bootstrapping"/> allows the creation of the SA
by having the right source address available to the key
manager before the beginning of the negotiation. When the SA
has been negotiated, some further exchanges are expected to
happen during the lifetime of the SA, including rekeying
related exchanges. After the first movement (and obviously
further ones), the address used during the bootstrapping
process becomes invalid. Even if the SPD and SAD entries are
updated (as described in <xref target="bigpic"/>), there is
also a need for the key manager to update the addresses used
by the IKE_SA.</t>
<t> When the key manager processes the MIGRATE message, it
uses the local and remote address information provided by the
sadb_x_kmaddress structure to update:
<list style="symbols">
<t> local copy of the SP entry maintained by the IKE
daemon which is specified in the MIGRATE message (as
described in <xref target="bootstrapping"/>).
</t>
<t> the existing IKE_SA associated with the SP entry which
is specified by the MIGRATE message.
</t>
</list>
</t>
<!--
<t> In fact, the update of addresses in the IKE_SA is the
continuity of the process described in <xref target="bootstrapping"/>
: when the IKE_SA is not available It simply targets the existing
IKE_SA bound to already created SA associated with the SP
referenced in the MIGRATE. </t>
-->
</section>
</section>
<!--
Issuing PF_KEY MIGRATE Message
-->
<section title="Issuing PF_KEY MIGRATE Message" toc="include" anchor="issuing">
<t> The Mobile IPv6 entity (MN or HA) code triggers the
migration by sending a PF_KEY MIGRATE message to its PF_KEY
socket. Conceptually, the PF_KEY MIGRATE message should
contain following information:</t>
<figure>
<artwork name="Figure D"><![CDATA[
o Key manager address information \
* source address | For IKE only
* destination address /
o Selector information: \
* source address/port |
* destination address/port |
* upper layer protocol (i.e., Mobility Header) |
* direction (inbound/outbound) |
o Old SA information: |
* old source endpoint address | For IKE and
* old destination endpoint address | IPsec stack
* IPsec protocol (ESP/AH) |
* mode (Tunnel/Transport/BEET) |
o New SA information: |
* new source endpoint address |
* new destination endpoint address |
* IPsec protocol (ESP/AH) |
* mode (Tunnel/Transport/BEET) /
]]></artwork>
</figure>
<t> Key manager address information content (source and
destination address) is recorded in the associated entry of
the SPD image. Those are used from now on by the key manager
for SA negotiation associated with that SP. The information is
also used by the key manager to update the local and remote
addresses of the IKE_SA (used by already negotiated SA
associated with the SP). </t>
<t> Selector information is required for specifying the target
SPD entry to be updated. Basically the information should
contain necessary elements which characterize traffic selector
as specified in the IPsec architecture
(<xref target="RFC2401"/>, <xref target="RFC4301"/>). With
regard to the upper layer protocol, when the Mobile IPv6 stack
is not fully aware of IPsec configuration, a wildcard value
could be given. In such case, an upper layer protocol
information should not be taken into account for searching SPD
entry. Plus, the direction of the security policy
(inbound/outbound) should be provided. </t>
<t> The old SA information, along with old locator information
is used to specify target SA to be updated. For tunnel and
BEET <xref target="I-D.nikander-esp-beet-mode" /> modes, the
endpoint addresses refer to the source and destination IP
addresses that appear in the IP header, and those should be
provided by the MIGRATE message. For transport mode, we
require it to be present to keep a fixed message format. For
all modes, the address information represents the locators of
the SA. For transport mode, it must match with the addresses
provided in the selector. For tunnel mode, it is obviously not
required. </t>
<t> The source and destination addresses (locators) of the
target entry should be overwritten. New locator values should
also be used to update SP. Note that the IPsec protocol and
mode fields should not be updated by a PF_KEY MIGRATE
message. </t>
<t> A PF_KEY MIGRATE message should be formed, based on
security policy configuration and binding record. The
selector information and some parts of the SA information
(IPsec protocol and mode) should be taken from the policy
configuration. The rest of the information should be taken
from the sequential binding information. For example, in the
case where the MN updates its inbound security policy and
corresponding tunnel mode SA pair, the old source address
should be set as its previous CoA, and the new source address
should be set as its current CoA. Hence, the MN should
sequentially keep track of its CoA record. Such information
shall be stored in binding update list entry. For the same
reason, the HA should keep track of previous CoAs of MNs. Such
information shall be stored in binding cache entry. In
previous scenario, the source and destination entries of the
address information for the key manager should respectively be
set to the CoA and the address of the HA. </t>
<t> A detailed format of MIGRATE message is provided in
Appendix A.</t>
</section>
<!--
Processing PF_KEY MIGRATE Message
-->
<section title="Processing PF_KEY MIGRATE Message" toc="include" anchor="processing">
<t> Since a PF_KEY MIGRATE message is applied to a single SPD
entry, the kernel should first check validity of the
message. During that process, it simply skips sadb_x_kmaddress
structure content. If the message is invalid, an EINVAL error
MUST be returned as a return value for the write() operation
made to the PF_KEY socket. After the validation, the kernel
checks if the target SPD entry really exists. If no entry is
found, an ENOENT error MUST be returned. If a SPD entry is
found and successfully updated, a success (0) MUST be returned
regardless of subsequent result of SAD lookup/update. Note
that there may be cases where a corresponding SAD entry does
not exist even if a SPD entry is successfully updated. In any
error case, a PF_KEY MIGRATE message MUST NOT have any effect
on the SPD and SAD. </t>
<t> With respect to the behavior of a normal process
(including the IKE daemon) which receives a PF_KEY MIGRATE
message from a PF_KEY socket, it SHOULD first check if the
message does not include erroneous information. When there is
any error indicated, the process MUST silently discard the
PF_KEY MIGRATE message. Otherwise, the processing of the
message may continue. This implies that the kernel is the only
entity responsible for returning a status regarding message
validation.</t>
</section>
<!--
Applicability of PF_KEY MIGRATE to Other Systems
-->
<section title="Applicability of PF_KEY MIGRATE to Other Systems" toc="include" anchor="applicability">
<t> The PF_KEY MIGRATE extension can also be applied to other
systems than Mobile IPv6. In some systems, there is a need to
update endpoint address of IPsec security association for
various reasons such as mobility management and multihoming. </t>
<t> In a Mobile VPN scenario (aka "road warrior"), client node
roams around different IP subnets while maintaining security
associations with the security gateway. Just like in Mobile
IPv6 case, both of the IKE peers need to update the endpoint
of the IPsec tunnel and PF_KEY MIGRATE message can be used for
that purpose. </t>
<t> In HIP mobility management scenario
<xref target="RFC5206"/>, a mobile host can maintain a
HIP association with its peer while moving around IP subnets.
When the mobile host changes its attachment point to the
Internet, it sends an UPDATE message to the peer reporting its
new locator. Since HIP association is represented by an IPsec
security association of ESP BEET mode, the same mechanism can
be applied for the purpose of updating endpoint. The
procedure of MIGRATE can take place when the mobile host
detects movement and when the peer receives the UPDATE
message. </t>
<t> From the ID/Locator separation point of view, PF_KEY
MIGRATE is designed to update locators stored in an IPsec
security association. Even if this usually applies to IPsec
security associations in tunnel mode, the MIGRATE framework
also covers the transport mode. For instance, there are
exceptional cases where IPsec security associations are
bundled. In some case, a transport mode security association
may be bundled with a tunnel mode security association. For
instance, a combination of AH (transport mode) and ESP (tunnel
mode) may assure confidentiality of the payload as well as
data integritiy of the whole IP packet including outer header.
In such case, PF_KEY MIGRATE message may be used for updating
endpoint addresses of IPsec transport mode. </t>
</section>
<!--
NAT Traversal
-->
<section title="NAT Traversal" toc="include" anchor="natt">
<t> Dual Stack Mobile IPv6
<xref target="I-D.ietf-mext-nemo-v4traversal"/> supports a
scenario where a MN is connected to a network behind a Network
Address Translator (NAT). In such case, the MN assigns a IPv4
private address to its network interface but it is still
capable of registering its care-of address to the HA, using
the NAT Traversal technique <xref target="RFC3948"/>. The MN
and HA leverage an IPsec tunnel to protect the return
routability messages. </t>
<t> It is possible for the PF_KEY MIGRATE message to handle
IPv4 private address when the MN is behind a NAT device. In a
NAT Traversal case, the endpoint address of the MN is
characterized by the IP address and the pair of source and
destination port numbers used for the UDP encapsulation.
Therefore, in a NAT Traversal scenario, a Mobile IPv6 module
MUST issue a PF_KEY MIGRATE message along with the pair of
source and destination port numbers of a UDP encpasulation, to
handle IPv4 private address. </t>
</section>
<!--
Limitations of PF_KEY MIGRATE
-->
<section title="Limitations of PF_KEY MIGRATE" toc="include" anchor="limitations">
<t> Currently, a Security Parameter Index (SPI) is not
included in the old SA information to specify target SAD
entry. This helps to lessen operational burden of Mobile
IPv6. However, this simplification can produce ambiguity in
searching for the target security association entry. When the
unique SPD level is available, it should be used because it
avoids this problem both by marking the SAs to update and by
limiting SA sharing.</t>
<t> It should be noted that delivery of PF_KEY MIGRATE
messages cannot be guaranteed, which is common to other PF_KEY
messages. It may be possible (even if highly unlikely) that a
MIGRATE message be lost. In such case, there will be
inconsistency between the binding record managed by Mobile
IPv6 and IPsec database inside the kernel or the IKE
daemon.
Once a PF_KEY MIGRATE message is lost, it would not be
possible for the receiver to process some subsequent MIGRATE
messages properly. Reinitialization of the Mobile IPv6 stack
and IPsec databases may be needed for recovery. </t>
</section>
</section>
<!--
Necessary Modifications to Mobile IPv6 and IPsec/IKE
-->
<section title="Necessary Modifications to Mobile IPv6 and IPsec/IKE" toc="include" anchor="modifications">
<t> In order to realize the proposed mechanism, there are some
necessary modifications to Mobile IPv6 and IPsec/IKE. They are
listed below for implementors of Mobile IPv6 and/or
IPsec/IKE.<vspace blankLines="1"/>
<list style="symbols">
<t> Modifications to Mobile IPv6:
<list style="symbols">
<t> The Mobile IPv6 code needs to make an access to
PF_KEY socket. In particular, the Mobile IPv6 code
should have privilege to write messages into a PF_KEY
socket. </t>
<t> Issuing PF_KEY MIGRATE messages: in order to send
MIGRATE messages, it is required that the Mobile IPv6
code has some knowledge of its IPsec configuration and
precise binding record. The Mobile IPv6 code may be
aware of exact IPsec configuration in form of security
policy. It would also be possible that the Mobile IPv6
code is only aware of minimum IPsec configuration
whether IPsec is utilized or not. </t>
<t> With regard to the emission of the MIGRATE message
during the home registration, the Mobile IPv6 code
need to emit it before issuing the Binding
Update. </t>
</list>
</t>
<t> Modifications to IPsec:
<list style="symbols">
<t> Processing PF_KEY MIGRATE messages: the kernel
should be able to process PF_KEY MIGRATE messages sent
by the Mobile IPv6 code. Unless the message is
invalid, it should be sent to all open PF_KEY
sockets. </t>
</list>
</t>
<t> Modifications to IKE (associated with processing of MIGRATE):
<list style="symbols">
<t> the IKE code need to update its local copy of IPsec
databases (SPD and SAD) in accordance with received
PF_KEY MIGRATE message. </t>
<t> the IKE code need to update its associated IKE_SA
with new local and remote addresses specifically
provided in PF_KEY MIGRATE messages (in sadb_x_kmaddress
structure). It also needs to maintain in its SPD the
addresses to be used for future negotiation of IKE_SA.</t>
</list>
</t>
</list>
</t>
</section>
<!--
Security Considerations
-->
<section title="Security Considerations" toc="include" anchor="security">
<t> There is no specific security considerations for the
mechanisms introduced by the document but as it makes
deployment of dynamic keying in Mobile IPv6 environments
easier it should improve the security of such environments.
Note that dynamic keying is known to be more secure (it
provides anti-replay for instance) and far more scalable. </t>
</section>
<!--
Conclusion
-->
<section title="Conclusion" toc="include" anchor="conclusion">
<t>
<list style="symbols">
<t> There is a need for Mobile IPv6 and IPsec/IKE to interact
with each other to provide full support of IPsec security
functions.</t>
<t> An extension to the PF_KEY framework (PF_KEY MIGRATE
message) is proposed, which makes it possible:
<list style="symbols">
<t> for the IPsec/IKE to migrate endpoint addresses IPsec SAs
from one to another.</t>
<t>to make the source address to be used by the key manager for
SA negotiation available before it is needed.</t>
<t> to update addresses of IKE_SA after movement.</t>
</list>
</t>
<t> An additional requirement associated with the solution for
IKE is the addition in SPD image of additional per-SP hints
to be used as addresses for negotiation of SAs.</t>
<t> Currently, large portion of the proposed mechanism is
implementation dependent due to lack of standard interface to
access the SPD (PF_POLICY?).</t>
</list>
</t>
</section>
</middle>
<back>
<!--
==================================================================
References
==================================================================
-->
<references title="Normative References">
<reference anchor="RFC3775">
<front>
<title>Mobility Support in IPv6</title>
<author initials="D." surname="Johnson" fullname="D. Johnson">
<organization/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<author initials="J." surname="Arkko" fullname="J. Arkko">
<organization/>
</author>
<date year="2004" month="June"/>
</front>
<seriesInfo name="RFC" value="3775"/>
<format type="TXT" octets="393514" target="ftp://ftp.isi.edu/in-notes/rfc3775.txt"/>
</reference>
<reference anchor="RFC3776">
<front>
<title> Using IPsec to Protect Mobile IPv6 Signaling Between
Mobile Nodes and Home Agents </title>
<author initials="J." surname="Arkko" fullname="J. Arkko">
<organization/>
</author>
<author initials="V." surname="Devarapalli" fullname="V. Devarapalli">
<organization/>
</author>
<author initials="F." surname="Dupont" fullname="F. Dupont">
<organization/>
</author>
<date year="2004" month="June"/>
</front>
<seriesInfo name="RFC" value="3776"/>
<format type="TXT" octets="87076" target="ftp://ftp.isi.edu/in-notes/rfc3776.txt"/>
</reference>
<reference anchor="RFC2367">
<front>
<title abbrev="PF_KEY"> PF_KEY Key Management API, Version 2 </title>
<author initials="D.L." surname="McDonald" fullname="D. McDonald">
<organization/>
</author>
<author initials="C." surname="Metz" fullname="C. Metz">
<organization/>
</author>
<author initials="B.G." surname="Phan" fullname="B. Phan">
<organization/>
</author>
<date year="1998" month="July"/>
</front>
<seriesInfo name="RFC" value="2367"/>
<format type="TXT" octets="146754" target="ftp://ftp.isi.edu/in-notes/rfc2367.txt"/>
</reference>
<reference anchor="RFC2401">
<front>
<title abbrev="Security Architecture"> Security Architecture
for the Internet Protocol </title>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization/>
</author>
<author initials="R." surname="Atkinson" fullname="R. Atkinson">
<organization/>
</author>
<date year="1998" month="November"/>
</front>
<seriesInfo name="RFC" value="2401"/>
<format type="TXT" octets="168162" target="ftp://ftp.isi.edu/in-notes/rfc2401.txt"/>
</reference>
<reference anchor="RFC2409">
<front>
<title>The Internet Key Exchange (IKE)</title>
<author initials="D." surname="Harkins" fullname="D. Harkins">
<organization/>
</author>
<author initials="D." surname="Carrel" fullname="D. Carrel">
<organization/>
</author>
<date year="1998" month="November"/>
</front>
<seriesInfo name="RFC" value="2409"/>
<format type="TXT" octets="94949" target="ftp://ftp.isi.edu/in-notes/rfc2409.txt"/>
</reference>
<reference anchor='RFC4301'>
<front>
<title>Security Architecture for the Internet Protocol</title>
<author initials='S.' surname='Kent' fullname='S. Kent'>
<organization /></author>
<author initials='K.' surname='Seo' fullname='K. Seo'>
<organization /></author>
<date year='2005' month='December' /></front>
<seriesInfo name='RFC' value='4301' />
<format type='TXT' octets='262123' target='ftp://ftp.isi.edu/in-notes/rfc4301.txt'/>
</reference>
<reference anchor='RFC4306'>
<front>
<title>Internet Key Exchange (IKEv2) Protocol</title>
<author initials='C.' surname='Kaufman' fullname='C. Kaufman'>
<organization /></author>
<date year='2005' month='December' /></front>
<seriesInfo name='RFC' value='4306' />
<format type='TXT' octets='250941' target='ftp://ftp.isi.edu/in-notes/rfc4306.txt' />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC3963">
<front>
<title> Network Mobility (NEMO) Basic Support Protocol </title>
<author initials="V." surname="Devarapalli" fullname="V. Devarapalli">
<organization/>
</author>
<author initials="R." surname="Wakikawa" fullname="R. Wakikawa">
<organization/>
</author>
<author initials="A." surname="Petrescu" fullname="A. Petrescu">
<organization/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert">
<organization/>
</author>
<date year="2005" month="January"/>
</front>
<seriesInfo name="RFC" value="3963"/>
<format type="TXT" octets="75955" target="ftp://ftp.isi.edu/in-notes/rfc3963.txt"/>
</reference>
<reference anchor="MIGRATE">
<front>
<title>PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE</title>
<author initials='S' surname='Sugimoto' fullname='Shinta Sugimoto'>
<organization />
</author>
<author initials='M' surname='Nakamura' fullname='Masahide Nakamura'>
<organization />
</author>
<author initials='F' surname='Dupont' fullname='Francis Dupont'>
<organization />
</author>
<date month='December' day='15' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value='draft-sugimoto-mip6-pfkey-migrate-04' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-sugimoto-mip6-pfkey-migrate-04.txt' />
</reference>
<reference anchor="I-D.nikander-esp-beet-mode">
<front>
<title>A Bound End-to-End Tunnel (BEET) mode for ESP</title>
<author initials='J' surname='Melen' fullname='Jan Melen'>
<organization />
</author>
<author initials='P' surname='Nikander' fullname='Pekka Nikander'>
<organization />
</author>
<date month='August' day='5' year='2008' />
</front>
<seriesInfo name='Internet-Draft' value='draft-nikander-esp-beet-mode-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-09.txt' />
</reference>
<reference anchor='RFC5206'>
<front>
<title>End-Host Mobility and Multihoming with the Host Identity Protocol</title>
<author initials='P' surname='Nikander' fullname='Pekka Henderson'>
<organization />
</author>
<author initials='T' surname='Henderson' fullname='Tom Henderson'>
<organization />
</author>
<author initials='C' surname='Vogt' fullname='Christian Vogt'>
<organization />
</author>
<author initials='J' surname='Arkko' fullname='Jari Arkko'>
<organization />
</author>
<date month='April' year='2008' />
</front>
<seriesInfo name='RFC' value='5206' />
<format type='TXT' octets='99430'
target='ftp://ftp.isi.edu/in-notes/rfc5206.txt' />
</reference>
<reference anchor='I-D.ietf-mext-nemo-v4traversal'>
<front>
<title>Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)</title>
<author initials='H' surname='Soliman' fullname='Hesham Soliman'>
<organization />
</author>
<date month='July' day='' year='2008' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mext-nemo-v4traversal-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-05.txt' />
</reference>
<reference anchor='RFC3948'>
<front>
<title>UDP Encapsulation of IPsec ESP Packets</title>
<author initials='A.' surname='Huttunen' fullname='A. Huttunen'>
<organization /></author>
<author initials='B.' surname='Swander' fullname='B. Swander'>
<organization /></author>
<author initials='V.' surname='Volpe' fullname='V. Volpe'>
<organization /></author>
<author initials='L.' surname='DiBurro' fullname='L. DiBurro'>
<organization /></author>
<author initials='M.' surname='Stenberg' fullname='M. Stenberg'>
<organization /></author>
<date year='2005' month='January' />
</front>
<seriesInfo name='RFC' value='3948' />
<format type='TXT' octets='30366' target='ftp://ftp.isi.edu/in-notes/rfc3948.txt' />
</reference>
</references>
<!--
===================================================================
Appendix A - PF_KEY MIGRATE message format
===================================================================
-->
<section title="PF_KEY MIGRATE Message Format" toc="include" anchor="messageformat">
<t> The figure below shows the message format of PF_KEY MIGRATE.
The message consists of 7 parts (boundary of each part is
marked with ">"). The message starts with PF_KEY base message
header directly followed by a sadb_x_kmaddress{}
structure. The extension holds the two IKE_SA local and remote
addresses as opaque data for the key manager (two 64-bit
aligned sockaddr). It is then followed by two address
extensions: those respectively hold source and destination
addresses of the selector. The rest of the message is specific
to IPsec implementations on BSD and Linux. sadb_x_policy{}
structure holds additional information of security policy.
The last part of the message is a pair of
sadb_x_ipsecrequest{} structures that hold old and new SA
information.
<figure>
<artwork><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---------------+---------------+---------------+---------------+
| ...version | sadb_msg_type | sadb_msg_errno| ...msg_satype |
+---------------+---------------+---------------+---------------+
| sadb_msg_len | sadb_msg_reserved |
+---------------+---------------+---------------+---------------+
| sadb_msg_seq |
+---------------+---------------+---------------+---------------+
| sadb_msg_pid |
>+---------------+---------------+---------------+---------------+
| sadb_x_kmaddress_len | sadb_x_kmaddress_exttype |
+---------------+---------------+---------------+---------------+
| sadb_x_kmaddress_reserved |
+---------------+---------------+---------------+---------------+
~ IKE_SA local address (64-bit aligned ... ~
+---------------+---------------+---------------+---------------+
~ IKE_SA remote address ... pair of sockaddr) ~
>+---------------+---------------+---------------+---------------+
| sadb_address_len | sadb_address_exttype |
+---------------+---------------+---------------+---------------+
| _address_proto| ..._prefixlen | sadb_address_reserved |
+---------------+---------------+---------------+---------------+
~ selector source address (64-bit aligned sockaddr) ~
>+---------------+---------------+---------------+---------------+
| sadb_address_len | sadb_address_exttype |
+---------------+---------------+---------------+---------------+
| _address_proto| ..._prefixlen | sadb_address_reserved |
+---------------+---------------+---------------+---------------+
~ selector destination address (64-bit aligned sockaddr) ~
>+---------------+---------------+---------------+---------------+
| sadb_x_policy_len | sadb_x_policy_exttype |
+---------------+---------------+---------------+---------------+
| sadb_x_policy_type | ..._dir | ..._reserved |
+---------------+---------------+---------------+---------------+
| sadb_x_policy_id |
+---------------+---------------+---------------+---------------+
| sadb_x_policy_priority |
>+---------------+---------------+---------------+---------------+
| sadb_x_ipsecrequest_len | sadb_x_ipsecrequest_proto |
+---------------+---------------+---------------+---------------+
| ..._mode | ..._level | sadb_x_ipsecrequest_reserved1 |
+---------------+---------------+---------------+---------------+
| sadb_x_ipsecrequest_reqid |
+---------------+---------------+---------------+---------------+
| sadb_x_ipsecrequest_reserved2 |
+---------------+---------------+---------------+---------------+
~ old source endpoint address (64-bit aligned ... ~
+---------------+---------------+---------------+---------------+
~ old destination endpoint address ... pair of sockaddr) ~
>+---------------+---------------+---------------+---------------+
| sadb_x_ipsecrequest_len | sadb_x_ipsecrequest_proto |
+---------------+---------------+---------------+---------------+
| ..._mode | ..._level | sadb_x_ipsecrequest_reserved1 |
+---------------+---------------+---------------+---------------+
| sadb_x_ipsecrequest_reqid |
+---------------+---------------+---------------+---------------+
| sadb_x_ipsecrequest_reserved2 |
+---------------+---------------+---------------+---------------+
~ new source endpoint address (64-bit aligned ... ~
+---------------+---------------+---------------+---------------+
~ new destination endpoint address ... pair of sockaddr) ~
+---------------+---------------+---------------+---------------+
]]></artwork>
</figure>
Following is a structure of PF_KEY base message header specified
in <xref target="RFC2367"/>. A new message type for PF_KEY
MIGRATE (i.e., SADB_X_MIGRATE) should be specified in member
sadb_msg_type.
<figure>
<artwork><![CDATA[
struct sadb_msg {
uint8_t sadb_msg_version;
uint8_t sadb_msg_type;
uint8_t sadb_msg_errno;
uint8_t sadb_msg_satype;
uint16_t sadb_msg_len;
uint16_t sadb_msg_reserved;
uint32_t sadb_msg_seq;
uint32_t sadb_msg_pid;
};
]]></artwork>
</figure>
Following is the structure of key manager address extension
header. SADB_X_EXT_KMADDRESS should be specified in
sadb_x_kmaddress_exttype field. It is followed by a pair of
sockaddr structures holding respectively up-to-date local and
remote address to be used by IKE_SA. The pair is globally 64-bit
aligned.
<figure>
<artwork><![CDATA[
struct sadb_x_kmaddress {
uint16_t sadb_x_kmaddress_len;
uint16_t sadb_x_kmaddress_exttype;
uint32_t sadb_x_kmaddress_reserved;
};
/* sizeof(struct sadb_x_kmaddress) == 8 */
/* Followed by two sockaddr (local and remote) */
]]></artwork>
</figure>
Following is a structure of address extension header
specified in <xref target="RFC2367"/>. Upper layer protocol
should be specified in member sadb_address_proto.
<figure>
<artwork><![CDATA[
struct sadb_address {
uint16_t sadb_address_len;
uint16_t sadb_address_exttype;
uint8_t sadb_address_proto;
uint8_t sadb_address_prefixlen;
uint16_t sadb_address_reserved;
};
]]></artwork>
</figure>
Following is a structure for holding attributes that are
relevant to security policy, which is available on BSD and Linux
IPsec implementations. Direction of the target security policy
should be specified in member sadb_x_policy_dir.
<figure>
<artwork><![CDATA[
struct sadb_x_policy {
uint16_t sadb_x_policy_len;
uint16_t sadb_x_policy_exttype;
uint16_t sadb_x_policy_type;
uint8_t sadb_x_policy_dir;
uint8_t sadb_x_policy_reserved;
uint32_t sadb_x_policy_id;
uint32_t sadb_x_policy_priority;
};
]]></artwork>
</figure>
Following is a structure for holding attributes that are
relevant to security association, which is available on BSD
and Linux IPsec implementation. IPsec protocol (ESP or AH) and
mode of the target security association should be provided in
member sadb_x_ipsecrequest_proto and sadb_x_ipsecrequest_mode,
respectively.
<figure>
<artwork><![CDATA[
struct sadb_x_ipsecrequest {
uint16_t sadb_x_ipsecrequest_len;
uint16_t sadb_x_ipsecrequest_proto;
uint8_t sadb_x_ipsecrequest_mode;
uint8_t sadb_x_ipsecrequest_level;
uint16_t sadb_x_ipsecrequest_reserved1;
uint32_t sadb_x_ipsecrequest_reqid;
uint32_t sadb_x_ipsecrequest_reserved2;
};
]]></artwork>
</figure>
</t>
</section>
<section title="Acknowledgements">
<t> Various people had contributed and were acknowledged in
previous version of MIGRATE draft. Because most of the text from
previous draft has been kept in this document, those
acknowledgements are still valid: Sebastien Decugis, Mitsuru
Kanda, Kazunori Miyazawa, Tsuyoshi Momose Shoichi Sakane, Keiichi
Shima, Noriaki Takamiya, and Hideaki Yoshifuji.</t>
<t>Support of NAT Traversal was suggested by Kazunori Miyazawa.</t>
<t>We would also like to acknowledge here the positive technical
feedback from Shinta Sugimoto while extending his MIGRATE
mechanism and also the work provided by people of USAGI (Masahide
Nakamura, Shinta Sugimoto, Hideaki Yoshifuji, ...) on Linux
kernel's Mobile IPv6 and IPsec stack.</t>
<t>This document was generated by xml2rfc.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:14:39 |