RFC 7018

Auto-Discovery VPN Problem Statement and Requirements

📅 published September 2013, from ietf

RFC 7018: Auto-Discovery VPN Problem Statement and Requirements 🦋

okay bestie, this one is from September 2013 and it's an Informational doc (not a Standards Track spec, so it's a "here's the problem and what we need" vibe, not a rulebook 💅). Two authors wrote it: V. Manral from HP and S. Hanna from Juniper. It's published under ISSN 2070-1721. Its header doesn't list any RFCs it obsoletes or updates, so it's standing on its own ✨

Abstract ✨

okay so this doc is about the problem of getting a huge number of systems to talk directly to each other while using IPsec to keep the traffic between them protected 🔐 It then goes into what a solution has to do.

Setting up every possible tunnel by hand is way too cumbersome in lots of cases 😩 And sometimes the IP addresses of endpoints keep changing, or the endpoints are hiding behind NAT gateways, so static configuration just isn't possible. The Auto-Discovery VPN solution is what's going to handle all of that 💖

Status of This Memo 🧾

this document is not an Internet Standards Track specification. It's published just for informational purposes, so no pressure 🌈

It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, though. See Section 2 of RFC 5741 for that 🤓

If you want the current status, any errata, or a way to send feedback, check out http://www.rfc-editor.org/info/rfc7018 🎀

Copyright Notice 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please actually read these, bestie, because they spell out your rights and restrictions for this document 🧐 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.

Table of Contents 🗺️

1. Introduction ....................................................2
   1.1. Terminology ................................................3
   1.2. Conventions Used in This Document ..........................4
2. Use Cases .......................................................4
   2.1. Use Case 1: Endpoint-to-Endpoint VPN .......................4
   2.2. Use Case 2: Gateway-to-Gateway VPN .........................5
   2.3. Use Case 3: Endpoint-to-Gateway VPN ........................6
3. Inadequacy of Existing Solutions ................................6
   3.1. Exhaustive Configuration ...................................6
   3.2. Star Topology ..............................................6
   3.3. Proprietary Approaches .....................................7
4. Requirements ....................................................7
   4.1. Gateway and Endpoint Requirements ..........................7
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
7. Normative References ...........................................12

1. Introduction ✨

okay so IPsec [RFC4301] gets used in a bunch of different situations, like tunnel-mode site-to-site VPNs and remote access VPNs 🌸 This doc covers both tunneling modes for IPsec gateways and host-to-host transport mode. 🫶

The big topic here is the problem that shows up when you run IPsec at a large scale, plus what a solution needs to do about it. The setup could be a whole pile of VPN gateways linking up different sites, a ton of remote endpoints connecting to some gateways or to each other, or a mix of both 🍓 The gateways and endpoints might all live in one administrative domain, or in a few domains that trust each other.

Section 4.4 of RFC 4301 is where you'll find the major IPsec databases needed for IPsec processing. The catch is that it needs a LOT of configuration for each tunnel, so manually setting up a system with lots of gateways and endpoints becomes basically impossible and super inflexible 😭

Here's the real drama: a lot of the configuration RFC 4301 talks about is required to set up a Security Association. The Internet Key Exchange Protocol (IKE) implementations need to know the identity and credentials of every possible peer system, plus the addresses of the hosts and/or networks sitting behind them. So what we need is a simpler mechanism for dynamically setting up point-to-point tunnels 🦋 Section 2 has a few use cases that show why this matters.

1.1. Terminology 📖

Auto-Discovery Virtual Private Network (ADVPN): a VPN solution that lets a large number of systems talk directly to each other, with minimal configuration and operator intervention, using IPsec to protect the communication between them 🧚
Endpoint: a device that implements IPsec for its own traffic but does not act as a gateway 💜
Gateway: a network device that implements IPsec to protect traffic flowing through the device 🚪
Point-to-Point: communication between two parties without any active participation (like encryption or decryption) from any other parties 🎯
Hub: the central point in a star topology or dynamic full-mesh topology, or one of the central points in the full-mesh style VPN. In other words, it's a gateway that multiple other hubs or spokes connect to. Hubs usually forward traffic coming from encrypted links on to other encrypted links, so there are no devices connected to them in the clear 👑
Spoke: the endpoint in a star topology or dynamic full-mesh topology, or a gateway, that forwards traffic from multiple cleartext devices to other hubs or spokes. Some of those other devices are connected to it in the clear, meaning it encrypts data coming from cleartext devices and forwards it into the ADVPN 🌈
ADVPN Peer: any member of an ADVPN, including gateways, endpoints, hubs, or spokes ✨
Star Topology: a topology where there's direct connectivity only between the hub and each spoke, and where communication between two spokes happens through the hub 🌟
Allied and Federated Environments: environments where you've got multiple different organizations that are closely associated and need to connect to each other 🤝
Full-Mesh Topology: a topology where every spoke has direct connectivity to every other spoke, without the traffic between the spokes having to get redirected through an intermediate hub device 🕸️
Dynamic Full-Mesh Topology: a topology where direct connections exist in a hub-and-spoke manner, but connections between the spokes get created and removed dynamically, on an as-needed basis 🦄
Security Association (SA): defined in [RFC4301] 🔐

