Network Working Group S. Sugimoto
Internet-Draft Ericsson/USAGI Project
Expires: August 18, 2005 F. Dupont
Point6
February 14, 2005
PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE
draft-sugimoto-mip6-pfkey-migrate-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes need for interface between Mobile IPv6 and
IPsec/IKE and show how two protocols can interwork each other. We
propose a mechanism to realize this interaction by extending PF_KEY
framework. Proposed mechanism makes it possible for Mobile IPv6 to
inform IPsec/IKE about the movement. Receiving the message, IPsec
Sugimoto & Dupont Expires August 18, 2005 [Page 1]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
components can take necessary actions to update corresponding entry
in SPD and SADB. In addition, IKE can use the notification for
keeping its IKE connection alive.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Needs for Interactions between Mobile IPv6 and IPsec/IKE . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. PF_KEY Extension for Mobile IPv6 . . . . . . . . . . . . . . . 8
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Message Sequence . . . . . . . . . . . . . . . . . . . . . 9
5.3 Issuing PF_KEY MIGRATE Message . . . . . . . . . . . . . . 10
5.4 Processing PF_KEY MIGRATE Message . . . . . . . . . . . . 11
5.5 Applicability of PF_KEY MIGRATE to Other Systems . . . . . 12
5.6 Limitation of PF_KEY MIGRATE . . . . . . . . . . . . . . . 12
6. Necessary Modifications to Mobile IPv6 and IPsec/IKE . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
A. PF_KEY MIGRATE Message Format . . . . . . . . . . . . . . . . 17
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
Sugimoto & Dupont Expires August 18, 2005 [Page 2]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
1. Introduction
In Mobile IPv6 [RFC3775], the MN and HA may use IPsec tunnel to
protect mobility signals and payload traffic. From security point of
view, it is preferable to protect mobility signals that are
transmitted on the path between MN and HA. In addition, mobile user
may want to have payload traffic protected by IPsec tunnel. Hence,
leveraging IPsec tunnel is essential in Mobile IPv6 operation. Since
the MN may change its attachment point to the Internet, it is
necessary to update endpoint address of the IPsec tunnel. This
indicates that corresponding entry in IPsec database (SPD and SADB)
should be updated when MN performs movement. In addition, IKE
requires treatment to keep its IKE connection alive in Mobile IPv6
environment.
This document describes need for interface between Mobile IPv6 and
IPsec/IKE and show how two protocols can interwork each other. We
propose a mechanism to realize this interaction by extending PF_KEY
framework [RFC2367]. Proposed mechanism makes it possible for Mobile
IPv6 to inform IPsec/IKE about the movement. Receiving the message,
IPsec components can take necessary actions to update corresponding
entry in SPD and SADB. In addition, IKE can use the notification for
keeping its IKE connection alive. Proposed mechanism has been
implemented on both Linux and BSD platform and confirmed to work well
with existing Mobile IPv6 and IPsec/IKE stack.
Sugimoto & Dupont Expires August 18, 2005 [Page 3]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
2. Terminology
There is no term newly introduced in this document. Definitions of
the terms relevant to Mobile IPv6 can be found in [RFC3775] and
[RFC3776]. Definitions of the terms relevant to IPsec can be found
in [RFC2401] and [I-D.ietf-ipsec-rfc2401bis]. Some clarifications
are provided below for the terms that are frequently used in this
document.
Care-of address (CoA) - Topologically correct IPv6 address assigned
for MN. MN registers its primary CoA to the HA, which is called home
registration. CoA should be an endpoint address of the tunnel
established between the MN and HA. The tunnel could be either
IP-in-IP tunnel or IPsec tunnel.
Movement - An event in which MN moves from one subnet to another
changing its primary CoA. In Mobile IPv6, movement can be
categorized into following three types: Home-to-Foreign,
Foreign-to-Foreign, and Foreign-to-Home. In terms of necessary
actions taken upon movement, each case should be differentiated.
Return Routability procedure - A mechanism for authorizing Binding
Update (BU) message sent by the MN to CN. There are four Mobility
Header (MH) messages involved in the procedure: Home Test Init
(HoTI), Home Test (HoT), Care-of Test Init (CoTI), and Care-of Test
(CoT). In order to minimize a chance for malicious node to eavesdrop
contents of the Home Test, it is strongly recommended to protect HoTI
and HoT with IPsec tunnel.
Sugimoto & Dupont Expires August 18, 2005 [Page 4]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
3. Needs for Interactions between Mobile IPv6 and IPsec/IKE
First of all we try to figure out needs for interactions between
Mobile IPv6 and IPsec/IKE. Ideally, there should be no interactions
needed. However, throughout prototyping activity and operation of
Mobile IPv6, we have identified following needs.
MN may change its attachment point to the Internet whenever it
performs movement. Consequently, its local address of tunnel
established between its HA should be updated. Since CoA is used as
an endpoint for the tunnel, both MN and HA should take necessary
update. On MN, local address of the tunnel should be updated with
newly assigned CoA. On HA, remote address of the tunnel should be
updated with newly registered CoA. As for normal IP-in-IP tunnel,
Mobile IPv6 should be able to update the endpoint address easily.
However, Mobile IPv6 may not have full control on updating endpoint
of IPsec tunnel since it requires direct access to the IPsec
database. This indicates that Mobile IPv6 should request IPsec for
updating specific entry in SADB.
In practical scenario, key management protocol such as IKE would be
used to establish security association between the MN and HA. IKE
daemon should always be aware of up-to-date SPD in order to perform
key negotiations and subsequent rekeying. Since IKE runs according
to the SPD, tunnel information (endpoint addresses) should be somehow
included in security policy entry. Although specific data structure
of a security policy is implementation specific, most of the existing
IPsec implementations conceptually have such information in security
policy. Considering the fact that tunnel endpoint address could be
dynamically updated, corresponding entry in SPD should also be
updated.
Mobile IPv6 specifies a flag named Key Management Mobility Capability
bit (K-bit) in Binding Update and Binding Acknowledgement message
(see section 10.3.1 of [RFC3775]), which indicates an ability of IKE
to survive movement. When both MN and HA agree to use this
functionality, the IKE daemons dynamically update its IKE connection
when the MN performs movement. In order to realize this, IKE daemon
should be notified by Mobile IPv6 and necessary information to
migrate the IKE connection should be provided.
Mobile IPv6 may need to make an access to SPD not only for updating
endpoint address but also for deletion/insertion of specific security
policy entry. When the MN performs Foreign-to-Home movement, IPsec
tunnel established between the MN and HA should be destroyed, 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
tunnel should newly be created. Hence security policy entries that
Sugimoto & Dupont Expires August 18, 2005 [Page 5]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
are associated with tunnel mode security association may dynamically
be added/removed in along with MN's movement.
It should be noted that NEMO Basic Support [RFC3963] may have similar
requirements for the Mobile Router (MR) and MR's HA (MRHA). In NEMO,
MR works just as same as MN registering its location information to
the MRHA and establishes tunnel (IP-in-IP or IPsec tunnel). If IPsec
tunnel is established between MR and MRHA, the MR serves as a
Security Gateway (SGW) for the nodes inside the mobile network. MR
is responsible for handling its tunnel endpoint properly.
Sugimoto & Dupont Expires August 18, 2005 [Page 6]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
4. Requirements
Given the needs for interface between Mobile IPv6 and IPsec/IKE,
there should be minimum interface between the two protocols.
Followings are the requirements for the interface from software
engineering point of view.
o Necessary modifications to the existing software, namely Mobile
IPv6 and IPsec/IKE should be kept minimum in order to realize
proposed mechanism.
o 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 mechanism.
Sugimoto & Dupont Expires August 18, 2005 [Page 7]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
5. PF_KEY Extension for Mobile IPv6
In order to fulfil the needs and requirements described in Section 3
and Section 4 we propose to extend PF_KEY framework so that Mobile
IPv6 and IPsec/IKE could interact each other. The extension is
primarily for migrating endpoint address of IPsec tunnel from one to
another, which results in updating IPsec database. A new PF_KEY
message named MIGRATE was introduced for the mechanism.
5.1 Overview
The figure below illustrates how Mobile IPv6 and IPsec/IKE components
interact each other with PF_KEY MIGRATE message in 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. In any case, Mobile IPv6 should be the one who issues
the MIGRATE message. On right top, there is an IKE daemon who is
responsible for establishing security associations required for
Mobile IPv6 operation. In manual keying scenario, the difference is
only that there is no IKE daemon running on the system.
+-------------+ +------------+
| | | |
| Mobile IPv6 | | IKE Daemon |
| | | |
+-------------+ +------------+
| 1. PF_KEY A 4. Update
| MIGRATE | SPD & SADB
+-----------+ +-----------+
| |
Userland V |
==========================[PF_KEY Socket]========================
Kernel | |
+----------+ +----------+
| 2. Update | 3. Update
V SPD V SADB
+-----------+ +------------+
| | | |
| SPD | | SADB |
| | | |
+-----------+ +------------+
The primary role of PF_KEY MIGRATE message is to migrate endpoint
address of tunnel mode SA requesting IPsec to update its database
(SPD and SADB). In addition, the message can be used by IKE to
enhance its mobility capability. If the PF_KEY MIGRATE message is
properly processed by the kernel, it will be sent to all open socket
as normal PF_KEY messages. A sequence of processing MIGRATE message
Sugimoto & Dupont Expires August 18, 2005 [Page 8]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
is done in following steps:
o Mobile IPv6 issues a PF_KEY MIGRATE message to the PF_KEY socket.
o Operating system (kernel) validates the message and checks if
corresponding security policy entry exists in SPD.
o If the message is confirmed to be valid, the target security
policy entry is updated according to the MIGRATE message. If
there is any target security association found that are also
target of the update, those should also be updated.
o After the MIGRATE message is successfully processed inside the
kernel, it will be sent to all open PF_KEY socket.
o IKE daemon receives the MIGRATE message from PF_KEY socket and
updates its SPD and SADB. IKE daemon may also update its IKE
connection to keep it alive.
Note that the way IKE maintains its local copy of SPD is
implementation specific issue since there is no standard interface to
access SPD. Some IKE implementation may continuously monitor SPD
inside the kernel. Some IKE implementation may expect notification
from the kernel when SPD is updated. In either way, the proposed
mechanism gives a chance for IKE to keep its SPD up-to-date which is
significant in Mobile IPv6 operation.
5.2 Message Sequence
Next, we will see how migration takes place in along with home
registration. The figure below shows sequence of mobility signals
and PF_KEY MIGRATE messages while the MN roams around subnets. It is
assumed that in initial state the tunnel endpoint address for given
MN is set as its home address. In initial home registration, the MN
and HA migrate the tunnel endpoint address from HoA to CoA1. It
should be noted that no migration takes place when the MN performs
re-registration since the care-of address remains same. Accordingly,
the MN performs movement and changes its primary care-of address from
CoA1 to CoA2. PF_KEY MIGRATE message is issued on both MN and HA.
When the MN returns home, migration takes place updating the endpoint
address with MN's home address.
Sugimoto & Dupont Expires August 18, 2005 [Page 9]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
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)
| |
5.3 Issuing PF_KEY MIGRATE Message
Mobile IPv6 entity (MN or HA) triggers the migration by sending
PF_KEY MIGRATE message to the PF_KEY socket. Conceptually, the
PF_KEY MIGRATE message should contain following information:
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 address of IPsec tunnel
* old destination address of IPsec tunnel
* IPsec protocol (ESP/AH)
* mode (Tunnel)
o New SA information
* new source address of IPsec tunnel
* new destination address of IPsec tunnel
Sugimoto & Dupont Expires August 18, 2005 [Page 10]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
* IPsec protocol (ESP/AH)
* mode (Tunnel)
Selector information is required for specifying target security
policy entry to be updated. It should contain information required
for selector as specified in [RFC2401]. Plus, direction of the
security policy (inbound/outbound) should be provided. Old SA
information is used to specify target security association to be
updated. Source and destination address of the target entry should
be overwritten with the ones included in new SA information. Note
that IPsec protocol and mode are not updated by the PF_KEY MIGRATE
message.
The PF_KEY MIGRATE message should be formed based on security policy
configuration and binding record. Selector information and some
parts of the SA information (IPsec protocol and mode) should be taken
from policy configuration. The rest of the information should be
taken from sequential binding information. For example, in the case
where the MN updates its inbound security policy and corresponding
tunnel mode security association, the old source address of the IPsec
tunnel should be set as its previous CoA, and the new source address
of the IPsec tunnel should be set as its current CoA. Hence, MN
should sequentially keep track of its CoA record. Such information
shall be stored in binding update list entry. For the same reason,
HA should keep track of previous CoA of MN. Such information shall
be stored in binding cache entry.
Additionally, a piece of information which indicates 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 IKE
endpoint in accordance with PF_KEY MIGRATE message.
Detailed message format of PF_KEY MIGRATE is provided in Appendix A.
5.4 Processing PF_KEY MIGRATE Message
Since a PF_KEY MIGRATE message is applied to single security policy
entry, kernel should first check validity of the message. If the
message is invalid, EINVAL error MUST be returned as a return value
for the write() operation made to the PF_KEY socket. After the
validation, kernel checks if target security policy entry really
exists in SPD. If there is no entry found, ESRCH error MUST be
returned. In any error case, the message must not have any effect on
SPD and SADB and migration becomes incomplete.
With respect to the behavior of normal process (including IKE daemon)
who receives PF_KEY MIGRATE message from PF_KEY socket, it SHOULD
first check if the message does not include error information. If
Sugimoto & Dupont Expires August 18, 2005 [Page 11]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
there is any error indicated, the process MUST silently discard the
PF_KEY MIGRATE message. Otherwise, processing of the message may
continue.
5.5 Applicability of PF_KEY MIGRATE to Other Systems
It should be noted that PF_KEY MIGRATE is also applicable to other
systems than Mobile IPv6. For example, it can be used in a scenario
where IPsec/IKE enabled node establishes tunnel mode security
association with its Security Gateway while it roams around the
network (aka "road warrior"). Security policy is set as such that
all traffic should bi-directionally go through the IPsec tunnel. In
such case, migration of the tunnel endpoint address can be handled by
PF_KEY MIGRATE message. Each time the node changes its attachment
point to the Internet, PF_KEY MIGRATE should be issued to the system.
Consequently, the IPsec database (SPD and SADB) shall be properly
updated.
It is also essential to keep design of the mechanism protocol
independent. More specifically, PF_KEY MIGRATE should be able to
work on both IPv4 and IPv6. In order to achieve this, IP addresses
to be stored in selector and security association information should
be handled in a protocol-independent manner.
5.6 Limitation of PF_KEY MIGRATE
Currently, Security Parameter Index (SPI) is not included in the old
SA information to specify target security association entry. This
helps to lessen operational burden of Mobile IPv6. However, this
simplification can produce ambiguity in searching for the target
security association entry. Further considerations and improvements
needed.
It should be noted that delivery of PF_KEY MIGRATE message cannot be
guaranteed, which is common to other PF_KEY messages. It may be
possible that the 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. Once a PF_KEY MIGRATE message
is lost, it would not be possible for the receiver to process
subsequent MIGRATE message properly. Initialization of Mobile IPv6
stack and IPsec database may be needed for recovery. Further
improvements should be made.
Sugimoto & Dupont Expires August 18, 2005 [Page 12]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
6. Necessary Modifications to Mobile IPv6 and IPsec/IKE
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
implementators of Mobile IPv6/IPsec/IKE.
o Modifications to Mobile IPv6:
* Mobile IPv6 makes an access to PF_KEY socket. In particular,
Mobile IPv6 should have privilege to write data to PF_KEY
socket.
* Issue PF_KEY MIGRATE message. In order to form the MIGRATE
message, it is required that Mobile IPv6 should be aware of its
IPsec (security policy) configuration and precise binding
record.
o Modifications to IPsec:
* Processing of PF_KEY MIGRATE message. Kernel should be able to
process the PF_KEY MIGRATE sent by Mobile IPv6. Unless the
message is invalid, it should be sent to all open PF_KEY
socket.
o Modifications to IKE:
* Processing of PF_KEY MIGRATE message. IKE may update its local
copy of IPsec database (SPD and SADB) in accordance with
received PF_KEY MIGRATE message. In addition, it may update
its IKE connection with new endpoint address indicated by the
PF_KEY MIGRATE message.
Sugimoto & Dupont Expires August 18, 2005 [Page 13]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
7. Security Considerations
There is no security considerations newly raised by the mechanism
proposed in this document.
Sugimoto & Dupont Expires August 18, 2005 [Page 14]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
8. Conclusion
o There are needs for Mobile IPv6 and IPsec/IKE to interact each
other to provide full support of IPsec security functions.
o An extension to PF_KEY framework (PF_KEY MIGRATE message) was
proposed, which makes it possible for the IPsec/IKE to migrate
endpoint address of the IPsec tunnel from one to another.
o PF_KEY MIGRATE message also makes it possible for IKE to survive
movements by updating its IKE connection.
o In order for the IKE to perform key negotiations and rekeying,
effort should be made to keep its SPD up-to-date.
o The proposed mechanism was implemented on both Linux and BSD
platform and confirmed to be working well.
o Currently, large portion of the proposed mechanism is
implementation dependent due to lack of standard interface to
access SPD (PF_POLICY?).
9. References
[I-D.ietf-ipsec-rfc2401bis]
Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol",
Internet-Draft draft-ietf-ipsec-rfc2401bis-05, December
2004.
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management
API, Version 2", RFC 2367, July 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3776] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
Sugimoto & Dupont Expires August 18, 2005 [Page 15]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
Authors' Addresses
Shinta Sugimoto
Ericsson Research Japan
Koraku Mori Building
1-4-14, Koraku, Bunkyo-ku
Tokyo 112-0004
Japan
Phone: +81 3 3830 2241
Email: shinta.sugimoto@ericsson.com
Francis Dupont
Point6
c/o GET/ENST Bretagne
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Fax: +33 2 99 12 70 30
Email: Francis.Dupont@enst-bretagne.fr
Sugimoto & Dupont Expires August 18, 2005 [Page 16]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
Appendix A. PF_KEY MIGRATE Message Format
The figure below shows the message format of PF_KEY MIGRATION. 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 of 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.
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 |
+---------------+---------------+---------------+---------------+
Sugimoto & Dupont Expires August 18, 2005 [Page 17]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
| sadb_x_ipsecrequest_reserved2 |
+---------------+---------------+---------------+---------------+
~ old tunnel source address (64-bit aligned sockaddr) ~
+---------------+---------------+---------------+---------------+
~ old tunnel destination address (64-bit aligned 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 sockaddr) ~
+---------------+---------------+---------------+---------------+
~ new tunnel destination address (64-bit aligned sockaddr) ~
+---------------+---------------+---------------+---------------+
Following is a structure of PF_KEY base message header specified in
[RFC2367]. A new message type for PF_KEY MIGRATE (i.e.
SADB_X_MIGRATE) should be specified in member sadb_msg_type.
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;
};
Following is a structure of address extension header specified in
[RFC2367]. Upper layer protocol should be specified in member
sadb_address_proto.
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;
};
Following is a structure for holding attributes that are relevant to
security policy, which is available on BSD IPsec implementation.
Sugimoto & Dupont Expires August 18, 2005 [Page 18]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
Direction of the target security policy should be specified in member
sadb_x_policy_dir.
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;
};
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.
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;
};
Sugimoto & Dupont Expires August 18, 2005 [Page 19]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
Appendix B. Acknowledgements
The authors gratefully acknowledges the contribution of: Masahide
Nakamura, Kazunori Miyazawa, Noriaki Takamiya.
Sugimoto & Dupont Expires August 18, 2005 [Page 20]
Internet-Draft PF_KEY Extension for Mobile IPv6 February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sugimoto & Dupont Expires August 18, 2005 [Page 21]