draft-ietf-ipsecme-ikev2-redirect-06.txt		draft-ietf-ipsecme-ikev2-redirect-07.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: September 24, 2009 March 23, 2009		Expires: October 10, 2009 April 8, 2009
	Redirect Mechanism for IKEv2		Redirect Mechanism for IKEv2
	draft-ietf-ipsecme-ikev2-redirect-06.txt		draft-ietf-ipsecme-ikev2-redirect-07.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may not be modified,		provisions of BCP 78 and BCP 79. This document may not be modified,
	and derivative works of it may not be created, except to format it		and derivative works of it may not be created, except to format it
	for publication as an RFC or to translate it into languages other		for publication as an RFC or to translate it into languages other
	than English.		than English.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	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 September 24, 2009.		This Internet-Draft will expire on October 10, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 7, line 44		skipping to change at page 7, line 44
	N[REDIRECT, IP_R/FQDN_R]}		N[REDIRECT, IP_R/FQDN_R]}
	In case the IKE_AUTH exchange involves EAP authentication as		In case the IKE_AUTH exchange involves EAP authentication as
	described in Section 2.16 of RFC 4306 [2] or multiple authentication		described in Section 2.16 of RFC 4306 [2] or multiple authentication
	methods as described in RFC 4739 [6], the IKE_AUTH exchange is more		methods as described in RFC 4739 [6], the IKE_AUTH exchange is more
	complicated. The identity presented by the client in the first		complicated. The identity presented by the client in the first
	IKE_AUTH request might be a temporary one. In addition, the gateway		IKE_AUTH request might be a temporary one. In addition, the gateway
	might decide to redirect the client based on the interaction with the		might decide to redirect the client based on the interaction with the
	the AAA server, when EAP authentication is used or the external		the AAA server, when EAP authentication is used or the external
	authentication server, when multiple authentication methods are used.		authentication server, when multiple authentication methods are used.
	In such cases, the exact message in which the gateway sends the		In such cases, the gateway should send the REDIRECT notification
	REDIRECT payload is TBD.		payload in the final IKE_AUTH response message that carries the AUTH
			payload and the traffic selectors.
	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 redirect		request by the initiator to indicate support for the IKEv2 redirect
	mechanism described in this document.		mechanism described in this document.
	1 2 3		1 2 3
	skipping to change at page 9, line 11		skipping to change at page 9, line 11
	~ Nonce Data ~		~ Nonce Data ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and		The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and
	the 'Notify Message Type' fields are the same as described in Section		the 'Notify Message Type' fields are the same as described in Section
	3.10 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that		3.10 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that
	the SPI is not present in this message. The 'Protocol ID' MUST be		the SPI is not present in this message. The 'Protocol ID' MUST be
	set to 0, since the notification is not specific to a particular		set to 0, since the notification is not specific to a particular
	security association.		security association.
	If the IP address of the new VPN gateway is sent, the 'Payload		The 'Payload Length' field is set to the length in octets of the
	Length' field MUST be set to either '13' or '25' depending on whether		entire payload, including the generic payload header. 'Notify
	an IPv4 or IPv6 address is sent in the message. If the FQDN of the
	new VPN gateway is sent, the 'Payload Length' field is set to the
	length of the FQDN plus the fixed fields in the message. The 'Notify
	Message Type' field is set to indicate the REDIRECT payload <value to		Message Type' field is set to indicate the REDIRECT payload <value to
	be assigned by IANA>. The 'GW Identity Type' field indicates the		be assigned by IANA>. The 'GW Identity Type' field indicates the
	type of information that is sent to identify the new VPN gateway.		type of information that is sent to identify the new VPN gateway.
	The following values are reserved by this document.		The following values are reserved by this document.
	1 - IPv4 address of the new VPN gateway		1 - IPv4 address of the new VPN gateway
	2 - IPv6 address of the new VPN gateway		2 - IPv6 address of the new VPN gateway
	3 - FQDN of the new VPN gateway		3 - FQDN of the new VPN gateway
	All other values for this field are reserved and MUST NOT be used.		All other values for this field are reserved and MUST NOT be used.
	skipping to change at page 11, line 22		skipping to change at page 11, line 11
	event. However, this may happen if a Home Agent/VPN server is		event. However, this may happen if a Home Agent/VPN server is
	shutdown for maintenance and all clients need to re-establish VPN		shutdown for maintenance and all clients need to re-establish VPN
	connections with another Home Agent/VPN server or if the on-path		connections with another Home Agent/VPN server or if the on-path
	attacker forces all IPsec security associations to expire by dropping		attacker forces all IPsec security associations to expire by dropping
	all received IKEv2 messages.		all received IKEv2 messages.
	The use of REDIRECTED_FROM payload is intended to discourage a rogue		The use of REDIRECTED_FROM payload is intended to discourage a rogue
	VPN gateway from redirecting a large number of VPN clients to a		VPN gateway from redirecting a large number of VPN clients to a
	particular VPN gateway. It does not prevent such a DoS attack.		particular VPN gateway. It does not prevent such a DoS attack.
			Since the redirect message is not always sent as a secure message, it
			MUST NOT result in the modification of the PAD entries on the client.
			The new gateway, to which the client is redirected to should be
			subject to the same authentication and authorization requirements as
			the original gateway. To support a scenario where the FQDN of the
			gateway is in the client's PAD entry and the client is redirected to
			another gateway in the same administrative domain, one can either
			configure all the possible gateways from the domain or use a wildcard
			entry like, for example, GW*.example.com, in the client's
			corresponding PAD entry.
	9. IANA Considerations		9. IANA Considerations
	This document defines four new IKEv2 Notification Message types as		This document defines four new IKEv2 Notification Message types as
	described in Section 6. The three Notify Message Types must be		described in Section 6. The three Notify Message Types must be
	assigned values between 16396 and 40959.		assigned values between 16396 and 40959.
	o REDIRECT_SUPPORTED		o REDIRECT_SUPPORTED
	o REDIRECT		o REDIRECT
	o REDIRECTED_FROM		o REDIRECTED_FROM
	skipping to change at page 11, line 44		skipping to change at page 11, line 44
	The use of anycast address with IKEv2 was first described in [7]. It		The use of anycast address with IKEv2 was first described in [7]. 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 [7]		removed before the RFC was published. Therefore the authors of [7]
	and RFC 5026 are acknowledged.		and RFC 5026 are acknowledged.
	Thanks to Pasi Eronen, with whom 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 and other comments		suggesting the use of REDIRECTED_FROM payload and other comments
	which helped improve the document. The authors would also like to		which helped improve the document. The authors would also like to
	thank Yaron Sheffer, Sunil Kumar, Fan Zhao, Yoav Nir, Richard		thank Yaron Sheffer, Sunil Kumar, Fan Zhao, Yoav Nir, Richard
	Graveman, and Arnaud Ebalard for their reviews and comments.		Graveman, Kanagavel Rajan, Srini Addepalli, and Arnaud Ebalard for
			their reviews and comments.
	11. References		11. References
	11.1. Normative References		11.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., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,		[2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
	December 2005.		December 2005.
End of changes. 7 change blocks.
	11 lines changed or deleted		21 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/