Network Working Group M. Qi Internet-Draft H. Li Intended status: Standards Track Tsinghua Univ. Expires:May 17, 2008January 15, 2009 P. Yang Hitachi (China) R&D Corporation H. Deng China Mobile Y. Ma Hitachi (China) R&D CorporationK. Xu Tsinghua Univ. NovemberJuly 14,20072008 Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensionsdraft-qi-mip6-ikev2-interfacing-01draft-qi-mip6-ikev2-interfacing-02 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 onMay 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2007).January 15, 2009. Abstract This draft discusses the issues associated with interfacing between IKEv2/IPsec and MIPv6. When mobile nodes bootstrap in foreign network or handover to a new network, IKEv2/IPsec can not probe the changing of care-of-address, which is related security associations. One simple extension to the SADB_ACQUIRE in PF_KEY framework is proposed to support this interfacing. And the operation modification of IKEv2 and MIPv6 are described in this proposal based on the SADB_ACQUIRE extension. A new mobility security reference database is created to store the temporary mobility parameters. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements on IKEv2 and MIPv6 integration . . . . . . . . . 5 3. Mobile Security Reference Database (MSRD) . . . . . . . . . . 6 3.1. the structure of MSRD . . . . . . . . . . . . . . . . . . 6 3.2. MSRD APIs . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview of the extension to PF_KEY interface . . . . . . . . 7 5. Applicability to Mobile IPv6 scenarios . . . . . . . . . . . . 9 5.1. Treatment of transport SA for BU/BA during bootstrap . . . 9 5.2. Update tunnel mode SAs during handover . . . . . . . . . . 10 5.3. How to do Re-key of IPsec/IKE security associations (SA) . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Summary on the modification of related softwares . . . . . . . 13 6.1. The modification of IKEv2 software . . . . . . . . . . . . 13 6.2. The modification of MIPv6 software . . . . . . . . . . . . 13 6.3. The modification of OS kernel . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 19 1. Introduction IP security (IPsec) [RFC4301] framework could provide security services for traffic at IP layer. Internet Key Exchange v2 (IKEv2) [RFC4306] protocol is designed to negotiate IPsec security association (SA) between two end-to-end nodes, which are also called initiator and responder. IKEv2 protocol is a protocol which consists of two exchanges: (1) An authentication and key exchange to establish IKE-SA. This is also called IKEv2 INIT procedure (2) The protocol exchange with some payloads for negotiation IPsec security associations (i.e., Child-SAs). These payloads contain security algorithm parameters and traffic selector fields. This is the IKEv2 AUTH procedure, which is protected by IKE-SA In addition to the above-mentioned parts IKEv2 also includes some payloads and messages which allow configuration parameters to be exchanged primarily for remote access scenarios. Mobile IPv6 (MIPv6)[RFC3775] allows the mobile nodes(MN) to maintain the reachability while moving in the IPv6 network. After registration to home agent(HA), the packets destined to MN could be routed correctly by using the end-to-end tunnel, while MN is away from the home network. According the specification in [RFC3775], the MIPv6 signaling messages and optionally data packets should be protected by IPsec in transport mode or tunnel mode. While MN changes its IP point of attachment, the survival of related IPsec SAs must be maintained. IPsec has two related databases: Security Policy Database (SPD) is the place to store the requirements of IP security; Security Association Database (SAD) is the warehouse for all the SAs. PF_KEY interface is a socket protocol used by key management entities (such as IKEv2) to communicate with OS kernels for internal security management. MIPv6 entity could use PF_KEY interface to populate its security requirements in SPD and get the SA parameters in SAD. [RFC2367]. This document describes the seamless interfacing solution between IKEv2/IPsec and MIPv6. A new simple PF_KEY extension is proposed to support the smooth MIPv6 operation with the IPsec framework and IKEv2. We extended the SADB_ACQUIRE message in PF_KEY framework. A new mobile security reference database is created to store the temporary mobility parameters. It's a key reference database for IKEv2 entity to update the SAs in SAD and IKE internal parameters, while MN moves to another network. While this solution could support the seamless interworking between IKEv2/IPsec and MIPv6, it is easy to be applied to IKEv1/IPsec [RFC2409] framework. 2. Requirements on IKEv2 and MIPv6 integration The MN and the HA must use a pair of IPsec SAs to protect the integrity and authenticity of the Binding Updates and Acknowledgements. [RFC4877] specifies the dynamic keying requirements which applies to IKEv2[RFC4306] for BU/BA between MNs and HAs. The transport SAs between MN and HA should base on Home Address (HoA) of MN for survial of SA after the Care-of Address (CoA) is changed. This is because the Home Address (HoA) is unrecheable before registration during the bootstrapping phase in foreign network. Tunnel mode ESP is needed for Home Test Init (HoTi), Home Test (HoT) messages and optionally payload packets. Since the MN may change its attachment point to the Internet, it is necessary to update its endpoint address of the IPsec SAs using tunnel mode. The IKEv2 entities should dynamically update these SAs when the MN moves. In order to realize this, IKEv2 entity should be notified by Mobile IPv6 daemon with necessary information to modify the related SAs. As time goes by, the IPsec SAs and IKE SAs may expire and need to rekey. But MN would have some new CoAs, if it roams to other networks. So it is required to make IPsec SA rekey process by using MN's current address. This document proposes the new mobile security reference database (MSRD) and extension to PF_KEY socket to support the following functions for IKEv2/IPsec and MIPv6 interfacing: (1) Provision of related MIPv6 parameters for IKEv2 during bootstrapping phase in foreign network. (2) Interfacing between MIPv6 and IKEv2 to update the related SAs when MN does handover to another network. (3) Provision of related MIPv6 parameters for rekey of IKEv2/IPsec. This proposal only requires very simple extension (SADB_ACQUIRE extension) to the existing PF_KEY API. It could support the seamless interfacing between MIPv6 and IKEv2/IPsec with minimum modification of related softwares. 3. Mobile Security Reference Database (MSRD) 3.1. the structure of MSRD MSRD is the database for mobile security reference. MIPv6 daemon will store the mobility related parameters in this database. The information in this database should only be accessible for OS kernel and related key management daemons (such as IKEv2, etc.). Considering the structure, MSRD could be designed as a table indexed by mobile parameter index (MPI). Every table entry should include at least the current CoA, HoA, HA address and lifetime. Some other information could also be included to support other interworking functions (such as redundant SA negotiation) between IKEv2/IPsec and MIPv6. 3.2. MSRD APIs MSRD should support some basic APIs, but not limited to for table operation, uint64 MSRD_ADD(HoA, HA, CoA, lifetime, ...) the return value is the MPI for the added MSRD entry uint64 MSRD_DELETE(HoA, HA, CoA, lifetime, ...) the return value is the MPI for the deleted MSRD entry uint64 MSRD_GETMPI(HoA, HA, CoA, lifetime, ...) the return value is the MPI of MSRD entry whose parameters match the API arguments uint8 MSRD_QUERY(MPI, *HoA, *HA, *CoA, *lifetime, ...) Get the mobility related information from MSRD indexed by MPI. The return values are defined as below: 0 - success, 1 - entry not found by MPI, 2 - table unaccessible uint8 MSRD_UPDATE(MPI, HoA, HA, CoA, lifetime, ...) update the mobility related information in MSRD indexed by MPI. The return values are defined as below: 0 - success, 1 - entry not found by MPI, 2 - table unaccessible 4. Overview of the extension to PF_KEY interface The definition of SADB_ACQUIRE message is shown below < base, address(SD), address(P)*, identity(SD)*, sensitivity* proposal > * means optional payload The SADB_ACQUIRE message is typically sent by the kernel to key socket listeners who have registered their key socket (Such as the IKEv2 daemon). SADB_ACQUIRE messages also can be sent by application-level consumers of security associations. In this document, MIPv6 can send this message to kernel for security services of MIPv6 signaling and payload traffic. In the proposal, the SADB_ACQUIRE message is extended as below: < base, address(SD), address(P)*, identity(SD)*, sensitivity*, proposal, ref* > * means optional payload The definition of SADB_X_REF for 'ref' in the message is described below: struct sadb_x_ref { uint8_t sadb_ref_ver; //version uint8_t sadb_ref_type; //type uint16_t sadb_ref_type_ext; //sub type uint16_t sadb_ref_len; //length uint16_t sadb_ref_reserved; //length uint64_t sadb_ref_mpi; //index in MSRD }; /* SADB_X_REF header */ /* sizeof(struct sadb_x_ref) == 32 */ sadb_ref_type Type of this extension, 0 means originated from APP, 1 means originated from kernel sadb_ref_type_ext Sub-type of this extension, 0 is reserved for MIPv6 usage sadb_ref_mpi 64bit Reference index to MSRD The illustration of message layout for SADB_X_REF extension is shown below: 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 +---------------+---------------+---------------+---------------+ | sadb_ref_ver | sadb_ref_type | sadb_ref_sub_type | +---------------+---------------+---------------+---------------+ | sadb_ref_len | sadb_ref_reserved | +---------------+---------------+---------------+---------------+ | sadb_ref_mpi | | (64 bits) | +---------------+---------------+---------------+---------------+ Mobility related information is needed for IKEv2 daemon to negotiate the IPsec SAs. MIPv6 daemon stores all the required mobility parameters in the MSRD, which is indexed by mobile protocol index (MPI). This MPI must be included in the SADB_X_REF extension of SADB_ACQUIRE message from MIPv6 daemon to the kernel. This message will be delivered to registered key management daemon (IKEv2). then, IKEv2 daemon could get the mobility related parameters (such as CoA, redundant HA, etc) from MSRD by using the sadb_ref_mpi field in the SADB_ACQUIRE message from kernel. 5. Applicability to Mobile IPv6 scenarios 5.1. Treatment of transport SA for BU/BA during bootstrap The Figure below shows the framework and internal procedure of interfacing between MIPv6 and IKEv2/IPsec to set up the transport mode SA for BU/BA protection during bootstrap. 6.Query 1. Modify +------------+ MSRD by MPI MSRD +-----------+ | |< ----------+ +-----------| | | IKEv2 | | V | MIPv6 | | | +------+ | | +------------+ | MSRD | +-----------+ | A +------+ | | 7. Update| | A 3. send| |2. Modify SAD | |5. PF_KEY | BU/BA| | SPD | | SADB_ACQUIRE | | | | | |4.GetMPI | | | | | by MSRD API | | User Space | | | | | ==========[ | | **PF_KEY Interface** | |]=========== Kernel | | +------+-----+ | | | +----------| IPsec |< -------+ | V | sub-system | V +-------+ +------------+ +-------+ | SAD | | SPD | +-------+ +-------+ The brief procedure is described as below: 1. MIPv6 daemon add or update the MSRD entries when it is needed to set up SAs to protect BU and BA; 2. MIPv6 daemon add or update the related SPD entries based on the related mobility parameters; 3. MIPv6 daemon sends BU or BA to the IPsec sub-system in kernel; 4. Kernel will query MSRD based on the content of BU to get the MPI by using MSRD API; 5. Kernel puts the MPI in SADB_X_REF extension, builds and sends the SADB_ACQUIRE message to IKEv2 daemon; 6. Upon receiving this SADB_ACQUIRE message from kernel, IKEv2 daemon will query the MSRD by MPI to get the mobility related parameters (such as CoA, etc); 7. IKEv2 daemon will negotiate the transport SA for BU/BA and update the SAD according to the specification in [RFC4877]; 5.2. Update tunnel mode SAs during handover The Figure below shows the framework and internal procedure of interfacing between MIPv6 and IKEv2/IPsec to update the tunnel mode SA between MN and HA during handover. 4.Query 1. Modify +------------+ MSRD by MPI MSRD +-----------+ | |< ----------+ +-----------| | | IKEv2 | | V | MIPv6 | | | +------+ | | +------------+ | MSRD | +-----------+ | A +------+ | | 5. Update| | | |2. Modify SAD | |3. PF_KEY | | SPD | | SADB_ACQUIRE | | | | | | | | | | User Space | | | | ==========[ | | **PF_KEY Interface** | |]=========== Kernel | | | | | +---------------------------------+ | V V +-------+ +-------+ | SAD | | SPD | +-------+ +-------+ The brief procedure is described as below: 1. MIPv6 daemon add or update the MSRD entries when it handover to a new network; 2. MIPv6 daemon update the related SPD entries based on the related mobility parameters; 3. MIPv6 daemon sends SADB_ACQUIRE message with SADB_X_REF extension to the IPsec sub-system in kernel. Inside this message, the MPI should be included. The kernal will check its integrity and deliver it to IKEv2 daemon; 6. Upon receiving this SADB_ACQUIRE message from kernal, IKEv2 daemon will query the MSRD by MPI to get the mobility related parameters (such as CoA, etc); 7. IKEv2 daemon will update the tunnel mode SAs in the SAD based on the information in MSRD and SPD. It will also update the related parameters inside IKEv2 daemon (such as IKE SA, etc); The BU/BA re-registration in same network will not trigger MIPv6 daemon to send the SADB_ACQUIRE messages 5.3. How to do Re-key of IPsec/IKE security associations (SA) When the MIPv6-related IPsec SAs in SAD expire, IPsec sub-system in kernel will send SADB_EXPIRE message to IKEv2 daemon. In this case, IKEv2 should know the mobility related information in MSRD. The straightforward way is to store the related MPI in IKEv2 daemon. So upon receiving the SADB_EXPIRE message from kernel, IKEv2 could get information MSRD by MPI directly and update the related SAD. This procedure is depicted in the picture below. 2.Query +------------+ MSRD by MPI +-----------+ | |< ----------+ +-----------| | | IKEv2 | | V | MIPv6 | | | +------+ | | +------------+ | MSRD | +-----------+ | A +------+ | 3. Update| | | SAD | |1. PF_KEY | | | SADB_EXPIRE | | | | | | | User Space | | | ==========[ | | **PF_KEY Interface** |]=========== Kernel | | +------------+ | | +----------| IPsec | | V | sub-system | V +-------+ +------------+ +-------+ | SAD | | SPD | +-------+ +-------+ If IKEv2 daemon does not store the MPI for mobility SAs, the OS kernal need to query the MSRD based on the information in SAs. After it gets the MPI, kernel could encapsulate it in SADB_X_REF extension of SADB_EXPIRE to IKEv2 daemon. In this case, the SADB_EXPIRE should be extended to support the SADB_X_REF extension. This could follow the same way of SADB_ACQUIRE extension in this documents. The picture below describes this case. 3.Query +------------+ MSRD by MPI +-----------+ | |< ----------+ +-----------| | | IKEv2 | | V | MIPv6 | | | +------+ | | +------------+ | MSRD | +-----------+ | A +------+ | 4. Update| | A | SAD | |2. PF_KEY | | | | SADB_EXPIRE | | | | |1.GetMPI | | | | by MSRD API | User Space | | | | ==========[ | | **PF_KEY Interface** |]=========== Kernel | | +------+-----+ | | +----------| IPsec | | V | sub-system | V +-------+ +------------+ +-------+ | SAD | | SPD | +-------+ +-------+ The brief procedure is described as below: 1. while the mobility-related SAs IPsec are expiring sub-system Kernal will query MSRD based on the content of BU to get the MPI; 2. Kernal puts the MPI in SADB_X_REF extension, builds and sends the SADB_EXPIRE message to IKEv2 daemon; 3. Upon receiving this SADB_EXPIRE message from kernel, IKEv2 daemon will query the MSRD by MPI to get the mobility related parameters (such as CoA, etc); 4. IKEv2 daemon will rekey the related SA in SAD; 6. Summary on the modification of related softwares 6.1. The modification of IKEv2 software IKEv2 daemon should be able to extract MPI from SADB_X_REF payload. It should be able to retrieve the mobility related parameters from MSRD by MPI or SA parameters. It should support the capability to set up the specific IPsec SAs in mobile environment or to modify IPsec SAs when receiving extended SADB_ACQUIRE message in this documents. It should be able to rekey the specific IPsec SAs in mobile environment when receiving extended SADB_EXPIRE message in this document. 6.2. The modification of MIPv6 software Mobile Ipv6 should be able to write and index the mobility information in the MSRD that can be read by OS kernel, IKEv2 daemon or any other related key management daemons. Mobile Ipv6 should send extended PF_KEY SADB_ACQUIRE message with SADB_X_REF to kernel. This is the notification of MN's roaming to new network. 6.3. The modification of OS kernel Kernel should be able to recognize SADB_X_REF payload and to deal with it. It should be able to add this payload in SADB_ACQUIRE message and optionally SADB_EXPIRE message. In some cases, OS kernel should support the MSRD query API for IPsec SA rekey. 7. Security Considerations The MSRD should be only accessible for MIPv6 daemon, OS kernel and related key management daemons (such as IKEv2). Only MIPv6 daemons could have the full manipulation right on MSRD. MSRD is read-only for all the other softwares. When a query is received, MSRD should check whether the MPI is valid. Besides this point, there is no other security issues for consideration introduced by this documents. 8. Conclusion In this documents, the simple PF_KEY extension is proposed to support the full seamless interworking between IKEv2/IPsec and MIPv6. A new SADB_X_REF extension is created for SADB_ACQUIRE message and optionally SADB_EXPIRE message in PF_KEY framework. The basic target for this extension is to provide the mobility related information in the cases of bootstrap in Foreign network, handover to a new network and IPsec SA rekey. The proposal in this document incurs small modification on the softwares of IKEv2, MIPv6 and OS kernel. 9. Normative References [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 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. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. Authors' Addresses Minpeng Qi Tsinghua Univ. Network Institute Department of Computer Science and Technology Tsinghua University Haidian District Beijing, 100084 P.R. China Phone: +861062785818(ext.)6864 Email: qiminpeng@csnet1.cs.tsinghua.edu.cn Haitao Li Tsinghua Univ. Network Institute Department of Computer Science and Technology Tsinghua University Haidian District Beijing, 100084 P.R. China Phone: +861062785818(ext.)6864 Email: lihaitao@csnet1.cs.tsinghua.edu.cn Peng Yang Hitachi (China) R&D Corporation N301, Tower C Raycom Infotech Park 2 kexueyuan Nanlu Haidian District Beijing, 100080 P.R. China Phone: +861082862918(ext.)328 Email: pyang@hitachi.cn Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 P.R. China Email: denghui@chinamobile.com Yuanchen Ma Hitachi (China) R&D Corporation N301, Tower C Raycom Infotech Park 2 kexueyuan Nanlu Haidian District Beijing, 100080 P.R. China Phone: +861082862918(ext.)327 Email: ycma@hitachi.cnKe Xu Tsinghua Univ. Network Institute Department of Computer Science and Technology Tsinghua University Haidian District Beijing, 100084 P.R. China Phone: +861062785818(ext.)6864 Email: xuke@csnet1.cs.tsinghua.edu.cnFull Copyright Statement Copyright (C) The IETF Trust(2007).(2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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.Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).