draft-ietf-ipsecme-ipsecha-protocol-04.txt		draft-ietf-ipsecme-ipsecha-protocol-05.txt
	Network Working Group R. Singh, Ed.		Network Working Group R. Singh, Ed.
	Internet-Draft G. Kalyani		Internet-Draft G. Kalyani
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Expires: September 3, 2011 Y. Nir		Expires: September 30, 2011 Y. Nir
	Check Point		Check Point
	Y. Sheffer		Y. Sheffer
	Independent		Independent
	D. Zhang		D. Zhang
	Huawei		Huawei
	March 2, 2011		March 29, 2011
	Protocol Support for High Availability of IKEv2/IPsec		Protocol Support for High Availability of IKEv2/IPsec
	draft-ietf-ipsecme-ipsecha-protocol-04		draft-ietf-ipsecme-ipsecha-protocol-05
	Abstract		Abstract
	The IPsec protocol suite is widely used for business-critical network		The IPsec protocol suite is widely used for business-critical network
	traffic. In order to make IPsec deployments highly available, more		traffic. In order to make IPsec deployments highly available, more
	scalable and failure-resistant, they are often implemented as IPsec		scalable and failure-resistant, they are often implemented as IPsec
	High Availability (HA) clusters. However there are many issues in		High Availability (HA) clusters. However there are many issues in
	IPsec HA clustering, and in particular in IKEv2 clustering. An		IPsec HA clustering, and in particular in IKEv2 clustering. An
	earlier document, "IPsec Cluster Problem Statement", enumerates the		earlier document, "IPsec Cluster Problem Statement", enumerates the
	issues encountered in the IKEv2/IPsec HA cluster environment. This		issues encountered in the IKEv2/IPsec HA cluster environment. This
	document attempts to resolve these issues with the least possible		document resolves these issues with the least possible change to the
	change to the protocol.		protocol.
	This document proposes an extension to the IKEv2 protocol to solve		This document defines an extension to the IKEv2 protocol to solve the
	the main issues of "IPsec Cluster Problem Statement" in the commonly		main issues of "IPsec Cluster Problem Statement" in the commonly
	deployed hot-standby cluster, and provides implementation advice for		deployed hot-standby cluster, and provides implementation advice for
	other issues. The main issues to be solved are the synchronization		other issues. The main issues solved are the synchronization of
	of IKEv2 Message ID counters, and of IPsec Replay Counters.		IKEv2 Message ID counters, and of IPsec Replay Counters.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on September 3, 2011.		This Internet-Draft will expire on September 30, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 4, line 10		skipping to change at page 4, line 10
	A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 22		A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 22
	A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 22		A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 22
	A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 22		A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	The IPsec protocol suite, including IKEv2, is a major building block		The IPsec protocol suite, including IKEv2, is a major building block
	of virtual private networks (VPNs). In order to make such VPNs		of virtual private networks (VPNs). In order to make such VPNs
	highly available, more scalable and failure-resistant, these VPNs are		highly available, more scalable and failure-resistant, these VPNs are
	implemented as IKEv2/IPsec Highly Available (HA) cluster. However		implemented as IKEv2/IPsec Highly Available (HA) clusters. However
	there are many issues with the IKEv2/IPsec HA cluster. The problem		there are many issues with the IKEv2/IPsec HA cluster. Section 4
	statement draft Section 4 enumerates the issues around the IKEv2/		below enumerates the issues around the IKEv2/IPsec HA cluster
	IPsec HA cluster solution.		solution.
	In the case of a hot-standby cluster implementation of IKEv2/IPsec		In the case of a hot-standby cluster implementation of IKEv2/IPsec
	based VPNs, the IKEv2/IPsec session is first established between the		based VPNs, the IKEv2/IPsec session is first established between the
	peer and the active member of the cluster. Later, the active member		peer and the active member of the cluster. Later, the active member
	continuously syncs/updates the IKE/IPsec SA state to the standby		continuously syncs/updates the IKE/IPsec SA state to the standby
	member of the cluster. This primary SA state sync-up takes place		member of the cluster. This primary SA state sync-up takes place
	upon each SA bring-up and/or rekey. Performing the SA state		upon each SA bring-up and/or rekey. Performing the SA state
	synchronization/update for every single IKE and IPsec message is very		synchronization/update for every single IKE and IPsec message is very
	costly, so normally it is done periodically. As a result, when the		costly, so normally it is done periodically. As a result, when the
	failover event happens, this is first detected by the standby member		failover event happens, this is first detected by the standby member
	skipping to change at page 5, line 22		skipping to change at page 5, line 22
	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].
	"SA Counter Synchronization Request/Response" are the request viz.		"SA Counter Synchronization Request/Response" are the request viz.
	response of the informational exchange defined in this document to		response of the informational exchange defined in this document to
	synchronize the IKEv2/IPsec SA counter information between one member		synchronize the IKEv2/IPsec SA counter information between one member
	of the cluster and the peer.		of the cluster and the peer.
	Some of the terms listed below are reused from [2] with further		Some of the terms listed below are reused from [4] with further
	clarification in the context of the current document.		clarification in the context of the current document.
	o "Hot Standby Cluster", or "HS Cluster" is a cluster where only one		o "Hot Standby Cluster", or "HS Cluster" is a cluster where only one
	of the members is active at any one time. This member is also		of the members is active at any one time. This member is also
	referred to as the "active" member, whereas the other(s) are		referred to as the "active" member, whereas the other(s) are
	referred to as "standby" members. VRRP [5] is one method of		referred to as "standby" members. VRRP [5] is one method of
	building such a cluster. The goal of the Hot Standby Cluster is		building such a cluster. The goal of the Hot Standby Cluster is
	to create the illusion of a single virtual gateway to the peer(s).		to create the illusion of a single virtual gateway to the peer(s).
	o "Active Member" is the primary member in the Hot-Standby cluster.		o "Active Member" is the primary member in the Hot-Standby cluster.
	It is responsible for forwarding packets on behalf of the virtual		It is responsible for forwarding packets on behalf of the virtual
	skipping to change at page 6, line 16		skipping to change at page 6, line 16
	The generic term "IKEv2/IPsec SA Counters" is used throughout this		The generic term "IKEv2/IPsec SA Counters" is used throughout this
	document. This term refers to both IKEv2 Message ID counters and		document. This term refers to both IKEv2 Message ID counters and
	IPsec replay counters. According to the IPsec standards, the IKEv2		IPsec replay counters. According to the IPsec standards, the IKEv2
	Message ID counter is mandatory, and used to ensure reliable delivery		Message ID counter is mandatory, and used to ensure reliable delivery
	as well as to protect against message replay in IKEv2; the IPsec SA		as well as to protect against message replay in IKEv2; the IPsec SA
	replay counters are optional, and are used to provide the IPsec anti-		replay counters are optional, and are used to provide the IPsec anti-
	replay feature.		replay feature.
	3. Issues Resolved from IPsec Cluster Problem Statement		3. Issues Resolved from IPsec Cluster Problem Statement
	The IPsec Cluster Problem Statement [2] enumerates the problems		The IPsec Cluster Problem Statement [4] enumerates the problems
	raised by IPsec clusters. The following table lists the problem		raised by IPsec clusters. The following table lists the problem
	statement's sections that are resolved by this document.		statement's sections that are resolved by this document.
	o 3.2. Lots of Long Lived State		o 3.2. Lots of Long Lived State
	o 3.3. IKE Counters		o 3.3. IKE Counters
	o 3.4. Outbound SA Counters		o 3.4. Outbound SA Counters
	o 3.5. Inbound SA Counters		o 3.5. Inbound SA Counters
	o 3.6. Missing Synchronization Messages		o 3.6. Missing Synchronization Messages
	o 3.7. Simultaneous use of IKE and IPsec SAs by Different Members		o 3.7. Simultaneous use of IKE and IPsec SAs by Different Members
	* 3.7.1. Outbound SAs using counter modes		* 3.7.1. Outbound SAs using counter modes
	o 3.8. Different IP addresses for IKE and IPsec		o 3.8. Different IP addresses for IKE and IPsec
	skipping to change at page 7, line 32		skipping to change at page 7, line 32
	of the problem statement) multiple members may need to send traffic		of the problem statement) multiple members may need to send traffic
	with the same selectors. To actually use the same SA the cluster		with the same selectors. To actually use the same SA the cluster
	would have to synchronize the Replay Counter after every packet, and		would have to synchronize the Replay Counter after every packet, and
	that would impose unreasonable requirements on the synch connection.		that would impose unreasonable requirements on the synch connection.
	A far better solution would be to not synchronize the outbound SA,		A far better solution would be to not synchronize the outbound SA,
	and create multiple outbound SAs, one for each member. The problem		and create multiple outbound SAs, one for each member. The problem
	with this option is that the peer might view these multiple parallel		with this option is that the peer might view these multiple parallel
	SAs as redundant, and tear down all but one of them.		SAs as redundant, and tear down all but one of them.
	Section 2.8 of [3] specifically allows multiple parallel SAs, but the		Section 2.8 of [2] specifically allows multiple parallel SAs, but the
	reason given for this is to have multiple SAs with different QoS		reason given for this is to have multiple SAs with different QoS
	attributes. So while this is not a new requirement of IKEv2		attributes. So while this is not a new requirement of IKEv2
	implementations, we re-iterate here that IPsec peers MUST accept the		implementations, we re-iterate here that IPsec peers MUST accept the
	long-term existence of multiple parallel SAs, even when QoS		long-term existence of multiple parallel SAs, even when QoS
	mechanisms are not in use.		mechanisms are not in use.
	3.3. Avoiding Collisions in SPI Number Allocation		3.3. Avoiding Collisions in SPI Number Allocation
	Section 3.9 of the problem statement describes the problem of two		Section 3.9 of the problem statement describes the problem of two
	cluster members allocating the same SPI number for two different SAs.		cluster members allocating the same SPI number for two different SAs.
	This would violate section 4.4.2.1 of [4]. There are several schemes		This would violate section 4.4.2.1 of [3]. There are several schemes
	to allow implementations to avoid such collisions, such as		to allow implementations to avoid such collisions, such as
	partitioning the SPI space, a request-response over the synch		partitioning the SPI space, a request-response over the synch
	channel, and locking mechanisms. We believe that these are		channel, and locking mechanisms. We believe that these are
	sufficiently robust and available so that we don't need to make an		sufficiently robust and available so that we don't need to make an
	exception to RFC 4301, and we can leave this problem for the		exception to RFC 4301, and we can leave this problem for the
	implementations to solve. Cluster members MUST NOT generate multiple		implementations to solve. Cluster members MUST NOT generate multiple
	inbound SAs with the same SPI.		inbound SAs with the same SPI.
	3.4. Interaction with Counter Modes		3.4. Interaction with Counter Modes
	skipping to change at page 8, line 23		skipping to change at page 8, line 23
	failing over from one member to another. See [9] for a discussion of		failing over from one member to another. See [9] for a discussion of
	this problem in another context.		this problem in another context.
	Just as in the SPI collision problem, there are ways to avoid a		Just as in the SPI collision problem, there are ways to avoid a
	collision of initial vectors, and this is left up to implementations.		collision of initial vectors, and this is left up to implementations.
	In the context of load sharing, parallel SAs are a simple solution to		In the context of load sharing, parallel SAs are a simple solution to
	this problem as well.		this problem as well.
	4. The IKEv2/IPsec SA Counter Synchronization Problem		4. The IKEv2/IPsec SA Counter Synchronization Problem
	The IKEv2 protocol [3] states that "An IKE endpoint MUST NOT exceed		The IKEv2 protocol [2] states that "An IKE endpoint MUST NOT exceed
	the peer's stated window size for transmitted IKE requests".		the peer's stated window size for transmitted IKE requests".
	All IKEv2 messages are required to follow a request-response		All IKEv2 messages are required to follow a request-response
	paradigm. The initiator of an IKEv2 request MUST retransmit the		paradigm. The initiator of an IKEv2 request MUST retransmit the
	request, until it has received a response from the peer. IKEv2		request, until it has received a response from the peer. IKEv2
	introduces a windowing mechanism that allows multiple requests to be		introduces a windowing mechanism that allows multiple requests to be
	outstanding at a given point of time, but mandates that the sender's		outstanding at a given point of time, but mandates that the sender's
	window should not move until the oldest message it has sent is		window should not move until the oldest message it has sent is
	acknowledged. Loss of even a single message leads to repeated		acknowledged. Loss of even a single message leads to repeated
	retransmissions followed by an IKEv2 SA teardown if the		retransmissions followed by an IKEv2 SA teardown if the
	skipping to change at page 13, line 15		skipping to change at page 13, line 15
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |		|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and		The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and
	'Notify Message Type' fields are the same as described in Section 3		'Notify Message Type' fields are the same as described in Section 3
	of [3]. The 'SPI Size' field MUST be set to 0 to indicate that the		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 set to		SPI is not present in this message. The 'Protocol ID' MUST be set to
	0, since the notification is not specific to a particular security		0, since the notification is not specific to a particular security
	association. The 'Payload Length' field is set to the length in		association. The 'Payload Length' field is set to the length in
	octets of the entire payload, including the generic payload header.		octets of the entire payload, including the generic payload header.
	The 'Notify Message Type' field is set to indicate		The 'Notify Message Type' field is set to indicate
	IKEV2_MESSAGE_ID_SYNC_SUPPORTED, value TBD by IANA. There is no data		IKEV2_MESSAGE_ID_SYNC_SUPPORTED, value TBD by IANA. There is no data
	associated with this notification.		associated with this notification.
	6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification		6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification
	skipping to change at page 13, line 40		skipping to change at page 13, line 40
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |		|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and		The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and
	'Notify Message Type' fields are the same as described in Section 3		'Notify Message Type' fields are the same as described in Section 3
	of [3] . The 'SPI Size' field MUST be set to 0 to indicate that the		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 set to		SPI is not present in this message. The 'Protocol ID' MUST be set to
	0, since the notification is not specific to a particular security		0, since the notification is not specific to a particular security
	association. The 'Payload Length' field is set to the length in		association. The 'Payload Length' field is set to the length in
	octets of the entire payload, including the generic payload header.		octets of the entire payload, including the generic payload header.
	The 'Notify Message Type' field is set to indicate		The 'Notify Message Type' field is set to indicate
	IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED, value TBD by IANA. There is no		IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED, value TBD by IANA. There is no
	data associated with this notification.		data associated with this notification.
	6.3. The IKEV2_MESSAGE_ID_SYNC Notification		6.3. The IKEV2_MESSAGE_ID_SYNC Notification
	skipping to change at page 14, line 42		skipping to change at page 14, line 42
	6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification		6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification
	This notification payload type (value TBD by IANA) is defined to		This notification payload type (value TBD by IANA) is defined to
	synchronize the IPsec SA Replay Counters between the newly-active		synchronize the IPsec SA Replay Counters between the newly-active
	(formerly standby) cluster member and the peer. Since there may be		(formerly standby) cluster member and the peer. Since there may be
	numerous IPsec SAs established under a single IKE SA, we do not		numerous IPsec SAs established under a single IKE SA, we do not
	directly synchronize the value of each one. Instead, a delta value		directly synchronize the value of each one. Instead, a delta value
	is sent and all Replay Counters for Child SAs of this IKE SA are		is sent and all Replay Counters for Child SAs of this IKE SA are
	incremented by the same value. Note that this solution requires that		incremented by the same value. Note that this solution requires that
	all these Child SAs either use or do not use Extended Sequence		all these Child SAs either use or do not use Extended Sequence
	Numbers [4]. This notification is only sent by the cluster.		Numbers [3]. This notification is only sent by the cluster.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Payload |C| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |		|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Incoming IPsec SA delta value |		| Incoming IPsec SA delta value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 20, line 48		skipping to change at page 20, line 48
	Added comment in Introduction to discuss the window sync process on		Added comment in Introduction to discuss the window sync process on
	WG mailing list to solve some concerns.		WG mailing list to solve some concerns.
	15. References		15. References
	15.1. Normative References		15.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] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027,		[2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key
	October 2010.
	[3] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key
	Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.		Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
	[4] Kent, S. and K. Seo, "Security Architecture for the Internet		[3] Kent, S. and K. Seo, "Security Architecture for the Internet
	Protocol", RFC 4301, December 2005.		Protocol", RFC 4301, December 2005.
	15.2. Informative References		15.2. Informative References
			[4] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027,
			October 2010.
	[5] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3		[5] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3
	for IPv4 and IPv6", RFC 5798, March 2010.		for IPv4 and IPv6", RFC 5798, March 2010.
	[6] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick		[6] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick
	Crash Detection Method for IKE",		Crash Detection Method for IKE",
	draft-ietf-ipsecme-failure-detection-05 (work in progress),		draft-ietf-ipsecme-failure-detection-07 (work in progress),
	February 2011.		March 2011.
	[7] Housley, R., "Using Advanced Encryption Standard (AES) Counter		[7] Housley, R., "Using Advanced Encryption Standard (AES) Counter
	Mode With IPsec Encapsulating Security Payload (ESP)",		Mode With IPsec Encapsulating Security Payload (ESP)",
	RFC 3686, January 2004.		RFC 3686, January 2004.
	[8] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM)		[8] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM)
	in IPsec Encapsulating Security Payload (ESP)", RFC 4106,		in IPsec Encapsulating Security Payload (ESP)", RFC 4106,
	June 2005.		June 2005.
	[9] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating		[9] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating
End of changes. 20 change blocks.
	29 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/