1.2. Conventions Used in This Document 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those capital-letter words are the official requirement language, so pay attention to them, bestie 🫡

2. Use Cases 🎀

This section walks through the key use cases for large-scale point-to-point VPNs 💅

In every one of these use cases, the participants (endpoints and gateways) might come from a single organization (administrative domain) or from multiple organizations with an established trust relationship. When multiple organizations are involved, products from multiple vendors get used, so open standards are needed to make everything interoperate 🌸 Setting up communication between participants with no established trust relationship is out of scope for this effort, so we're not doing that one 🙅‍♀️

2.1. Use Case 1: Endpoint-to-Endpoint VPN 💬

Two endpoints want to communicate securely through a point-to-point SA.

Secure endpoint-to-endpoint communication is often driven by the need for high-bandwidth, low-latency local connectivity, instead of slow, expensive links to remote gateways 🚀 For example, two users who are close together might want to place a direct, secure video or voice call without sending it through remote gateways. Those gateways would add latency to the call, eat up precious remote bandwidth, and raise overall costs 💸 This use case also enables connectivity when both users are behind NAT gateways. It ought to allow for seamless connectivity even as endpoints roam, whether they're moving out from behind a NAT gateway, going from behind one NAT gateway to behind another, or going from a standalone position to behind a NAT gateway 🏃‍♀️

In a star topology, when two endpoints communicate, they need an authentication mechanism so that they don't expose themselves to impersonation by the other spoke endpoint 🕵️‍♀️

2.2. Use Case 2: Gateway-to-Gateway VPN 🌐

A typical Enterprise traffic model follows a star topology, with the gateways connecting to each other using IPsec tunnels 🏢

Here's the catch, though: for voice and other rich media traffic that needs a lot of bandwidth or is performance sensitive, traffic tromboning (taking 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 would make the best use of available network capacity and performance. But deploying a fully meshed solution involves considerable configuration, especially when a large number of nodes are involved 🥴 That's why spoke-to-spoke tunnels get dynamically created and torn down. For the sake of cost and manual error reduction, it's desired that there be minimal configuration on each gateway 💖

The solution ought to work when the endpoints are in different administrative domains that have an existing trust relationship. For example, two organizations collaborating on a project might want to join their networks while keeping independent control over their configuration 🤓 It's highly desirable that the solution works for the star, full-mesh, and dynamic full-mesh topologies 🌈

The solution ought to also address the case where gateways use dynamic IP addresses 🌀

The routing implications of gateway-to-gateway communication also need to be addressed. In the simple case, selectors provide enough information for a gateway to forward traffic appropriately 🧭 In other cases, additional tunneling (e.g., Generic Routing Encapsulation (GRE)) and routing (e.g., Open Shortest Path First (OSPF)) protocols get run over IPsec tunnels, and the configuration impact on those protocols needs to be considered 🎢

There's also the case where Layer 3 Virtual Private Networks (L3VPNs) operate over IPsec tunnels 🦋

When two gateways communicate, they need to use an authentication mechanism so that they don't expose themselves to the risk of impersonation by the other entities 🔒

2.3. Use Case 3: Endpoint-to-Gateway VPN 🗺️

A mobile endpoint ought to be able to use the most efficient gateway as it roams around the Internet 🧳

A mobile user roaming on the Internet may connect to a gateway that, because of the roaming, is no longer the most efficient one to use. The reasons could be cost, efficiency, latency, or some other factor 🤔 The mobile user ought to be able to discover the current, most efficient gateway and connect to it in a seamless way, without having to bring down the connection ✨

part 1 of 3 done, bestie! more coming, so stay tuned 🫶💖

3. Inadequacy of Existing Solutions ✨

Okay so there are a bunch of solutions floating around for these problems, right? 💅 But none of them is adequate, and here's exactly why, bestie. 🫶

3.1. Exhaustive Configuration

One super simple idea is to pre-configure every gateway and endpoint with all the info needed to figure out which gateway or endpoint is the best one, and then set up an SA with that one. 🧚 But this doesn't scale in a big network with hundreds of thousands of gateways and endpoints, especially when there are multiple administrative domains and everything is changing fast (hello, mobile endpoints 📱). It's also limited by the smallest endpoint or gateway, since the same exhaustive configuration has to be applied on all of them. 😭 So we really need a more dynamic, secure, and scalable system for setting up SAs between gateways. 💜

3.2. Star Topology

The most common way people handle part of this today is something called a "star topology" 🌟. One or a few gateways get defined as "hub gateways", and everything else (endpoints or gateways) gets defined as "spokes". Spokes never connect to other spokes. They only open tunnels with the hub gateways. Also, for a big number of gateways in one administrative domain, one gateway might get defined as the hub, and the rest of the gateways and remote access clients connect only to that one. 🦋

This gets complicated when the spokes use dynamic IP addresses and DNS with dynamic updates needs to be used. It's also desired that there's minimal to no configuration on the hub as the number of spokes grows and new spokes get added and deleted randomly. 🙈

