Network Working Group Y. Xu Internet-Draft Tsinghua Univ. Intended status: Standards Track P. Yang Expires: April 10, 2009 Y. Ma Hitachi (China) R&D Corporation H. Deng China Mobile K. Xu Tsinghua University October 7, 2008 IKEv2 SA Synchronization for session resumption draft-xu-ike-sa-sync-01 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 on April 10, 2009. Xu, et al. Expires April 10, 2009 [Page 1] Internet-Draft IKEv2 SA SYNC October 2008 Abstract It will take a long time and mass computation to do session resumption among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded. The major reason is that the prcocedure of IKEv2 SA re-establishment will incur a time-consuming computation especially in the Diffie- Hellman exchange. In this draft, a new IKE security associations synchronization solution is proposed to do fast IKE SA session resumption by directly transferring the indexed IKE SA (named stub) from old gateway to new gateway, wherein the most expensive Diffie- Hellman calculation can be avoided. Without some time-consuming IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption procedures can be finished in a short time. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Application scenarios of IKEv2 Session Resumption . . . . . . 4 2.1. Scenario of IKEv2 Gateway fail . . . . . . . . . . . . . . 4 2.2. Scenario of load-balance . . . . . . . . . . . . . . . . . 5 3. Details on Proposed solution . . . . . . . . . . . . . . . . . 6 3.1. Overview of the Proposed solution . . . . . . . . . . . . 6 3.2. data structure of stub . . . . . . . . . . . . . . . . . . 7 3.3. Consideration on building IKE SA in session resumption . . 7 3.4. Consideration on Stub handling . . . . . . . . . . . . . . 7 3.5. Consideration on location of Stub . . . . . . . . . . . . 9 3.6. When should Gateways download/update Stub . . . . . . . . 10 3.7. Related new messages . . . . . . . . . . . . . . . . . . . 11 4. Modification on the base IKEv2 protocol . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Xu, et al. Expires April 10, 2009 [Page 2] Internet-Draft IKEv2 SA SYNC October 2008 1. Background IKEv2 protocol which has been defined by [RFC4306] provides us a method to negotiate ipsec's key automatically between ipsec clients and gateway. Before negotiating ipsec's key, they should negotiate IKE's SA first. Usually, ipsec client sends IKE_INIT message to gateway with SAi1, KEi, Ni, then gateway chooses some proposal of SAi1 which come to the algorithm for encryption and decryption, also proposal for Diffie-Hellman, and then calculates the Diffie-Hellman, sends IKE_INIT respond message back to ipsec client. At this time, the most important keyring can be generated. After other IKE_AUTH exchange, The identity has verified. IKE SA has completely been established. The timing overhead of IKEv2 protocol, including some computation and signaling round-trips, is rather big especially when the Extensible Authentication Protocol (EAP) is used for third-party authentication. The picture below is the typical procedure for IKEv2 SA establishment. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> < -- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,],AUTH, SAi2, TSi, TSr} --> < -- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Figure 1: IKE_INIT and IKE_AUTH exchanges The establishment of an IKE SA in the first two exchanges of IKEv2 procedure in [RFC4306] (especially Diffie-Hellman computation), is rather time-consuming. Normally, the IKEv2/IPsec gateway embodyment (like IPsec VPN gateway, Mobile IPv6 Home Agent, etc) keeps a large number of IKE/IPsec sessions. So in some scenarios (see Section 2), it will take a very time to re-establish all the IKE SA for session resumption of IKEv2/IPsec clients. Xu, et al. Expires April 10, 2009 [Page 3] Internet-Draft IKEv2 SA SYNC October 2008 2. Application scenarios of IKEv2 Session Resumption 2.1. Scenario of IKEv2 Gateway fail IPsec old new/old client Gateway gateway | | | | IKE/IPsec SAs | | |< ========================== >| | | | | | | | | O Fail of old GW | | | | O detect the fail | | | of old GW | | | | | | new IKE init procedure | |< =================================================== >| | | | | set up other child IPsec SAs | |< =================================================== >| | | | Figure 2: scenarios of IKEv2 Gateway fail In this scenario, IPsec clients has established IKE/IPsec connections with old gateway with tunnel mode or transporation mode. Because of some reason, the old gateway may fail. In this case, IPsec client can know old gateway has failed(how to know gateway fail is out of our scope in this draft), and re-establish the IKEv2/IPsec sessions with the old gateway or another new gateway. While a large number of IPsec clients try to make the IKEv2/IPsec connections at the same moment, it will take a rather long time due to the reason mentioned in Section 1. And, the target gateway may have problem to response some clients in this case as well. The problem statement and goals for a failover solution are described in [Narayanan06]. Xu, et al. Expires April 10, 2009 [Page 4] Internet-Draft IKEv2 SA SYNC October 2008 2.2. Scenario of load-balance IPsec old new client Gateway gateway | | | | IKE/IPsec SAs | | |< ========================== >| | | | | | | | | O overload of old GW | | | | O detect the overload | | | of old GW | | | | | | new IKE init procedure | |< =================================================== >| | | | | set up other child IPsec SAs | |< =================================================== >| | | | Figure 3: load-balance scenarios In this scenario, after establishing IKE connections between IPsec clients and old gateway, the old gateway may be over-loading. then, some of the IPsec clients should stop the connection with old gateway and establish the connection with new gateway(how to know new gateway is also out of our scope). Again, while many IKE/IPsec sessions are transferred from old gateway to new gateway, it is a challenge to new gateway to re-establish bunch of IKE SAs at the same time. Xu, et al. Expires April 10, 2009 [Page 5] Internet-Draft IKEv2 SA SYNC October 2008 3. Details on Proposed solution 3.1. Overview of the Proposed solution In this section, a new data structure is named as "stub", which has the most important information of IKE SA. And gateway can use this data structure to accelerate the rebuilding of IKE SA. IKE_INIT message is extended with a new payload called IKE_SA_SYN. Since the gateway's IP address and SPI can uniquely index the stub of IKE SA, these two information are mandatory in the IKE_SA_SYN payload in order to retrieve the stub of IKE SA by the target gateway. The detailed data structure of Stub is introduced in Section 3.2. The IKE SA session resumption procedure in this draft is depicted below: Initiator Responder ----------- -------------- HDRGBP[not]SAr1, KEi, Ni, [SYN] ---> < -- HDR, Nr Figure 4: IKE SA synchronization exchange o While the IPsec client notices that it has to be transfer from old gateway to target gateway and want to pursue the fast session resumption, it sends IKE_INIT message with the SYN payload. The stub indexing information like old gateway IP address and old gateway's SPI shall be enclosed in the IKE SYN payload. o Upon receiving the IKE_INIT message with the IKE_SA_SYN payload, the target gateway uses the information inside to retrieve the the stub of previous IKE SA in the stub bank. if the retrieved stub is qualified for IKE SA re-building, the target gateway will choose the new SPI, derive the new set of keyring and re-establish the IKE session for the related client. Lastly, it sends IKE_INIT response with new SPI in the IKEv2 header and Nr. The new IKE_SA has been re- established successfully. If the taget gateway does not support IKE_SA_SYN or not find the proper stub, it can establish IKE SA by normal IKE_INIT and IKE_AUTH exchanges as specified in [RFC4306], or just drop the packet based on the local policy configured by network operator. The stub can be stored in an independent stub bank, co-located with target gateway or even co-located with the corresponding IPsec client. This is discussed in Section 3.5. However, the case of stub co-located with IPsec client is only optional in this draft. Xu, et al. Expires April 10, 2009 [Page 6] Internet-Draft IKEv2 SA SYNC October 2008 3.2. data structure of stub the stub data structure should conclude all these informations. o IDi, IDr. o SPIi, SPIr. o SAr (the accepted proposal). o SK_d_old. o shared secret. o old gateway's ip address. o lifetime In the data structure of stub, the old gateway's ip address and SPI are used as the index for retrieval of stub. SAr have the encrypt and decrypt algorithm, and shared secrect is the DH exchange's result, we can calculate the IKE SA's keyring as rekey process. It will be very quick. 3.3. Consideration on building IKE SA in session resumption After the stub index has been presented by IKE client in the gateway, it will retrieve the stub from the stub bank. The way to get the stub from the stub bank can be found in Section 3.4. As shown in Section 3.2, IDi, SA value can be obtained directly from the retrieved stub. The target gateway shall choose the new SPIr (called SPIr_new in this draft) for the key derivation of session resumption. The nounce values, Ni and Nr, are from the current IKE SYNC exchange. So, the new value of SKEYSEED is calculated as below (SK_d_old value is from the stub): SKEYSEED = prf (SK_d_old, Ni | Nr) And the keyring set are derived by the way of generic IKEv2 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr_new ) The prf (pseudo-random function) of the cryptographic algorithms is specified in the SA value of stub. 3.4. Consideration on Stub handling 1) generation Xu, et al. Expires April 10, 2009 [Page 7] Internet-Draft IKEv2 SA SYNC October 2008 After IKE SA has been established(after first two exchanges), the IKE/IPsec gateway extracts the stub from IKE SA. 2) propagation After extracted from IKE SA, stubs should be updated to infrastructure such as stub bank. The stub bank can be independent entity in the network or co-located with the gateways (see Section 3.5). 3) Retrieve The gateway can use the the old gateway's ip address and spi can index the unique stub. 4) Expire The stub may be invalid when the lifetime expires. The value of lifetime is recommended to be same as the one in the IKE SA. The gateway may set different lifetime in stub. 5) Delete When the IKEv2/IPsec session is deleted, the gateway shall delete the related stubs in the stub bank. The following signaling shall be supported by IKE/IPsec gateways to communicate with Stub bank. o Initiate Stub: Gateway initiates the stub in the stub bank once new stub has been established. The index shall at least include the gateway's IP address and SPI. o Update Stub: Gateway updates its stub to infrastructure once the related IKE SA has been changed o GET Stub: Gateway uses this message to receives stub by the information in IKE_SA SYN payload from IKE client. o Download Stub: The stub bank can use this message to push the stubs to gateway. Xu, et al. Expires April 10, 2009 [Page 8] Internet-Draft IKEv2 SA SYNC October 2008 o Delete Stub: The Gateway can delete the stubs while the related IKE SAs are no longer available. 3.5. Consideration on location of Stub 1. Centralized infrastructure IPsec old Target stub client GW GW bank | | | | | IKE/IPsec | | | |< ================= >| | Update Stub | | | ------------------------>| | o Fail | | | | | | | HDR,SAr1,KEi,Ni,SYN | | |----------------------------->| GET Stub | | | |---------------->| | | | Download Stub | | | |< ---------------| | HDR,Nr | | | |< --------------------------- | | | | | | Figure 5: centralized structure This proposal has a centralized Stub Bank server, gateway doesn't need local stub database. a) After IKE connection has been established, old gateway set up the stub to stub bank. b) Once the fast session resumption is started, IPsec client sends IKE_INIT with SYN payload. c) When the target gateway receives IKE_INIT with SYN payload, it asks Stub Bank for stub via GET Stub signaling. d) stub bank push proper stub to target gateway. e) Target gateway gets the stub and rebuild IKE SA, then send HDR, Nr to Notify IPsec client that the new IKE SA has been set up by IKE SYNC session resumption. 2. Distributed infrastructure Xu, et al. Expires April 10, 2009 [Page 9] Internet-Draft IKEv2 SA SYNC October 2008 IPsec Target Old GW client gateway Stub | | | | HDR,SAr1,KEi,Ni,SYN| Update Stub | | ------------------->| < ------------------| | < ------------------| | | HDR,Nr | | Figure 6: distributed structure This structure doesn't have centralized Stub Bank, and all gateway must have local stub database. if there is stub in local database, it will find the stub in local database, otherwise, it will GET the stub from other gateways. a) After IKE connection has been established, old gateway initiates the stub to the potential target gateway. b) Once session resumption is initiated, IPsec client send IKE_INIT with SYN payload. c) Target gateway finds the proper stub and rebuild IKE SA, then send HDR, Nr to IPsec client. Gateway has to store stubs in distributed structure, but it seems more simple than centralized structure. Also, these two proposals can mix together, other gateway also can be Stub Bank. 3. Full distributed in IKEv2/IPsec Client There is also the possibility that the Gateway or Stub bank push the stub to the corresponding client. During the session resumption process, the target gateway can have another option to retrieve the stub from the corresponding client by the way specified in Section 3.4. But, this way of stub co-located with IPsec client is ONLY OPTIONAL. if the operator wants to use this case, the stub MUST be protected perfectly by strong encryption and integrity protection. So, in this draft, it is only optional to co-locate the stub in the client. 3.6. When should Gateways download/update Stub Because of the stub is not sensitive with time, the gateways assemble the stub messages to reduce the message number in initiate event. The single gateway can get many stubs at a time in download event. The gateway may also update the stubs in bundles whenever it was Xu, et al. Expires April 10, 2009 [Page 10] Internet-Draft IKEv2 SA SYNC October 2008 thought to be necessary 3.7. Related new messages 1)IKE_SA_SYN Payload format 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GateWay's SPI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GateWay's IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C bit is the direction of this message. 2) Stub related signaling Header Format 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload| type | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type number Init 0x01 update 0x02 get 0x03 download 0x04 delete 0x05 reserved 0x00 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PAYLOAD CONTENT | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Xu, et al. Expires April 10, 2009 [Page 11] Internet-Draft IKEv2 SA SYNC October 2008 4. Modification on the base IKEv2 protocol As the core principle of this draft, the base IKEv2 protocol should be changed as little as possible. In the proposal, three aspects require slight modification on IKEv2 protocol in [RFC4306] 1) new IKE payload in the IKE_INIT message: IKE_SA_SYN 2) Modification on the state machine IPsec client can send generic IKE_INIT message with SYN payload, if it decides to use the session resumption. Upon receiving IKE_INIT response only with the Nr and SPIr_new, it will calculate the new IKE SA as IKE SA rekey. And set state to IKE SA has been established. if the session resumption can not be accepted by the target gateway, the client will receive the usual IKE_INIT response as in [RFC4306] and continue the usual IKE_AUTH procedure afterwards The target gateway, once receives IKE_SA_SYN payload, will firstly find the proper stub. if the stub can be found successfully, it will follow the session resumption proecedure as specified in this draft: re-establish IKE SA, send IKE_INIT respond with Nr only to ipsec client, and set state to IKE SA has been established. if the session resumption can not be accepted by target gateway, it just follows the usual IKEv2 initiation procedure as in [RFC4306] 3) The gateway should support the Stub related functions as specified in Section 3.4 Xu, et al. Expires April 10, 2009 [Page 12] Internet-Draft IKEv2 SA SYNC October 2008 5. Security Considerations the security framework of IKEv2 protocol will not be compromised in this solution. 1) The stub index (Old gateway's IP address and SPI) in IKE_SA_SYN is a light-weighted information, which can be transported without encryption. And it relies on IKE_INIT message to handle the replay protection and DoS attack. 2) The Gateway can use SAr1, KEi to verify the identity, such as ID property. 3) Even if the index is right and IPsec client cannot rebuild IKE_SA because of some reason, the newly re-built IKE SA in gateway will be deleted after somewhile. 4) In the case of stub co-located with IPsec Client, the stub MUST be perfected protected to prevent the malicious attackers from cracking the stub, if they can obtain the stub on the network. Actually, even if the stub is strongly encrypted, there still has the risk. With the development of harware in accord with the Moore's Law, the capability of computing equipment will be increased step by step. Sometime, somehow, the brutal force decryption of the stub encryption method may be possible. And, there is also posibility that the currently safe encryption algorithm may be proved to be mathematically solvable. So, all in all, it is only optional to tranport the stub on the untrusted network, even if it can be protected strongly. Xu, et al. Expires April 10, 2009 [Page 13] Internet-Draft IKEv2 SA SYNC October 2008 6. Conclusion In this draft, a new solution is proposed to do IKE SA synchrinization for quick session resumption of IKE SA. With the extension of IKE_SA_SYNC payload in IKE_INIT message, it can remove the most time-consuming IKEv2 exchanges to re-build the IKE SA, which makes it much faster to transfer millions of IKE sessions from old gateway to target gateway. And the proposal in this draft will just slightly modify the base IKEv2 protocol with a new logical IKE SA Stub bank in the network. Xu, et al. Expires April 10, 2009 [Page 14] Internet-Draft IKEv2 SA SYNC October 2008 7. Normative References [Narayanan06] Narayanan, V., "IPsec Gateway Failover and Redundancy Problem Statement and Goals", draft-vidya-ipsec-failover-ps-00.txt (work in progress), December 2006. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [Sheffer07] Xie, Y., "Stateless Session Resumption for the IKE Protocol", draft-sheffer-ike-session-resumption-00.txt (work in progress), January 2007. Xu, et al. Expires April 10, 2009 [Page 15] Internet-Draft IKEv2 SA SYNC October 2008 Authors' Addresses Yan Xu Tsinghua Univ. Department of Computer Science Tsinghua University Haidian District Beijing, 100088 P.R. China Email: xydkl@163.com Peng Yang Hitachi (China) R&D Corporation 301, North Wing, Tower C Raycom Infotech Park 2 kexueyuan Nanlu Haidian District Beijing, 100080 P.R. China Phone: +861082862918(ext.)328 Email: peng.yang.chn@gmail.com Yuanchen Ma Hitachi (China) R&D Corporation 301, North Wing, Tower C Raycom Infotech Park 2 kexueyuan Nanlu Haidian District Beijing, 100080 P.R. China Phone: +861082862918(ext.)327 Email: ycma@hitachi.cn Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui@chinamobile.com Xu, et al. Expires April 10, 2009 [Page 16] Internet-Draft IKEv2 SA SYNC October 2008 Ke Xu Tsinghua University Department of Computer Science Tsinghua University Haidian District Beijing, 100088 P.R. China Email: xuke@mail.tsinghua.edu.cn Xu, et al. Expires April 10, 2009 [Page 17] Internet-Draft IKEv2 SA SYNC October 2008 Full Copyright Statement Copyright (C) The IETF Trust (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. Xu, et al. Expires April 10, 2009 [Page 18]