draft-ietf-ipsecme-ad-vpn-problem-09.txt   rfc7018.txt 
IPsecME Working Group V. Manral Internet Engineering Task Force (IETF) V. Manral
Internet-Draft HP Request for Comments: 7018 HP
Intended status: Informational S. Hanna Category: Informational S. Hanna
Expires: January 17, 2014 Juniper ISSN: 2070-1721 Juniper
July 16, 2013 September 2013
Auto Discovery VPN Problem Statement and Requirements Auto-Discovery VPN Problem Statement and Requirements
draft-ietf-ipsecme-ad-vpn-problem-09
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 addresses of endpoints
or the endpoints may be behind NAT gateways, making static change, or the endpoints may be behind NAT gateways, making static
configuration impossible. The Auto Discovery VPN solution will configuration impossible. The Auto-Discovery VPN solution will
address these requirements. address these requirements.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on January 17, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7018.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4 1.2. Conventions Used in This Document ..........................4
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Use Cases .......................................................4
2.1. Endpoint-to-Endpoint VPN Use Case . . . . . . . . . . . . 4 2.1. Use Case 1: Endpoint-to-Endpoint VPN .......................4
2.2. Gateway-to-Gateway VPN Use Case . . . . . . . . . . . . . 5 2.2. Use Case 2: Gateway-to-Gateway VPN .........................5
2.3. Endpoint-to-Gateway VPN Use Case . . . . . . . . . . . . 5 2.3. Use Case 3: Endpoint-to-Gateway VPN ........................6
3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . 6 3. Inadequacy of Existing Solutions ................................6
3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . 6 3.1. Exhaustive Configuration ...................................6
3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Star Topology ..............................................6
3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . 7 3.3. Proprietary Approaches .....................................7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements ....................................................7
4.1. Gateway and Endpoint Requirements . . . . . . . . . . . . 7 4.1. Gateway and Endpoint Requirements ..........................7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations ........................................11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements ...............................................11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Normative References ...........................................12
8. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
IPsec [RFC4301] is used in several different cases, including tunnel- IPsec [RFC4301] is used in several different cases, including
mode site-to-site VPNs and Remote Access VPNs. Both tunneling modes tunnel-mode site-to-site VPNs and remote access VPNs. Both tunneling
for IPsec gateways and host-to-host transport mode are supported in modes for IPsec gateways and host-to-host transport mode are
this document. supported in this document.
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 and the requirements on a solution to address deployments of IPsec and the requirements on a solution to address
the problem. These may be a large collection of VPN gateways the problem. These may be a large collection of VPN gateways
connecting various sites, a large number of remote endpoints connecting various sites, a large number of remote endpoints
connecting to a number of gateways or to each other, or a mix of the 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 two. The gateways and endpoints may belong to a single
administrative domain or several domains with a trust relationship. administrative domain or several domains with a trust relationship.
Section 4.4 of RFC 4301 describes the major IPsec databases needed Section 4.4 of RFC 4301 describes the major IPsec databases needed
for IPsec processing. It requires an extensive configuration for for IPsec processing. It requires extensive configuration for each
each tunnel, so manually configuring a system of many gateways and tunnel, so manually configuring a system of many gateways and
endpoints becomes infeasible and inflexible. endpoints becomes infeasible and inflexible.
The difficulty is that a lot of configuration mentioned in RFC 4301 The difficulty is that a lot of configuration mentioned in RFC 4301
is required to set up a Security Association. IKE implementations is required to set up a Security Association. The Internet Key
need to know the identity and credentials of all possible peer Exchange Protocol (IKE) implementations need to know the identity and
systems, as well as the addresses of hosts and/or networks behind credentials of all possible peer systems, as well as the addresses of
them. A simplified mechanism for dynamically establishing point-to- hosts and/or networks behind them. A simplified mechanism for
point tunnels is needed. Section 2 contains several use cases that dynamically establishing point-to-point tunnels is needed. Section 2
motivate this effort. contains several use cases that motivate this effort.
1.1. Terminology 1.1. Terminology
ADVPN - Auto Discovery Virtual Private Network (ADVPN) is VPN Auto-Discovery Virtual Private Network (ADVPN) - A VPN solution that
solution that enables a large number of systems to communicate enables a large number of systems to communicate directly, with
directly, with minimal configuration and operator intervention using minimal configuration and operator intervention, using IPsec to
IPsec to protect communication between them. protect communication between them.
Endpoint - A device that implements IPsec for its own traffic but Endpoint - A device that implements IPsec for its own traffic but
does not act as a gateway. does 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 - Communication between two parties without active Point-to-Point - Communication between two parties without active
participation (e.g. encryption or decryption) by any other parties. participation (e.g., encryption or decryption) by any other
parties.
Hub - The central point in a star topology/ dynamic full mesh Hub - The central point in a star topology/dynamic full-mesh
topology, or one of the central points in the full mesh style VPN, 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 i.e., a gateway to which multiple other hubs or spokes connect.
hubs usually forward traffic coming from encrypted links to other The hubs usually forward traffic coming from encrypted links to
encrypted links, i.e. there are no devices connected to it in clear. other encrypted links, i.e., there are no devices connected to
them in the clear.
Spoke - The endpoint in a star topology/ dynamic full mesh topology, Spoke - The endpoint in a star topology/dynamic full-mesh topology
or gateway which forwards traffic from multiple cleartext devices to or gateway that forwards traffic from multiple cleartext devices
other hubs or spokes, and some of those other devices are connected to other hubs or spokes, and some of those other devices are
to it in clear (i.e. it encrypts data coming from cleartext devices connected to it in the clear (i.e., it encrypts data coming from
and forwards it to the ADVPN). cleartext devices and forwards it to the ADVPN).
ADVPN Peer - any member of an ADVPN including gateways, endpoints, ADVPN Peer - Any member of an ADVPN, including gateways, endpoints,
hub or spoke. hubs, or spokes.
Star topology - This is the topology where there is direct Star Topology - Topology in which there is direct connectivity only
connectivity only between the hub and spoke and communication between between the hub and spoke, and where communication between the 2
the 2 spokes happens through the hub. spokes happens through the hub.
Allied and Federated Environments - Environments where we have Allied and Federated Environments - Environments where we have
multiple different organizations that have close association and need multiple different organizations that have close associations and
to connect to each other. need to connect to each other.
Full Mesh topology - This is the topology where there is a direct Full-Mesh Topology - Topology in which there is direct connectivity
connectivity between every Spoke to every other Spoke directly, between every spoke to every other spoke, without the traffic
without the traffic between the spokes having to be redirected between the spokes having to be redirected through an intermediate
through an intermediate hub device. hub device.
Dynamic Full Mesh topology - This is the topology where direct Dynamic Full-Mesh Topology - Topology in which direct connections
connections exist in a hub and spoke manner, but dynamic connections exist in a hub-and-spoke manner but dynamic connections are
are created/ removed between the spokes on a need basis. created/removed between the spokes on an as-needed basis.
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
This section presents the key use cases for large-scale point-to- This section presents the key use cases for large-scale
point VPN. point-to-point VPNs.
In all of these use cases, the participants (endpoints and gateways) In all of these use cases, the participants (endpoints and gateways)
may be from a single organization (administrative domain) or from may be from a single organization (administrative domain) or from
multiple organizations with an established trust relationship. When multiple organizations with an established trust relationship. When
multiple organizations are involved, products from multiple vendors multiple organizations are involved, products from multiple vendors
are employed so open standards are needed to provide are employed, so open standards are needed to provide
interoperability. Establishing communications between participants interoperability. Establishing communications between participants
with no established trust relationship is out of scope for this with no established trust relationship is out of scope for this
effort. effort.
2.1. Endpoint-to-Endpoint VPN Use Case 2.1. Use Case 1: Endpoint-to-Endpoint VPN
Two endpoints wish to communicate securely via a point-to-point Two endpoints wish to communicate securely via a point-to-point SA.
Security Association (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, as the remote gateways would add
call, consume precious remote bandwidth, and increase overall costs. latency to the call, consume precious remote bandwidth, and increase
Such a use case also enables connectivity when both users are behind overall costs. Such a use case also enables connectivity when both
NAT gateways. Such a use case ought to allow for seamless users are behind NAT gateways. Such a use case ought to allow for
connectivity even as endpoints roam, even if they are moving out from seamless connectivity even as endpoints roam and even if they are
behind a NAT gateway, from behind one NAT gateway to behind another, moving out from behind a NAT gateway, from behind one NAT gateway to
or from a standalone position to behind a NAT gateway. behind another, or from a standalone position to behind a NAT
gateway.
In a star topology, when two endpoints communicate they need a In a star topology, when two endpoints communicate, they need a
mechanism for authentication, such that they do not expose themselves mechanism for authentication such that they do not expose themselves
to impersonation by the other spoke endpoint. to impersonation by the other spoke endpoint.
2.2. Gateway-to-Gateway VPN Use Case 2.2. Use Case 2: Gateway-to-Gateway VPN
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 voice and other rich media traffic that requires a lot of However, for voice and other rich media traffic that require a lot of
bandwidth or is performance sensitive, the traffic tromboning (taking bandwidth or is performance sensitive, the traffic tromboning (taking
a suboptimal path) to the hub can create traffic bottlenecks on the 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 hub and can lead to an increase in cost. A fully meshed solution
would make best use of the available network capacity and performance would make best use of the available network capacity and
but the deployment of a fully meshed solution involves considerable performance, but the deployment of a fully meshed solution involves
configuration, especially when a large number of nodes are involved. considerable configuration, especially when a large number of nodes
It is for this purpose spoke-to-spoke tunnels are dynamically created are involved. It is for this purpose that spoke-to-spoke tunnels are
and torn-down. For the reasons of cost and manual error reduction, dynamically created and torn down. For the reasons of cost and
it is desired that there be minimal configuration on each gateway. manual error reduction, it is desired that there be minimal
configuration on each gateway.
The solution ought to work in cases where the endpoints are in The solution ought to work in cases where the endpoints are in
different administrative domains, albeit, ones that have an existing different administrative domains that have an existing trust
trust relationship (for example two organisations who are relationship (for example, two organizations that are collaborating
collaborating on a project, they may wish to join their networks, on a project may wish to join their networks while retaining
whilst retaining independent control over configuration). It is independent control over configuration). It is highly desirable that
highly desirable that the solution works for the star, full mesh as the solution works for the star, full-mesh, and dynamic full-mesh
well as dynamic full mesh topology. topologies.
The solution ought to also address the case where gateways use The solution ought to also address the case where gateways use
dynamic IP addresses. dynamic IP addresses.
Additionally, the routing implications of gateway-to-gateway Additionally, the routing implications of gateway-to-gateway
communication need to be addressed. In the simple case, selectors communication need to be addressed. In the simple case, selectors
provide sufficient information for a gateway to forward traffic provide sufficient information for a gateway to forward traffic
appropriately. In other cases, additional tunneling (e.g., Generic appropriately. In other cases, additional tunneling (e.g., Generic
Routing Encapsulation - GRE) and routing (e.g., Open Shortest Path Routing Encapsulation (GRE)) and routing (e.g., Open Shortest Path
First - OSPF) protocols are run over IPsec tunnels, and the First (OSPF)) protocols are run over IPsec tunnels, and the
configuration impact on those protocols needs to be considered. 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. There is also the case where Layer 3 Virtual Private Networks
(L3VPNs) operate over IPsec tunnels.
When two gateways communicate, they need to use a mechanism for When two gateways communicate, they need to 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
of impersonation by the other entities. impersonation by the other entities.
2.3. Use Case 3: Endpoint-to-Gateway VPN
2.3. Endpoint-to-Gateway VPN Use Case
A mobile endpoint ought to be able to use the most efficient gateway A mobile endpoint ought to be able to use the most efficient gateway
as it roams in the internet. as it roams in the Internet.
A mobile user roaming on the Internet may connect to a gateway, which A mobile user roaming on the Internet may connect to a gateway that,
because of roaming is no longer the most efficient gateway to use because of roaming, is no longer the most efficient gateway to use
(reasons could be cost/ efficiency/ latency or some other factor). (reasons could be cost, efficiency, latency, or some other factor).
The mobile user ought to be able to discover and then connect to the 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 current, most efficient gateway in a seamless way without having to
bring down the connection. bring down 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 administrative domains are involved and things are rapidly multiple administrative domains are involved and things are rapidly
changing (e.g. mobile endpoints). Such a solution is also limited by changing (e.g., mobile endpoints). Such a solution is also limited
the smallest endpoint/ gateway, as the same exhaustive configuration by the smallest endpoint/gateway, as the same exhaustive
is to be applied on all endpoints/ gateways. A more dynamic, secure configuration is to be applied on all endpoints/gateways. A more
and scalable system for establishing SAs between gateways is needed. 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 a part of this this problem today is The most common way to address a part of this problem today is to use
to use what has been termed a "star topology". In this case one or a what has been termed a "star topology". In this case, one or a few
few gateways are defined as "hub gateways", while the rest of the gateways are defined as "hub gateways", while the rest of the systems
systems (whether endpoints or gateways) are defined as "spokes". The (whether endpoints or gateways) are defined as "spokes". The spokes
spokes never connect to other spokes. They only open tunnels with never connect to other spokes. They only open tunnels with the hub
the hub gateways. Also for a large number of gateways in one gateways. Also, for a large number of gateways in one administrative
administrative domain, one gateway may be defined as the hub, and the domain, one gateway may be defined as the hub, and the rest of the
rest of the gateways and remote access clients connect only to that gateways and remote access clients connect only to that gateway.
gateway.
This solution however is complicated by the case when the spokes use This solution, however, is complicated by the case where the spokes
dynamic IP addresses and DNS with dynamic updates needs to be used. use dynamic IP addresses and DNS with dynamic updates needs to be
It is also desired that there is minimal to no configuration on the used. It is also desired that there is minimal to no configuration
hub as the number of spokes increases and new spokes are added and on the hub as the number of spokes increases and new spokes are added
deleted randomly. and 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 impacts both processing power and 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
building with high-speed wifi (for example, at an IETF meeting). building with high-speed WiFi (for example, at an IETF meeting).
Channeling their conversation through the hub gateways of their Channeling their conversation through the hub gateways of their
respective employers seems extremely wasteful, as well as having respective employers seems extremely wasteful, given that a more
lower bandwidth. optimal direct path exists.
The challenge is to build large scale, IPsec-protected networks that The challenge is to build large-scale IPsec-protected networks that
can dynamically change with minimal administrative overhead. can dynamically change with minimal 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, 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 away from such solutions, as the features are not standardized.
multiple organizations cannot be expected to all choose the same Besides, multiple organizations cannot be expected to all choose the
equipment vendor. same equipment vendor.
4. Requirements 4. Requirements
This section defines 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
when a new gateway or endpoint is added, removed, or changed, mesh), when a new gateway or endpoint is added, removed, or
configuration changes are minimized as follows. Adding or removing a changed, configuration changes are minimized as follows. Adding
spoke in the topology MUST NOT require configuration changes to the or removing a spoke in the topology MUST NOT require
hubs other than where the spoke was connected to and SHOULD NOT configuration changes to hubs other than where the spoke was
require configuration changes to the hub the spoke was connected to. connected and SHOULD NOT require configuration changes to the
The changes also MUST NOT require configuration changes in other hub to which the spoke was connected. The changes also MUST NOT
spokes. require configuration changes in other spokes.
Specifically, when evaluating potential proposals, we will compare Specifically, when evaluating potential proposals, we will
them by looking at how many endpoints or gateways must be compare them by looking at how many endpoints or gateways must
reconfigured when a new gateway or endpoint is added, removed, or be reconfigured when a new gateway or endpoint is added,
changed and how substantial this reconfiguration is, besides the removed, or changed and how substantial this reconfiguration is,
amount of static configuration required. in addition to the 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 1 and 2 and by the
scaling limitations pointed out in section 3.1. scaling limitations pointed out in Section 3.1.
2. ADVPN peers MUST allow IPsec Tunnels to be setup with other 2. ADVPN Peers MUST allow IPsec tunnels to be set up with other
members of the ADVPN without any configuration changes, even when members of the ADVPN without any configuration changes, even
peer addresses get updated every time the device comes up. This when peer addresses get updated every time the device comes up.
implies that SPD entries or other configuration based on peer IP This implies that Security Policy Database (SPD) entries or
address will need to be automatically updated, avoided, or handled in other configuration based on a peer IP address will need to be
some manner to avoid a need to manually update policy whenever an automatically updated, avoided, or handled in some manner to
address changes. avoid a need to manually update policy whenever an address
changes.
3. In many cases additional tunneling protocols (e.g. GRE) or 3. In many cases, additional tunneling protocols (e.g., GRE) or
Routing protocols (e.g. 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
no, configuration impact. The ADVPN solution SHOULD NOT increase the minimal or no configuration impact. The ADVPN solution SHOULD
amount of information required to configure protocols running over NOT increase the amount of information required to configure
IPsec tunnels. protocols running over IPsec tunnels.
4. In the full mesh and dynamic full mesh topology, Spokes MUST 4. In the full-mesh and dynamic full-mesh topologies, 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
spokes MUST be disallowed. between 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 1 and 2 and by the
limitations of a star topology pointed out in section 3.2. limitations of a star topology as pointed out in Section 3.2.
5. Any of the ADVPN Peers MUST NOT have a way to get the long term 5. ADVPN Peers MUST NOT have a way to get the long-term
authentication credentials for any other ADVPN Peers. The compromise authentication credentials for any other ADVPN Peers. The
of an Endpoint MUST NOT affect the security of communications between compromise of an endpoint MUST NOT affect the security of
other ADVPN Peers. The compromise of a Gateway SHOULD NOT affect the communications between other ADVPN Peers. The compromise of a
security of the communications between ADVPN Peers not associated gateway SHOULD NOT affect the security of the communications
with that Gateway. between ADVPN Peers not associated with that gateway.
This requirement is driven by use case 2.1. ADVPN Peers (especially This requirement is driven by use case 1. ADVPN Peers
Spokes) become compromised fairly often. The compromise of one ADVPN (especially spokes) become compromised fairly often. The
Peer SHOULD NOT affect the security of other unrelated ADVPN Peers. compromise of one ADVPN Peer SHOULD NOT affect the security of
other unrelated ADVPN Peers.
6. Gateways SHOULD allow for seamless handoff of sessions in case 6. Gateways SHOULD allow for seamless handoff of sessions in cases
endpoints are roaming, even if they cross policy boundaries. This where endpoints are roaming, even if they cross policy
would mean the data traffic is minimally affected even as the handoff boundaries. This would mean the data traffic is minimally
happens. External factors like firewall, NAT boxes that will be part affected even as the handoff happens. External factors like
of the overall solution when DVPN is deployed will not be considered firewalls and NAT boxes that will be part of the overall
part of this solution. solution when ADVPN is deployed will not be considered part of
this solution.
Such endpoint roaming may affect not only the endpoint-to-endpoint SA Such endpoint roaming may affect not only the endpoint-to-
but also the relationship between the endpoints and gateways (such as endpoint SA but also the relationship between the endpoints and
when an endpoint roams to a new network that is handled by a gateways (such as when an endpoint roams to a new network that
different gateway). is handled by a different gateway).
This requirement is driven by use case 2.1. Today's endpoints are This requirement is driven by use case 1. Today's endpoints are
mobile and transition often between different networks (from 4G to mobile and transition often between different networks (from 4G
WiFi and among various WiFi networks). to 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 ability to migrate traffic from one gateway to another applies This ability to migrate traffic from one gateway to another
regardless of whether the gateways in question are hubs or spokes. applies regardless of whether the gateways in question are hubs
It even applies in the case where a gateway (hub or spoke) moves in or spokes. It even applies in the case where a gateway (hub or
the network, as may happen with a vehicle-based network. spoke) moves in the network, as may happen with a vehicle-based
network.
This requirement is driven by use case 2.3. This requirement is driven by use case 3.
8. Gateways and endpoints MUST have the capability to participate in 8. Gateways and endpoints MUST have the capability to participate
an ADVPN even when they are located behind NAT boxes. However, in in an ADVPN even when they are located behind NAT boxes.
some cases they may be deployed in such a way that they will not be However, in some cases they may be deployed in such a way that
fully reachable behind a NAT box. It is especially difficult to they will not be fully reachable behind a NAT box. It is
handle cases where the Hub is behind a NAT box. Where the two especially difficult to handle cases where the hub is behind a
endpoints are both behind separate NATs, communication between these NAT box. When the two endpoints are both behind separate NATs,
spokes SHOULD be supported using workarounds such as port forwarding communication between these spokes SHOULD be supported using
by the NAT or detecting when two spokes are behind uncooperative NATs workarounds such as port forwarding by the NAT or detecting when
and using a hub in that case. 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 1 and 2. Endpoints are
often behind NATs and gateways sometimes are. IPsec SHOULD continue often behind NATs, and gateways sometimes are. IPsec SHOULD
to work seamlessly regardless, using ADVPN techniques whenever continue to work seamlessly regardless, using ADVPN techniques
possible and providing graceful fallback to hub and spoke techniques whenever possible and providing graceful fallback to hub-and-
as needed. spoke techniques 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.
This requirement is driven by manageability concerns for all the use This requirement is driven by manageability concerns for all the
cases, especially use case 2.2. As IPsec networks become more use cases, especially use case 2. As IPsec networks become more
dynamic, management tools become more essential. dynamic, management tools become more essential.
10. To support allied and federated environments, endpoints and 10. To support allied and federated environments, endpoints and
gateways from different organizations SHOULD be able to connect to gateways from different organizations SHOULD be able to connect
each other. to each other.
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.
11. The administrator of the ADVPN SHOULD allow for the 11. The administrator of the ADVPN SHOULD allow for the
configuration of a Star, Full mesh or a partial full mesh topology, configuration of a star, full-mesh, or partial full-mesh
based on which tunnels are allowed to be setup. topology, based on which tunnels are allowed to be set up.
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.
12. The ADVPN solution SHOULD be able to scale for multicast 12. The ADVPN solution SHOULD be able to scale for multicast
traffic. traffic.
This requirement is driven by the use case 2.2, where the amount of This requirement is driven by use case 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,
reporting of the dynamic changes, to help for trouble shooting such and reporting of the dynamic changes to help with
environments. troubleshooting such 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. There is also the case when L3VPNs operate over IPsec Tunnels, 14. There is also the case where L3VPNs operate over IPsec tunnels,
for example Provider Edge (PE) based VPN's. An ADVPN MUST support for example, Provider-Edge-based VPNs. An ADVPN MUST support
L3VPN as an application protected by the IPsec Tunnels. L3VPNs as applications 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.
15. There ADVPN solution SHOULD allow the enforcement of per peer 15. The ADVPN solution SHOULD allow the enforcement of per-peer QoS
QoS in both the Star as well as the Full Mesh topology. in both the star and full-mesh topologies.
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.
16. There ADVPN solution SHOULD take care of not letting the Hub to 16. The ADVPN solution SHOULD take care of not letting the hub be a
be a single point of failure. single point of failure.
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 statement and requirement document for the ADVPN This is a problem statement and requirements document for the
solution, and in itself does not introduce any new security concerns. ADVPN solution and in itself does not introduce any new security
The solution to the problems presented in this draft may involve concerns. The solution to the problems presented in this document
dynamic updates to databases defined by RFC 4301, such as the may involve dynamic updates to databases defined by RFC 4301,
Security Policy Database (SPD) or the Peer Authorization Database such as the Security Policy Database (SPD) or the Peer Authorization
(PAD). Database (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 preconfigured 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 proxy and read
read all traffic to that site. Updates to this database requires a all traffic to that site. Updates to this database require a clear
clear trust model. trust model.
Hubs can be a single point of failure which can cause loss of Hubs can be a single point of failure that can cause loss of
connectivity of the entire system, that can be a big security issue. connectivity of the entire system; this can be a big security issue.
Any ADVPN solution design should take care of these concerns. Any ADVPN solution design should take care of these concerns.
6. IANA Considerations 6. Acknowledgements
No actions are required from IANA for this informational document.
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. While we cannot thank all contributors, some have played
it. While we cannot thank all contributors, some have played an an especially prominent role. Yoav Nir, Yaron Sheffer, 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, Toby Mao, Suresh Melam, which this specification was based. Geoffrey Huang, Toby Mao, Suresh
Praveen Sathyanarayan, Andreas Steffen, Brian Weis, and Lou Berger Melam, Praveen Sathyanarayan, Andreas Steffen, Brian Weis, Lou
provided essential input. Berger, and Tero Kivinen provided essential input.
8. Normative References 7. 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
Vishwas Manral Vishwas Manral
Hewlett-Packard Co. Hewlett-Packard Co.
19111 Pruneridge Ave. 3000 Hanover St.
Cupertino, CA 95113 Palo Alto, CA 94304
USA USA
Email: vishwas.manral@hp.com EMail: vishwas.manral@hp.com
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
 End of changes. 97 change blocks. 
302 lines changed or deleted 304 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/