One document matched: draft-ietf-ipsecme-ad-vpn-problem-09.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc ipr="trust200902" docName="draft-ietf-ipsecme-ad-vpn-problem-09" category="info">
<front>
<title abbrev="Auto Discovery VPN">Auto Discovery VPN Problem Statement and Requirements</title>
<author initials="V." surname="Manral" fullname="Vishwas Manral">
<organization abbrev="HP">Hewlett-Packard Co.</organization>
<address>
<postal>
<street>19111 Pruneridge Ave.</street>
<city>Cupertino</city>
<region>CA</region>
<code>95113</code>
<country>USA</country>
</postal>
<email>vishwas.manral@hp.com</email>
</address>
</author>
<author initials="S." surname="Hanna" fullname="Steve Hanna">
<organization abbrev="Juniper">Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>shanna@juniper.net</email>
</address>
</author>
<date year="2013"/>
<area>Security Area</area>
<workgroup>IPsecME Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t> This document describes the problem of enabling a large number
of systems to communicate directly using IPsec to protect the traffic
between them. It then expands on the requirements, for such a solution. </t>
<t> Manual configuration of all possible tunnels is too
cumbersome in many such cases. In other cases the IP address of endpoints
change or the endpoints may be behind NAT gateways, making
static configuration impossible. The Auto Discovery VPN solution will
address these requirements. </t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t> IPsec <xref target="RFC4301"/> is used in several different cases, including tunnel-mode
site-to-site VPNs and Remote Access VPNs. Both tunneling modes for IPsec gateways and
host-to-host transport mode are supported in this document. </t>
<t> The subject of this document is the problem presented by large
scale deployments of IPsec and the requirements on a solution to address the problem.
These may be a large collection of
VPN gateways connecting various sites, a large number of remote endpoints
connecting to a number of gateways or to each other, or a mix of the two.
The gateways and endpoints may belong to a single administrative domain
or several domains with a trust relationship.</t>
<t> Section 4.4 of RFC 4301 describes the major IPsec databases needed for IPsec processing.
It requires an extensive configuration for each tunnel, so manually
configuring a system of many gateways and endpoints becomes infeasible
and inflexible.</t>
<t> The difficulty is that a lot of configuration mentioned in RFC 4301 is required to set up a Security Association.
IKE implementations need to know the identity and credentials of all possible peer
systems, as well as the addresses of hosts and/or networks behind them. A simplified
mechanism for dynamically establishing point-to-point tunnels is
needed. <xref target="usecases"/> contains
several use cases that motivate this effort.</t>
<section anchor="terminology" title="Terminology">
<t> ADVPN - Auto Discovery Virtual Private Network (ADVPN) is VPN solution that enables a
large number of systems to communicate directly, with minimal configuration and operator
intervention using IPsec to protect communication between them. </t>
<t>Endpoint - A device that implements IPsec for its own traffic
but does not act as a gateway.</t>
<t>Gateway - A network device that implements IPsec to protect
traffic flowing through the device.</t>
<t>Point-to-Point - Communication between two parties without
active participation (e.g. encryption or decryption) by
any other parties.</t>
<t> Hub - The central point in a star topology/ dynamic full mesh topology, or one of the
central points in the full mesh style VPN, i.e. gateway where multiple other hubs or
spokes connect to. The hubs usually forward traffic coming from encrypted links to
other encrypted links, i.e. there are no devices connected to it in clear.</t>
<t> Spoke - The endpoint in a star topology/ dynamic full mesh topology, or gateway
which forwards traffic from multiple cleartext devices to other hubs or spokes, and some of those
other devices are connected to it in clear (i.e. it encrypts data coming from cleartext devices
and forwards it to the ADVPN).</t>
<t> ADVPN Peer - any member of an ADVPN including gateways, endpoints, hub or spoke. </t>
<t> Star topology - This is the topology where there is direct connectivity only between the
hub and spoke and communication between the 2 spokes happens through the hub. </t>
<t> Allied and Federated Environments - Environments where we have multiple different organizations
that have close association and need to connect to each other.
</t>
<t> Full Mesh topology -
This is the topology where there is a direct connectivity between
every Spoke to every other Spoke directly, without the traffic between the spokes having to
be redirected through an intermediate hub device. </t>
<t> Dynamic Full Mesh topology - This is the topology where direct connections exist
in a hub and spoke manner, but dynamic connections are created/ removed between the
spokes on a need basis.</t>
<t>Security Association (SA) - Defined in <xref target="RFC4301"/>.</t>
</section>
<section anchor="mustshouldmay" title="Conventions Used in This Document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119"/>.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="usecases" title="Use Cases">
<t> This section presents the key use cases for large-scale
point-to-point VPN.</t>
<t> In all of these use cases, the participants (endpoints and
gateways) may be from a single organization (administrative domain) or from multiple
organizations with an established trust relationship. When
multiple organizations are involved, products from multiple
vendors are employed so open standards are needed to provide
interoperability. Establishing communications between participants
with no established trust relationship is out of scope for
this effort. </t>
<section anchor="e2e_use_case" title="Endpoint-to-Endpoint VPN Use Case">
<t> Two endpoints wish to communicate securely via a
point-to-point Security Association (SA).</t>
<t> The need for secure endpoint-to-endpoint communications
is often driven by a need to employ high-bandwidth, low
-latency
local connectivity instead of using slow, expensive
links to remote gateways. For example, two users in close
proximity may wish to place a direct, secure video or voice
call without needing to send the call through remote gateways,
which would add latency to the call, consume precious
remote bandwidth, and increase overall costs. Such a use case
also enables connectivity when both users are behind NAT
gateways. Such a use case ought to allow for seamless connectivity
even as endpoints roam, even if they are moving out from
behind a NAT gateway, from behind one NAT gateway to behind another,
or from a standalone position to behind a NAT gateway. </t>
<t> In a star topology, when two endpoints communicate
they need a mechanism for authentication, such that they do not
expose themselves to impersonation by the other spoke endpoint. </t>
</section>
<section anchor="g2g_use_case" title="Gateway-to-Gateway VPN Use Case">
<t> A typical Enterprise traffic model follows a star topology, with the gateways
connecting to each other using IPsec tunnels. </t>
<t> However for voice and other rich media traffic that requires a
lot of bandwidth or is performance sensitive, the traffic tromboning (taking a suboptimal path)
to the hub can create traffic bottlenecks
on the hub and can lead to an increase in cost. A fully
meshed solution would make best use of the available network capacity and
performance but the deployment of a fully meshed solution involves considerable
configuration, especially when a large number of nodes are involved. It is for this purpose
spoke-to-spoke tunnels are dynamically created and torn-down. For the reasons
of cost and manual error reduction, it is desired that there be minimal configuration on
each gateway. </t>
<t> The solution ought to work in cases where the endpoints are in different
administrative domains, albeit, ones that have an existing trust relationship
(for example two organisations who are collaborating on a project, they may wish to join
their networks, whilst retaining independent control over configuration). It is highly desirable that the
solution works for the star, full mesh as well as dynamic full mesh topology. </t>
<t> The solution ought to also address the case where gateways use dynamic IP addresses. </t>
<t> Additionally, the routing implications of gateway-to-gateway communication need to
be addressed. In the simple case, selectors provide sufficient information for a gateway
to forward traffic appropriately. In other cases, additional tunneling (e.g., Generic Routing Encapsulation - GRE) and
routing (e.g., Open Shortest Path First - OSPF) protocols are run over IPsec tunnels, and the configuration impact
on those protocols needs to be considered. There is also the case when Layer-3 Virtual Private Networks (L3VPNs) operate
over IPsec Tunnels. </t>
<t> When two gateways communicate, they need to use a mechanism for authentication,
such that they do not expose themselves to the risk of impersonation by the other entities. </t>
</section>
<section anchor="e2g_use_case" title="Endpoint-to-Gateway VPN Use Case">
<t> A mobile endpoint ought to be able to use the most efficient gateway as it roams in
the internet. </t>
<t>A mobile user roaming on the Internet may connect to a gateway, which
because of roaming is no longer the most efficient
gateway to use (reasons could
be cost/ efficiency/ latency or some other factor). The mobile user
ought to be able
to discover and then connect to the current most efficient gateway in a seamless way
without having to bring down the connection. </t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="solutions" title="Inadequacy of Existing Solutions">
<t> Several solutions exist for the problems described above.
However, none of these solutions is adequate, as described here.</t>
<section anchor="exhaustive" title="Exhaustive Configuration">
<t> One simple solution is to configure all gateways and
endpoints in advance with all the information needed to
determine which gateway or endpoint is optimal and to
establish an SA with that gateway or endpoint. However,
this solution does not scale in a large network with
hundreds of thousands of gateways and endpoints, especially
when multiple administrative domains are involved and things are
rapidly changing (e.g. mobile endpoints). Such a solution is also
limited by the smallest endpoint/ gateway, as the same exhaustive
configuration
is to be applied on all endpoints/ gateways. A more
dynamic, secure and scalable system for establishing
SAs between
gateways is needed. </t>
</section>
<section anchor="star" title="Star Topology">
<t> 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 few
gateways
are defined as
"hub gateways", while the rest of the systems
(whether endpoints or
gateways) are defined as "spokes". The spokes
never connect to other spokes. They
only open tunnels with the hub
gateways.
Also for a large number of gateways in one
administrative domain, one gateway may be defined
as the hub, and the rest of the
gateways and remote access clients connect only to that
gateway.</t>
<t> This solution however is complicated by the case when the spokes use dynamic IP
addresses and DNS with dynamic updates needs to be used. It is also
desired that there is minimal to no configuration on the hub as the number
of spokes increases and new spokes are added and deleted randomly.</t>
<t> 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 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 encrypted and decrypted multiple
times. It would be much preferable if these gateways and clients could initiate tunnels
between them, bypassing the hub gateways. Additionally, the path bandwidth to 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 building with high-speed wifi (for example, at an
IETF meeting). Channeling their conversation through the hub gateways of their respective
employers seems extremely wasteful, as well as having lower bandwidth.</t>
<t> The challenge is to build large scale, IPsec-protected networks that
can dynamically change with minimal administrative overhead.</t>
</section>
<section anchor="proprietary" title="Proprietary Approaches">
<t> Several vendors offer proprietary solutions to these problems.
However, these solutions offer no interoperability between
equipment from one vendor and another. This means that they
are generally restricted to use within one organization, and it is harder
to move off such solutions as the features are not standardized.
Besides multiple organizations cannot be expected to all choose the
same equipment vendor. </t>
</section>
</section>
<section anchor="requirements" title="Requirements">
<t> This section defines the requirements, on which the solution will be based. </t>
<section anchor="gateway" title="Gateway and Endpoint Requirements">
<t> 1. For any network topology (star, full mesh and dynamic full mesh),
when a new gateway or endpoint is added, removed, or
changed, configuration changes are minimized as follows. Adding or removing a spoke in the topology MUST NOT require
configuration changes to the hubs other than where the spoke was connected to and SHOULD
NOT require configuration changes to the hub the spoke was connected to. The changes also
MUST NOT require configuration changes in other spokes. </t>
<t>Specifically, when evaluating potential proposals,
we will compare them by looking at how
many endpoints or gateways must
be reconfigured when a new gateway or endpoint is added,
removed, or
changed and how substantial this reconfiguration is, besides the amount of static configuration
required. </t>
<t> This requirement is driven by use cases 2.1 and 2.2 and by the
scaling limitations pointed out in section 3.1. </t>
<t> 2. ADVPN peers MUST allow IPsec Tunnels to be setup with other members
of the ADVPN without any configuration changes, even when peer addresses get updated
every time the device comes up. This implies that SPD entries or
other configuration based on peer IP address will need to be
automatically updated, avoided, or handled in some manner to avoid
a need to manually update policy whenever an address changes. </t>
<t> 3. In many cases additional tunneling protocols (e.g. GRE) or Routing protocols
(e.g. OSPF) are run over the IPsec tunnels. Gateways MUST allow for the operation of
tunneling and Routing protocols operating over spoke-to-spoke IPsec Tunnels with
minimal or no, configuration impact. The ADVPN solution SHOULD NOT increase the
amount of information required to configure protocols running over IPsec tunnels. </t>
<t> 4. In the full mesh and dynamic full mesh topology, Spokes MUST
allow for direct communication
with other spoke gateways and endpoints. In the star topology
mode, direct communication between spokes MUST be disallowed.</t>
<t> 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. </t>
<t> 5. Any of the ADVPN Peers MUST NOT have a way to get the long
term 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. </t>
<t> This requirement is driven by use case 2.1. ADVPN Peers (especially
Spokes) become compromised fairly often. The compromise of one ADVPN
Peer SHOULD NOT affect the security of other unrelated ADVPN Peers. </t>
<t> 6. Gateways SHOULD allow for seamless handoff of sessions in case
endpoints are roaming, even if they cross policy boundaries. This would mean the
data traffic is minimally affected even as the handoff happens. External factors like
firewall, NAT boxes that will be part of the overall solution when DVPN is deployed
will not be considered part of this solution. </t>
<t> Such endpoint roaming may affect not only the
endpoint-to-endpoint SA but also the relationship
between the endpoints and gateways (such as when
an endpoint roams to a new network that is handled
by a different gateway). </t>
<t> This requirement is driven by use case 2.1. Today's endpoints
are mobile and transition often between different networks
(from 4G to WiFi and among various WiFi networks). </t>
<t> 7. Gateways SHOULD allow for easy handoff of a session to another
gateway, to optimize latency, bandwidth, load balancing, availability,
or other factors, based on policy. </t>
<t> This ability to migrate traffic from one gateway
to another applies regardless of whether the gateways
in question are hubs or spokes. It even applies in
the case where a gateway (hub or spoke) moves in the
network, as may happen with a vehicle-based network. </t>
<t> This requirement is driven by use case 2.3. </t>
<t> 8. Gateways and endpoints MUST have the capability to participate
in an ADVPN even when they are located behind NAT boxes. However,
in some cases they may be deployed in such a way that they will not be
fully reachable behind a NAT box. It is especially difficult to handle cases
where the Hub is behind a NAT box. Where the two endpoints are both
behind separate NATs, communication between these 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. </t>
<t> This requirement is driven by use cases 2.1 and 2.2. Endpoints
are often behind NATs and gateways sometimes are. IPsec SHOULD
continue to work seamlessly regardless, using ADVPN techniques
whenever possible and providing graceful fallback to hub and
spoke techniques as needed. </t>
<t> 9. Changes such as establishing a new IPsec SA SHOULD be
reportable and manageable. However, creating a MIB or other
management technique is not within scope for this effort. </t>
<t> This requirement is driven by manageability concerns for
all the use cases, especially use case 2.2. As IPsec networks
become more dynamic, management tools become more essential. </t>
<t> 10. To support allied and federated environments, endpoints
and gateways from different organizations SHOULD be able to
connect to each other. </t>
<t> This requirement is driven by demand for all the use cases
in federated and allied environments. </t>
<t> 11. The administrator of the ADVPN SHOULD allow for the configuration of
a Star, Full mesh or a partial full mesh topology, based on which tunnels are
allowed to be setup. </t>
<t> This requirement is driven by demand for all the use cases
in federated and allied environments. </t>
<t> 12. The ADVPN solution SHOULD be able to scale for multicast traffic. </t>
<t> This requirement is driven by the use case 2.2, where the amount of rich media
multicast traffic is increasing. </t>
<t> 13. The ADVPN solution SHOULD allow for easy monitoring, logging and reporting of
the dynamic changes, to help for trouble shooting such environments. </t>
<t> This requirement is driven by demand for all the use cases
in federated and allied environments. </t>
<t> 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. </t>
<t> This requirement is driven by demand for all the use cases
in federated and allied environments. </t>
<t> 15. There ADVPN solution SHOULD allow the enforcement of per peer QoS in both the Star
as well as the Full Mesh topology. </t>
<t> This requirement is driven by demand for all the use cases
in federated and allied environments. </t>
<t> 16. There ADVPN solution SHOULD take care of not letting the Hub to be a single point of failure. </t>
<t> This requirement is driven by demand for all the use cases in federated and allied environments. </t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="security" title="Security Considerations">
<t> This is a Problem statement 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
dynamic updates to
databases defined by RFC 4301, such as the Security Policy Database (SPD) or the Peer
Authorization Database (PAD).</t>
<t> 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 human. Allowing dynamic updates to these
databases must be thought out carefully, because it allows the protocol to alter the
security policy that the IPsec endpoints implement.</t>
<t> 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. 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 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 clear trust model.</t>
<t> 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.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>No actions are required from IANA for this informational document.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t> Many people have contributed to the development of this problem
statement and many more will probably do so before we are done with it.
While we cannot thank all contributors, some have played an especially
prominent role. Yoav Nir, Yaron Sheffer, Jorge Coronel Mendoza,
Chris Ulliott, and John
Veizades wrote the document upon which this draft
was based. Geoffrey Huang,
Toby Mao,
Suresh Melam, Praveen Sathyanarayan,
Andreas Steffen, Brian Weis, and Lou Berger
provided essential input.</t>
</section>
<!-- ====================================================================== -->
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
<reference anchor='RFC4301'>
<front>
<title>Security Architecture for the Internet Protocol</title>
<author initials='S.' surname='Kent' fullname='S. Kent'>
<organization>BBN Technologies</organization></author>
<author initials='K.' surname='Seo' fullname='K. Seo'>
<organization>BBN Technologies</organization></author>
<date year='2005' month='December' />
</front>
<seriesInfo name='RFC' value='4301' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc4301.txt' />
<format type='HTML' target='http://xml.resource.org/public/rfc/html/rfc4301.html' />
<format type='XML' target='http://xml.resource.org/public/rfc/xml/rfc4301.xml' />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='16553' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5703' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
</references>
<!-- ====================================================================== -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:53:16 |