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/