draft-ietf-ipsecme-ikev2-redirect-01.txt   draft-ietf-ipsecme-ikev2-redirect-02.txt 
Network Working Group V. Devarapalli Network Working Group V. Devarapalli
Internet-Draft WiChorus Internet-Draft WiChorus
Intended status: Standards Track K. Weniger Intended status: Standards Track K. Weniger
Expires: May 7, 2009 Panasonic Expires: June 14, 2009 Panasonic
November 3, 2008 December 11, 2008
Re-direct Mechanism for IKEv2 Re-direct Mechanism for IKEv2
draft-ietf-ipsecme-ikev2-redirect-01.txt draft-ietf-ipsecme-ikev2-redirect-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Abstract
IKEv2 is a popular protocol for setting up VPN tunnels from a remote IKEv2 is a protocol for setting up VPN tunnels from a remote location
location to a gateway so that the VPN client can access services in to a gateway so that the VPN client can access services in the
the network behind the gateway. Currently there is no standard network behind the gateway. Currently there is no standard mechanism
mechanism specified that allows an overloaded VPN gateway to re- specified that allows an overloaded VPN gateway or a VPN gateway that
direct the VPN client to attach to another gateway. This document is being shut down for maintenance to re-direct the VPN client to
proposes a re-direct mechanism for IKEv2. The proposed mechanism can attach to another gateway. This document proposes a re-direct
also be used for Mobile IPv6 to enable the home agent to re-direct mechanism for IKEv2. The proposed mechanism can also be used in
the mobile node to another home agent. Mobile IPv6 to enable the home agent to re-direct the mobile node to
another home agent.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IKEv2 Exchange with Redirect . . . . . . . . . . . . . . . . . 4 3. IKEv2 Exchange with Redirect . . . . . . . . . . . . . . . . . 4
4. Use of Anycast Addresses with the Re-direct Mechanism . . . . 5 4. Use of Anycast Addresses with the Re-direct Mechanism . . . . 5
5. Gateway Initiated Redirect . . . . . . . . . . . . . . . . . . 6 5. Gateway Initiated Redirect . . . . . . . . . . . . . . . . . . 6
6. Redirect Messages . . . . . . . . . . . . . . . . . . . . . . 7 6. Redirect Messages . . . . . . . . . . . . . . . . . . . . . . 7
6.1. REDIRECT_SUPPORTED . . . . . . . . . . . . . . . . . . . . 7 6.1. REDIRECT_SUPPORTED . . . . . . . . . . . . . . . . . . . . 7
6.2. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. REDIRECTED_FROM . . . . . . . . . . . . . . . . . . . . . 8 6.3. REDIRECTED_FROM . . . . . . . . . . . . . . . . . . . . . 8
6.4. REDIRECT_ACK . . . . . . . . . . . . . . . . . . . . . . . 9 6.4. REDIRECT_ACK . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Introduction 1. Introduction
IKEv2 [2] is widely used for setting up IPsec-based VPNs. The IP IKEv2 [2] is used for setting up IPsec-based VPNs. The IP address of
address of the VPN gateway can be configured on the VPN client. But the VPN gateway can be configured on the VPN client. But this does
this does not scale well, when the number of VPN gateways is large. not scale well, when the number of VPN gateways is large. Dynamic
Dynamic discovery of VPN gateways using DNS is quite widely used too. discovery of VPN gateways using DNS is quite widely used too.
However, using DNS is not flexible when it comes to assigning a VPN 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 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 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 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 setup fails, then the VPN client tries to attach to the other VPN
gateways returned in the DNS response. gateways returned in the DNS response.
This document proposes a re-direct mechanism for IKEv2 that enables a 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 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 example, based on the load condition. The re-direct is done during
skipping to change at page 4, line 13 skipping to change at page 4, line 13
created on the home agent. created on the home agent.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
3. IKEv2 Exchange with Redirect 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 that initially received the IKE_SA_INIT request selects another VPN
gateway and responds to the VPN client with a REDIRECT Notification gateway and responds to the VPN client with a REDIRECT Notification
payload. The mechanism by which the initial VPN gateway selects payload. The mechanism by which the initial VPN gateway selects
another VPN gateway is out of scope for this document. The IP another VPN gateway is out of scope for this document. The IP
address of the selected VPN gateway is sent in the REDIRECT payload. address of the selected VPN gateway is sent in the REDIRECT payload.
The VPN client indicates support for the IKEv2 redirect mechanism by The VPN client indicates support for the IKEv2 redirect mechanism by
including a REDIRECT_SUPPORTED notification message in the initial including a REDIRECT_SUPPORTED notification message in the initial
IKE_SA_INIT request. If the IKE_SA_INIT request did not include the IKE_SA_INIT request. If the IKE_SA_INIT request did not include the
REDIRECT_SUPPORTED payload, the responder MUST NOT send the REDIRECT REDIRECT_SUPPORTED payload, the responder MUST NOT send the REDIRECT
skipping to change at page 6, line 41 skipping to change at page 6, line 41
message, it MUST send an INFORMATIONAL message with the REDIRECT_ACK message, it MUST send an INFORMATIONAL message with the REDIRECT_ACK
Notify payload. Until the client responds with an INFORMATIONAL Notify payload. Until the client responds with an INFORMATIONAL
message with the REDIRECT_ACK payload, the gateway SHOULD re-transmit message with the REDIRECT_ACK payload, the gateway SHOULD re-transmit
the re-direct INFORMATIONAL message as described in [2]. The the re-direct INFORMATIONAL message as described in [2]. The
following illustrates the INFORMATIONAL message exchange for gateway- following illustrates the INFORMATIONAL message exchange for gateway-
initiated redirect. initiated redirect.
Initiator (VPN client) Responder (VPN GW) 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 INFORMATIONAL message exchange described above is protected by
the existing IKEv2 SA between the client and the gateway. 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. Redirect Messages
6.1. REDIRECT_SUPPORTED 6.1. REDIRECT_SUPPORTED
The REDIRECT_SUPPORTED payload is included in the initial IKE_SA_INIT The REDIRECT_SUPPORTED payload is included in the initial IKE_SA_INIT
request by the initiator to indicate support for the IKEv2 re-direct request by the initiator to indicate support for the IKEv2 re-direct
mechanism described in this document. mechanism described in this document.
1 2 3 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 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
skipping to change at page 10, line 31 skipping to change at page 11, line 6
o REDIRECTED_FROM o REDIRECTED_FROM
o REDIRECT_ACK o REDIRECT_ACK
9. Acknowledgements 9. Acknowledgements
The use of anycast address with IKEv2 was first described in [6]. It 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 was then added to an early draft version of RFC 5026 and later
removed before the RFC was published. Therefore the authors of [6] removed before the RFC was published. Therefore the authors of [6]
and RFC 5026 are acknowledged. 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 document was extensively discussed. Thanks to Tero Kivinen for
suggesting the use of REDIRECTED_FROM payload. The authors would suggesting the use of REDIRECTED_FROM payload. The authors would
also like to thank Yaron Sheffer, Sunil Kumar and Arnaud Ebalard for also like to thank Yaron Sheffer, Sunil Kumar, Fan Zhao, Yoav Nir and
their reviews and comments. Arnaud Ebalard for their reviews and comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key [2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
Exchange Protocol: IKEv2", draft-ietf-ipsecme-ikev2bis-01 (work December 2005.
in progress), October 2008.
10.2. Informative References 10.2. Informative References
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[4] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [4] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[5] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility [5] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility
 End of changes. 15 change blocks. 
29 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/