draft-ietf-ipsecme-ipsecha-protocol-00.txt		draft-ietf-ipsecme-ipsecha-protocol-01.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: March 10, 2011 Y. Nir		Expires: April 14, 2011 Y. Nir
	Check Point		Check Point
	D. Zhang		D. Zhang
	Huawei		Huawei
	September 6, 2010		October 11, 2010
	Protocol Support for High Availability IKEv2/IPsec		Protocol Support for High Availability IKEv2/IPsec
	draft-ietf-ipsecme-ipsecha-protocol-00		draft-ietf-ipsecme-ipsecha-protocol-01
	Abstract		Abstract
	IKEv2 and IPsec protocols are widely used for deploying VPN. In		IKEv2 and IPsec protocols are widely used for deploying VPN. In
	order to make such VPN highly available and failure-prone, these VPNs		order to make such VPN highly available, more scalable and failure-
	are implemented as IKEv2/IPsec Highly Available (HA) cluster. But		prone, these VPNs are implemented as IKEv2/IPsec Highly Available
	there are many issues in IKEv2/IPsec HA cluster. The draft "IPsec		(HA) cluster. But there are many issues in IKEv2/IPsec HA cluster.
	Cluster Problem Statement" enumerates all the issues encountered in		The draft "IPsec Cluster Problem Statement" enumerates all the issues
	IKEv2/IPsec HA cluster environment.		encountered in IKEv2/IPsec HA cluster environment.
	This draft proposes an extension to IKEv2 protocol to solve main		This document proposes an extension to IKEv2 protocol to solve main
	issues of "IPsec Cluster Problem Statement" in Hot Standby cluster		issues of "IPsec Cluster Problem Statement" in Hot Standby cluster
	and gives implementation advice for other issues. The main issues to		and gives implementation advice for other issues. The main issues to
	be solved are:		be solved are:
	o IKE Message Id synchronization : This is done by obtaining the		o IKEv2 Message Id synchronization : This is done by syncing up
	message Id values from the peer and updating the values at the		expected send and receive message Id values with the peer and
	newly active cluster member after the failover.		updating the values at the newly active cluster member after the
	o IPsec SA Counter synchronization : This is done by sending		failover.
	incremented values of replay counters by the newly active cluster		o IPsec Replay Counter synchronization : This is done by syncing up
	member to the peer as expected replay counter value.		bumped up outgoing SA replay counters values with peer and
			updating the values at the newly active cluster member after the
			failover.
	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 March 10, 2011.
			This Internet-Draft will expire on April 14, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 11		skipping to change at page 3, line 11
	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 solved from IPsec Cluster Problem Statement . . . . . . 6		3. Issues solved from IPsec Cluster Problem Statement . . . . . . 6
	4. IKEv2/IPsec SA Counter Synchronization Problem . . . . . . . . 6		4. IKEv2/IPsec SA Counter Synchronization Problem . . . . . . . . 6
	5. IKEv2/IPsec SA Counter Synchronization Solution . . . . . . . 7		5. IKEv2/IPsec SA Counter Synchronization Solution . . . . . . . 8
	6. SA counter synchronization notify and payload types . . . . . 9		6. IKEv2/IPsec synchronization notification payloads . . . . . . 9
	6.1. SYNC_SA_COUNTER_INFO_SUPPORTED . . . . . . . . . . . . . . 9		6.1. IKEV2_MESSAGE_ID_SYNC_SUPPORTED . . . . . . . . . . . . . 10
	6.2. SYNC_SA_COUNTER_INFO . . . . . . . . . . . . . . . . . . . 9		6.2. IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED . . . . . . . . . . . 10
	7. Details of implementation . . . . . . . . . . . . . . . . . . 11		6.3. IKEV2_MESSAGE_ID_SYNC . . . . . . . . . . . . . . . . . . 11
	8. Step-by-Step details . . . . . . . . . . . . . . . . . . . . . 12		6.4. IPSEC_REPLAY_COUNTER_SYNC . . . . . . . . . . . . . . . . 11
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Details of implementation . . . . . . . . . . . . . . . . . . 12
	10. Interaction with other drafts . . . . . . . . . . . . . . . . 13		8. Step-by-Step details . . . . . . . . . . . . . . . . . . . . . 13
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		10. Interaction with other drafts . . . . . . . . . . . . . . . . 14
	13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	13.1. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 15		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 15		13.1. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 16
	14.2. Informative References . . . . . . . . . . . . . . . . . . 15		13.2. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
			14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
			14.2. Informative References . . . . . . . . . . . . . . . . . . 17
			Appendix A. IKEv2 Message Id examples . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	IKEv2 is used for deploying IPsec-based VPNs. In order to make such		IKEv2 is used for deploying IPsec-based VPNs. In order to make such
	VPN highly available and failure-prone, these VPNs are inplemented as		VPN highly available, more scalable and failure-prone, these VPNs are
	IKEv2/IPsec Highly Available (HA) cluster. But there are many issues		implemented as IKEv2/IPsec Highly Available (HA) cluster. But there
	in IKEv2/IPsec HA cluster. The draft "IPsec Cluster Problem		are many issues in IKEv2/IPsec HA cluster. The draft "IPsec Cluster
	Statement" enumerates all the issues encountered in IKEv2/IPsec HA		Problem Statement" enumerates all the issues encountered in IKEv2/
	cluster.		IPsec HA cluster.
	In case of Hot Standby cluster implementaion of IKEv2/IPsec based		In case of Hot Standby cluster implementation of IKEv2/IPsec based
	VPNs, the IKEv2/IPsec session gets established with the peer and the		VPNs, the IKEv2/IPsec session gets established with the peer and the
	active member of cluster. After that, the active member syncs/		active member of cluster. After that, the active member syncs/
	updates the IKE/IPsec SA state to the standby member of the cluster.		updates the IKE/IPsec SA state to the standby member of the cluster.
	This primary SA state sync-up is done on SA bring up and/or rekey.		This primary SA state sync-up is done on SA bring up and/or rekey.
	Doing SA state synchronization/updation between active and peer		Doing SA state synchronization/updation between active and peer
	member for each IKE and IPsec message standby cluster is very costly,		member for each IKE and IPsec message standby cluster is very costly,
	so normally its done periodically. So, when "failover" event happens		so normally its done periodically. So, when "failover" event happens
	in the cluster, first "failover' is detected by the standby member		in the cluster, first "failover' is detected by the standby member
	and then it becomes active member and it takes considerable time.		and then it becomes active member and it takes considerable time.
	During the time of failover and standby member becoming newly active		During the time of failover and standby member becoming newly active
	member, the peer is unaware of failover and keeps sending IKE request		member, the peer is unaware of failover and keeps sending IKE request
	and IPsec packets to the cluster which is allowed as per IKEv2 and		and IPsec packets to the cluster which is allowed as per IKEv2 and
	IPsec windowing feature. Now, newly active member after coming up		IPsec windowing feature. Now, newly active member after coming up
	finds the mismtach in IKE message id's and IPsec replay counters.		finds the mismtach in IKE message Id's and IPsec replay counters.
	Please see Section 4 for more details.		Please see Section 4 for more details.
	This draft proposes an extension to IKEv2 protocol to solve main		This document proposes an extension to IKEv2 protocol to solve main
	issues of IKE message id sync and IPsec SA replay counter sync and		issues of IKE message id sync and IPsec SA replay counter sync and
	gives implementation advice for others. Here is summary of solutions		gives implementation advice for others. Here is summary of solutions
	provided in this draft:		provided in this document:
	IKE Message Id synchronization : This is done by obtaining the
	message Id values from the peer and updating the values at the newly
	active cluster member after the failover.
	IPsec SA Counter synchronization : This is done by sending		IKEv2 Message Id synchronization :This is done by syncing up expected
	incremented values of replay counters by the newly active cluster		send and receive message Id values with the peer and updating the
	member to the peer as expected replay counter value.		values at the newly active cluster member after the failover.
	Though this draft describes the IKEv2/IPsec SA counter		IPsec Replay Counter synchronization : This is done by syncing up
	synchronisation in context of hot standby cluster. This solution can		bumped up outgoing SA replay counters values with peer and updating
	be used in other scenarios where IKEv2/IPsec SA counters are mis-		the values at the newly active cluster member after the failover
	matched and couner sync is needed.
	There were some concerns about the current window sync process. The		Though this document describes the IKEv2 message Id sync and IPsec
	concern was to make IKEv2 window sync optional but we beleive IKEv2		replay counter synchronization in context of IPsec HA cluster, the
	window sync will be mandatory.		solution provided is genetic and can be used in other scenarios where
			IKEv2 message Id sync or IPsec SA replay counters sync is required.
	[[ This topic needs to be discussed further on the WG mailing list.		While some IPsec HA implementation suffers from IKEv2 message Id
	]]		synchronization problem, some other implementation suffers from IPsec
			replay counter synchronization. Both of these problem are handled
			separately, using separate notify for each problem. This provides
			the flexibility of implementing IKEv2 message Id synchronization or
			IPsec replay counter synchronization or both.
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	"SA Counter SYNC Request" is the information exchange request defined		"SA Counter SYNC Request" is the information exchange request defined
	in this draft to synchronize the IKEv2/IPsec SA counter information		in this document to synchronize the IKEv2/IPsec SA counter
	between member of the cluster and the peer.		information between member of the cluster and the peer.
	"SA Counter SYNC Response" is the information exchange response		"SA Counter SYNC Response" is the information exchange response
	defined in this draft to synchronize the IKEv2/IPsec SA counter		defined in this document to synchronize the IKEv2/IPsec SA counter
	information between member of the cluster and the peer.		information between member of the cluster and the peer.
	Below are the terms taken from [IPsec Cluster Problem Statement] with		Below are the terms taken from [IPsec Cluster Problem Statement] with
	added information in context of this draft.		added information in context of this document.
	"Hot Standby Cluster", or "HS Cluster" is a cluster where only one of		"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 referred		the members is active at any one time. This member is also referred
	to as the "active", whereas the other(s) are referred to as		to as the "active", whereas the other(s) are referred to as
	"standbys". VRRP ([RFC5798]) is one method of building such a		"standbys". VRRP ([RFC5798]) is one method of building such a
	cluster. The goal of Hot Standby Cluster is that it creates illusion		cluster. The goal of Hot Standby Cluster is that it creates illusion
	of single virtual gateway to the peer(s).		of single virtual gateway to the peer(s).
	"Active Member" is the primary member in the Hot Standby cluster. It		"Active Member" is the primary member in the Hot Standby cluster. It
	is responsible for forwarding packets for the virtual gateway.		is responsible for forwarding packets for the virtual gateway.
	"Standby Member" is the primary backup router. The member takes		"Standby Member" is the primary backup router. The member takes
	control i.e. becomes active member after the "failover" event.		control i.e. becomes active member after the "failover" event.
	"Peer" is the IKEv2/IPsec endpoint which establishes VPN connection		"Peer" is the IKEv2/IPsec endpoint which establishes VPN connection
	with Hot Standby cluster. The Peer knows Hot Standby Cluster by		with Hot Standby cluster. The Peer knows Hot Standby Cluster by
	single cluster's IP address. In case of "failover", the standby		single cluster's IP address. In case of "failover", the standby
	member of the cluster becomes active, so the peer normally doesn't		member of the cluster becomes active, so the peer normally doesn't
	notice that "failover" has occured in the cluster.		notice that "failover" has occurred in the cluster.
	The generic term IKEv1/IPsec SA counters is used throughout. By		"Multiple failover" is the situation when in a cluster with three or
			more nodes failover happens in rapid succession. The protocol and
			implementation must be able to handle multiple failover i.e. able to
			handle new failover even if they are still processing the old
			failover.
			"Simultaneous failover" is the situation when in a cluster the
			failover happens at the both ends at the same time. The protocol and
			implementation must be able to handle simultaneous failover.
			The generic term IKEv2/IPsec SA counters is used throughout. By
	IKEv2 SA counter stands for IKEv2 message ids and IPsec SA counter		IKEv2 SA counter stands for IKEv2 message ids and IPsec SA counter
	stands for IPsec SA replay counters which are used to provide		stands for IPsec SA replay counters which are used to provide
	optional anti-replay feature.		optional anti-replay feature.
	3. Issues solved from IPsec Cluster Problem Statement		3. Issues solved from IPsec Cluster Problem Statement
	IPsec Cluster Problem Statement defines the problems encountered in		IPsec Cluster Problem Statement defines the problems encountered in
	IPsec Clusters. . The problems along with their section names as		IPsec Clusters. . The problems along with their section names as
	given in the statement are as follows.		given in the statement are as follows.
	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 Synch Messages		o 3.6. Missing Synch 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
	This draft solves the main issues using the protocol extention, and		This document solves the main issues using the protocol extension,
	provides implementation advice for other issues, given as follows.		and provides implementation advice for other issues, given as
			follows.
	o 3.2 This section mentions that there's lots of state that needs to		o 3.2 This section mentions that there's lots of state that needs to
	be synchronized. If state is not synchronized, it's not really an		be synchronized. If state is not synchronized, it's not really an
	interesting cluster - failover will be just like a reboot, so the		interesting cluster - failover will be just like a reboot, so the
	issue need not be solved with protocol extensions.		issue need not be solved with protocol extensions.
	o 3.3, 3.4,3.5, and 3.6 are solved by this draft. Please see		o 3.3, 3.4,3.5, and 3.6 are solved by this document. Please see
	Section 4, for more details.		Section 4, for more details.
	o 3.7 is the problem to be solved while building clusters. However,		o 3.7 is the problem to be solved while building clusters. However,
	the peers should be mandated to accept multiple parallel SAs for		the peers should be mandated to accept multiple parallel SAs for
	3.7.1		3.7.1
	o 3.8 can be solved by using IKEv2 Redirect Mechanism [RFC-5685].		o 3.8 can be solved by using IKEv2 Redirect Mechanism [RFC-5685].
	o 3.9 is the problem about avoiding collision of same SPI's among		o 3.9 is the problem about avoiding collision of same SPI's among
	the cluster members. This is outside the scope of the document		the cluster members. This is outside the scope of the document
	since this has to be solved within the context of the cluster and		since this has to be solved within the context of the cluster and
	not with the peer.		not with the peer.
	skipping to change at page 6, line 49		skipping to change at page 7, line 10
	IKEv2 RFC states that "An IKE endpoint MUST NOT exceed the peer's		IKEv2 RFC states that "An IKE endpoint MUST NOT exceed the peer's
	stated window size for transmitted IKE requests".		stated window size for transmitted IKE requests".
	As per the protocol, all IKEv2 packets follows request-response		As per the protocol, all IKEv2 packets follows 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		outstanding at a given point of time, but mandates that the sender
	window does not move until the oldest message sent from one peer to		window does not move until the oldest message sent from one peer to
	another is acknowledged. Loss of even a single packet leads to		another is acknowledged. Loss of even a single packet leads to
	repeated retransmissions followed by an IKEv2 SA teardown if the		repeated re-transmissions followed by an IKEv2 SA teardown if the re-
	retransmissions are unacknowledged.		transmissions are unacknowledged.
	IPsec Hot Standby Cluster is required to ensure that in case of		IPsec Hot Standby Cluster is required to ensure that in case of
	failover of active member, the standby member becomes active		failover of active member, the standby member becomes active
	immediately. The standby member is expected to have the exact values		immediately. The standby member is expected to have the exact values
	of message id fields of active member before failover. Even with the		of message id fields of active member before failover. Even with the
	best efforts to update the message Id values from active to standby		best efforts to update the message Id values from active to standby
	member, the values at standby member can be stale due to following		member, the values at standby member can be stale due to following
	reasons:		reasons:
	o Standby member is unaware of the last message that was received		o Standby member is unaware of the last message that was received
	and acknowledged by the older active member as failover could have		and acknowledged by the older active member as failover could have
	happened before the standby could be updated.		happened before the standby could be updated.
	o Standby member does not have information about on-going		o Standby member does not have information about on-going
	unackowledged requests of active member before the failover event.		unacknowledged requests of active member before the failover
	So after failover event when standby member becomes active, it can		event. So after failover event when standby member becomes
	not re-transmit those requests.		active, it can not re-transmit those requests.
	When a standby member takes over as the active member, it would start		When a standby member takes over as the active member, it would start
	the message id ranges from previously updated values. This would		the message id ranges from previously updated values. This would
	make it reject requests from the peer, since the values would be		make it reject requests from the peer, since the values would be
	stale. As a sender, the standby member may end up reusing a stale		stale. As a sender, the standby member may end up reusing a stale
	message id which will cause the peer to drop the request. Eventually		message id which will cause the peer to drop the request. Eventually
	there is a high probability of the IKEv2 and corresponding IPsec SAs		there is a high probability of the IKEv2 and corresponding IPsec SAs
	getting torn down simply because of a transitory message id mismatch		getting torn down simply because of a transitory message id mis-match
	and re-transmission of requests. This is not a desirable feature of		and re-transmission of requests. This is not a desirable feature of
	HA. Even after updating standby memeber periodically the cluster can		HA. Even after updating standby member periodically the cluster can
	loose IKE and so all IPsec SA due to message id i.e. SA counter		loose IKE and so all IPsec SA due to message id i.e. SA counter
	mismatch.		mismatch.
	Similar issue is observed in IPsec counters also if anti-replay		Similar issue is observed in IPsec counters also if anti-replay
	protection/ESN is implemented. Even with the best efforts of syncing		protection/ESN is implemented. Even with the best efforts of syncing
	the ESP and AH SA counter numbers from active to stand by member ,		the ESP and AH SA counter numbers from active to stand by member ,
	there is a chance that the stand-by member would have stale counter		there is a chance that the stand-by member would have stale counter
	values. The standby member would then send the stale counter		values. The standby member would then send the stale counter
	numbers. The peer would reject such packets since in case of anti-		numbers. The peer would reject/drop such packets since in case of
	replay protection feature, duplicate use of counters are not allowed.		anti-replay protection feature, duplicate use of counters are not
	In case of IPsec it is ok to skip some counter values and start with		allowed. In case of IPsec it is OK to skip some counter values and
	the highr counter values.		start with the higher counter values.
	Hence a mechanism is required in HA to ensure that the standby member		Hence a mechanism is required in HA to ensure that the standby member
	has correct values of message Id values and IPsec counters, so that		has correct values of message Id values and IPsec counters, so that
	sessions are not torn down just because of window ranges.		sessions are not torn down just because of mismatching counters.
	5. IKEv2/IPsec SA Counter Synchronization Solution		5. IKEv2/IPsec SA Counter Synchronization Solution
	After the standby member becomes the active member after failover		When the standby member becomes the active member after failover
	event in the cluster, the standby member would send an authenticated		event in the cluster, the standby member would send an authenticated
	IKEv2 request to the peer to send its values of SA counters.		IKEv2 request to the peer to send its values of SA counters.
	The standby member would then update its values of SA counters and		The standby member would then update its values of SA counters and
	then start sending/receiving the requests.		then start sending/receiving the requests.
	The peer MUST negotiate its ability to support SA counter		First, the peer MUST negotiate its ability to support IKEv2 message
	synchronization information with active member by sending the		Id synchronization information with active member of the cluster by
	SYNC_SA_COUNTER_INFO_SUPPORTED notification in IKE_AUTH exchange.		sending the IKEV2_MESSAGE_ID_SYNC_SUPPORTED notification in IKE_AUTH
			exchange.
	Peer Active Member		Similarly to support IPsec replay counter synchronization, the peer
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -		MUST negotiate its ability to support IPsec replay counter
	HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH,		synchronization with active member of the cluster by sending
	N[SYNC_SA_COUNTER_INFO_SUPPORTED], SAi2, TSi, TSr} ---------->		IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED notification in IKE_AUTH
			exchange.
	<---------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH,		Peer Active Member
	N[SYNC_SA_COUNTER_INFO_SUPPORTED], SAr2, TSi, TSr}		- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
			HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH,
			N[IKEV2_MESSAGE_ID_SYNC_SUPPORTED],
			N[IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED],
			SAi2, TSi, TSr} ---------->
			<---------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH,
			N[IKEV2_MESSAGE_ID_SYNC_SUPPORTED],
			N[IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED], SAr2, TSi, TSr}
	When peer and active member both support SA counter synchronization,		When peer and active member both support SA counter synchronization,
	the active member MUST sync/update SA counter synchronization		the active member MUST sync/update SA counter synchronization
	capability to the standby member after the establishment of the IKE		capability to the standby member after the establishment of the IKE
	SA. So that standby member is aware of the capability and can use it		SA . So that standby member is aware of the capability and can use
	when it becomes the active member after failover event.		it when it becomes the active member after failover event.
	After failover event, when the standby member becomes the active		After failover event, when the standby member becomes the active
	member, it has to request the peer for the SA counters. Standby		member, it has to request the peer for the SA counters. Standby
	member would initiate the SYNC Request with an INFORMATIONAL exchange		member would initiate the SYNC Request with an INFORMATIONAL exchange
	containing the notify SYNC_SA_COUNTER_INFO. The SYNC_SA_COUNTER_INFO		with message Id zero containing the notify IKEV2_MESSAGE_ID_SYNC or
	information can be used for update IKEv2 counters i.e. message ids		IPSEC_REPLAY_COUNTER_SYNC or both depending on whether the
	and also IPsec SA replay counters.		synchronization needs to be done for IKEv2 message Ids, IPsec replay
			counters, or both.
	If there are many IPsec SAs and all IPsec SA counters cannot be		The initiator of IKEv2 message Id sync request sends its expected
	synchronized with a single counter sync exchange, then another		send and receive message Id values and "failover count" in
	counter sync exchange SHOULD be send for remaining IPsec SAs, but for		IKEV2_MESSAGE_ID_SYNC notify. The responder of the request compares
	this exchange message id would be synced IKE message id after first		the received values with the available local values. The higher
	counter sync exchnage NOT zero.		among both is selected and sent as sync response with notify
			IKEV2_MESSAGE_ID_SYNC. The initiator now updates send and receive
			IKEv2 message Ids to the values received in sync response and can
			start normal IKEv2 message exchange.
	The peer will respond back with the notify SYNC_SA_COUNTER_INFO. The		The initiator of IPsec replay counter sync sends bumped outgoing
	SYNC_SA_COUNTER_INFO request contains NONCE data to avoid DOS attack		IPsec SA reply counter value and "failover count" in
	due to replay of SA counter sync response. The Nonce data send in		IPSEC_REPLAY_COUNTER_SYNC notify. The responder of the request
	SYNC_SA_COUNTER_INFO response MUST match with nonce data sent by		updates its incoming IPsec SA counter values and sends its bumped
	newly-active member in SYNC_SA_COUNTER_INFO request. If nonce data		outgoing IPsec SA replay counter value in sync response with
	received in SYNC_SA_COUNTER_INFO response does not match with nonce		IPSEC_REPLAY_COUNTER_SYNC. The initiator now updates its incoming
	data sent in SYNC_SA_COUNTER_INFO request, the standby i.e. newly-		IPsec SA counter to values received in sync response and can start
	active member MUST discard this SYNC_SA_COUNTER_INFO response, and		normal IPsec data traffic.
	normal IKEv2 behaviour of re-transmitting the request and waiting for
	genuine reply from the peer SHOULD follow, before tearing down the SA		Both the notify types IKEV2_MESSAGE_ID_SYNC and
	becuase of re-transmits.		IPSEC_REPLAY_COUNTER_SYNC contain Nonce Data in the payload to avoid
			DOS attack due to replay of SA counter sync request/response. The
			Nonce are defined per notify and MUST be validated. The Nonce data
			sent in response MUST match with nonce data sent by newly-active
			member in request. If nonce data received in response does not match
			with nonce data sent in request, the standby i.e. newly-active member
			MUST discard this response, and normal IKEv2 behavior of re-
			transmitting the request and waiting for genuine reply from the peer
			SHOULD follow, before tearing down the SA because of re-transmits.
	Standby [Newly Active] Member Peer		Standby [Newly Active] Member Peer
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -		- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	HDR, SK {N[SYNC_SA_COUNTER_INFO]+} -------->		HDR, SK {N[IKEV2_MESSAGE_ID_SYNC ],
			N[IPSEC_REPLAY_COUNTER_SYNC]} -------->
	<--------- HDR, SK {N[SYNC_SA_COUNTER_INFO]+}		<--------- HDR, SK {N[IKEV2_MESSAGE_ID_SYNC ],
			N[IPSEC_REPLAY_COUNTER_SYNC]}
	6. SA counter synchronization notify and payload types		6. IKEv2/IPsec synchronization notification payloads
	Below are the new notify and payload types that are defined		Below are the new notify and payload types that are defined
	6.1. SYNC_SA_COUNTER_INFO_SUPPORTED		6.1. IKEV2_MESSAGE_ID_SYNC_SUPPORTED
	SYNC_SA_COUNTER_INFO_SUPPORTED: This notify is included in the		IKEV2_MESSAGE_ID_SYNC_SUPPORTED: This notify is included in the
	IKE_AUTH request by the peer to indicate the support for IKEv2/IPsec		IKE_AUTH request/response to indicate support for IKEv2 message Id
	SA counter synchronization mechanism described in this document.		synchronization 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	SYNC_SA_COUNTER_INFO_SUPPORTED
	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 [IKEv2bis]. The 'SPI Size' field MUST be set to 0 to indicate		of [RFC5996]. The 'SPI Size' field MUST be set to 0 to indicate that
	that the SPI is not present in this message. The 'Protocol ID' MUST		the SPI is not present in this message. The 'Protocol ID' MUST be
	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. 'Payload Length' field is set to the length in		security association. '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		The 'Notify Message Type' field is set to indicate the
	SYNC_SA_COUNTER_INFO_SUPPORTED payload.		IKEV2_MESSAGE_ID_SYNC_SUPPORTED payload.
	6.2. SYNC_SA_COUNTER_INFO		6.2. IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED
	SYNC_SA_COUNTER_INFO : This payload type is defined to sync the SA		IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED: This notify is included in the
	counter information among newly-active [standby] member and the peer.		IKE_AUTH request/response to indicate support for IPsec SA replay
	The SYNC_SA_COUNTER_INFO payload can be used to synchronize IKE SA		counter synchronization mechanism described in this document.
	counter and IPsec SA counters as well. So, multiple payloads of this
	type can be used in the single exchange where one payload is used to
	sync the IKE SA counter information, another payload can be used to
	sync the Child SA [ e.g. ESP, AH etc] information.
	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 |M| RESERVED | Payload Length |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Protocol ID | SPI Size | # of SPI's |Counter Size |		|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ ~		The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and
	| |		'Notify Message Type' fields are the same as described in Section 3
	~ Nonce Data ~		of [RFC5996]. 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 0, since the notification is not specific to a particular
	| |		security association. 'Payload Length' field is set to the length in
			octets of the entire payload, including the generic payload header.
			The 'Notify Message Type' field is set to indicate the
			IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED payload.
			6.3. IKEV2_MESSAGE_ID_SYNC
			IKEV2_MESSAGE_ID_SYNC : This payload type is defined to sync the
			IKEv2 message Ids among newly-active [standby] member and the peer.
			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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| EXPECTED_SEND_REQ_MESSAGE_ID |		| Next Payload | RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| EXPECTED_RECV_REQ_MESSAGE_ID |		| Failover count |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPI |		| Nonce Data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| EXPECTED_SEND_REQ_MESSAGE_ID |
	~ Last Counter ~		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| EXPECTED_RECV_REQ_MESSAGE_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	SYNC_SA_COUNTER_INFO
	It contains the following data.		It contains the following data.
	o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3		o Failover count (4 octets) : The failover count within the cluster,
	for ESP.		it increases with each failover event in HA cluster.
	o SPI Size (1 octet) - Length in octets of the SPI as defined by the		o Nonce Data (4 octets) : The random nonce data. It should be sent
	protocol ID. It MUST be zero for IKE or four for AH and ESP.		same in the SYNC Request and Response. The nonce data is used to
	o # of SPIs (1 octet) - The number of SPIs contained in this		counter the replay of IKEV2_MESSAGE_ID_SYNC response by the
	payload. The size of each SPI is defined by the SPI Size field.		attacker.
	It MUST be zero if protocol is IKE.
	o Counter Size (1 octet) is the size of IPsec SA counter in octets.
	It is 4 if the Extended Sequence Numbers option is not set for the
	SAs described in this payload, or 8 otherwise. It MUST be zero if
	protocol is IKE.
	o Nonce Data (16 octets) - The nonce data MUST be present if
	protocol is IKE. The nonce data is used to counter the replay of
	SYNC_SA_COUNTER_INFO response by the attacker.
	o EXPECTED_SEND_REQ_MESSAGE_ID (4 octets) : This MUST be present		o EXPECTED_SEND_REQ_MESSAGE_ID (4 octets) : This MUST be present
	only if protocol ID is IKE. This field is used by the sender of		only if protocol ID is IKE. This field is used by the sender of
	this notify, to indicate the message Id it will use in the next		this notify, to indicate the message Id it will use in the next
	request, t that it will send to the peer. It MUST be present only		request, that it will send to the other side peer.
	in SA counter synchronization response and MUST be ignored in SA		o EXPECTED_RECV_REQ_MESSAGE_ID (4 octets) : This field is used by
	counter synchronization request.		the sender of this notify, to indicate the message Id it can
	o EXPECTED_RECV_REQ_MESSAGE_ID(4 octets) : This field is used by the		accept in the next request, received from the other side peer.
	sender of this notify, to indicate the message Id it can accept in
	the next request, received from the peer.This data MUST be present		6.4. IPSEC_REPLAY_COUNTER_SYNC
	only in response and MUST be ignored if present in REQUEST.This
	MUST be present only if protocol ID is IKE.		IPSEC_REPLAY_COUNTER_SYNC: This payload type is defined to sync the
	o SPI (4 octets) is the Security Parameter Index of the outbound SA		IPsec SA replay counters among newly-active [standby] member and the
	for the sender, or the inbound SA for the receiver.		peer.
	o Last Counter (4 or 8 octets) is the counter number of the last
	packet sent. The receiver MUST drop any IPsec packet with replay		1 2 3
	counter lower than this.		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
	o M (More - 1 bit) - This flag MUST be set when there are some IPsec		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	are left to be synced, but can not be send due to packet size or		| Next Payload |ESN| RESERVED | Payload Length |
	some other limitation. When M bit is zero it, it tell it is last		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	SA counter sync message.		| Failover count |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Outgoing IPsec SA counter |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			It contains the following data.
			o ESN (1 bit) : The ESN bit MUST be ON if IPsec SA were established
			with Extended Sequence Numbers.
			o Failover count (4 octets) : The failover count within the cluster,
			it increases with each failover event in HA cluster.
			o Outgoing IPsec SA counter (4 octets or 8 octect) : The outgoing
			IPsec SA counter is the bumped-up outgoing IPsec SA replay counter
			value considering ALL Child SA under the IKEv2 SA. The size of
			outgoing IPsec SA counter depends on ESN bit. If ESN bit is ON,
			it is size of 8 octets else it is 4 octets.
	7. Details of implementation		7. Details of implementation
	The message Id used in this exchange MUST be zero so that it is not		The message Id used IKEV2_MESSAGE_ID_SYNC exchange MUST be zero so
	vaildated upon receipt. Message Id zero MUST be permitted only for		that it is not validated upon receipt as per IKEv2 windowing.
	informational exchange that would have NOTIFY of type		Message Id zero MUST be permitted only for informational exchange
	SYNC_SA_COUNTER_INFO. If any packet uses the message Id Zero,		that would have NOTIFY of type IKEV2_MESSAGE_ID_SYNC. If any
	without having this Notify along with the Nonce payload, then such		INFORMATIONAL exchange uses the message Id Zero, without having this
	packets MUST be discarded upon decryption. No other payloads are		Notify, then such packets MUST be discarded upon decryption and
	allowed in this Informational exchange.		INVALID_SYNTAX notify SHOULD be sent. No other payloads are allowed
			in this Informational exchange. Whenever IKEV2_MESSAGE_ID_SYNC or
			IPSEC_REPLAY_COUNTER_SYNC notify is received with invalid failover
			count or nonce data, the event SHOULD be logged.
	The standby member can initiate the synchronization of IKEv2 Message		The standby member can initiate the synchronization of IKEv2 Message
	Id's		Id's
	o When it receives the bad IKEv2/IPsec packet. The 'bad" IKEv2/		o When it receives the bad IKEv2/IPsec packet. The 'bad" IKEv2/
	IPsec packet means a packet outside receive window.		IPsec packet means a packet outside receive window.
	o When it has to send an IKEv2/IPsec packet after failover event.		o When it has to send an IKEv2/IPsec packet after failover event.
	o It has just got the control from active member and would require		o It has just got the control from active member and would require
	to update the values before-hand, so that it need not start this		to update the values before-hand, so that it need not start this
	exchange at the time of sending/receiving the request.		exchange at the time of sending/receiving the request.
	skipping to change at page 12, line 9		skipping to change at page 13, line 14
	o If there is traffic using the IPsec SA in the recent past and		o If there is traffic using the IPsec SA in the recent past and
	there could be stale replay counter at standby member		there could be stale replay counter at standby member
	Since there can be many sessions at Standby member, and sending		Since there can be many sessions at Standby member, and sending
	exchanges from all of the sessions can cause throttling, the standby		exchanges from all of the sessions can cause throttling, the standby
	member can choose to initiate the exchange when it has to send or		member can choose to initiate the exchange when it has to send or
	receive the request. Thus the trigger to initiate this exchange		receive the request. Thus the trigger to initiate this exchange
	depends on the requirement/discretion of the standby member.		depends on the requirement/discretion of the standby member.
	The member which has not announced its capability		The member which has not announced its capability
	SYNC_SA_COUNTER_INFO_SUPPORTED MUST NOT send/receive the notify		IKEV2_MESSAGE_ID_SYNC_SUPPORTED MUST NOT send/receive the notify
	SYNC_SA_COUNTER_INFO.		IKEV2_MESSAGE_ID_SYNC.
	If a peer gets SYNC_SA_COUNTER_INFO request even though it did not		The member which has not announced its capability
	announce its capability in IKE_AUTH exchange, then it MUST ignore		IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED MUST NOT send/receive the notify
	this message.		IPSEC_REPLAY_COUNTER_SYNC.
			If a peer gets IKEV2_MESSAGE_ID_SYNC or IPSEC_REPLAY_COUNTER_SYNC
			request even though it did not announce its capability in IKE_AUTH
			exchange, then it MUST ignore this message.
			If any of the Notify or the SYNC request/response is malformed, then
			it is treated as INVALID_SYNTAX message.
	8. Step-by-Step details		8. Step-by-Step details
	The step by step details of the synchronisation of IKE message Id is		The step by step details of the synchronization of IKE message Id is
	as follows.		as follows.
	o Active member and peer device establish the session . They		o Active member and peer device establish the session . They
	announce the capability to sync the counter info by sending		announce the capability to sync the counter info by sending
	SYNC_SA_COUNTER_INFO_SUPPORTED notify in AUTH Exchange.		IKEV2_MESSAGE_ID_SYNC_SUPPORTED notify in IKE_AUTH Exchange.
	o Active member dies and Stand-by member takes over. . Stand-by		o Active member dies and Stand-by member takes over. Standby Member
	Member sends its own idea of the IKE Message ID (its side) to		sends its own idea of the IKE Message ID (its side) to peer in an
	peer.		INFORMATIONAL message exchange with message Id zero.
	o The peer will send its EXPECTED_SEND_REQ_MESSAGE_ID and		o The peer first authenticates the message and then validates that
	EXPECTED_RECV_REQ_MESSAGE_ID. Since the message Id values		failover count. The peer will compare the received values with
	received are higher than values at the stand-by member , itwould		the values available locally and finally picks the higher value.
	update its local values of message Id's with the received values.		It then updates its message Id's with the higher values and also
			propose the same in Response.
	o The peer should not wait for pending response while responding		o The peer should not wait for pending response while responding
	with this message Id values. For example if window size is 5 and		with this message Id values. For example if window size is 5 and
	peer window is 3-7 and if peer has sent requests 3, 4,5,6,7 and		peer window is 3-7 and if peer has sent requests 3, 4,5,6,7 and
	but got response only for 4,5,6,7 but not 3 then it should send		but got response only for 4,5,6,7 but not 3 then it should send
	the EXPECTED_SEND_REQ_MESSAGE_ID as 8 and should not wait for		the EXPECTED_SEND_REQ_MESSAGE_ID as 8 and should not wait for
	response of 3 anymore.		response of 3 anymore.
	o The peer should not wait for pending request also. For example if		o The peer should not wait for pending request also. For example if
	window size is 5 and peer window is 3-7 and if peer has received		window size is 5 and peer window is 3-7 and if peer has received
	requests 4,5,6,7 but not 3 then it should send the		requests 4,5,6,7 but not 3 then it should send the
	EXPECTED_RECV_REQ_MESSAGE_ID as 8 and should not wait for 3		EXPECTED_RECV_REQ_MESSAGE_ID as 8 and should not wait for 3
	anymore.		anymore.
	The step by step details of the synchronisation of IPsec SA Counter		There is corner case with "failover count' and multiple failover.
	synchronization is as follows.		What if "failover count" is not updated on a member, and next
	o Active member and peer device establish the session . They		"failover" happened, then "failover count" is updated on other side
	announce the capability to sync the counter info by sending		but not on this member. [[ This need to be discussed on mailing list.
	SYNC_SA_COUNTER_INFO_SUPPORTED notify in AUTH Exchange.		]]
	o Active member dies and Stand-by member takes over. Stand-by
	Member increments its values of Outbound SA Counters for each
	IPsec SA and sends them to the peer.
	o The peer will update its Inbound SA Counter corresponding to each
	IPsec SA and send its Outbound SA Counter value for each IPsec SA
	on it.
	o If replay counters were bumped by large amount, we MAY slowly do
	child sa rekey to reset counter when member is less loaded after
	failover event.
	9. Security Considerations		9. Security Considerations
	There can be two types of DOS attacks.		There can be two types of DOS attacks.
	o Replay of Message SYNC Request. This can be countered by rate		o Replay of Message SYNC Request. This is countered by "failover
	limiting the number of such requests a peer can receive. The rate		count", since synchronization starts after failover event and each
	limiting can be done either by number or the time delay between		member of the cluster is aware of failover event. The receiver of
	which Message SYNC request can be received or both.These options		sync request should verify and maintain failover count. If a peer
	are configurable.		again receives a sync request with same "failover count', it can
	o Replay of Message SYNC Response. This can be countered by sending		safely safely discard the request if it has received valid
	the NONCE data along with the SYNC_SA_COUNTER_INFO notify. The		request/response from other side peer after sync exchange. The
	same NONCE data has to be returned in response. Thus the standby		peer can send the cached response for sync request till it has not
	member can accept the reply only for the current request. After		received valid request/response from other side peer or failover
	it receives the response, it MUST not accept the same response		count has not increased.
	again and MUST drop the response.		o Replay of Message SYNC Response. This is countered by sending the
			NONCE data along with the sync notify. The same NONCE data has to
			be returned in response. Thus the standby member can accept the
			reply only for the current request. After it receives the valid
			response, it MUST NOT process same response again and MUST discard
			the response.
	10. Interaction with other drafts		10. Interaction with other drafts
	The primary assumption of IKEv2/IPsec SA Counter Synchronization		The primary assumption of IKEv2/IPsec SA Counter Synchronization
	prososal is IKEv2 SA has been established between active member of		proposal is IKEv2 SA has been established between active member of
	Hot Standby Cluster and peer, after that the failover event occurred		Hot Standby Cluster and peer, after that the failover event occurred
	and now standby member has "become" active. It also assumes the		and now standby member has "become" active. It also assumes the
	IKEv2 SA state was synced between active and standby member of the		IKEv2 SA state was synced between active and standby member of the
	Hot Standby Cluster before the failover event.		Hot Standby Cluster before the failover event.
	o Session Resumption. Session resumption assumes that peer i.e.		o Session Resumption. Session resumption assumes that peer i.e.
	client or initiator detects the need to re-establish the session.		client or initiator detects the need to re-establish the session.
	In IKEv2/IPsec SA counter cynchronization, standby member which		In IKEv2/IPsec SA counter synchronization, standby member which
	becomes active i.e. gateway or responder detects the need to		becomes active i.e. gateway or responder detects the need to
	synchronize the SA counter after the failover event. Also in Hot		synchronize the SA counter after the failover event. Also in Hot
	Standby Cluster, peer establishes the IKEv2/IPsec session with		Standby Cluster, peer establishes the IKEv2/IPsec session with
	single cluster's IP address, so peer normally does not detect the		single cluster's IP address, so peer normally does not detect the
	event of failover in the cluster until standby member took very		event of failover in the cluster until standby member took very
	long to become active and IKEv2 SA times out via liveness check.		long to become active and IKEv2 SA times out via liveness check.
	So, session resumption and SA counter synchronization after		So, session resumption and SA counter synchronization after
	failover are mutually exclusive.		failover are mutually exclusive.
	o This document describes the operation of tightly coupled clusters,		o This document describes the operation of tightly coupled clusters,
	which are the common way of building IPsec clusters. In these		which are the common way of building IPsec clusters. In these
	skipping to change at page 14, line 25		skipping to change at page 15, line 35
	establishment. While SA counter sync is used after IKE SA has		establishment. While SA counter sync is used after IKE SA has
	been established and failover event has occurred. So it is		been established and failover event has occurred. So it is
	mutually exclusive with redirect during init and auth. The		mutually exclusive with redirect during init and auth. The
	redirect after session established is used for timed or planned		redirect after session established is used for timed or planned
	shutdown/maintenance. The failover event can not be detected on		shutdown/maintenance. The failover event can not be detected on
	active member beforehand and so using redirect after session		active member beforehand and so using redirect after session
	establishment is not possible in case of failover. So, Redirect		establishment is not possible in case of failover. So, Redirect
	and SA counter synchronization after failover are mutually		and SA counter synchronization after failover are mutually
	exclusive.		exclusive.
	o Crash detection. Solves the similar problem where peer detect		o Crash detection. Solves the similar problem where peer detect
	that cluster member has crashed based on a token. It is mutualy		that cluster member has crashed based on a token. It is mutually
	exclusive with HA with SA counter sync.		exclusive with HA with SA counter sync.
	11. IANA Considerations		11. IANA Considerations
	This document introduces two new IKEv2 Notification Message types as		This document introduces four new IKEv2 Notification Message types as
	described in Section 6.The new Notify Message Types must be assigned		described in Section 6.The new Notify Message Types must be assigned
	values between 16396 and 40959.		values between 16396 and 40959.
	o SYNC_SA_COUNTER_INFO_SUPPORTED		o IKEV2_MESSAGE_ID_SYNC_SUPPORTED.
	o SYNC_SA_COUNTER_INFO		o IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED.
			o IKEV2_MESSAGE_ID_SYNC.
			o IPSEC_REPLAY_COUNTER_SYNC.
	12. Acknowledgements		12. Acknowledgements
	We would like to thank Pratima Sethi and Frederic Detienne for their		We would like to thank Pratima Sethi and Frederic Detienne for their
	reviews comments and valuable suggestions for initial version of the		reviews comments and valuable suggestions for initial version of the
	document.		document.
	We would also like to thank following people (in alphabetical order)		We would also like to thank following people (in alphabetical order)
	for their review comments and valuable suggestions: Dan Harkins, Paul		for their review comments and valuable suggestions: Dan Harkins, Paul
	Hoffman, Steve Kent, Tero Kivinen, David McGrew, Pekka Riikonen,		Hoffman, Steve Kent, Tero Kivinen, David McGrew, Pekka Riikonen, and
	Yaron Sheffar.		Yaron Sheffar.
	13. Change Log		13. 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 in before final RFC		NOTE TO RFC EDITOR: Please remove this section before publication.
	publication.
	13.1. Draft -00		13.1. Draft -01
			Added "Multiple and Simultaneous failover' scenarios.
			Now document provides a mechanism to sync either IKEv2 message or
			IPsec replay counter or both to cater different types of
			implementations.
			HA cluster's "failover count' is used to encounter replay of sync
			requests by attacker.
			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
			IKEv2 SA.
			The examples added for IKEv2 message Id sync to provide more clarity.
			Some edits as per comments on mailing list to enhance clarity.
			13.2. 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.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[IKEv2bis]
	Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
	"Internet Key Exchange Protocol: IKEv2",
	draft-ietf-IPsecme-ikev2bis (work in progress), May 2010.
	[IPsec Cluster Problem Statement]		[IPsec Cluster Problem Statement]
	Nir, Y., "IPsec Cluster Problem Statement", July 2010.		Nir, Y., "IPsec Cluster Problem Statement", July 2010.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
			"Internet Key Exchange Protocol: IKEv2", RFC 5996,
			September 2010.
	14.2. Informative References		14.2. Informative References
	[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for		[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for
	IKEv2", RFC 5685, November 2009.		IKEv2", RFC 5685, November 2009.
	[RFC5723] Sheffer, Y. and H. Tschofenig, "IKEv2 Session Resumption",		[RFC5723] Sheffer, Y. and H. Tschofenig, "IKEv2 Session Resumption",
	RFC 5723, January 2010.		RFC 5723, January 2010.
			Appendix A. IKEv2 Message Id examples
			Below are the examples to illustrate how the IKEv2 message Id values
			are synced. The notation used to denote EXPECTED_SEND_REQ_MESSAGE_ID
			and EXPECTED_RECV_REQ_MESSAGE_ID on a member is
			(EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID).
			Normal failover - Example 1
			Standby [Newly Active] Member Peer
			- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
			Request SYNC (2, 3) -------->
			Peer has values as (4, 5) so it sends
			< -------------( 4, 5) Response SYNC
			Normal failover - Example 2
			Standby [Newly Active] Member Peer
			- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
			Request SYNC (2, 5) -------->
			Peer has values as (2, 4) so it sends
			< -------------( 5, 4) Response SYNC
			Simultaneous failover
			In case of simultaneous failover, both the sides send the SYNC
			request, but whichever side has the higher value will be eventually
			synced.
			Standby [Newly Active] Member Peer
			- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
			request SYNC (4,4) ----->
			<-------------- request SYNC (5,5)
			response SYNC (5,5) ---->
			<-------- response SYNC (5,5)
	Authors' Addresses		Authors' Addresses
	Raj Singh (Editor)		Raj Singh (Editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Divyashree Chambers, B Wing, O'Shaugnessy Road		Divyashree Chambers, B Wing, O'Shaugnessy Road
	Bangalore, Karnataka 560025		Bangalore, Karnataka 560025
	India		India
	Phone: +91 80 4426 4833		Phone: +91 80 4301 3320
	Email: rsj@cisco.com		Email: rsj@cisco.com
	Kalyani Garigipati		Kalyani Garigipati
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Divyashree Chambers, B Wing, O'Shaugnessy Road		Divyashree Chambers, B Wing, O'Shaugnessy Road
	Bangalore, Karnataka 560025		Bangalore, Karnataka 560025
	India		India
	Phone: +91 80 4426 4831		Phone: +91 80 4426 4831
	Email: kagarigi@cisco.com		Email: kagarigi@cisco.com
End of changes. 78 change blocks.
	242 lines changed or deleted		359 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/