One document matched: draft-nir-ipsecme-p2p-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc ipr="trust200902" docName="draft-nir-ipsecme-p2p-00" category="info">
<front>
<title abbrev="IPsec P2P">Creating Large Scale Mesh VPNs Problem Statement</title>
<author initials="Y." surname="Nir" fullname="Yoav Nir">
<organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
<address>
<postal>
<street>5 Hasolelim st.</street>
<city>Tel Aviv</city>
<code>67897</code>
<country>Israel</country>
</postal>
<email>ynir@checkpoint.com</email>
</address>
</author>
<author initials="J." surname="Veizades" fullname="John Veizades">
<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>jveizades at juniper dot net</email>
</address>
</author>
<author initials="C." surname="Ulliott" fullname="Chris Ulliott">
<organization abbrev="CESG">CESG</organization>
<address>
<postal>
<street>Hubble Road</street>
<city>Cheltenham</city>
<code>GL51 0EX</code>
<country>UK</country>
</postal>
<email>Chris.Ulliott@cesg.gsi.gov.uk</email>
</address>
</author>
<author initials="J." surname="Mendoza" fullname="Jorge Coronel Mendoza">
<organization abbrev="Microsoft">Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>USA</country>
</postal>
<email>jcoronel@microsoft.com</email>
</address>
</author>
<date year="2011"/>
<area>Security Area</area>
<workgroup>IPsecME Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t> This document presents the problem of configuring a large number of IKE/IPsec
systems in such a way that any two of them can use IPsec to protect the traffic
between them. Manual configuration of all possible tunnels is too cumbersome in such cases,
so an automated method is needed.</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. Host to host communication employing transport
mode also exists, but is far less commonly deployed. The subject of this document is large
scale deployments. These may be a large collection of VPN gateways and hosts, all
administered within the same administrative domain, or they may be a smaller collection of
VPN gateways, with many remote access clients connecting to any of them, or they may be
several collections of gateways, each collection administered by a different domain, or
they may be combinations of all of the above.</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 "mesh" of
several gateways becomes inconvenient.</t>
<t> One way to handle this is what has been termed a "star topology", or a "trunk topology".
In this case one gateway, or a few gateways are defined as "core gateways", while the rest,
whether remote-access clients or gateways are defined as "satellites". The satellites never
connect to other satellites. They only open tunnels with the core gateways.</t>
<t> For a large number of gateways in one administrative domain, one gateway may be defined
as the core, and the rest of the gateways and remote access clients connect only to that
gateway. If the packet destination is behind another gateway, then the core gateway will
re-encrypt the traffic, and send it through the other tunnel. If we have two collections of
gateways under two administrative domains, then each domain has its own "core", and the
administrators only need to define an IPsec tunnel between the two cores. This tunnel is
often referred to as a "trunk".</t>
<t> The problem with stars and trunks is that it creates a high load on the core gateways as
well as on the trunk connection. This load is both in processing power and in network
bandwidth. A single packet in the trunk scenario can be encrypted and decrypted three
times. It would be much preferable if these gateways and clients could initiate tunnels
between them, bypassing the core gateways. Additionally, the path bandwidth to these core
gateways may be lower than that of the path between the satellites. 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 core gateways of their respective
employers seems extremely wasteful, as well as having lower bandwidth.</t>
<t> The challenge is how to build large scale, fully meshed IPsec protected networks that
can dynamically change with minimum administrative overhead.</t>
<t> The difficulty is that all the configuration mentioned in RFC 4301 is not superfluous.
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 establishing ad-hoc tunnels is needed. <xref target="usecases"/> contains
several use cases that led to the publishing of this document.</t>
<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>
<t> "Administrative Domain" is used in this document for the entity, whether human, team,
or computer, that configures VPN gateways and clients. Gateways are said to be under the
same administrative domain if they are configured by a single entity and implement the
same policy. Some products have the ability to configure multiple VPN gateways or clients,
which would solve the problem presented in this document for gateways under the same
administrative domain, but they do not solve the problem for multiple administrative
domains.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="usecases" title="Use Cases">
<t> This section presents the use cases that have motivated this document in no particular
order. </t>
<section anchor="uc_serv_prov" title="The Service Provider Use Case">
<t> A service provider wishes to control communication between network elements with
authentication and encryption as provided by standard protocols like IPsec. This is
possible today but the amount of configuration information on each system is currently
order n squared so from an operational standpoint this can be challenging as the size
of the enterprise network grows. In short service providers wish to minimize the
configuration data that is required by any one system to initiate a secure communication
link to any other arbitrary system that is part of the service provider enterprise.</t>
<t> These same service providers wish to extend these secure communication links to
partners that have similar systems. Again they wish to minimize the amount of
configuration needed to initiate these secure connections to arbitrary systems at an
arbitrary partner. Additionally they required a directory of connection information that
can be updated independently to manage the identity of the connection endpoints at each
one of their partners. </t>
</section>
<section anchor="uc_xdom_mesh" title="Cross Domain Mesh Use Case">
<t> This section describes requirements for dynamically creating a mesh of VPN endpoints
although those endpoints belong to different administrative domains.</t>
<section anchor="uc_xdom_1" title="Scenario 1">
<t> Multiple users, connected to a corporate remote access solution are participating in
high bandwidth peer to peer communications. It is required that to optimise bandwidth
and latency (subject to policy), the solution is able to establish links between
remote peers rather than through a central gateway.</t>
</section>
<section anchor="uc_xdom_2" title="Scenario 2">
<t> Rather than remote hosts, the next scenario covers the connectivity between gateways.
Behind each gateway there are a number of individual hosts who aren't aware of the
protection being offered by the gateway. As each client send traffic to a host at a
different site, the gateway is required to identify the location of the remote host and
selects the most approprate gateway. Having made this decision, it dynamically
establishes a secure tunnel and forwards the traffic. </t>
</section>
<section anchor="uc_xdom_3" title="Scenario 3">
<t> The third scenario is a combination of the first two, where a remote user is no
longer tied to using a specific remote access gateway. Should the remote host need to
communicate with an entity protected by a gateway as described above, it would be
possible for it to identify a suitable gateway and establish a dynamic SA / tunnel and
communicate via the most effective route (subject to policy) It is essential that any
solution that meets the above scenarios, that we specify a mechanism for identifying
permitted hosts / gateways and deploying a policy to each gateway and participating host.
The solution also needs to work in an environment where gateways / hosts are
administered by different entitites or management domains. </t>
</section>
</section>
<section anchor="uc_cons" title="The Consultant Use Case">
<t> This section describes use cases for a consultant who works for multiple organizations
but is not an employee of any of them.</t>
<section anchor="uc_cons_1" title="Scenario A: Mobile worker and multiple domains">
<t> A consultant is hired by corporations (A and B) each of them with their own isolated
domains and resources protected with IPsec authentication. The consultant has signed
NDA and the corporation granted some level of trust in the form of an authentication
ID. This level of trust allows the contractor to access secured resources and networks
protected by IPsec until such trust is revoked.</t>
<t> In any given work week the consultant would be providing services on site or remotely
to multiple corporations. This is possible today, yet unmanageable due to the amount of
configuration required in order for the consultant to dynamically identify the
parameters to use when:<list style="symbols">
<t> He/She needs to get connected to secure resources when on premises (E2E client to
server secured connection)</t>
<t> He/She needs to use a secure access point when working remotely (Client to Edge
connection)</t></list></t>
<t> One key aspect of this problem is that the consultant may be providing consulting
services to Corp A and Corp B, for privacy reasons this information should be
protected.</t>
</section>
<section anchor="uc_cons_2" title="Scenario B: Consultants sharing securely">
<t> Consultant team A and team B have hired by corporation C and are working together in
a project that requires collaboration, however because they are from different
consulting firms half of the consultants are based in WA and half in CA. As in the
scenario above they have been entrusted with authentication ID. They have a need to
share folders with sensitive files in order to work efficiently towards a tight
deadline.</t>
<t> They have a need to securely handle this information hence they have a need to
discover what type of security should be used when attempting to share information
among themselves.</t>
</section>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t> 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.43.10. If we add an entry to an IPsec endpoint's SPD
that says that traffic to 192.0.43.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> More to be added.</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> The authors would like to thank Geoffrey Huang, Suresh Melam, Andreas Stephen, and Brian
Weis for their discussion and comments on early versions of this draft. We would also like
to thank Stephen Hanna for gathering the group that has produced this draft.</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-24 02:03:22 |