< draft-ietf-ipsecme-ad-vpn-problem-07.txt   draft-ietf-ipsecme-ad-vpn-problem-08.txt >
IPsecME Working Group S. Hanna IPsecME Working Group S. Hanna
Internet-Draft Juniper Internet-Draft Juniper
Intended status: Informational V. Manral Intended status: Informational V. Manral
Expires: December 05, 2013 HP Expires: January 14, 2014 HP
June 03, 2013 July 13, 2013
Auto Discovery VPN Problem Statement and Requirements Auto Discovery VPN Problem Statement and Requirements
draft-ietf-ipsecme-ad-vpn-problem-07 draft-ietf-ipsecme-ad-vpn-problem-08
Abstract Abstract
This document describes the problem of enabling a large number of This document describes the problem of enabling a large number of
systems to communicate directly using IPsec to protect the traffic systems to communicate directly using IPsec to protect the traffic
between them. It then expands on the requirements, for such a between them. It then expands on the requirements, for such a
solution. solution.
Manual configuration of all possible tunnels is too cumbersome in Manual configuration of all possible tunnels is too cumbersome in
many such cases. In other cases the IP address of endpoints change many such cases. In other cases the IP address of endpoints change
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 05, 2013. This Internet-Draft will expire on January 14, 2014.
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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 ADVPN Use Case . . . . . . . . . . . 4 2.1. Endpoint-to-Endpoint VPN Use Case . . . . . . . . . . . . 4
2.2. Gateway-to-Gateway ADVPN Use Case . . . . . . . . . . . . 5 2.2. Gateway-to-Gateway VPN Use Case . . . . . . . . . . . . . 5
2.3. Endpoint-to-Gateway ADVPN Use Case . . . . . . . . . . . 5 2.3. Endpoint-to-Gateway VPN Use Case . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 tunnel-
mode site-to-site VPNs and Remote Access VPNs. Host to host mode site-to-site VPNs and Remote Access VPNs. Both tunneling modes
communication employing transport mode also exists, but is far less for IPsec gateways and host-to-host transport mode are supported in
commonly deployed. 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 an extensive configuration for
each tunnel, so manually configuring a system of many gateways and each tunnel, so manually configuring a system of many gateways and
endpoints becomes infeasible and inflexible. endpoints becomes infeasible and inflexible.
The difficulty is that all the configuration mentioned in RFC 4301 is The difficulty is that a lot of configuration mentioned in RFC 4301
not superfluous. IKE implementations need to know the identity and is required to set up a Security Association. IKE implementations
credentials of all possible peer systems, as well as the addresses of need to know the identity and credentials of all possible peer
hosts and/or networks behind them. A simplified mechanism for systems, as well as the addresses of hosts and/or networks behind
dynamically establishing point-to-point tunnels is needed. Section 2 them. A simplified mechanism for dynamically establishing point-to-
contains several use cases that motivate this effort. point tunnels is needed. Section 2 contains several use cases that
motivate this effort.
1.1. Terminology 1.1. Terminology
ADVPN - Auto Discovery Virtual Private Network (ADVPN) is VPN ADVPN - Auto Discovery Virtual Private Network (ADVPN) is VPN
solution that enables a large number of systems to communicate solution that enables a large number of systems to communicate
directly, with minimal configuration and operator intervention using directly, with minimal configuration and operator intervention using
IPsec to protect communication between them. IPsec to 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. gateway where multiple other hubs or spokes connect to. The
hubs usually forward traffic coming from encrypted links to other hubs usually forward traffic coming from encrypted links to other
encrypted links, i.e. there are no devices connected to it in clear. encrypted links, i.e. there are no devices connected to it in 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 which forwards traffic from multiple cleartext devices to
other hubs or spokes, and some of those other devices are connected 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 to it in clear (i.e. it encrypts data coming from cleartext devices
and forwards it to the ADVPN). 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. hub or spoke.
Star topology - This is the topology where there is direct Star topology - This is the topology where there is direct
connectivity only between the hub and spoke and communication between connectivity only between the hub and spoke and communication between
the 2 spokes happens through the hub. the 2 spokes happens through the hub.
Allied and Federated Environments - Environments where we have Allied and Federated Environments - Environments where we have
skipping to change at page 4, line 33 skipping to change at page 4, line 36
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 ADVPN Use Case 2.1. Endpoint-to-Endpoint VPN Use Case
Two endpoints wish to communicate securely via a point-to-point Two endpoints wish to communicate securely via a point-to-point
Security Association (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, which would add latency to the
call, consume precious remote bandwidth, and increase overall costs. call, consume precious remote bandwidth, and increase overall costs.
Such a use case also enables connectivity when both behind NAT Such a use case also enables connectivity when both users are behind
gateways. Such a use case ought to allow for seamless connectivity NAT gateways. Such a use case ought to allow for seamless
even as endpoints roam, even if they are moving out from behind a NAT connectivity even as endpoints roam, even if they are moving out from
gateway, from behind one NAT gateway to behind another, or from a behind a NAT gateway, from behind one NAT gateway to behind another,
standalone position to behind a NAT gateway. 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 ADVPN Use Case 2.2. Gateway-to-Gateway VPN Use Case
A typical Enterprise traffic model follows a star topology, with the A typical Enterprise traffic model follows a star topology, with the
gateways connecting to each other using IPsec tunnels. gateways connecting to each other using IPsec tunnels.
However for voice and other rich media traffic that requires a lot of However for voice and other rich media traffic that requires a lot of
bandwidth or is performance sensitive, the traffic tromboning to the bandwidth or is performance sensitive, the traffic tromboning (taking
hub can create traffic bottlenecks on the hub and can lead to an a suboptimal path) to the hub can create traffic bottlenecks on the
increase in cost. A fully meshed solution would make best use of the hub and can lead to an increase in cost. A fully meshed solution
available network capacity and performance but the deployment of a would make best use of the available network capacity and performance
fully meshed solution involves considerable configuration, especially but the deployment of a fully meshed solution involves considerable
when a large number of nodes are involved. It is for this purpose configuration, especially when a large number of nodes are involved.
spoke-to-spoke tunnels are dynamically created and torn-down. For It is for this purpose spoke-to-spoke tunnels are dynamically created
the reasons of cost and manual error reduction, it is desired that and torn-down. For the reasons of cost and manual error reduction,
there be minimal configuration on each gateway. 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, albeit, ones that have an existing
trust relationship (for example two organisations who are trust relationship (for example two organisations who are
collaborating on a project, they may wish to join their networks, collaborating on a project, they may wish to join their networks,
whilst retaining independent control over configuration). It is whilst retaining independent control over configuration). It is
highly desirable that the solution works for the star, full mesh as highly desirable that the solution works for the star, full mesh as
well as dynamic full mesh topology. well as dynamic full mesh topology.
The solution ought to also address the case where gateways use The solution ought to also address the case where gateways use
skipping to change at page 5, line 50 skipping to change at page 5, line 50
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) There is also the case when Layer-3 Virtual Private Networks (L3VPNs)
operate over IPsec Tunnels. 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 impersonation by the other entities. of impersonation by the other entities.
2.3. Endpoint-to-Gateway ADVPN Use Case 2.3. Endpoint-to-Gateway VPN Use Case
An endpoint ought to be able to use the most efficient gateway as it A mobile endpoint ought to be able to use the most efficient gateway
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, which
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 without having to reinitiate the current most efficient gateway in a seamless way without having to
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 changing (e.g. mobile endpoints). Such a solution is also limited by
by the smallest endpoint/ gateway, as the same exhaustive the smallest endpoint/ gateway, as the same exhaustive configuration
configuration is to be applied on all endpoints/ gateways. A more is to be applied on all endpoints/ gateways. A more dynamic, secure
dynamic, secure and scalable system for establishing SAs between and scalable system for establishing SAs between gateways is needed.
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 this problem today is
to use what has been termed a "star topology". In this case one or a to use what has been termed a "star topology". In this case one or a
few gateways are defined as "hub gateways", while the rest of the few gateways are defined as "hub gateways", while the rest of the
systems (whether endpoints or gateways) are defined as "spokes". The systems (whether endpoints or gateways) are defined as "spokes". The
spokes never connect to other spokes. They only open tunnels with spokes never connect to other spokes. They only open tunnels with
the hub gateways. Also for a large number of gateways in one the hub gateways. Also for a large number of gateways in one
administrative domain, one gateway may be defined as the hub, and the administrative domain, one gateway may be defined as the hub, and the
skipping to change at page 7, line 19 skipping to change at page 7, line 16
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, as well as having
lower bandwidth. lower bandwidth.
The challenge is to build a large scale, IPsec protected networks The challenge is to build large scale, IPsec-protected networks that
that can dynamically change with minimum 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 off such solutions as the features are not standardized. Besides
multiple organizations cannot be expected to all choose the same multiple organizations cannot be expected to all choose the same
equipment vendor. 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 mesh)
gateways and endpoints SHOULD minimize configuration changes when a gateways and endpoints needs to minimize configuration changes when a
new gateway or endpoint is added, removed or changed. Adding or new gateway or endpoint is added, removed or changed. Adding or
removing a spoke in the topology MUST NOT require configuration removing a spoke in the topology MUST NOT require configuration
changes to the hubs other than where the spoke was connected to and changes to the hubs other than where the spoke was connected to and
SHOULD NOT require configuration changes to the hub the spoke was SHOULD NOT require configuration changes to the hub the spoke was
connected to. The changes also MUST NOT require configuration connected to. The changes also MUST NOT require configuration
changes in other spokes. changes in other spokes.
Specifically, when evaluating potential proposals, we will compare Specifically, when evaluating potential proposals, we will compare
them by looking at how many endpoints or gateways must be them by looking at how many endpoints or gateways must be
reconfigured when a new gateway or endpoint is added, removed, or reconfigured when a new gateway or endpoint is added, removed, or
skipping to change at page 8, line 16 skipping to change at page 8, line 16
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 setup with other
members of the ADVPN without any configuration changes, even when members of the ADVPN without any configuration changes, even when
peer addresses get updated every time the device comes up. This peer addresses get updated every time the device comes up. This
implies that SPD entries or other configuration based on peer IP implies that SPD entries or other configuration based on peer IP
address will need to be automatically updated, avoided, or handled in address will need to be automatically updated, avoided, or handled in
some manner to avoid a need to manually update policy whenever an some manner to avoid a need to manually update policy whenever an
address changes. 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 minimal or
no, configuration impact. The ADVPN solution SHOULD NOT increase the no, configuration impact. The ADVPN solution SHOULD NOT increase the
amount of information required to configure protocols running over amount of information required to configure protocols running over
IPsec tunnels. IPsec tunnels.
4. In the full mesh and dynamic full mesh topology, Spokes MUST 4. In the full mesh and dynamic full mesh topology, Spokes MUST
allow for direct communication with other spoke gateways and allow for direct communication with other spoke gateways and
endpoints. In the star topology mode, direct communication between endpoints. In the star topology mode, direct communication between
spokes MUST be disallowed. spokes MUST be disallowed.
skipping to change at page 8, line 46 skipping to change at page 8, line 46
security of the communications between ADVPN Peers not associated security of the communications between ADVPN Peers not associated
with that Gateway. with that Gateway.
This requirement is driven by use case 2.1. ADVPN Peers (especially This requirement is driven by use case 2.1. ADVPN Peers (especially
Spokes) become compromised fairly often. The compromise of one ADVPN Spokes) become compromised fairly often. The compromise of one ADVPN
Peer SHOULD NOT affect the security of other unrelated ADVPN Peers. 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 case
endpoints are roaming, even if they cross policy boundaries. This endpoints are roaming, even if they cross policy boundaries. This
would mean the data traffic is minimally affected even as the handoff would mean the data traffic is minimally affected even as the handoff
happens. External factors like firewall, NAT boxes will not be happens. External factors like firewall, NAT boxes that will be part
considered part of this solution. of the overall solution when DVPN 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-endpoint SA
but also the relationship between the endpoints and gateways (such as but also the relationship between the endpoints and gateways (such as
when an endpoint roams to a new network that is handled by a when an endpoint roams to a new network that is handled by a
different gateway). different gateway).
This requirement is driven by use case 2.1. Today's endpoints are This requirement is driven by use case 2.1. Today's endpoints are
mobile and transition often between different networks (from 4G to mobile and transition often between different networks (from 4G to
WiFi and among various WiFi networks). WiFi and among various WiFi networks).
skipping to change at page 10, line 26 skipping to change at page 10, line 29
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 and
reporting of the dynamic changes, to help for trouble shooting such reporting of the dynamic changes, to help for trouble shooting such
environments. 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 when L3VPNs operate over IPsec Tunnels,
for example Provider Edge (PE) based VPN's. An ADVPN MUST support for example Provider Edge (PE) based VPN's. An ADVPN MUST support
L3VPN as an application protected by the IPsec Tunnels. L3VPN as an application 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. There ADVPN solution SHOULD allow the enforcement of per peer
QoS in both the Star as well as the Full Mesh topology. QoS in both the Star as well as the Full Mesh topology.
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 now letting the Hub to
be a single point of failure.
This requirement is driven by demand for all the use cases in
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 requirement document for the ADVPN
solution, and in itself does not introduce any new security concerns. solution, and in itself does not introduce any new security concerns.
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
(PAD). (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
skipping to change at page 11, line 13 skipping to change at page 11, line 21
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 to proxy and
read all traffic to that site. Updates to this database requires a read all traffic to that site. Updates to this database requires a
clear trust model. clear trust model.
Hubs can be a single point of failure and the solutions that
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, Yaron Sheffer, Jorge Coronel especially prominent role. Yoav Nir, Yaron Sheffer, Jorge Coronel
 End of changes. 26 change blocks. 
57 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/