< draft-ietf-ipsecme-ad-vpn-problem-02.txt   draft-ietf-ipsecme-ad-vpn-problem-03.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: June 10, 2013 HP Expires: June 20, 2013 HP
December 7, 2012 December 17, 2012
Auto Discovery VPN Problem Statement and Requirements Auto Discovery VPN Problem Statement and Requirements
draft-ietf-ipsecme-ad-vpn-problem-02 draft-ietf-ipsecme-ad-vpn-problem-03
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 June 10, 2013. This Internet-Draft will expire on June 20, 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 48 skipping to change at page 5, line 48
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 would make best use of
of the available network capacity and performance but the deployment the available network capacity and performance but the deployment of
of a fully meshed solution involves considerable configuration, a fully meshed solution involves considerable configuration,
especially when a large number of nodes are involved. It is for this especially when a large number of nodes are involved. It is for this
purpose spoke-to-spoke tunnels are dynamically created and torn-down. purpose spoke-to-spoke tunnels are dynamically created and torn-down.
For the reasons of cost and manual error reduction, it is desired For the reasons of cost and manual error reduction, it is desired
that there be minimal configuration on each gateway. 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,
skipping to change at page 9, line 7 skipping to change at page 9, line 7
Several vendors offer proprietary solutions to these problems. Several vendors offer proprietary solutions to these problems.
However, these solutions offer no interoperability between equipment However, these solutions offer no interoperability between equipment
from one vendor and another. This means that they are generally from one vendor and another. This means that they are generally
restricted to use within one organization, and it is harder to move restricted to use within one organization, and it is harder to move
off such solutions as the features are not standardized. Besides off such solutions as the features are not standardized. Besides
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 sectiondefines 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 MUST minimize configuration changes when a new gateways and endpoints SHOULD minimize configuration changes when a
gateway or endpoint is added, removed or changed. Adding or removing new gateway or endpoint is added, removed or changed. Adding or
a spoke in the topology MUST NOT require configuration changes to the removing a spoke in the topology MUST NOT require configuration
hubs other than where the spoke was connected to and SHOULD NOT changes to the hubs other than where the spoke was connected to and
require configuration changes to the hub the spoke was connected to. SHOULD NOT require configuration changes to the hub the spoke was
The changes also MUST NOT require configuration changes in other connected to. The changes also MUST NOT require configuration
spokes. changes in other 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 30 skipping to change at page 10, line 30
This requirement is driven by use case 2.1. Today's endpoints are This requirement is driven by use case 2.1. Today's endpoints are
mobile and transition often between different networks (from 4G to mobile and transition often between different networks (from 4G to
WiFi and among various WiFi networks). WiFi and among various WiFi networks).
7. Gateways SHOULD allow for easy handoff of a session to another 7. Gateways SHOULD allow for easy handoff of a session to another
gateway, to optimize latency, bandwidth, load balancing, gateway, to optimize latency, bandwidth, load balancing,
availability, or other factors, based on policy. availability, or other factors, based on policy.
This requirement is driven by use case 2.3. This requirement is driven by use case 2.3.
8. Gateways and endpoints MUST be able to work when they are behind 8. Gateways and endpoints MUST have the capability to participate in
NAT boxes. It is especially difficult to handle cases where the Hub an AD VPN even when they are located behind NAT boxes. However, in
is behind a NAT box, such a requirement MAY be supported. Where the some cases they may be deployed in such a way that they will not be
two endpoints are both behind separate NATs, communication between fully reachable behind a NAT box. It is especially difficult to
these spokes SHOULD be supported. In the cases, workarounds MAY be handle cases where the Hub is behind a NAT box. Where the two
used such as port forwarding by the NAT or detecting when two spokes endpoints are both behind separate NATs, communication between these
are behind uncooperative NATs and using a hub in that case. spokes SHOULD be supported using workarounds such as port forwarding
by the NAT or detecting when two spokes are behind uncooperative NATs
and using a hub in that case.
This requirement is driven by use cases 2.1 and 2.2. Endpoints are This requirement is driven by use cases 2.1 and 2.2. Endpoints are
often behind NATs and gateways sometimes are. IPsec should continue often behind NATs and gateways sometimes are. IPsec should continue
to work seamlessly regardless, using AD VPN techniques whenever to work seamlessly regardless, using AD VPN techniques whenever
possible and providing graceful fallback to hub and spoke techniques possible and providing graceful fallback to hub and spoke techniques
as needed. as needed.
9. Changes such as establishing a new IPsec SA SHOULD be reportable 9. Changes such as establishing a new IPsec SA SHOULD be reportable
and manageable. However, creating a MIB or other management and manageable. However, creating a MIB or other management
technique is not within scope for this effort. technique is not within scope for this effort.
skipping to change at page 11, line 27 skipping to change at page 11, line 29
This requirement is driven by the use case 2.2, where the amount of This requirement is driven by the use case 2.2, where the amount of
rich media multicast traffic is increasing. rich media multicast traffic is increasing.
13. The ADVPN solution SHOULD allow for easy monitoring, logging and 13. The ADVPN solution SHOULD allow for easy monitoring, logging and
reporting of the dynamic changes, to help for trouble shooting such reporting of the dynamic changes, to help for trouble shooting such
environments. environments.
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.
14. The ADVPN solution MUST support Provider Edge (PE) based VPN's. 14. There is also the case when L3VPNs operate over IPsec Tunnels,
for example Provider Edge (PE) based VPN's. An ADVPN MUST support
L3VPN as an application protected by the IPsec Tunnels.
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 state and requirement document for the ADVPN
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
dynamic updates to databases defined by RFC 4301, such as the dynamic updates to databases defined by RFC 4301, such as the
Security Policy Database (SPD) or the Peer Authorization Database Security Policy Database (SPD) or the Peer Authorization Database
(PAD). (PAD).
RFC 4301 is silent about the way these databases are populated, and RFC 4301 is silent about the way these databases are populated, and
it is implied that these databases are static and pre-configured by a it is implied that these databases are static and pre-configured by a
human. Allowing dynamic updates to these databases must be thought human. Allowing dynamic updates to these databases must be thought
out carefully, because it allows the protocol to alter the security out carefully, because it allows the protocol to alter the security
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.
More to be added.
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 Scheffer, 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, Suresh Melam, Praveen
Sathyanarayan, Andreas Steffen, Brian Weis, and Lou Berger provided Sathyanarayan, Andreas Steffen, Brian Weis, and Lou Berger provided
essential 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.
 End of changes. 11 change blocks. 
26 lines changed or deleted 30 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/