< draft-ietf-ipsecme-ad-vpn-problem-01.txt		draft-ietf-ipsecme-ad-vpn-problem-02.txt >
	IPsecME Working Group S. Hanna		IPsecME Working Group S. Hanna
	Internet-Draft Juniper		Internet-Draft Juniper
	Intended status: Informational V. Manral		Intended status: Informational V. Manral
	Expires: May 30, 2013 HP		Expires: June 10, 2013 HP
	November 26, 2012		December 7, 2012
	Auto Discovery VPN Problem Statement and Requirements		Auto Discovery VPN Problem Statement and Requirements
	draft-ietf-ipsecme-ad-vpn-problem-01		draft-ietf-ipsecme-ad-vpn-problem-02
	Abstract		Abstract
	This document describes the problem of enabling a large number of		This document describes the problem of enabling a large number of
	systems to communicate directly using IPsec to protect the traffic		systems to communicate directly using IPsec to protect the traffic
	between them. It then expands on the requirements, for such a		between them. It then expands on the requirements, for such a
	solution.		solution.
	Manual configuration of all possible tunnels is too cumbersome in		Manual configuration of all possible tunnels is too cumbersome in
	many such cases. In other cases the IP address of endpoints change		many such cases. In other cases the IP address of endpoints change
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 May 30, 2013.		This Internet-Draft will expire on June 10, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 5, line 33 ¶		skipping to change at page 5, line 33 ¶
	The need for secure endpoint to endpoint communications is often		The need for secure endpoint to endpoint communications is often
	driven by a need to employ high-bandwidth, low latency local		driven by a need to employ high-bandwidth, low latency local
	connectivity instead of using slow, expensive links to remote		connectivity instead of using slow, expensive links to remote
	gateways. For example, two users in close proximity may wish to		gateways. For example, two users in close proximity may wish to
	place a direct, secure video or voice call without needing to send		place a direct, secure video or voice call without needing to send
	the call through remote gateways, which would add latency to the		the call through remote gateways, which would add latency to the
	call, consume precious remote bandwidth, and increase overall costs.		call, consume precious remote bandwidth, and increase overall costs.
	Such a use case also enables connectivity when both endpoints are		Such a use case also enables connectivity when both endpoints are
	behind NAT gateways. Such use case should allow for seamless		behind NAT gateways. Such use case should allow for seamless
	connectivity even as endpoints roam, even if they are moving out from		connectivity even as endpoints roam, even if they are moving out from
	behind a gateway, from behind one gateway to behind another, or from		behind a NAT gateway, from behind one NAT gateway to behind another,
	a standalone position to behind a gateway.		or from a standalone position to behind a NAT gateway.
	In a hub and spoke topology when two endpoints communicate, they must		In a hub and spoke topology when two endpoints communicate, they must
	use a mechanism for authentication, such that they do not expose them		use a mechanism for authentication, such that they do not expose them
	to impersonation by the other spoke endpoint.		to impersonation by the other spoke endpoint.
	2.2. Gateway-to-Gateway AD VPN Use Case		2.2. Gateway-to-Gateway AD VPN Use Case
	A typical Enterprise traffic model follows a star topology, with the		A typical Enterprise traffic model follows a star topology, with the
	gateways connecting to each other using IPsec tunnels.		gateways connecting to each other using IPsec tunnels.
	However for the voice and other rich media traffic that requires a		However for the voice and other rich media traffic that requires a
	lot of bandwidth or is performance sensitive, the traffic tromboning		lot of bandwidth or is performance sensitive, the traffic tromboning
	to the hub can create traffic bottlenecks on the hub and can lead to		to the hub can create traffic bottlenecks on the hub and can lead to
	an increase in cost. A fully meshed solution is would make best use		an increase in cost. A fully meshed solution is would make best use
	of the available network capacity and performance but the deployment		of the available network capacity and performance but the deployment
	of a fully meshed solution involves considerable configuration,		of a fully meshed solution involves considerable configuration,
	especially when a large number of nodes are involved. For the		especially when a large number of nodes are involved. It is for this
	reasons of cost and manual error reduction, it is desired that there		purpose spoke-to-spoke tunnels are dynamically created and torn-down.
	be minimal configuration on each gateway.
			For the reasons of cost and manual error reduction, it is desired
			that there be minimal configuration on each gateway.
	The solution should work in cases where the endpoints are		The solution should work in cases where the endpoints are
	administrated by separate management domains, albeit, ones that have		administrated by separate management domains, albeit, ones that have
	an existing trust relationship (for example two organisations who are		an existing trust relationship (for example two organisations who are
	collaborating on a project, they may wish to join their networks,		collaborating on a project, they may wish to join their networks,
	whilst retaining independent control over configuration)It is for		whilst retaining independent control over configuration). It is
	this purpose spoke-to-spoke tunnels are dynamically created and torn-		highly desirable that the solution works for the star, full mesh as
	down. It is highly desirable that the solution works for the star,		well as dynamic full mesh topology.
	full mesh as well as dynamic full mesh topology.
	The gateways can themselves come up and down, getting different IP		The solution should also address the case where gateways use dynamic
	addresses in the process, making static configuration impossible.		IP addresses.
			Additionally, the routing implications of gateway-to-gateway
			communication must be addressed. In the simple case, selectors
			provide sufficient information for a gateway to forward traffic
			appropriately. In other cases, additional tunneling (e.g., GRE) and
			routing (e.g., OSPF) protocols are run over IPsec tunnels, and the
			configuration impact on those protocols must be considered. There is
			also the case when L3VPNs operate over IPsec Tunnels.
	When two gateways communicate, they must use a mechanism for		When two gateways communicate, they must use a mechanism for
	authentication, such that they do not expose themselves to the risk		authentication, such that they do not expose themselves to the risk
	of impersonation by the other entities.		of impersonation by the other entities.
	2.3. Endpoint-to-Gateway AD VPN Use Case		2.3. Endpoint-to-Gateway AD VPN Use Case
	An endpoint should be able to use the most efficient gateway as it		An endpoint should be able to use the most efficient gateway as it
	roams in the internet.		roams in the internet.
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 35 ¶
	The most common way to address a part of this this problem today is		The most common way to address a part of this this problem today is
	to use what has been termed a "star topology". In this case one or a		to use what has been termed a "star topology". In this case one or a
	few gateways are defined as "hub gateways", while the rest of the		few gateways are defined as "hub gateways", while the rest of the
	systems (whether endpoints or gateways) are defined as "spokes". The		systems (whether endpoints or gateways) are defined as "spokes". The
	spokes never connect to other spokes. They only open tunnels with		spokes never connect to other spokes. They only open tunnels with
	the hub gateways. Also for a large number of gateways in one		the hub gateways. Also for a large number of gateways in one
	administrative domain, one gateway may be defined as the hub, and the		administrative domain, one gateway may be defined as the hub, and the
	rest of the gateways and remote access clients connect only to that		rest of the gateways and remote access clients connect only to that
	gateway.		gateway.
	This solution however does not work when the spokes get dynamic IP		This solution however is complicated by the case when the spokes use
	address which the "hub gateways" cannot be configured with. It is		dynamic IP addresses and DNS with dynamic updates must be used. It
	also desired that there is minimal to no configuration on the hub as		is also desired that there is minimal to no configuration on the hub
	the number of spokes increases and new spokes are added and deleted		as the number of spokes increases and new spokes are added and
	randomly.		deleted randomly.
	Another problem with the star topology is that it creates a high load		Another problem with the star topology is that it creates a high load
	on the hub gateways as well as on the connection between the spokes		on the hub gateways as well as on the connection between the spokes
	and the hub. This load is both in processing power and in network		and the hub. This load is both in processing power and in network
	bandwidth. A single packet in the hub-and-spoke scenario can be		bandwidth. A single packet in the hub-and-spoke scenario can be
	encrypted and decrypted multiple times. It would be much preferable		encrypted and decrypted multiple times. It would be much preferable
	if these gateways and clients could initiate tunnels between them,		if these gateways and clients could initiate tunnels between them,
	bypassing the hub gateways. Additionally, the path bandwidth to		bypassing the hub gateways. Additionally, the path bandwidth to
	these hub gateways may be lower than that of the path between the		these hub gateways may be lower than that of the path between the
	spokes. For example, two remote access users may be in the same		spokes. For example, two remote access users may be in the same
	skipping to change at page 9, line 40 ¶		skipping to change at page 9, line 40 ¶
	2. Gateways and endpoints MUST allow IPsec Tunnels to be setup		2. Gateways and endpoints MUST allow IPsec Tunnels to be setup
	without any configuration changes, even when peer addresses get		without any configuration changes, even when peer addresses get
	updated every time the device comes up. This implies that SPD		updated every time the device comes up. This implies that SPD
	entries or other configuration based on peer IP address will need to		entries or other configuration based on peer IP address will need to
	be automatically updated, avoided, or handled in some manner to avoid		be automatically updated, avoided, or handled in some manner to avoid
	a need to manually update policy whenever an address changes.		a need to manually update policy whenever an address changes.
	This requirement is driven by use cases 2.1 and 2.2 and by the		This requirement is driven by use cases 2.1 and 2.2 and by the
	scaling limitations pointed out in section 3.1.		scaling limitations pointed out in section 3.1.
	3. In many cases additional tunneling protocols (i.e. GRE) or		3. In many cases additional tunneling protocols (e.g. GRE) or
	Routing protocols (i.e. OSPF) are run over the IPsec tunnels.		Routing protocols (e.g. OSPF) are run over the IPsec tunnels.
	Gateways MUST allow for the operation of tunneling and Routing		Gateways MUST allow for the operation of tunneling and Routing
	protocols operating over spoke-to-spoke IPsec Tunnels with minimal or		protocols operating over spoke-to-spoke IPsec Tunnels with minimal or
	no, configuration impact. Routing using the tunnels can work		no, configuration impact. The ADVPN solution SHOULD NOT increase the
	seamlessly without any updates to the higher level application		amount of information required to configure protocols running over
	configuration i.e. OSPF configuration, when the tunnel parameter		IPsec tunnels.
	changes.
	4. In the full mesh and dynamic full mesh topology, Spokes MUST		4. In the full mesh and dynamic full mesh topology, Spokes MUST
	allow for direct communication with other spoke gateways and		allow for direct communication with other spoke gateways and
	endpoints. In the star topology mode, direct communication between		endpoints. In the star topology mode, direct communication between
	spokes MUST be disallowed.		spokes MUST be disallowed.
	This requirement is driven by use cases 2.1 and 2.2 and by the		This requirement is driven by use cases 2.1 and 2.2 and by the
	limitations of a star topology pointed out in section 3.2.		limitations of a star topology pointed out in section 3.2.
	5. One spoke MUST NOT be able to impersonate another spoke.		5. One spoke MUST NOT be able to impersonate another spoke.
	skipping to change at page 14, line 13 ¶		skipping to change at page 14, line 13 ¶
	No actions are required from IANA for this informational document.		No actions are required from IANA for this informational document.
	7. Acknowledgements		7. Acknowledgements
	Many people have contributed to the development of this problem		Many people have contributed to the development of this problem
	statement and many more will probably do so before we are done with		statement and many more will probably do so before we are done with
	it. While we cannot thank all contributors, some have played an		it. While we cannot thank all contributors, some have played an
	especially prominent role. Yoav Nir, Yaron Scheffer, Jorge Coronel		especially prominent role. Yoav Nir, Yaron Scheffer, Jorge Coronel
	Mendoza, Chris Ulliott, and John Veizades wrote the document upon		Mendoza, Chris Ulliott, and John Veizades wrote the document upon
	which this draft was based. Geoffrey Huang, Suresh Melam, Praveen		which this draft was based. Geoffrey Huang, Suresh Melam, Praveen
	Sathyanarayan, Andreas Steffen, and Brian Weis provided essential		Sathyanarayan, Andreas Steffen, Brian Weis, and Lou Berger provided
	input.		essential input.
	8. Normative References		8. 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.
	Authors' Addresses		Authors' Addresses
End of changes. 11 change blocks.
	28 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/