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]