< draft-ietf-ipsecme-ad-vpn-problem-00.txt   draft-ietf-ipsecme-ad-vpn-problem-01.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: February 22, 2013 HP Expires: May 30, 2013 HP
August 21, 2012 November 26, 2012
Auto Discovery VPN Problem Statement and Requirements Auto Discovery VPN Problem Statement and Requirements
draft-ietf-ipsecme-ad-vpn-problem-00 draft-ietf-ipsecme-ad-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. 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 February 22, 2013. This Internet-Draft will expire on May 30, 2013.
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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Endpoint-to-Endpoint AD VPN Use Case . . . . . . . . . . . 5 2.1. Endpoint-to-Endpoint AD VPN Use Case . . . . . . . . . . . 5
2.2. Gateway-to-Gateway AD VPN Use Case . . . . . . . . . . . . 5 2.2. Gateway-to-Gateway AD VPN Use Case . . . . . . . . . . . . 5
2.3. Endpoint-to-Gateway AD VPN Use Case . . . . . . . . . . . 6 2.3. Endpoint-to-Gateway AD VPN Use Case . . . . . . . . . . . 6
3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . . 7 3. Inadequacy of Existing Solutions . . . . . . . . . . . . . . . 7
3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . . 7 3.1. Exhaustive Configuration . . . . . . . . . . . . . . . . . 7
3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Star Topology . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . . 8 3.3. Proprietary Approaches . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Gateway and Endpoint Requirements . . . . . . . . . . . . 9 4.1. Gateway and Endpoint Requirements . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . . 14 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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 and the requirements on a solution to address deployments of IPsec and the requirements on a solution to address
skipping to change at page 3, line 44 skipping to change at page 3, line 44
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 - 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 Hub - The central point in a star topology/ dynamic full mesh
a gateway. topology, or one of the central points in the full mesh style VPN,
i.e. gateway where multiple other hubs or spokes connect to. The
hubs usually forward traffic coming from encrypted links to other
encrypted links, i.e. there is no devices connected to it in clear.
Spoke - The edge devices in a star topology, implemented in endpoints Spoke - The edge devices in the a star topology/ dynamic full mesh
or gateways. topology, or gateway which forwards traffic from multiple cleartext
devices to other hubs or spokes, and some of those other devices are
connected to it in clear (i.e. it encrypt data coming from cleartext
device and forwards it to the AD VPN).
Star topology - This is the topology where there is direct
connectivity only between the hub and spoke and communication between
the 2 spokes happens through the hub.
Full Mesh topology - This is the topology where there is a direct
connectivity between every Spoke to every other Spoke directly,
without the traffic between the spokes having to be redirected
through an intermediate hub device.
Dynamic Full Mesh topology - This is the topology where direct
connections exist in a hub and spoke manner, but dynamic connections
are created/ removed between the spokes on a need basis.
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 5, line 42 skipping to change at page 5, line 42
connectivity even as endpoints roam, even if they are moving out from connectivity even as endpoints roam, even if they are moving out from
behind a gateway, from behind one gateway to behind another, or from behind a gateway, from behind one gateway to behind another, or from
a standalone position to behind a gateway. a standalone position to behind a gateway.
In a hub and spoke topology when two endpoints communicate, they must In a hub and spoke topology when two endpoints communicate, they must
use a mechanism for authentication, such that they do not expose them use a mechanism for authentication, such that they do not expose them
to impersonation by the other spoke endpoint. to impersonation by the other spoke endpoint.
2.2. Gateway-to-Gateway AD VPN Use Case 2.2. Gateway-to-Gateway AD VPN Use Case
A typical Enterprise traffic model is hub and spoke, 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 the voice and other rich media traffic that occupies a However for the voice and other rich media traffic that requires a
lot of bandwidth and the traffic tromboning to the hub can create lot of bandwidth or is performance sensitive, the traffic tromboning
traffic bottlenecks on the hub and can lead to a increase cost. It to the hub can create traffic bottlenecks on the hub and can lead to
is for this purpose spoke-to-spoke tunnels are dynamically created an increase in cost. A fully meshed solution is would make best use
and torn-down. of the available network capacity and performance but the deployment
of a fully meshed solution involves considerable configuration,
especially when a large number of nodes are involved. For the
reasons of cost and manual error reduction, it is desired that there
be minimal configuration on each gateway.
The spoke gateways can themselves come up and down, getting different The solution should work in cases where the endpoints are
IP addresses in the process, making th static configuration administrated by separate management domains, albeit, ones that have
impossible. an existing trust relationship (for example two organisations who are
collaborating on a project, they may wish to join their networks,
whilst retaining independent control over configuration)It is for
this purpose spoke-to-spoke tunnels are dynamically created and torn-
down. It is highly desirable that the solution works for the star,
full mesh as well as dynamic full mesh topology.
Also for the reasons of cost and manual error reduction, it is The gateways can themselves come up and down, getting different IP
desired there be minimal or even no configuration on the hub as a new addresses in the process, making static configuration impossible.
spoke Router is added or removed.
In a hub and spoke topology when two spoke gateways communicate, they When two gateways communicate, they must use a mechanism for
must use a mechanism for authentication, such that they do not expose authentication, such that they do not expose themselves to the risk
them to impersonation by the other gateways spoke. of impersonation by the other entities.
2.3. Endpoint-to-Gateway AD VPN Use Case 2.3. Endpoint-to-Gateway AD VPN Use Case
An endpoint should be able to use the most efficient gateway as it An endpoint should be able to use the most efficient gateway as it
roams in the internet. 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 should be able to discover and then connect to the The mobile user should be able to discover and then connect to the
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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). Such a solution is also limited by the (e.g. mobile endpoints). Such a solution is also limited by the
smallest endpoint/ gateway, as the same exhaustive configuration is smallest endpoint/ gateway, as the same exhaustive configuration is
to be applied on all endpoints/ gateways. A more dynamic, secure and to be applied on all endpoints/ gateways. A more dynamic, secure and
scalable system for establishing SAs between gateways is needed. 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 a part of this this problem today is
been termed a "star topology". In this case one or a few gateways to use what has been termed a "star topology". In this case one or a
are defined as "hub gateways", while the rest of the systems (whether few gateways are defined as "hub gateways", while the rest of the
endpoints or gateways) are defined as "spokes". The spokes never systems (whether endpoints or gateways) are defined as "spokes". The
connect to other spokes. They only open tunnels with the hub spokes never connect to other spokes. They only open tunnels with
gateways. Also for a large number of gateways in one administrative the hub gateways. Also for a large number of gateways in one
domain, one gateway may be defined as the hub, and the rest of the administrative domain, one gateway may be defined as the hub, and the
gateways and remote access clients connect only to that gateway. rest of the gateways and remote access clients connect only to that
gateway.
This solution however does not work when the spokes get dynamic IP This solution however does not work when the spokes get dynamic IP
address which the "hub gateways" cannot be configured with. It is address which the "hub gateways" cannot be configured with. It is
also desired that there is minimal to no configuration on the hub as also desired that there is minimal to no configuration on the hub as
the number of spokes increases and new spokes are added and deleted the number of spokes increases and new spokes are added and deleted
randomly. 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 is both in processing power and in 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 three times. It would be much preferable if encrypted and decrypted multiple times. It would be much preferable
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 a large scale, IPsec protected networks
that can dynamically change with minimum administrative overhead. that can dynamically change with minimum administrative overhead.
skipping to change at page 9, line 7 skipping to change at page 9, line 7
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 is currently being updated and hence under flux. This sectiondefines the requirements, on which the solution will be
based.
4.1. Gateway and Endpoint Requirements 4.1. Gateway and Endpoint Requirements
1. For any network topology (whether hub-and-spoke or Full Mesh) 1. For any network topology (star, full mesh and dynamic full mesh)
gateways and endpoints MUST minimize configuration changes when a new gateways and endpoints MUST minimize configuration changes when a new
gateway or endpoint is added, removed or changed. Specifically, when gateway or endpoint is added, removed or changed. Adding or removing
evaluating potential solutions, we will compare them by looking at a spoke in the topology MUST NOT require configuration changes to the
how many endpoints or gateways must be reconfigured when a new hubs other than where the spoke was connected to and SHOULD NOT
gateway or endpoint is added, removed, or changed and how substantial require configuration changes to the hub the spoke was connected to.
this reconfiguration is. The changes also MUST NOT require configuration changes in other
spokes.
Specifically, when evaluating potential proposals, we will compare
them by looking at how many endpoints or gateways must be
reconfigured when a new gateway or endpoint is added, removed, or
changed and how substantial this reconfiguration is, besides the
amount of static configuration required.
This requirement is driven by use cases 2.1 and 2.2 and by the This requirement is driven by use cases 2.1 and 2.2 and by the
scaling limitations pointed out in section 3.1. scaling limitations pointed out in section 3.1.
2. Gateways and endpoints MUST allow IPsec Tunnels to be setup 2. Gateways and endpoints MUST allow IPsec Tunnels to be setup
without any configuration changes, even when peer addresses get without any configuration changes, even when peer addresses get
updated every time the device comes up. This implies that SPD updated every time the device comes up. This implies that SPD
entries or other configuration based on peer IP address will need to entries or other configuration based on peer IP address will need to
be automatically updated, avoided, or handled in some manner to avoid be automatically updated, avoided, or handled in some manner to avoid
a need to manually update policy whenever an address changes. a need to manually update policy whenever an address changes.
This requirement is driven by use cases 2.1 and 2.2 and by the This requirement is driven by use cases 2.1 and 2.2 and by the
scaling limitations pointed out in section 3.1. scaling limitations pointed out in section 3.1.
3. Gateways MUST allow tunnel binding, such that applications like 3. In many cases additional tunneling protocols (i.e. GRE) or
Routing using the tunnels can work seamlessly without any updates to Routing protocols (i.e. OSPF) are run over the IPsec tunnels.
the higher level application configuration i.e. OSPF configuration. Gateways MUST allow for the operation of tunneling and Routing
protocols operating over spoke-to-spoke IPsec Tunnels with minimal or
no, configuration impact. Routing using the tunnels can work
seamlessly without any updates to the higher level application
configuration i.e. OSPF configuration, when the tunnel parameter
changes.
4. In a hub-and-spoke topology, spoke gateways and endpoints 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. endpoints. In the star topology mode, direct communication 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 2.1 and 2.2 and by the
limitations of a star topology pointed out in section 3.2. limitations of a star topology pointed out in section 3.2.
5. One spoke MUST NOT be able to impersonate another spoke. 5. One spoke MUST NOT be able to impersonate another spoke.
This requirement is driven by use case 2.1. Endpoints become This requirement is driven by use case 2.1. Spokes become
compromised fairly often. The compromise of one endpoint should not compromised fairly often. The compromise of one Spoke should not
affect the security of other endpoints. affect the security of other endpoints.
6. Gateways SHOULD allow for easy 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
means that TCP session breakage and packet loss should be avoided, would mean the data traffic is minimally affected even as the handoff
when possible. happens. External factors like firewall, NAT box will not be
considered part of this solution.
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).
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 requirement is driven by use case 2.3. This requirement is driven by use case 2.3.
8. Gateways and endpoints MUST be able to work when they are behind 8. Gateways and endpoints MUST be able to work when they are behind
NAT boxes. However, it is especially difficult to handle cases where NAT boxes. It is especially difficult to handle cases where the Hub
gateways are behind NATs and where two endpoints are both behind is behind a NAT box, such a requirement MAY be supported. Where the
separate NATs. In those cases, workarounds MAY be used such as port two endpoints are both behind separate NATs, communication between
forwarding by the NAT or detecting when two spokes are behind these spokes SHOULD be supported. In the cases, workarounds MAY be
uncooperative NATs and using a hub in that case. used such as port forwarding by the NAT or detecting when 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 2.1 and 2.2. Endpoints are
often behind NATs and gateways sometimes are. IPsec should continue often behind NATs and gateways sometimes are. IPsec should continue
to work seamlessly regardless, using AD VPN techniques whenever to work seamlessly regardless, using AD VPN techniques whenever
possible and providing graceful fallback to hub and spoke techniques possible and providing graceful fallback to hub and spoke techniques
as needed. 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 use
cases, especially use case 2.2. As IPsec networks become more cases, especially use case 2.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 to
each other. each other.
11. The administrator of the ADVPN SHOULD allow for the
configuration of a Star, Full mesh or a partial full mesh topology,
based on which tunnels are allowed to be setup.
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 solution SHOULD allow administrators the ability to 12. The ADVPN solution SHOULD be able to scale for multicast
configure a variety of permissible topologies: full mesh, partial traffic.
mesh, star, etc. They should be able to set different topologies for
different types of traffic: voice, video, web, email, etc.
This requirement is driven by counter-balancing requirements to log This requirement is driven by the use case 2.2, where the amount of
or control traffic of certain types (e.g. email) while ensuring rich media multicast traffic is increasing.
efficient, low-latencies flows of other types (e.g. video).
13. The ADVPN solution SHOULD allow for easy monitoring, logging and
reporting of the dynamic changes, to help for trouble shooting such
environments.
This requirement is driven by demand for all the use cases in
federated and allied environments.
14. The ADVPN solution MUST support Provider Edge (PE) based VPN's.
This requirement is driven by demand for all the use cases in
federated and allied environments.
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
(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
it is implied that these databases are static and pre-configured by a it is implied that these databases are static and pre-configured by a
 End of changes. 26 change blocks. 
67 lines changed or deleted 124 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/