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.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/