Another problem is that a star topology creates a high load on the hub gateways, as well as on the connection between the spokes and the hub. That load hits both processing power and network bandwidth. A single packet in the hub-and-spoke setup can be encrypted and decrypted multiple times. 💀 It would be way better if these gateways and clients could initiate tunnels between them, bypassing the hub gateways. Plus, the path bandwidth to the hub gateways may be lower than the path between the spokes. For example, two remote access users sitting in the same building with high-speed WiFi (like at an IETF meeting) could be routing their whole conversation through the hub gateways of their respective employers. That seems extremely wasteful when a more optimal direct path exists. 🍓

The challenge is to build large-scale IPsec-protected networks that can dynamically change with minimal administrative overhead. 👑

3.3. Proprietary Approaches

Several vendors offer proprietary solutions to these problems. 🌈 But these solutions offer no interoperability between one vendor's equipment and another's. That means they're generally restricted to use within one organization, and it's harder to move away from them since the features aren't standardized. Besides, multiple organizations can't be expected to all choose the same equipment vendor. 🙄

4. Requirements

This section defines the requirements the solution will be built on. 🎀

4.1. Gateway and Endpoint Requirements

For any network topology (star, full mesh, and dynamic full mesh), when a new gateway or endpoint is added, removed, or changed, configuration changes are minimized as follows. Adding or removing a spoke in the topology MUST NOT require configuration changes to hubs other than where the spoke was connected, and SHOULD NOT require configuration changes to the hub the spoke was connected to. The changes also MUST NOT require configuration changes in other spokes.

Specifically, when we evaluate potential proposals, we'll 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 that reconfiguration is, plus the amount of static configuration required. 🔍

This requirement is driven by use cases 1 and 2 and by the scaling limitations pointed out in Section 3.1. 🧠

ADVPN Peers MUST allow IPsec tunnels to be set up with other members of the ADVPN without any configuration changes, even when peer addresses get updated every time the device comes up. This implies that Security Policy Database (SPD) entries or other configuration based on a peer IP address will need to be automatically updated, avoided, or handled in some manner, so nobody has to manually update policy whenever an address changes. 💅
In many cases, additional tunneling protocols (e.g., GRE) or routing protocols (e.g., OSPF) run over the IPsec tunnels. Gateways MUST allow for the operation of tunneling and routing protocols over spoke-to-spoke IPsec tunnels with minimal or no configuration impact. The ADVPN solution SHOULD NOT increase the amount of information required to configure protocols running over IPsec tunnels. 🧚
In the full-mesh and dynamic full-mesh topologies, spokes MUST allow for direct communication with other spoke gateways and endpoints. In the star topology mode, direct communication between spokes MUST be disallowed.

This requirement is driven by use cases 1 and 2 and by the limitations of a star topology pointed out in Section 3.2. 🌸

ADVPN Peers MUST NOT have a way to get the long-term authentication credentials for any other ADVPN Peers. The compromise of an endpoint MUST NOT affect the security of communications between other ADVPN Peers. The compromise of a gateway SHOULD NOT affect the security of communications between ADVPN Peers not associated with that gateway. 🔐

This requirement is driven by use case 1. ADVPN Peers (especially spokes) become compromised fairly often 😭. The compromise of one ADVPN Peer SHOULD NOT affect the security of other unrelated ADVPN Peers.

Gateways SHOULD allow for seamless handoff of sessions in cases where endpoints are roaming, even if they cross policy boundaries. This means data traffic is minimally affected even as the handoff happens. External factors like firewalls and NAT boxes that will be part of the overall 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 but also the relationship between the endpoints and gateways (such as when an endpoint roams to a new network that is handled by a different gateway).

This requirement is driven by use case 1. Today's endpoints are mobile and transition often between different networks (from 4G to WiFi and among various WiFi networks). 📶

Gateways SHOULD allow for easy handoff of a session to another gateway, to optimize latency, bandwidth, load balancing, availability, or other factors, based on policy.

This ability to migrate traffic from one gateway to another applies regardless of whether the gateways in question are hubs or spokes. It even applies when a gateway (hub or spoke) moves in the network, as may happen with a vehicle-based network. 🚗

This requirement is driven by use case 3.

Gateways and endpoints MUST have the capability to participate in an ADVPN even when they are located behind NAT boxes. However, in some cases they may be deployed in such a way that they won't be fully reachable behind a NAT box. It's especially difficult to handle cases where the hub is behind a NAT box. When the two endpoints are both behind separate NATs, communication between these spokes SHOULD be supported using workarounds 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 1 and 2. Endpoints are often behind NATs, and gateways sometimes are. IPsec SHOULD continue to work seamlessly regardless, using ADVPN techniques whenever possible and providing graceful fallback to hub-and-spoke techniques as needed. ✨

Changes such as establishing a new IPsec SA SHOULD be reportable and manageable. However, creating a MIB or other management technique is not within scope for this effort. 📊

This requirement is driven by manageability concerns for all the use cases, especially use case 2. As IPsec networks become more dynamic, management tools become more essential.

To support allied and federated environments, endpoints and gateways from different organizations SHOULD be able to connect to each other. 🤝