draft-ietf-ipsecme-ipsecha-protocol-03.txt		draft-ietf-ipsecme-ipsecha-protocol-04.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: August 12, 2011 Y. Nir		Expires: September 3, 2011 Y. Nir
	Check Point		Check Point
	Y. Sheffer		Y. Sheffer
	Independent		Independent
	D. Zhang		D. Zhang
	Huawei		Huawei
	February 8, 2011		March 2, 2011
	Protocol Support for High Availability of IKEv2/IPsec		Protocol Support for High Availability of IKEv2/IPsec
	draft-ietf-ipsecme-ipsecha-protocol-03		draft-ietf-ipsecme-ipsecha-protocol-04
	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
	skipping to change at page 2, line 4		skipping to change at page 2, line 4
	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 August 12, 2011.		This Internet-Draft will expire on September 3, 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 3, line 10		skipping to change at page 3, line 10
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Issues Resolved from IPsec Cluster Problem Statement . . . . . 6		3. Issues Resolved from IPsec Cluster Problem Statement . . . . . 6
	4. The IKEv2/IPsec SA Counter Synchronization Problem . . . . . . 7		3.1. Large Amount of State . . . . . . . . . . . . . . . . . . 6
	5. SA Counter Synchronization Solution . . . . . . . . . . . . . 8		3.2. Multiple Members Using the Same SA . . . . . . . . . . . . 7
	5.1. Processing Rules for IKE Message ID Synchronization . . . 10		3.3. Avoiding Collisions in SPI Number Allocation . . . . . . . 7
			3.4. Interaction with Counter Modes . . . . . . . . . . . . . . 8
			4. The IKEv2/IPsec SA Counter Synchronization Problem . . . . . . 8
			5. SA Counter Synchronization Solution . . . . . . . . . . . . . 9
			5.1. Processing Rules for IKE Message ID Synchronization . . . 11
	5.2. Processing Rules for IPsec Replay Counter		5.2. Processing Rules for IPsec Replay Counter
	Synchronization . . . . . . . . . . . . . . . . . . . . . 11		Synchronization . . . . . . . . . . . . . . . . . . . . . 12
	6. IKEv2/IPsec Synchronization Notification Payloads . . . . . . 11		6. IKEv2/IPsec Synchronization Notification Payloads . . . . . . 12
	6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification . . . . . 11		6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification . . . . . 12
	6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification . . . 12		6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification . . . 13
	6.3. The IKEV2_MESSAGE_ID_SYNC Notification . . . . . . . . . . 12		6.3. The IKEV2_MESSAGE_ID_SYNC Notification . . . . . . . . . . 13
	6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification . . . . . . . . 13		6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification . . . . . . . . 14
	7. Implementation Details . . . . . . . . . . . . . . . . . . . . 14		7. Implementation Details . . . . . . . . . . . . . . . . . . . . 15
	8. IKE SA and IPsec SA Message Sequencing . . . . . . . . . . . . 14		8. IKE SA and IPsec SA Message Sequencing . . . . . . . . . . . . 16
	8.1. Handling of Pending IKE Messages . . . . . . . . . . . . . 15		8.1. Handling of Pending IKE Messages . . . . . . . . . . . . . 16
	8.2. Handling of Pending IPsec Messages . . . . . . . . . . . . 15		8.2. Handling of Pending IPsec Messages . . . . . . . . . . . . 16
	8.3. IKE SA Inconsistencies . . . . . . . . . . . . . . . . . . 15		8.3. IKE SA Inconsistencies . . . . . . . . . . . . . . . . . . 16
	9. Step by Step Details . . . . . . . . . . . . . . . . . . . . . 15		9. Step by Step Details . . . . . . . . . . . . . . . . . . . . . 16
	10. Interaction with other drafts . . . . . . . . . . . . . . . . 16		10. Interaction with other drafts . . . . . . . . . . . . . . . . 17
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 17		11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
	14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18		14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	14.1. Draft -03 . . . . . . . . . . . . . . . . . . . . . . . . 18		14.1. Draft -04 . . . . . . . . . . . . . . . . . . . . . . . . 19
	14.2. Draft -02 . . . . . . . . . . . . . . . . . . . . . . . . 18		14.2. Draft -03 . . . . . . . . . . . . . . . . . . . . . . . . 19
	14.3. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 18		14.3. Draft -02 . . . . . . . . . . . . . . . . . . . . . . . . 20
	14.4. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 19		14.4. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 20
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		14.5. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 20
	15.1. Normative References . . . . . . . . . . . . . . . . . . . 19		15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	15.2. Informative References . . . . . . . . . . . . . . . . . . 19		15.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	Appendix A. IKEv2 Message ID Sync Examples . . . . . . . . . . . 20		15.2. Informative References . . . . . . . . . . . . . . . . . . 21
	A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 20		Appendix A. IKEv2 Message ID Sync Examples . . . . . . . . . . . 21
	A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 20		A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 22
	A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 20		A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 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) cluster. However
	there are many issues with the IKEv2/IPsec HA cluster. The problem		there are many issues with the IKEv2/IPsec HA cluster. The problem
	statement draft Section 4 enumerates the issues around the IKEv2/		statement draft Section 4 enumerates the issues around the IKEv2/
	IPsec HA cluster solution.		IPsec HA cluster solution.
	skipping to change at page 6, line 30		skipping to change at page 6, line 30
	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
	o 3.9. Allocation of SPIs		o 3.9. Allocation of SPIs
	The main problem areas are solved using the protocol extension		The main problem areas are solved using the protocol extension
	defined below; additionally, this document provides implementation		defined below, starting with Section 5; additionally, this section
	advice for other issues, as follows.		provides implementation advice for other issues in the following
	o Section 3.2 of the Problem Statement mentions that there is a		subsections.
	large amount of state that needs to be synchronized. However if
	state is not synchronized, this is not really an interesting		3.1. Large Amount of State
	cluster: failover is equivalent to a reboot of the cluster member,
	and so the issue need not be solved with a protocol extension.		Section 3.2 of the Problem Statement mentions that a lot of state
	o 3.3, 3.4,3.5, and 3.6 are solved by this document. Please see		needs to be synchronized for a cluster to be transparent. The actual
	Section 4, for more details.		volume of that data is very much implementation-dependent, and even
	o 3.7 is an implementation problem that needs to be solved while		for the same implementation, the amounts of data may vary wildly. An
	building IPsec clusters. However, the peers should be required to		IPsec gateway used for inter-domain VPN with a dozen other gateways,
	accept multiple parallel SAs for 3.7.1.		and having SAs that are rekeyed every 8 hours, will need a lot less
	o 3.8 can be solved by using the IKEv2 Redirect mechanism [6].		synchronization traffic than a similar gateway used for remote
	o 3.9 discusses the avoidance of collisions where the same SPI value		access, and supporting 10,000 clients. This is because counter
	is used by multiple cluster members. This is outside the		synchronization is proportional to the number of SAs and requires
	document's scope since the problem needs to be solved internally		little data, and the setting up of an SA requires a lot of data.
	to the cluster and does not involve the peer.		Additionally, remote access IKE and IPsec SA setup tend to happen at
			a particular time of day, so the example gateway with the 10,000
			clients may see 30-50 IKE SA setups per second at 9:00 AM. This
			would require very heavy synchronization traffic over that short
			period of time.
			If a large volume of traffic is necessary, it may be advisable to use
			a dedicated high-speed network interface for synch traffic. When
			packet loss can be made extremely low, it may be advisable to use a
			stateless transport such as UDP, to minimize network overhead.
			If these methods are insufficient, it may be prudent that for some
			SAs the entire state is not synchronized. Instead, only an
			indication of the SA's existence is synchronized. This, in
			combination with a sticky solution (as described in section 3.7 of
			the problem statement) ensures that the traffic from a particular
			peer does not reach a different member before an actual failover
			happens. When that happens, the method described in [6] can be used
			to quickly force the peer to set up a new SA.
			3.2. Multiple Members Using the Same SA
			In a load-sharing cluster of the "duplicate" variety (see section 3.7
			of the problem statement) multiple members may need to send traffic
			with the same selectors. To actually use the same SA the cluster
			would have to synchronize the Replay Counter after every packet, and
			that would impose unreasonable requirements on the synch connection.
			A far better solution would be to not synchronize the outbound SA,
			and create multiple outbound SAs, one for each member. The problem
			with this option is that the peer might view these multiple parallel
			SAs as redundant, and tear down all but one of them.
			Section 2.8 of [3] specifically allows multiple parallel SAs, but the
			reason given for this is to have multiple SAs with different QoS
			attributes. So while this is not a new requirement of IKEv2
			implementations, we re-iterate here that IPsec peers MUST accept the
			long-term existence of multiple parallel SAs, even when QoS
			mechanisms are not in use.
			3.3. Avoiding Collisions in SPI Number Allocation
			Section 3.9 of the problem statement describes the problem of two
			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
			to allow implementations to avoid such collisions, such as
			partitioning the SPI space, a request-response over the synch
			channel, and locking mechanisms. We believe that these are
			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
			implementations to solve. Cluster members MUST NOT generate multiple
			inbound SAs with the same SPI.
			3.4. Interaction with Counter Modes
			For SAs involving counter mode ciphers such as CTR [7] or GCM [8]
			there is yet another complication. The initial vector for such modes
			MUST NOT be repeated, and senders use methods such as counters or
			LFSRs to ensure this property. For an SA shared between multiple
			active members (load sharing cases), implementations MUST ensure that
			no initial vector is ever repeated. Similar concerns apply to an SA
			failing over from one member to another. See [9] for a discussion of
			this problem in another context.
			Just as in the SPI collision problem, there are ways to avoid a
			collision of initial vectors, and this is left up to implementations.
			In the context of load sharing, parallel SAs are a simple solution to
			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 [3] 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
	skipping to change at page 16, line 32		skipping to change at page 17, line 40
	10. Interaction with other drafts		10. Interaction with other drafts
	The usage scenario of the IKEv2/IPsec SA counter synchronization		The usage scenario of the IKEv2/IPsec SA counter synchronization
	proposal is that an IKEv2 SA has been established between the active		proposal is that an IKEv2 SA has been established between the active
	member of a hot-standby cluster and a peer, then a failover event		member of a hot-standby cluster and a peer, then a failover event
	occurred with the standby member becoming active. The proposal		occurred with the standby member becoming active. The proposal
	further assumes that the IKEv2 SA state was continuously synchronized		further assumes that the IKEv2 SA state was continuously synchronized
	between the active and standby members of the cluster before the		between the active and standby members of the cluster before the
	failover event.		failover event.
	o Session resumption [7] assumes that a peer (client or initiator)		o Session resumption [10] assumes that a peer (client or initiator)
	detects the need to re-establish the session. In IKEv2/IPsec SA		detects the need to re-establish the session. In IKEv2/IPsec SA
	counter synchronization, it is the newly-active member (a gateway		counter synchronization, it is the newly-active member (a gateway
	or responder) that detects the need to synchronize the SA counter		or responder) that detects the need to synchronize the SA counter
	after the failover event. Also in a hot-standby cluster, the peer		after the failover event. Also in a hot-standby cluster, the peer
	establishes the IKEv2/IPsec session with a single IP address that		establishes the IKEv2/IPsec session with a single IP address that
	represents the whole cluster, so the peer normally does not detect		represents the whole cluster, so the peer normally does not detect
	the event of failover in the cluster unless the standby member		the event of failover in the cluster unless the standby member
	takes too long to become active and the IKEv2 SA times out by use		takes too long to become active and the IKEv2 SA times out by use
	of the IKEv2 liveness check mechanism. To conclude, session		of the IKEv2 liveness check mechanism. To conclude, session
	resumption and SA counter synchronization after failover are		resumption and SA counter synchronization after failover are
	mutually exclusive.		mutually exclusive.
	o The IKEv2 Redirect mechanism for load-balancing [6] can be used
			o The IKEv2 Redirect mechanism for load-balancing [11] can be used
	either during the initial stages of SA setup (the IKE_SA_INIT and		either during the initial stages of SA setup (the IKE_SA_INIT and
	IKE_AUTH exchanges) or after session establishment. SA counter		IKE_AUTH exchanges) or after session establishment. SA counter
	synchronization is only useful after the IKE SA has been		synchronization is only useful after the IKE SA has been
	established and a failover event has occurred. So, unlike		established and a failover event has occurred. So, unlike
	Redirect, it is irrelevant during the first two exchanges.		Redirect, it is irrelevant during the first two exchanges.
	Redirect after the session has been established is mostly useful		Redirect after the session has been established is mostly useful
	for timed or planned shutdown/maintenance. A real failover event		for timed or planned shutdown/maintenance. A real failover event
	cannot be detected by the active member ahead of time, and so		cannot be detected by the active member ahead of time, and so
	using Redirect after session establishment is not possible in the		using Redirect after session establishment is not possible in the
	case of failover. So, Redirect and SA counter synchronization		case of failover. So, Redirect and SA counter synchronization
	after failover are mutually exclusive.		after failover are mutually exclusive.
	o IKEv2 Failure Detection [8] solves a similar problem where the		o IKEv2 Failure Detection [6] solves a similar problem where the
	peer can rapidly detect that a cluster member has crashed based on		peer can rapidly detect that a cluster member has crashed based on
	a token. It is unrelated to the current scenario because the goal		a token. It is unrelated to the current scenario because the goal
	in failover is for the peer not to notice that a failure has		in failover is for the peer not to notice that a failure has
	occurred.		occurred.
	11. Security Considerations		11. Security Considerations
	Since Message ID synchronization messages need to be sent with		Since Message ID synchronization messages need to be sent with
	Message ID zero, they are potentially vulnerable to replay attacks.		Message ID zero, they are potentially vulnerable to replay attacks.
	Because of the semantics of this protocol, these can only be denial-		Because of the semantics of this protocol, these can only be denial-
	skipping to change at page 18, line 22		skipping to change at page 19, line 31
	order) for their review comments and valuable suggestions: Dan		order) for their review comments and valuable suggestions: Dan
	Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, and		Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, and
	Pekka Riikonen.		Pekka Riikonen.
	14. Change Log		14. Change Log
	This section lists all the changes in this document.		This section lists all the changes in this document.
	NOTE TO RFC EDITOR: Please remove this section before publication.		NOTE TO RFC EDITOR: Please remove this section before publication.
	14.1. Draft -03		14.1. Draft -04
			Extended Sec. 3 for better coverage of other IPsec cluster-related
			issues, and how they are resolved within the existing standards.
			14.2. Draft -03
	Clarified the rules for Message ID sync, so that replay attacks can		Clarified the rules for Message ID sync, so that replay attacks can
	be avoided without a failover counter.		be avoided without a failover counter.
	Added wording regarding inconsistent IKE state (basically choosing to		Added wording regarding inconsistent IKE state (basically choosing to
	ignore the problem) and further rules dealing with pending traffic.		ignore the problem) and further rules dealing with pending traffic.
	The IPsec replay counter delta value now refers to incoming traffic.		The IPsec replay counter delta value now refers to incoming traffic.
	The associated notification is only sent from the cluster to the		The associated notification is only sent from the cluster to the
	peer, and not back.		peer, and not back.
	14.2. Draft -02		14.3. Draft -02
	Addressed comments by Yaron Sheffer posted on the WG mailing list.		Addressed comments by Yaron Sheffer posted on the WG mailing list.
	Numerous editorial changes.		Numerous editorial changes.
	14.3. Draft -01		14.4. Draft -01
	Added "Multiple and Simultaneous failover' scenarios as pointed out		Added "Multiple and Simultaneous failover' scenarios as pointed out
	by Pekka Riikonen.		by Pekka Riikonen.
	Now document provides a mechanism to sync either IKEv2 message or		Now document provides a mechanism to sync either IKEv2 message or
	IPsec replay counter or both to cater different types of		IPsec replay counter or both to cater different types of
	implementations.		implementations.
	HA cluster's "failover count' is used to encounter replay of sync		HA cluster's "failover count' is used to encounter replay of sync
	requests by attacker.		requests by attacker.
	The sync of IPsec SA replay counter optimized to to have just one		The sync of IPsec SA replay counter optimized to to have just one
	global bumped-up outgoing IPsec SA counter of ALL Child SAs under an		global bumped-up outgoing IPsec SA counter of ALL Child SAs under an
	IKEv2 SA.		IKEv2 SA.
	The examples added for IKEv2 Message ID sync to provide more clarity.		The examples added for IKEv2 Message ID sync to provide more clarity.
	Some edits as per comments on mailing list to enhance clarity.		Some edits as per comments on mailing list to enhance clarity.
	14.4. Draft -00		14.5. Draft -00
	Version 00 is identical to		Version 00 is identical to
	draft-kagarigi-ipsecme-ikev2-windowsync-04, started as WG document.		draft-kagarigi-ipsecme-ikev2-windowsync-04, started as WG document.
	Added IPSECME WG HA design team members as authors.		Added IPSECME WG HA design team members as authors.
	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] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027,
	October 2010.		October 2010.
	[3] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key		[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		[4] 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
	[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] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the		[6] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick
	Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685,		Crash Detection Method for IKE",
	November 2009.		draft-ietf-ipsecme-failure-detection-05 (work in progress),
			February 2011.
	[7] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol		[7] Housley, R., "Using Advanced Encryption Standard (AES) Counter
	Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.		Mode With IPsec Encapsulating Security Payload (ESP)",
			RFC 3686, January 2004.
	[8] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick		[8] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM)
	Crash Detection Method for IKE",		in IPsec Encapsulating Security Payload (ESP)", RFC 4106,
	draft-ietf-ipsecme-failure-detection-03 (work in progress),		June 2005.
	January 2011.
			[9] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating
			Security Payload (ESP) and Authentication Header (AH) to
			Protect Group Traffic", RFC 6054, November 2010.
			[10] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol
			Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
			[11] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the
			Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685,
			November 2009.
	Appendix A. IKEv2 Message ID Sync Examples		Appendix A. IKEv2 Message ID Sync Examples
	This (non-normative) section presents some examples that illustrate		This (non-normative) section presents some examples that illustrate
	how the IKEv2 Message ID values are synchronized. We use a tuple		how the IKEv2 Message ID values are synchronized. We use a tuple
	notation, denoting the two counters EXPECTED_SEND_REQ_MESSAGE_ID and		notation, denoting the two counters EXPECTED_SEND_REQ_MESSAGE_ID and
	EXPECTED_RECV_REQ_MESSAGE_ID on a member as		EXPECTED_RECV_REQ_MESSAGE_ID on a member as
	(EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID).		(EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID).
	A.1. Normal Failover - Example 1		A.1. Normal Failover - Example 1
End of changes. 22 change blocks.
	79 lines changed or deleted		169 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/