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