draft-ietf-ipsecme-ipsec-ha-08.txt		draft-ietf-ipsecme-ipsec-ha-09.txt
	Network Working Group Y. Nir		Network Working Group Y. Nir
	Internet-Draft Check Point		Internet-Draft Check Point
	Intended status: Informational June 28, 2010		Intended status: Informational July 4, 2010
	Expires: December 30, 2010		Expires: January 5, 2011
	IPsec Cluster Problem Statement		IPsec Cluster Problem Statement
	draft-ietf-ipsecme-ipsec-ha-08		draft-ietf-ipsecme-ipsec-ha-09
	Abstract		Abstract
	This document defines terminology, problem statement and requirements		This document defines terminology, problem statement and requirements
	for implementing IKE and IPsec on clusters. It also describes gaps		for implementing IKE and IPsec on clusters. It also describes gaps
	in existing standards and their implementation that need to be		in existing standards and their implementation that need to be
	filled, in order to allow peers to interoperate with clusters from		filled, in order to allow peers to interoperate with clusters from
	different vendors. An agreed terminology, problem statement and		different vendors. An agreed terminology, problem statement and
	requirements will allow the IPSECME WG to consider development of		requirements will allow IETF working gropus to consider development
	IPsec/IKEv2 mechanisms to simplify cluster implementations.		of IPsec/IKEv2 mechanisms to simplify cluster implementations.
	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 December 30, 2010.		This Internet-Draft will expire on January 5, 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 2, line 25		skipping to change at page 2, line 25
	3.3. IKE Counters . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. IKE Counters . . . . . . . . . . . . . . . . . . . . . . . 6
	3.4. Outbound SA Counters . . . . . . . . . . . . . . . . . . . 6		3.4. Outbound SA Counters . . . . . . . . . . . . . . . . . . . 6
	3.5. Inbound SA Counters . . . . . . . . . . . . . . . . . . . 7		3.5. Inbound SA Counters . . . . . . . . . . . . . . . . . . . 7
	3.6. Missing Synch Messages . . . . . . . . . . . . . . . . . . 8		3.6. Missing Synch Messages . . . . . . . . . . . . . . . . . . 8
	3.7. Simultaneous use of IKE and IPsec SAs by Different		3.7. Simultaneous use of IKE and IPsec SAs by Different
	Members . . . . . . . . . . . . . . . . . . . . . . . . . 8		Members . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.7.1. Outbound SAs using counter modes . . . . . . . . . . . 9		3.7.1. Outbound SAs using counter modes . . . . . . . . . . . 9
	3.8. Different IP addresses for IKE and IPsec . . . . . . . . . 9		3.8. Different IP addresses for IKE and IPsec . . . . . . . . . 9
	3.9. Allocation of SPIs . . . . . . . . . . . . . . . . . . . . 10		3.9. Allocation of SPIs . . . . . . . . . . . . . . . . . . . . 10
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	IKEv2, as described in [RFC4306] and [IKEv2bis], and IPsec, as		IKEv2, as described in [RFC4306] and [IKEv2bis], and IPsec, as
	described in [RFC4301] and others, allows deployment of VPNs between		described in [RFC4301] and others, allows deployment of VPNs between
	different sites as well as from VPN clients to protected networks.		different sites as well as from VPN clients to protected networks.
	As VPNs become increasingly important to the organizations deploying		As VPNs become increasingly important to the organizations deploying
	them, there is a demand to make IPsec solutions more scalable and		them, there is a demand to make IPsec solutions more scalable and
	skipping to change at page 5, line 6		skipping to change at page 5, line 6
	cluster, this usually happens because of a failure of one of the		cluster, this usually happens because of a failure of one of the
	members, but certain load-balancing technologies may allow a		members, but certain load-balancing technologies may allow a
	particular load (such as all the flows associated with a particular		particular load (such as all the flows associated with a particular
	child SA) to move from one member to another to even out the load,		child SA) to move from one member to another to even out the load,
	even without any failures.		even without any failures.
	"Tight Cluster" is a cluster where all the members share an IP		"Tight Cluster" is a cluster where all the members share an IP
	address. This could be accomplished using configured interfaces with		address. This could be accomplished using configured interfaces with
	specialized protocols or hardware, such as VRRP, or through the use		specialized protocols or hardware, such as VRRP, or through the use
	of multicast addresses, but in any case, peers need only be		of multicast addresses, but in any case, peers need only be
	configured with one IP address in the PAD.		configured with one IP address in the Peer Authentication Database.
	"Loose Cluster" is a cluster where each member has a different IP		"Loose Cluster" is a cluster where each member has a different IP
	address. Peers find the correct member using some method such as DNS		address. Peers find the correct member using some method such as DNS
	queries or the IKEv2 redirect mechanism ([RFC5685]). In some cases,		queries or the IKEv2 redirect mechanism ([RFC5685]). In some cases,
	a member's IP address(es) may be allocated to another member at		a member's IP address(es) may be allocated to another member at
	failover.		failover.
	"Synch Channel" is a communications channel among the cluster		"Synch Channel" is a communications channel among the cluster
	members, used to transfer state information. The synch channel may		members, used to transfer state information. The synch channel may
	or may not be IP based, may or may not be encrypted, and may work		or may not be IP based, may or may not be encrypted, and may work
	skipping to change at page 8, line 35		skipping to change at page 8, line 35
	associated IPsec SAs will get dropped.		associated IPsec SAs will get dropped.
	The above scenario may be rare enough that it is acceptable that on a		The above scenario may be rare enough that it is acceptable that on a
	configuration with thousands of IKE SAs, a few will need to be		configuration with thousands of IKE SAs, a few will need to be
	recreated from scratch or using session resumption techniques.		recreated from scratch or using session resumption techniques.
	However, detecting this may take a long time (several minutes) and		However, detecting this may take a long time (several minutes) and
	this negates the goal of creating a cluster in the first place.		this negates the goal of creating a cluster in the first place.
	3.7. Simultaneous use of IKE and IPsec SAs by Different Members		3.7. Simultaneous use of IKE and IPsec SAs by Different Members
	For LS clusters, all active members may need to use the same SAs,		For load sharing clusters, all active members may need to use the
	both IKE and IPsec. This is an even greater problem than in the case		same SAs, both IKE and IPsec. This is an even greater problem than
	of HS clusters, because consecutive packets may need to be sent by		in the case of hot-standby clusters, because consecutive packets may
	different members to the same peer gateway.		need to be sent by different members to the same peer gateway.
	The solution to the IKE SA issue is up to the application. It's		The solution to the IKE SA issue is up to the implementation. It's
	possible to create some locking mechanism over the synch channel, or		possible to create some locking mechanism over the synch channel, or
	else have one member "own" the IKE SA and manage the child SAs for		else have one member "own" the IKE SA and manage the child SAs for
	all other members. For IPsec, solutions fall into two broad		all other members. For IPsec, solutions fall into two broad
	categories.		categories.
	The first is the "sticky" category, where all communications with a		The first is the "sticky" category, where all communications with a
	single peer, or all communications involving a certain SPD cache		single peer, or all communications involving a certain SPD cache
	entry go through a single peer. In this case, all packets that match		entry go through a single peer. In this case, all packets that match
	any particular SA go through the same member, so no synchronization		any particular SA go through the same member, so no synchronization
	of the replay counter needs to be done. Inbound processing is a		of the replay counter needs to be done. Inbound processing is a
	"sticky" issue, because the packets have to be processed by the		"sticky" issue (no pun intended), because the packets have to be
	correct member based on peer and SPI. Another issue is that most		processed by the correct member based on peer and SPI, and most load
	load balancers will not be able to match the SPIs of the encrypted		balancers will not be able to match the SPIs to the correct member,
	side to the clear traffic, and so the wrong member may get the the		unless stickyness extends to all traffic with a particular peer.
	other half of the flow.		Another disadvantage of sticky solutions, is that the load tends to
			not distribute evenly, especially if one SA covers a significant
			portion of IPsec traffic.
	The second is the "duplicate" category, where the child SA is		The second is the "duplicate" category, where the child SA is
	duplicated for each pair of IPsec SAs for each active member.		duplicated for each pair of IPsec SAs for each active member.
	Different packets for the same peer go through different members, and		Different packets for the same peer go through different members, and
	get protected using different SAs with the same selectors and		get protected using different SAs with the same selectors and
	matching the same entries in the SPD cache. This has some		matching the same entries in the SPD cache. This has some
	shortcomings:		shortcomings:
	o It requires multiple parallel SAs, which the peer has no use for.		o It requires multiple parallel SAs, which the peer has no use for.
	Section 2.8 or [RFC4306] specifically allows this, but some		Section 2.8 of [RFC4306] specifically allows this, but some
	implementation might have a policy against long term maintenance		implementation might have a policy against long term maintenance
	of redundant SAs.		of redundant SAs.
	o Different packets that belong to the same flow may be protected by		o Different packets that belong to the same flow may be protected by
	different SAs, which may seem "weird" to the peer gateway,		different SAs, which may seem "weird" to the peer gateway,
	especially if it is integrated with some deep inspection		especially if it is integrated with some deep inspection
	middleware such as a firewall. It is not known whether this will		middleware such as a firewall. It is not known whether this will
	cause problems with current gateways. It is also impossible to		cause problems with current gateways. It is also impossible to
	mandate against this, because the definition of "flow" varies from		mandate against this, because the definition of "flow" varies from
	one implementation to another.		one implementation to another.
	o Reply packets may arrive with an IPsec SA that is not "matched" to		o Reply packets may arrive with an IPsec SA that is not "matched" to
	skipping to change at page 9, line 48		skipping to change at page 9, line 50
	active member, or even failing over from one member to another need		active member, or even failing over from one member to another need
	to make sure that they do not generate the same initial vector. See		to make sure that they do not generate the same initial vector. See
	[COUNTER_MODES] for a discussion of this problem in another context.		[COUNTER_MODES] for a discussion of this problem in another context.
	3.8. Different IP addresses for IKE and IPsec		3.8. Different IP addresses for IKE and IPsec
	In many implementations there are separate IP addresses for the		In many implementations there are separate IP addresses for the
	cluster, and for each member. While the packets protected by tunnel		cluster, and for each member. While the packets protected by tunnel
	mode child SAs are encapsulated in IP headers with the cluster IP		mode child SAs are encapsulated in IP headers with the cluster IP
	address, the IKE packets originate from a specific member, and carry		address, the IKE packets originate from a specific member, and carry
	that member's IP address. For the peer, this looks weird, as the		that member's IP address. This may be done so that IPsec traffic
	usual thing is for the IPsec packets to come from the same IP address		bypasses the load balancer for greater scalability. For the peer,
	as the IKE packets.		this looks weird, as the usual thing is for the IPsec packets to come
			from the same IP address as the IKE packets. Unmodified peers may
			drop such packets.
	One obvious solution is to use some fancy capability of the IKE host		One obvious solution is to use some fancy capability of the IKE host
	to change things so that IKE packets also come out of the cluster IP		to change things so that IKE packets also come out of the cluster IP
	address. This can be achieved through NAT or through assigning		address. This can be achieved through NAT or through assigning
	multiple addresses to interfaces. This is not, however, possible for		multiple addresses to interfaces. This is not, however, possible for
	all implementations.		all implementations, and will not reduce load on the balancer.
	[ARORA] discusses this problem in greater depth, and proposes another		[ARORA] discusses this problem in greater depth, and proposes another
	solution, that does involve protocol changes.		solution, that does involve protocol changes.
	3.9. Allocation of SPIs		3.9. Allocation of SPIs
	The SPI associated with each child SA, and with each IKE SA, MUST be		The SPI associated with each child SA, and with each IKE SA, MUST be
	unique relative to the peer of the SA. Thus, in the context of a		unique relative to the peer of the SA. Thus, in the context of a
	cluster, each cluster member MUST generate SPIs in a fashion that		cluster, each cluster member MUST generate SPIs in a fashion that
	avoids collisions (with other cluster members) for these SPI values.		avoids collisions (with other cluster members) for these SPI values.
	skipping to change at page 10, line 39		skipping to change at page 10, line 42
	Moreover, thought must be given to the synching requirements of any		Moreover, thought must be given to the synching requirements of any
	protocol extension, to make sure that it does not create an		protocol extension, to make sure that it does not create an
	opportunity for denial of service attacks on the cluster.		opportunity for denial of service attacks on the cluster.
	As mentioned in Section 3.5, allowing an inbound child SA to fail		As mentioned in Section 3.5, allowing an inbound child SA to fail
	over to another member has the effect of disabling replay counter		over to another member has the effect of disabling replay counter
	protection for a short time. Though the threat is arguably low, it		protection for a short time. Though the threat is arguably low, it
	is a policy decision whether this is acceptable.		is a policy decision whether this is acceptable.
			Section 3.7 describes the problem of the two directions of a flow
			being protected by two SAs which are not part of a matched pair, or
			even not being processed by the same cluster member. This is not a
			security problem as far as IPsec is concerned, because IPsec has
			policy at the IP, protocol and port level only. However, many IPsec
			implementations are integrated with stateful firewalls, which need to
			see both sides of a flow. Such implementations may have to forward
			packets to other members for the firewall to properly inspect the
			traffic.
	5. IANA Considerations		5. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	6. Acknowledgements		6. Acknowledgements
	This document is the collective work, and includes contribution from		This document is the collective work, and includes contribution from
	many people who participate in the IPsecME working group.		many people who participate in the IPsecME working group.
	The editor would particularly like to acknowledge the extensive		The editor would particularly like to acknowledge the extensive
	contribution of the following people (in alphabetical order):		contribution of the following people (in alphabetical order):
			Jitender Arora, Jean-Michel Combes, Dan Harkins, David Harrington,
	Jitender Arora, Jean-Michel Combes, Dan Harkins, Steve Kent, Tero		Steve Kent, Tero Kivinen, Alexey Melnikov, Yaron Sheffer, Melinda
	Kivinen, Yaron Sheffer, Melinda Shore, and Rodney Van Meter.		Shore, and Rodney Van Meter.
	7. Change Log		7. Change Log
	NOTE TO RFC EDITOR: REMOVE THIS SECTION BEFORE PUBLICATION		NOTE TO RFC EDITOR: REMOVE THIS SECTION BEFORE PUBLICATION
	Version 00 was identical to draft-nir-ipsecme-ipsecha-ps-00, re-spun		Version 00 was identical to draft-nir-ipsecme-ipsecha-ps-00, re-spun
	as an WG document.		as an WG document.
	Version 01 included closing issues 177, 178 and 180, with updates to		Version 01 included closing issues 177, 178 and 180, with updates to
	terminology, and added discussion of inbound SAs and the CTR issue.		terminology, and added discussion of inbound SAs and the CTR issue.
	skipping to change at page 11, line 30		skipping to change at page 11, line 42
	Version 03 fixes some ID-nits, and adds the problem presented by		Version 03 fixes some ID-nits, and adds the problem presented by
	Jitender Arora in [ARORA].		Jitender Arora in [ARORA].
	Version 04 fixes a spelling mistake, moves the scope discussion to a		Version 04 fixes a spelling mistake, moves the scope discussion to a
	subsection of its own (Section 3.1), and adds a short discussion of		subsection of its own (Section 3.1), and adds a short discussion of
	the duplicate SPI problem, presented by Jean-Michel Combes.		the duplicate SPI problem, presented by Jean-Michel Combes.
	Versions 05, 06 and 07 just corrected nits and notation		Versions 05, 06 and 07 just corrected nits and notation
			Versions 08 and 09 include suggestions from the IETF last call.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
End of changes. 16 change blocks.
	28 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/