--- 1/draft-ietf-ipsecme-ikev2-redirect-01.txt 2008-12-11 21:12:03.000000000 +0100 +++ 2/draft-ietf-ipsecme-ikev2-redirect-02.txt 2008-12-11 21:12:03.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group V. Devarapalli Internet-Draft WiChorus Intended status: Standards Track K. Weniger -Expires: May 7, 2009 Panasonic - November 3, 2008 +Expires: June 14, 2009 Panasonic + December 11, 2008 Re-direct Mechanism for IKEv2 - draft-ietf-ipsecme-ikev2-redirect-01.txt + draft-ietf-ipsecme-ikev2-redirect-02.txt 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 @@ -24,60 +24,61 @@ 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 May 7, 2009. + This Internet-Draft will expire on June 14, 2009. Abstract - IKEv2 is a popular protocol for setting up VPN tunnels from a remote - location to a gateway so that the VPN client can access services in - the network behind the gateway. Currently there is no standard - mechanism specified that allows an overloaded VPN gateway to re- - direct the VPN client to attach to another gateway. This document - proposes a re-direct mechanism for IKEv2. The proposed mechanism can - also be used for Mobile IPv6 to enable the home agent to re-direct - the mobile node to another home agent. + IKEv2 is a protocol for setting up VPN tunnels from a remote location + to a gateway so that the VPN client can access services in the + network behind the gateway. Currently there is no standard mechanism + specified that allows an overloaded VPN gateway or a VPN gateway that + is being shut down for maintenance to re-direct the VPN client to + attach to another gateway. This document proposes a re-direct + mechanism for IKEv2. The proposed mechanism can also be used in + Mobile IPv6 to enable the home agent to re-direct the mobile node to + another home agent. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IKEv2 Exchange with Redirect . . . . . . . . . . . . . . . . . 4 4. Use of Anycast Addresses with the Re-direct Mechanism . . . . 5 5. Gateway Initiated Redirect . . . . . . . . . . . . . . . . . . 6 6. Redirect Messages . . . . . . . . . . . . . . . . . . . . . . 7 6.1. REDIRECT_SUPPORTED . . . . . . . . . . . . . . . . . . . . 7 6.2. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.3. REDIRECTED_FROM . . . . . . . . . . . . . . . . . . . . . 8 6.4. REDIRECT_ACK . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 - Intellectual Property and Copyright Statements . . . . . . . . . . 12 + Intellectual Property and Copyright Statements . . . . . . . . . . 13 1. Introduction - IKEv2 [2] is widely used for setting up IPsec-based VPNs. The IP - address of the VPN gateway can be configured on the VPN client. But - this does not scale well, when the number of VPN gateways is large. - Dynamic discovery of VPN gateways using DNS is quite widely used too. + IKEv2 [2] is used for setting up IPsec-based VPNs. The IP address of + the VPN gateway can be configured on the VPN client. But this does + not scale well, when the number of VPN gateways is large. Dynamic + discovery of VPN gateways using DNS is quite widely used too. However, using DNS is not flexible when it comes to assigning a VPN gateway to the VPN client based on the load on the VPN gateways. The VPN client typically tries to connect to the IP address of the VPN gateways that appears first in the DNS response. If the VPN tunnel setup fails, then the VPN client tries to attach to the other VPN gateways returned in the DNS response. This document proposes a re-direct mechanism for IKEv2 that enables a VPN gateway to re-direct the VPN client to another VPN gateway, for example, based on the load condition. The re-direct is done during @@ -111,21 +112,21 @@ created on the home agent. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 3. IKEv2 Exchange with Redirect - To redirect a IKEv2 session to another VPN gateway, the VPN gateway + To redirect an IKEv2 session to another VPN gateway, the VPN gateway that initially received the IKE_SA_INIT request selects another VPN gateway and responds to the VPN client with a REDIRECT Notification payload. The mechanism by which the initial VPN gateway selects another VPN gateway is out of scope for this document. The IP address of the selected VPN gateway is sent in the REDIRECT payload. The VPN client indicates support for the IKEv2 redirect mechanism by including a REDIRECT_SUPPORTED notification message in the initial IKE_SA_INIT request. If the IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload, the responder MUST NOT send the REDIRECT @@ -220,27 +221,35 @@ message, it MUST send an INFORMATIONAL message with the REDIRECT_ACK Notify payload. Until the client responds with an INFORMATIONAL message with the REDIRECT_ACK payload, the gateway SHOULD re-transmit the re-direct INFORMATIONAL message as described in [2]. The following illustrates the INFORMATIONAL message exchange for gateway- initiated redirect. Initiator (VPN client) Responder (VPN GW) ---------------------- ------------------ - <-- HDR, SK {[REDIRECT]} + <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} - HDR, SK {[REDIRECT_ACK]} --> + HDR, SK {N[REDIRECT_ACK]} --> The INFORMATIONAL message exchange described above is protected by the existing IKEv2 SA between the client and the gateway. + Once the client responds to the gateway with the REDIRECT_ACK + payload, it SHOULD delete the existing security associations with the + old gateway. The gateway MAY also decide to delete the security + associations without any signaling from the client. However, it + should allow sufficient time for the client to setup the required + security associations with the new security gateway. This time + period should be configurable on the gateway. + 6. Redirect Messages 6.1. REDIRECT_SUPPORTED The REDIRECT_SUPPORTED payload is included in the initial IKE_SA_INIT request by the initiator to indicate support for the IKEv2 re-direct mechanism described in this document. 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 @@ -397,36 +406,35 @@ o REDIRECTED_FROM o REDIRECT_ACK 9. Acknowledgements The use of anycast address with IKEv2 was first described in [6]. It was then added to an early draft version of RFC 5026 and later removed before the RFC was published. Therefore the authors of [6] and RFC 5026 are acknowledged. - Thanks to Pasi Eronen, with who, the solution described in this + Thanks to Pasi Eronen, with whom the solution described in this document was extensively discussed. Thanks to Tero Kivinen for suggesting the use of REDIRECTED_FROM payload. The authors would - also like to thank Yaron Sheffer, Sunil Kumar and Arnaud Ebalard for - their reviews and comments. + also like to thank Yaron Sheffer, Sunil Kumar, Fan Zhao, Yoav Nir and + Arnaud Ebalard for their reviews and comments. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key - Exchange Protocol: IKEv2", draft-ietf-ipsecme-ikev2bis-01 (work - in progress), October 2008. + [2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, + December 2005. 10.2. Informative References [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [5] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility