draft-ietf-ipsecme-ad-vpn-problem-08.txt   draft-ietf-ipsecme-ad-vpn-problem-09.txt 
IPsecME Working Group S. Hanna IPsecME Working Group V. Manral
Internet-Draft Juniper Internet-Draft HP
Intended status: Informational V. Manral Intended status: Informational S. Hanna
Expires: January 14, 2014 HP Expires: January 17, 2014 Juniper
July 13, 2013 July 16, 2013
Auto Discovery VPN Problem Statement and Requirements Auto Discovery VPN Problem Statement and Requirements
draft-ietf-ipsecme-ad-vpn-problem-08 draft-ietf-ipsecme-ad-vpn-problem-09
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 January 14, 2014. This Internet-Draft will expire on January 17, 2014.
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 7, line 36 skipping to change at page 7, line 36
multiple organizations cannot be expected to all choose the same multiple organizations cannot be expected to all choose the same
equipment vendor. equipment vendor.
4. Requirements 4. Requirements
This section defines the requirements, on which the solution will be This section defines the requirements, on which the solution will be
based. based.
4.1. Gateway and Endpoint Requirements 4.1. Gateway and Endpoint Requirements
1. For any network topology (star, full mesh and dynamic full mesh) 1. For any network topology (star, full mesh and dynamic full mesh),
gateways and endpoints needs to minimize configuration changes when a when a new gateway or endpoint is added, removed, or changed,
new gateway or endpoint is added, removed or changed. Adding or configuration changes are minimized as follows. Adding or removing a
removing a spoke in the topology MUST NOT require configuration spoke in the topology MUST NOT require configuration changes to the
changes to the hubs other than where the spoke was connected to and hubs other than where the spoke was connected to and SHOULD NOT
SHOULD NOT require configuration changes to the hub the spoke was require configuration changes to the hub the spoke was connected to.
connected to. The changes also MUST NOT require configuration The changes also MUST NOT require configuration changes in other
changes in other spokes. spokes.
Specifically, when evaluating potential proposals, we will compare Specifically, when evaluating potential proposals, we will compare
them by looking at how many endpoints or gateways must be them by looking at how many endpoints or gateways must be
reconfigured when a new gateway or endpoint is added, removed, or reconfigured when a new gateway or endpoint is added, removed, or
changed and how substantial this reconfiguration is, besides the changed and how substantial this reconfiguration is, besides the
amount of static configuration required. amount of static configuration required.
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.
skipping to change at page 10, line 41 skipping to change at page 10, line 41
This requirement is driven by demand for all the use cases in This requirement is driven by demand for all the use cases in
federated and allied environments. federated and allied environments.
15. There ADVPN solution SHOULD allow the enforcement of per peer 15. There ADVPN solution SHOULD allow the enforcement of per peer
QoS in both the Star as well as the Full Mesh topology. QoS in both the Star as well as the Full Mesh topology.
This requirement is driven by demand for all the use cases in This requirement is driven by demand for all the use cases in
federated and allied environments. federated and allied environments.
16. There ADVPN solution SHOULD take care of now letting the Hub to 16. There ADVPN solution SHOULD take care of not letting the Hub to
be a single point of failure. be a single point of failure.
This requirement is driven by demand for all the use cases in This requirement is driven by demand for all the use cases in
federated and allied environments. federated and allied environments.
5. Security Considerations 5. Security Considerations
This is a Problem statement and requirement document for the ADVPN This is a Problem statement and requirement document for the ADVPN
solution, and in itself does not introduce any new security concerns. solution, and in itself does not introduce any new security concerns.
The solution to the problems presented in this draft may involve The solution to the problems presented in this draft may involve
skipping to change at page 11, line 21 skipping to change at page 11, line 21
policy that the IPsec endpoints implement. policy that the IPsec endpoints implement.
One obvious attack to watch out for is stealing traffic to a One obvious attack to watch out for is stealing traffic to a
particular site. The IP address for www.example.com is 192.0.2.10. particular site. The IP address for www.example.com is 192.0.2.10.
If we add an entry to an IPsec endpoint's SPD that says that traffic If we add an entry to an IPsec endpoint's SPD that says that traffic
to 192.0.2.10 is protected through peer Gw-Mallory, then this allows to 192.0.2.10 is protected through peer Gw-Mallory, then this allows
Gw-Mallory to either pretend to be www.example.com or to proxy and Gw-Mallory to either pretend to be www.example.com or to proxy and
read all traffic to that site. Updates to this database requires a read all traffic to that site. Updates to this database requires a
clear trust model. clear trust model.
Hubs can be a single point of failure and the solutions that Hubs can be a single point of failure which can cause loss of
connectivity of the entire system, that can be a big security issue.
Any ADVPN solution design should take care of these concerns.
6. IANA Considerations 6. IANA Considerations
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 Sheffer, Jorge Coronel especially prominent role. Yoav Nir, Yaron Sheffer, 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, Toby Mao, Suresh Melam,
Sathyanarayan, Andreas Steffen, Brian Weis, and Lou Berger provided Praveen Sathyanarayan, Andreas Steffen, Brian Weis, and Lou Berger
essential input. provided 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
Steve Hanna
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
Email: shanna@juniper.net
Vishwas Manral Vishwas Manral
Hewlett-Packard Co. Hewlett-Packard Co.
19111 Pruneridge Ave. 19111 Pruneridge Ave.
Cupertino, CA 95113 Cupertino, CA 95113
USA USA
Email: vishwas.manral@hp.com Email: vishwas.manral@hp.com
Steve Hanna
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
Email: shanna@juniper.net
 End of changes. 9 change blocks. 
28 lines changed or deleted 22 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/