draft-ietf-ipsecme-p2p-vpn-problem-00.txt   draft-ietf-ipsecme-p2p-vpn-problem-01.txt 
IPsecME Working Group S. Hanna IPsecME Working Group S. Hanna
Internet-Draft Juniper Internet-Draft Juniper
Intended status: Informational March 5, 2012 Intended status: Informational V. Manral
Expires: September 6, 2012 Expires: November 26, 2012 HP
May 25, 2012
Point to Point VPNs Problem Statement Auto Discovery VPN Problem Statement
draft-ietf-ipsecme-p2p-vpn-problem-00 draft-ietf-ipsecme-p2p-vpn-problem-01
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. Manual configuration of all possible tunnels is too between them. Manual configuration of all possible tunnels is too
cumbersome in such cases, so an automated method is needed. cumbersome in many such cases. In other cases the IP address of end
points change or the end points may be behind NAT gateways, making
static configuration impossible. The Auto Discovery VPN solution is
chartered to address these requirements.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 6, 2012. This Internet-Draft will expire on November 26, 2012.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 3 1.2. Conventions Used in This Document . . . . . . . . . . . . 4
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Endpoint-to-Endpoint P2P VPN Use Case . . . . . . . . . . 4 2.1. Endpoint-to-Endpoint P2P VPN Use Case . . . . . . . . . . 5
2.2. Gateway-to-Gateway P2P VPN Use Case . . . . . . . . . . . 4 2.2. Gateway-to-Gateway AD VPN Use Case . . . . . . . . . . . . 5
2.3. Endpoint-to-Gateway P2P VPN Use Case . . . . . . . . . . . 4 2.3. Endpoint-to-Gateway AD VPN Use Case . . . . . . . . . . . 6
3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . . 6 3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . . 7
3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . . 6 3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . . 7
3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . . 7 3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
IPsec [RFC4301] is used in several different cases, including tunnel- IPsec [RFC4301] is used in several different cases, including tunnel-
mode site-to-site VPNs and Remote Access VPNs. Host to host mode site-to-site VPNs and Remote Access VPNs. Host to host
communication employing transport mode also exists, but is far less communication employing transport mode also exists, but is far less
commonly deployed. commonly deployed.
The subject of this document is the problem presented by large scale The subject of this document is the problem presented by large scale
deployments of IPsec. These may be a large collection of VPN deployments of IPsec. These may be a large collection of VPN
skipping to change at page 3, line 43 skipping to change at page 3, line 43
Endpoint - A host that implements IPsec for its own traffic but does Endpoint - A host that implements IPsec for its own traffic but does
not act as a gateway. not act as a gateway.
Gateway - A network device that implements IPsec to protect traffic Gateway - A network device that implements IPsec to protect traffic
flowing through the device. flowing through the device.
Point-to-Point - Direct communication between two parties without Point-to-Point - Direct communication between two parties without
active participation (e.g. encryption or decryption) by any other active participation (e.g. encryption or decryption) by any other
parties. parties.
Hub - The central point in a star topology, generally implemented in
a gateway
Spoke - The edge devices in a star topology, implemented in endpoints
or gateways
Security Association (SA) - Defined in [RFC4301]. Security Association (SA) - Defined in [RFC4301].
1.2. Conventions Used in This Document 1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Use Cases 2. Use Cases
skipping to change at page 4, line 30 skipping to change at page 5, line 30
Two endpoints wish to communicate securely via a direct, point-to- Two endpoints wish to communicate securely via a direct, point-to-
point SA. point SA.
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 usecase also enables connectivity when both endpoints are
behind NAT gateways. Such usecase should allow for seamless
connectivity even as Endpoints roam, in behing or away from gateways.
2.2. Gateway-to-Gateway P2P VPN Use Case In a hub and spoke topology when two end-points communicate, they
must use a mechanism for authentication, such that they do not expose
them to impersonation by the other spoke endpoint.
Two gateways suddenly need to exchange a lot of data. 2.2. Gateway-to-Gateway AD VPN Use Case
For example, a mobile worker from one government agency may sit down A typical Enterprise traffic model is Hub and Spoke, with the
in a shared remote office and start up his VOIP or video phone Gateways connecting to each other using IPsec tunnels.
software. He should rapidly get an efficient, secure, low latency
connection to his voice mail system and to anyone that he might call.
This user, his voice mail system, and other people that he calls will
probably be operating behind gateways but those gateways may have
little advance warning of the need to establish secure connectivity
between them.
2.3. Endpoint-to-Gateway P2P VPN Use Case However for the voice and other rich media traffic that occupies a
lot of bandwidth and the traffic tromboning to the Hub can create
traffic bottlenecks on the Hub and can lead to a increase cost. It
is for this purpose Spoke-to-Spoke tunnels are dynamically created
and torn-down.
An endpoint wants to connect directly to the most efficient gateway The Spoke Gateways can themselves come up and down, getting different
for accessing a particular service. IP addresses in the process, making th static configuration
impossible.
For example, a mobile user roaming on the Internet may need to open a Also for the reasons of cost and manual error reduction, it is
remote desktop connection to a virtual machine hosted on a particular desired there be minimal or even no configuration on the Hub as a new
server or to a service provided by a variety of servers distributed Spoke Router is added or removed.
around the globe. The user should be able to establish a connection
directly to the gateway closest to the service desired. If multiple In a hub and spoke topology when two spoke gateways communicate, they
gateways can suffice, load balancing and failover across gateways may must use a mechanism for authentication, such that they do not expose
be useful. them to impersonation by the other gateways spoke.
2.3. Endpoint-to-Gateway AD VPN Use Case
An endpoint should be able to use the most efficient gateway as it
roams in the internet.
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 should be able to discover and then connect to the
current most efficient gateway without having to reinitiate the
connection.
3. Inadequacy of Existing Solutions 3. Inadequacy of Existing Solutions
Several solutions exist for the problems described above. However, Several solutions exist for the problems described above. However,
none of these solutions is adequate, as described here. none of these solutions is adequate, as described here.
3.1. Exhaustive Configuration 3.1. Exhaustive Configuration
One simple solution is to configure all gateways and endpoints in One simple solution is to configure all gateways and endpoints in
advance with all the information needed to determine which gateway or advance with all the information needed to determine which gateway or
endpoint is optimal and to establish an SA with that 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 endpoint. However, this solution does not scale in a large network
with hundreds of thousands of gateways and endpoints, especially when with hundreds of thousands of gateways and endpoints, especially when
multiple organizations are involved and things are rapidly changing multiple organizations are involved and things are rapidly changing
(e.g. mobile endpoints). A more dynamic system for securely and (e.g. mobile endpoints). Such a solution is also limited by the
scalably establishing SAs between gateways is needed. 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.
3.2. Star Topology 3.2. Star Topology
The most common way to address this problem today is to use what has The most common way to address this problem today is to use what has
been termed a "star topology". In this case one or a few gateways been termed a "star topology". In this case one or a few gateways
are defined as "core gateways", while the rest of the systems are defined as "Hub gateways", while the rest of the systems (whether
(whether endpoints or gateways) are defined as "satellites". The endpoints or gateways) are defined as "spokes". The spokes never
satellites never connect to other satellites. They only open tunnels connect to other spokes. They only open tunnels with the core
with the core gateways. gateways. Also 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.
For a large number of gateways in one administrative domain, one This solution however does not work when the spokes, get dynamic IP
gateway may be defined as the core, and the rest of the gateways and address which the "core gateways" cannot be configured with. It is
remote access clients connect only to that gateway. If the packet also desired that there is minimal to no configuration on the Hub as
destination is behind another gateway, then the core gateway will re- the number of spokes increases and new spokes are added and deleted
encrypt the traffic, and send it through the other tunnel. If we randomly.
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".
One problem with stars and trunks is that it creates a high load on Another problem with stars and trunks is that it creates a high load
the core gateways as well as on the trunk connection. This load is on the core gateways as well as on the trunk connection. This load
both in processing power and in network bandwidth. A single packet is both in processing power and in network bandwidth. A single
in the trunk scenario can be encrypted and decrypted three times. It packet in the trunk scenario can be encrypted and decrypted three
would be much preferable if these gateways and clients could initiate times. It would be much preferable if these gateways and clients
tunnels between them, bypassing the core gateways. Additionally, the could initiate tunnels between them, bypassing the core gateways.
path bandwidth to these core gateways may be lower than that of the Additionally, the path bandwidth to these core gateways may be lower
path between the satellites. For example, two remote access users than that of the path between the satellites. For example, two
may be in the same building with high-speed wifi (for example, at an remote access users may be in the same building with high-speed wifi
IETF meeting). Channeling their conversation through the core (for example, at an IETF meeting). Channeling their conversation
gateways of their respective employers seems extremely wasteful, as through the core gateways of their respective employers seems
well as having lower bandwidth. extremely wasteful, as well as having lower bandwidth.
The challenge is how to build large scale, fully meshed IPsec The challenge is to build a large scale, IPsec protected networks
protected networks that can dynamically change with minimum that can dynamically change with minimum administrative overhead.
administrative overhead.
3.3. Proprietary Approaches 3.3. Proprietary Approaches
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. Multiple organizations restricted to use within one organization, and it is harder to move
cannot be expected to all choose the same equipment vendor. off such solutions as the features are not standardized. Besides
multiple organizations cannot be expected to all choose the same
equipment vendor.
4. Requirements 4. Requirements
This section will be completed when the use cases are agreed upon. This section will be completed when the use cases are agreed upon.
5. Security Considerations 5. Security Considerations
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
skipping to change at page 11, line 10 skipping to change at page 12, line 10
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, Jorge Coronel Mendoza, Chris especially prominent role. Yoav Nir, Yaron Scheffer, Jorge Coronel
Ulliott, and John Veizades wrote the document upon which this draft Mendoza, Chris Ulliott, and John Veizades wrote the document upon
was based. Geoffrey Huang, Suresh Melam, Praveen Sathyanarayan, which this draft was based. Geoffrey Huang, Suresh Melam, Praveen
Andreas Steffen, and Brian Weis provided essential input. Sathyanarayan, Andreas Steffen, and Brian Weis 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.
Author's Address Authors' Addresses
Steve Hanna Steve Hanna
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: shanna@juniper.net Email: shanna@juniper.net
Vishwas Manral
Hewlett-Packard Co.
19111 Pruneridge Ave.
Cupertino, CA 95113
USA
Email: vishwas.manral@hp.com
 End of changes. 22 change blocks. 
78 lines changed or deleted 106 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/