One document matched: draft-sugimoto-mip6-pfkey-migrate-04.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="info" docName="draft-sugimoto-mip6-pfkey-migrate-04" 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 fullname="Shinta Sugimoto" initials="S" surname="Sugimoto">
<organization abbrev="Ericsson"> Nippon Ericsson K.K.</organization>
<address>
<postal>
<street>Koraku Mori Building</street>
<street>1-4-14, Koraku, Bunkyo-ku</street>
<city>Tokyo</city>
<code>112-0004</code>
<country>Japan</country>
</postal>
<phone>+81 3 3830 2241</phone>
<email>shinta.sugimoto@ericsson.com</email>
</address>
</author>
<author initials="F." surname="Dupont" fullname="Francis Dupont">
<organization>CELAR</organization>
<address>
<email>Francis.Dupont@fdupont.fr</email>
</address>
</author>
<author fullname="Masahide Nakamura" initials="M" surname="Nakamura">
<organization abbrev="Hitachi"> Hitachi Communication
Technologies, Ltd.</organization>
<address>
<postal>
<street>216 Totsuka-cho, Totsuka-ku</street>
<city>Yokohama</city>
<code>244-8567</code>
<country>Japan</country>
</postal>
<phone> +81 45 865 7003</phone>
<email>masahide.nakamura.cz@hitachi.com</email>
</address>
</author>
<date month="December" year="2007"/>
<area>Internet</area>
<!-- <workgroup>Network Working Group</workgroup> -->
<keyword>Mobile IPv6</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. We propose a set of extensions to the PF_KEY
framework which allows smooth and solid operation of IKE in a
Mobile IPv6 environment. The first extension is called PF_KEY
MIGRATE and is for migrating the endpoint addresses of a IPsec
Security Association pair in tunnel mode. The second extension
is named SADB_X_EXT_PACKET and allows IKE to make the right
choice for address selection in bootstrapping process. Both
extensions are helpful for assuring smooth interworking between
Mobile IPv6 and IPsec/IKE and achieving performance
optimization.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="include">
<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 to update its tunnel endpoint
address of the IPsec SAs. This indicates that corresponding
entry in IPsec databases (Security Policy (SPD) and SA (SAD)
databases) should be updated when MN performs movements. In
addition, IKE requires treatment to keep its IKE session alive
in a Mobile IPv6 environment. </t>
<t>This document describes the need for an interface between
Mobile IPv6 and IPsec/IKE and shows how the two protocols can
interwork. We propose a set of extensions to the <xref
target="RFC2367">PF_KEY framework</xref> which allows smooth and
solid operation of IKE in an Mobile IPv6 environment. The first
extension is called PF_KEY MIGRATE and is for migrating the
endpoint addresses of the IPsec SAs in tunnel mode. The second
extension is named SADB_X_EXT_PACKET and allows IKE to make the
right choice in address selection in the bootstrapping
process. Both extensions are helpful for assuring smooth
interworking between Mobile IPv6 and IPsec/IKE and achieving
performance optimization. </t>
<t>In this document, the term IKE implicitly stands for both
IKEv1 <xref target="RFC2409"/> and IKEv2 <xref
target="RFC4306"/>. In description with regard to any
functionality that is specific to either of the protocols,
specific protocol name shall be provided.</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 applies 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 so not yet in the bootstrapping phase. </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. This document is mainly about this API. </t>
<t> Mobile IPv6 specifies a flag named Key Management Mobility
Capability bit (K-bit) in Binding Update (BU) and Binding
Acknowledgement (BA) messages (section 10.3.1 of <xref
target="RFC3775"/>), which indicates the ability of IKE sessions
to survive movement. When both the MN and HA agree to use this
functionality, the IKE daemons dynamically update the IKE
session when the MN moves. In order to realize this, IKE daemons
should be notified by Mobile IPv6, and necessary information to
migrate the IKE session should be provided. </t>
<t> Mobile IPv6 may need to make an access to the SPD not only
for updating an endpoint address but also for the
deletion/insertion of 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 any more. 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 as same as 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> Given the need for an interface between Mobile IPv6 and
IPsec/IKE, there should be a minimum interface between the two
protocols. Followings 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" toc="include">
<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 could interact with each other. </t>
<section title="PF_KEY MIGRATE Message">
<t> The first extension is primarily for migrating an endpoint
address of an IPsec SA pair in tunnel mode from one to
another, which results in updating IPsec databases. A new
PF_KEY message named MIGRATE is introduced for the
mechanism. </t>
<section title="Overview">
<t> The figure below illustrates how Mobile IPv6 and
IPsec/IKE components interact with each other using PF_KEY
MIGRATE messages in a dynamic keying scenario. On left top,
there is a Mobile IPv6 entity. It may be possible that
Mobile IPv6 component is completely implemented inside the
kernel (this is the case for our implementations because it
makes some facilities and extensions far easier at the cost
of maintaining a SPD image in daemons). In any case, Mobile
IPv6 should be the one which issues the MIGRATE messages.
On right top, there is an IKE daemon which is responsible
for establishing SAs required for Mobile IPv6 operation. In
a manual keying scenario, the difference is only 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
| MIGRATE | SPD & SAD
+-----------+ +-----------+
| |
Userland V |
==========================[PF_KEY Socket]========================
Kernel | |
+----------+ +----------+
| 2. Update | 3. Update
V SPD V SAD
+-----------+ +------------+
| | | |
| SPD | | SAD |
| | | |
+-----------+ +------------+
]]></artwork>
</figure>
<t> The primary role of PF_KEY MIGRATE messages is to
migrate endpoint addresses of tunnel mode SA pairs
requesting IPsec to update its databases (SPD and SAD). In
addition, the new message can be used by IKE to enhance its
mobility capability. When a PF_KEY MIGRATE message is
properly processed by the kernel, it is sent to all open
sockets as normal PF_KEY messages. The processing of a
sequence of MIGRATE messages 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 target
SPD entry is updated according to the MIGRATE message. If
there is any target SA found that are also target of the
update, those should also be updated. </t>
<t> After the MIGRATE message is successfully processed
inside the kernel, it will be sent to all open PF_KEY
sockets. </t>
<t> The IKE daemon receives the MIGRATE message from its
PF_KEY socket and updates its SPD and SAD images. The IKE
daemon may also update its state to keep the IKE session
alive. </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
implementation may continuously monitor the SPD inside the
kernel. Some IKE implementation may expect notification 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>
<!--
Message Sequence
-->
<section title="Message Sequence" toc="include">
<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 a MIGRATE message on
the MN side, the message can be issued immediately after the
home registration. That is, there is no need to wait until
the acknowledgment from the HA to issue migrate the endpoint
addresses stored in the IPsec databases. The Mobile IPv6
specification (<xref target="RFC3775"/> Section 11.6.3)
actually allows the MN to start using the new care-of
address immediately after sending a BU message to the HA.
This may help the MN to minimize the packet loss of its
outbound traffic during the handover.</t>
<figure>
<artwork><![CDATA[
MN HA
| |
~ ~
Movement->| BU (Initial home registration) |
|----------------------------------------->|
MIGRATE ->| BA |<- MIGRATE
(HoA->CoA1) |<-----------------------------------------| (HoA->CoA1)
| |
~ BU (Home re-registration) ~
|----------------------------------------->|
| BA |
|<-----------------------------------------|
| |
~ ~
| |
Movement->| BU (Home registration) |
|----------------------------------------->|
MIGRATE ->| BA |<- MIGRATE
(CoA1->CoA2)|<-----------------------------------------| (CoA1->CoA2)
| |
~ ~
Movement->| BU (Home de-registration) |
|----------------------------------------->|
MIGRATE ->| BA |<- MIGRATE
(CoA2->HoA) |<-----------------------------------------| (CoA2->HoA)
| |
]]></artwork>
</figure>
</section>
<section title="Issuing PF_KEY MIGRATE Message">
<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: <vspace blankLines="1"/>
<list style="symbols">
<t> Selector information: <list style="symbols">
<t>source address/port</t>
<t>destination address/port</t>
<t>upper layer protocol (i.e., Mobility Header)</t>
<t>direction (inbound/outbound)</t>
</list>
</t>
<t> Old SA information: <list style="symbols">
<t>old source endpoint address</t>
<t>old destination endpoint address</t>
<t>IPsec protocol (ESP/AH)</t>
<t>mode (Tunnel)</t>
</list>
</t>
<t> New SA information: <list style="symbols">
<t>new source endpoint address</t>
<t>new destination endpoint address </t>
<t>IPsec protocol (ESP/AH)</t>
<t>mode (Tunnel)</t>
</list>
</t>
</list>
<vspace blankLines="1"/> 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, an wild-card 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. The old SA information is used to specify
target security association to be updated. The source and
destination addresses of the target entry should be
overwritten with the ones included in the new SA
information. 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. </t>
<t> Additionally, a piece of information which indicates a
mobility capability of IKE (K-bit) should be provided by any
means. This makes it possible for IKE to see if there is a
need to update its state (IKE endpoint addresses) in
accordance with PF_KEY MIGRATE messages. </t>
<t> A detailed message format of PF_KEY MIGRATE is provided
in <xref target="messageformat"/>. </t>
</section>
<section title="Processing PF_KEY MIGRATE Message">
<t> Since a PF_KEY MIGRATE message is applied to a single
SPD entry, the kernel should first check validity of the
message. 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 a case 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. </t>
</section>
<section title="Applicability of PF_KEY MIGRATE to Other Systems">
<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 association with the security gateway. Just like
the case in Mobile IPv6, both of the IKE peers need to
update the endpoint of the IPsec tunnel and PF_KEY MIGRATE
message can be used for the update.</t>
<t>In HIP mobility management scenario<xref
target="I-D.ietf-hip-mm"/>, 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. Hence, the message can be applied to
IPsec security association in tunnel mode. However, 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 integrity 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>
<section title="NAT Traversal">
<t>Dual Stack Mobile IPv6 <xref
target="I-D.ietf-mip6-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 an 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 encapsulation,
to handle IPv4 private address.</t>
<t></t>
</section>
<section title="Limitation of PF_KEY MIGRATE">
<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 that a MIGRATE message
is 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.
<!-- FD: note I believe this is false but making PF_KEY
reliable at the user level is not so easy (but
ipsec-tools racoon seems to have this -->
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 title="Interoperability Issue">
<t>It is a choice of implementers whether to support the
PF_KEY MIGRATE message in their MIPv6 and IPsec/IKE
implementations. However, asymmetry in the support of the
PF_KEY MIGRATE message may cause an interoperability issue
in some case.</t>
<t>It should be noted that an interoperability issue may be
raised when the HA does not support PF_KEY MIGRATE message
whereas the MN does support the mechanism. This is based on
the working assumption that HA serves as a responder in the
IKE negotiations conducted to maintain the IPsec SAs
required for MIPv6 operation. It is unlikely that the HA
serves as an initiator in the IKE negotiation in the MIPv6
network scenario for practical reasons. Thus, the HA
without the support of PF_KEY MIGRATE suffers from having
the old information in the IPsec database. More
specifically, the HA may forward the IP packets destined for
the MN to a wrong destination.</t>
<t>Therefore, it is RECOMMENDED that HA implements PF_KEY
MIGRATE message or equivalent function to avoid an
interoperability issue with regard to the dynamic update of
IPsec database.</t>
</section>
</section>
<!--
==================================================================
SADB_X_EXT_PACKET
==================================================================
-->
<section title="PF_KEY Packet Extension">
<t>In the bootstrapping stage of Mobile IPv6, the MN and 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 HA.</t>
<t>As mentioned in <xref target="RFC3776"/>, a 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 in a
sense that the IKE endpoint and the SA address on the MN side
are different; IKE endpoint must be an IP address other than
the home address of the MN, whereas the SA address must be the
MN's home address. This is because the home address cannot be
used prior to the initial home registration. The best
candidate for the IKE endpoint on MN side is the primary
care-of address of the MN since it is verified by the Mobile
IPv6 module to work.</t>
<t>For the above reasons, there is a need to guide IKE module
to make the right choice of IKE endpoint and SA address. More
specifically, IKE module should be notified on which IP
address the IKE negotiation should run.</t>
<t>A simple solution which enables the notification is to add
the information of the triggering packet to the SADB_ACQUIRE
message. The extension is called Packet Extension, which
allows a receiver of a SADB_ACQUIRE message (e.g. IKE module)
to inspect the triggering packet and take necessary action,
such as choosing specific IP address as an IKE endpoint for
the subsequent IKE negotiation.</t>
<t>The following is a structure of an extended SADB_ACQUIRE
message. As the figure shows, information of the triggering
packet is appended to the SADB_ACQUIRE message.
<figure>
<artwork><![CDATA[
<base, address(SD), address(P)*, identity(SD)*,
sensitivity*, proposal, packet*>
]]></artwork>
</figure>
</t>
<section title="Inserting Packet Extension to SADB_ACQUIRE Message">
<t>The IPsec subsystem MAY include a Packet Extension to a
SADB_ACQUIRE message when absence of IPsec SA is detected
during outbound packet processing. The IP packet to be
included in the Packet Extension MUST be the very IP packet
which triggered the ACQUIRE message IPsec sublayer.</t>
<t>The information of the triggering packet MUST contain IP
header, IP header options (in the case of IPv4), IP
extension headers (in the case of IPv6), and the transport
layer protocol header if there is any.</t>
<t>More than one packet extensions MUST NOT be appended to a
SADB_ACQUIRE message.</t>
<t>The figure below shows the format of the Packet Extension
which conforms the extension header specified in <xref
target="RFC2367"/>.
<figure>
<artwork><![CDATA[
struct sadb_x_packet {
uint16_t sadb_packet_len;
uint16_t sadb_packet_exttype;
uint32_t sadb_packet_copylen;
};
/* sizeof(struct sadb_x_packet) == 8 */
/* followed by an IP packet header which triggered
the SADB_ACQUIRE message */
]]></artwork>
</figure>
<list style="hanging">
<t hangText="sadb_packet_copylen">Indicates the exact
length of the packet header that follows the extension
header. Note that the 64 bit alignment rule applies to
the Packet Extension thus there could be padding appended
to meet the alignment requirement. This padding SHOULD be
set to zero by the sender (kernel) and MUST be ignored by
the receiver.</t>
</list>
</t>
</section>
<section title="Extracting Home Registration Information from Acquire Message">
<!-- address MIPv6 specific issues -->
<t>A receiver of a SADB_ACQUIRE message with a Packet
Extension MAY extract and process the extension header.</t>
<t>A Mobile IPv6 aware IKE daemon should be able to process
a Packet Extension which includes the IPv6 packet containing
the initial home registration BU message. An IPv6 packet
which contains following information is suspected to be a
home registration Binding Update message:
<vspace blankLines="1"/>
<list style="symbols">
<t>A mobility header message with message type 5 (BU).</t>
<t>In the BU message, Home Registration (H) bit is set.</t>
</list>
<vspace blankLines="1"/>
The source address field of the IPv6 header is supposed to
be the home address of the MN. In some systems, a home
address destination option may be present in the IP packet.
In such case, a care is needed to extract the care-of
address of the MN. In any case, the care-of address MUST be
extracted from the alternate care-of address, if the option
is present in the packet.</t>
<t>Recommendation: Mobile IPv6 module is recommended to
include an alternate care-of address option in every BU
message, regardless of the type of IPsec protocol (AH or
ESP) which is used to protect the message.</t>
</section>
<section title="Relation of Packet Extension to IKEv2">
<t>The Packet Extension is useful not only for Mobile IPv6
usage but also for other network scenarios where IKEv2 is
used as a key management protocol.</t>
<t>In <xref target="RFC4306">IKEv2</xref>, it is specified
that the first traffic selector of TSi and TSr should
contain the information of triggering packet when an
initiator requests establishment of IPsec SA triggered by a
data packet. The Packet Extension can provide the
information of the triggering packet to the IKE module.</t>
</section>
</section>
</section>
<!--
==================================================================
Necessary Modifications to Mobile IPv6 and IPsec/IKE
==================================================================
-->
<section title="Necessary Modifications to Mobile IPv6 and IPsec/IKE" toc="default">
<t> In order to realize the proposed mechanism, there are some
necessary modifications to Mobile IPv6 and IPsec/IKE. Following
are the summary of necessary modifications, which could be of
interest to 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 can 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 or security policy. It would also be
possible that the Mobile IPv6 code is only aware of minimum
IPsec configuration whether if IPsec is utilized or not.
<!-- FD: I don't understand -->
</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>
<t> Enabling Packet Extensions (SADB_X_EXT_PACKET): the
kernel should be able to append a SADB_X_EXT_PACKET
extension to SADB_ACQUIRE messages when they are triggered
by an output of a data packet. </t>
</list>
</t>
<t> Modifications to IKE: <list style="symbols">
<t> Processing PF_KEY MIGRATE messages: the IKE code may
update its local copy of IPsec databases (SPD and SAD) in
accordance with received PF_KEY MIGRATE messages. In addition,
it may update its state / IKE session with new endpoint
addresses indicated by PF_KEY MIGRATE messages. </t>
<t> Processing of Packet Extensions (SADB_X_EXT_PACKET): the
IKE code may process SADB_X_EXT_PACKET extensions and extract
necessary information from triggering packets. In order for
the IKE code to be MIPv6-aware, it should properly extract the
home address, care-of address, and HA address from IP packets
which carry home registration BU messages. </t>
</list>
</t>
</list>
</t>
</section>
<!--
==================================================================
Security Consideration
==================================================================
-->
<section title="Security Considerations" toc="default">
<t>The proposed schemes in this document do not raise any
security issue with regard to the authenticity of the IP packets
to be handled under the protection of an IPsec SA pair in tunnel
mode. This is because authenticity of the IP packet has nothing
to do with IP addresses in the IP header.</t>
</section>
<!--
==================================================================
Conclusion
==================================================================
-->
<section title="Conclusion" toc="default">
<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 for the
IPsec/IKE to migrate an endpoint address of tunnel IPsec SAs
from one to another. </t>
<t> PF_KEY MIGRATE messages also make it possible for IKE to
survive movements by updating its IKE session. </t>
<t> In order for the IKE to perform key negotiations and
rekeying, effort should be made to keep its SPD image
up-to-date. </t>
<t> The proposed mechanism was implemented on both Linux and
BSD platforms and confirmed to be working well. </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='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='February' day='23' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value='draft-nikander-esp-beet-mode-07' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-07.txt' />
</reference>
-->
<reference anchor='I-D.ietf-hip-mm'>
<front>
<title>End-Host Mobility and Multihoming with the Host Identity Protocol</title>
<author initials='T' surname='Henderson' fullname='Tom Henderson'>
<organization />
</author>
<date month='March' day='2' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-hip-mm-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-05.txt' />
</reference>
<reference anchor='I-D.ietf-mip6-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='November' day='' year='2007' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mip6-nemo-v4traversal-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-06.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 6 parts (boundary of each part
is marked with ">"). The message starts with PF_KEY base
message header followed by two address extensions. A pair of
address extensions hold source and destination address of the
selector. Rest of the message are specific to IPsec
implementation on BSD. 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_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 tunnel source address (64-bit aligned ... ~
+---------------+---------------+---------------+---------------+
~ old tunnel destination 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 tunnel source address (64-bit aligned ... ~
+---------------+---------------+---------------+---------------+
~ new tunnel destination 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 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 IPsec
implementation. 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
IPsec implementation. IPsec protocol (ESP or AH) and mode
(Tunnel) 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> The authors gratefully acknowledge the contribution of (in
alphabetical order): Arnaud Ebalard, 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>Kazunori Miyazawa provided valuable comments on Packet
Extension. Arnaud Ebalard provided valuable comments on Packet
Extension based on his implementation experience.</t>
<t>This document was generated by xml2rfc.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:27:30 |