< draft-ietf-ipsecme-ad-vpn-problem-05.txt		draft-ietf-ipsecme-ad-vpn-problem-06.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: October 11, 2013 HP		Expires: October 24, 2013 HP
	April 09, 2013		April 22, 2013
	Auto Discovery VPN Problem Statement and Requirements		Auto Discovery VPN Problem Statement and Requirements
	draft-ietf-ipsecme-ad-vpn-problem-05		draft-ietf-ipsecme-ad-vpn-problem-06
	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 October 11, 2013.		This Internet-Draft will expire on October 24, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 8, line 21 ¶		skipping to change at page 8, line 21 ¶
	IPsec tunnels.		IPsec tunnels.
	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 ADVPN peer MUST NOT be able to impersonate another ADVPN		5. Any of the ADVPN Peers MUST NOT have a way to get the long term
	peer.		authentication credentials for any other ADVPN Peers. The compromise
			of an Endpoint MUST NOT affect the security of communications between
			other ADVPN Peers. The compromise of a Gateway SHOULD NOT affect the
			security of the communications between ADVPN Peers not associated
			with that Gateway.
	This requirement is driven by use case 2.1. ADVPN peers (especially		This requirement is driven by use case 2.1. ADVPN Peers (especially
	spokes) become compromised fairly often. The compromise of one ADVPN		Spokes) become compromised fairly often. The compromise of one ADVPN
	peer SHOULD NOT affect the security of other peers.		Peer SHOULD NOT affect the security of other unrelated ADVPN Peers.
	6. Gateways SHOULD allow for seamless handoff of sessions in case		6. Gateways SHOULD allow for seamless handoff of sessions in case
	endpoints are roaming, even if they cross policy boundaries. This		endpoints are roaming, even if they cross policy boundaries. This
	would mean the data traffic is minimally affected even as the handoff		would mean the data traffic is minimally affected even as the handoff
	happens. External factors like firewall, NAT boxes will not be		happens. External factors like firewall, NAT boxes will not be
	considered part of this solution.		considered part of this solution.
	Such endpoint roaming may affect not only the endpoint-to-endpoint SA		Such endpoint roaming may affect not only the endpoint-to-endpoint SA
	but also the relationship between the endpoints and gateways (such as		but also the relationship between the endpoints and gateways (such as
	when an endpoint roams to a new network that is handled by a		when an endpoint roams to a new network that is handled by a
End of changes. 5 change blocks.
	9 lines changed or deleted		13 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/