RFC 4111

RFC 4111: Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) 🎀

okay so this is the big one for PPVPN security, and it's giving "I wrote the checklist so everyone else can check their homework" 💅 🦋

Written by L. Fang, Ed. from AT&T Labs. (the Ed. means they were the editor, aka the one who kept everyone's drafts organized 🫶). It was published in July 2005 as an Informational document, which means it shares information with the Internet community and doesn't set a standard ✨. It's part of the Network Working Group series of Requests for Comments. It doesn't list any RFCs it obsoletes or updates, so it's a standalone doc 🌸

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice 🌈

Copyright (C) The Internet Society (2005).

Abstract 💜

okay bestie, the abstract is the whole vibe in one go 🫶 This document is all about security for Provider-Provisioned Virtual Private Networks (PPVPNs). First, it goes through the security threats that show up in PPVPNs and the defensive techniques people can use against them 🛡️ It looks at issues that come from malicious behavior by anyone, and from careless or wrong behavior by the providers too. It also covers how these attacks should be detected and reported 🚨

Then it talks about what users might reasonably want for PPVPN security, and how those wants turn into requirements for the providers. The provider might have extra requirements of its own, so its network infrastructure is secure enough to keep PPVPN customers happy 💖 Last but not least, the document defines a template you can use to describe and analyze the security characteristics of a specific PPVPN technology. It's literally a checklist, and I'm obsessed 😭✨

Table of Contents 🧚

1.  Introduction .................................................  2
2.  Terminology ..................................................  4
3.  Security Reference Model .....................................  4
4.  Security Threats .............................................  6
    4.1.  Attacks on the Data Plane ..............................  7
    4.2.  Attacks on the Control Plane ...........................  9
5.  Defensive Techniques for PPVPN Service Providers ............. 11
    5.1.  Cryptographic Techniques ............................... 12
    5.2.  Authentication ......................................... 20
    5.3.  Access Control Techniques .............................. 22
    5.4.  Use of Isolated Infrastructure ......................... 27
    5.5.  Use of Aggregated Infrastructure ....................... 27
    5.6.  Service Provider Quality Control Processes ............. 28
    5.7.  Deployment of Testable PPVPN Service ................... 28
6.  Monitoring, Detection, and Reporting of Security Attacks ..... 28
7.  User Security Requirements ................................... 29
    7.1.  Isolation .............................................. 30
    7.2.  Protection ............................................. 30
    7.3.  Confidentiality ........................................ 31
    7.4.  CE Authentication ...................................... 31
    7.5.  Integrity .............................................. 31
    7.6.  Anti-replay ............................................ 32
8.  Provider Security Requirements ............................... 32
    8.1.  Protection within the Core Network ..................... 32
    8.2.  Protection on the User Access Link ..................... 34
    8.3.  General Requirements for PPVPN Providers ............... 36
9.  Security Evaluation of PPVPN Technologies .................... 37
    9.1.  Evaluating the Template ................................ 37
    9.2.  Template ............................................... 37
10. Security Considerations ...................................... 40
11. Contributors ................................................. 41
12. Acknowledgement .............................................. 42
13. Normative References ......................................... 42
14. Informative References ....................................... 43

1. Introduction ✨

Security is an integral part of PPVPN services, no cap 🔐 The motivation and rationale for both Provider-Provisioned Layer-2 VPN and Provider-Provisioned Layer-3 VPN services are covered in [RFC4110] and [RFC4031]. Those docs both admit that security is important and integral for PPVPN services, for VPN customers and for VPN service providers alike. Both sides benefit from a PPVPN Security Framework document that lists the customer and provider security requirements for PPVPN services. It can be used to check how well a particular technology protects against security threats and meets those requirements 🫶

First, we describe the security threats that matter in the context of PPVPNs, and the defensive techniques that can be used to fight them 🛡️ We look at security issues that come from malicious or incorrect behavior by users and other parties, and from negligent or incorrect behavior by the providers. A big part of defense is detecting and reporting a security attack, and this document covers that too 🚨 IP mobility within PPVPNs brings its own special considerations, but those are out of scope for this document, so we're skipping them 🙈

Then we talk about the possible user and provider security requirements for a PPVPN service. User expectations for the security characteristics of a VPN service must be met. Those user requirements turn into matching requirements for the providers offering the service. On top of that, providers have their own security requirements to protect their network infrastructure, securing it to the level needed to deliver PPVPN services alongside their other services 💅

Finally, we define a template that can describe the security characteristics of a specific PPVPN technology, in a way that matches the security framework in this document 🎀 Analyzing the security properties of specific technologies is not in scope here. The goal is a shared tool, basically a checklist, that other documents can use for in-depth security analysis of individual PPVPN technologies. That way everyone describes their security in a complete and consistent way, and different technologies have common ground to be compared on 🦋

It's important to be clear that this document only describes the security requirements that users and providers have for PPVPN services. It is not trying to write precise "requirements" for each specific technology, meaning it doesn't define the mechanisms and techniques that have to be implemented to meet those user and provider needs 💜

This document is organized as follows. Section 2 defines the terminology used in the document. Section 3 defines the security reference model for security in PPVPN networks. Section 4 describes the security threats that are specific to PPVPNs. Section 5 reviews defense techniques that may be used against those threats. Section 6 describes how attacks may be detected and reported. Section 7 discusses the user security requirements that apply to PPVPN services. Section 8 describes additional security requirements on the provider to guarantee the security of the network infrastructure providing PPVPN services. In Section 9, we provide a template that may be used to describe the security characteristics of specific PPVPN technologies. Finally, Section 10 discusses security considerations 🌸

2. Terminology 🍓

This document uses PPVPN-specific terminology. Definitions and details for that terminology can be found in [RFC4026] and [RFC4110]. The most important definitions are repeated in this section, and for everything else, the reader is referred to [RFC4026] and [RFC4110] 📚

• CE: Customer Edge device, a router or a switch in the customer network interfacing with the service provider's network.
• P: Provider Router. The Provider Router is a router in the service provider's core network that does not have interfaces directly toward the customer. A P router is used to interconnect the PE routers. A P router does not have to maintain VPN state and is thus VPN unaware 🧠
• PE: Provider Edge device, the equipment in the service provider's network that interfaces with the equipment in the customer's network.
• PPVPN: Provider-Provisioned Virtual Private Network, a VPN that is configured and managed by the service provider (and thus not by the customer itself) 👑
• SP: Service Provider.
• VPN: Virtual Private Network, which restricts communication between a set of sites using an IP backbone shared by traffic that is not going to or coming from those sites 🔒

3. Security Reference Model ✨

okay so this section sets up the reference model for security in PPVPN networks 🎀

A PPVPN core network is the central infrastructure (P and PE routers) that PPVPN services get delivered over 🌐 It's made up of one or more SP networks. Every network element in the core is under the operational control of one or more PPVPN service providers. Even when several providers run the core together, it still looks like a single zone of trust to PPVPN users 🫶 But here's the tea: those providers still have to protect themselves from each other 👀 PPVPN services can also ride over the Internet, and when they do, the Internet becomes a logical part of the PPVPN core 🦋

A PPVPN user is a company, institution, or residential client of the PPVPN service provider 💼

A PPVPN service is a private network service that a service provider makes available to a PPVPN user 💖 It's built out of virtual constructs sitting on a shared PPVPN core network. The service connects the sites of a PPVPN user, so it's giving private network but make it shared infrastructure 🧚

Extranets are VPNs where the sites belong to different (legal) entities 🌸 They're another PPVPN deployment scenario, where restricted and controlled communication is allowed between trusted zones, usually through well-defined transit points. Very controlled, very intentional 💅

So this document treats each PPVPN as one trusted zone, and the PPVPN core as another trusted zone 🔥 The main worry is security breaches coming from the "outside" of a trusted zone into the "inside" of that zone. Here's the picture of how trusted zones fit into the PPVPN framework:

   +------------+                             +------------+
   | PPVPN      +-----------------------------+      PPVPN |
   | user           PPVPN                             user |
   | site       +---------------------XXX-----+       site |
   +------------+  +------------------XXX--+  +------------+
                   |   PPVPN core     | |  |
                   +------------------| |--+
                                      | |
                                      | +------\
                                      +--------/  Internet

                Figure 1: The PPVPN trusted zone model

In principle, the trusted zones should be separate 🙈 But PPVPN core networks often offer Internet access too, so a transit point (marked "XXX" in the figure) gets defined. Plot twist, but it's manageable ✨

The key requirement of a "virtual private" network (VPN) is that sharing the core infrastructure with other VPNs must not compromise the security of the VPN's trusted zone 🔒 That's the whole vibe.

Security against threats that start inside the same trusted zone as their target is out of scope for this document 🚫 Think attacks from a user in a PPVPN against other users in that same PPVPN, or attacks happening entirely inside the core network.

Also out of scope are all the aspects of network security that don't depend on whether a network is a PPVPN or a private network 💀 For example, attacks from the Internet against a web server inside a given PPVPN aren't considered here, unless the way the PPVPN is provisioned could make a difference to that server's security.

4. Security Threats 😤

This section talks about the network security threats that can endanger PPVPNs 🛡️ The discussion is limited to threats that are unique to PPVPNs, or that hit PPVPNs in unique ways. A successful attack on a particular PPVPN, or on a service provider's PPVPN infrastructure, may cause one or more of these ill effects:

• observation, modification, or deletion of PPVPN user data,
• replay of PPVPN user data,
• injection of non-authentic data into a PPVPN,
• traffic pattern analysis on PPVPN traffic,
• disruption of PPVPN connectivity, or
• degradation of PPVPN service quality.

It helps to think of threats to a PPVPN, whether malicious or accidental, as coming from different kinds of sources 🧐 For example, they may come from:

• users of other PPVPNs provided by the same PPVPN service provider,
• the PPVPN service provider or persons working for it,
• other persons who obtain physical access to a service provider site,
• other persons who use social engineering methods to influence behavior of service provider personnel,
• users of the PPVPN itself, i.e., intra-VPN threats (such threats are beyond the scope of this document), or
• others, i.e., attackers from the Internet at large.

Some parties in PPVPNs can be in more advantageous positions, which lets them launch attacks that others can't 👀 For example, users of different PPVPNs provided by the same service provider may be able to launch attacks that people completely outside the network can't.

Security is generally a compromise between expense and risk, so it's also worth thinking about how likely different attacks are 💰 There's at least a perceived difference in how likely most types of attacks are to succeed in different environments, such as:

• in a PPVPN contained within one service provider's network, or
• in a PPVPN transiting the public Internet.

Most types of attacks get easier to mount, and therefore more likely, as the shared infrastructure providing VPN service grows from a single service provider, to multiple cooperating providers, and then to the global Internet 📈 Attacks that might not be likely enough to worry about in a tightly controlled environment often deserve defenses in broader, more open ones.

The following sections discuss specific types of exploits that threaten PPVPNs 🎯

4.1. Attacks on the Data Plane

This category covers attacks on the PPVPN user's data, as seen by the service provider 📦 Note that from the PPVPN user's point of view, some of this might be control plane traffic, e.g., routing protocols running from PPVPN user site to PPVPN user site via an L2 PPVPN.

4.1.1. Unauthorized Observation of Data Traffic

This is "sniffing" VPN packets and examining their contents 👁️ It can lead to exposure of confidential information. It can also be a first step toward other attacks (described below) where the recorded data is modified and re-inserted, or re-inserted unchanged.

4.1.2. Modification of Data Traffic

This is changing the contents of packets as they travel through the VPN ✏️

4.1.3. Insertion of Non-authentic Data Traffic: Spoofing and Replay

This is inserting packets that don't belong into the VPN (or "spoofing") with the goal of having the recipient accept them as legitimate 😈 This category also includes inserting copies of once-legitimate packets that were recorded and replayed.

4.1.4. Unauthorized Deletion of Data Traffic

This is causing packets to be discarded as they traverse the VPN 🗑️ It's a specific type of Denial-of-Service attack.

4.1.5. Unauthorized Traffic Pattern Analysis

This is "sniffing" VPN packets and examining aspects or meta-aspects of them that may still be visible even when the packets themselves are encrypted 🕵️‍♀️ An attacker might gain useful information from the amount and timing of traffic, packet sizes, source and destination addresses, etc. For most PPVPN users, this type of attack is generally considered significantly less of a concern than the other types discussed in this section 😌

4.1.6. Denial-of-Service Attacks on the VPN

Denial-of-Service (DoS) attacks are ones where an attacker tries to disrupt or prevent the use of a service by its legitimate users 🚨 Taking network devices out of service, modifying their configuration, or overwhelming them with requests for service are several of the possible avenues for a DoS attack.

Overwhelming the network with requests for service, also known as a "resource exhaustion" DoS attack, may target any resource in the network, e.g., link bandwidth, packet forwarding capacity, session capacity for various protocols, and CPU power 🔥

DoS attacks of the resource exhaustion type can be mounted against the data plane of a particular PPVPN by trying to insert (spoof) an overwhelming quantity of non-authentic data into the VPN from outside that VPN 🌊 Potential results include exhausting the bandwidth available to that VPN, or overwhelming the VPN's cryptographic authentication mechanisms.

Data plane resource exhaustion attacks can also be mounted by flooding the service provider's general (VPN-independent) infrastructure with traffic 🌧️ These attacks on the general infrastructure aren't usually a PPVPN-specific issue, unless the attack is mounted by another PPVPN user from a privileged position. For example, a PPVPN user might be able to monopolize network data plane resources and thus disrupt other PPVPNs.)

4.2. Attacks on the Control Plane

This category covers attacks on the control structures operated by the PPVPN service provider 🎛️

4.2.1. Denial-of-Service Attacks on Network Infrastructure

Control plane DoS attacks can be mounted specifically against the mechanisms the service provider uses to provide PPVPNs (e.g., IPsec, MPLS), or against the general infrastructure of the service provider (e.g., P routers or shared aspects of PE routers.) Attacks against the general infrastructure are only within the scope of this document if the attack happens in relation to the VPN service. Otherwise, they aren't a PPVPN-specific issue 🙅‍♀️

Of special concern for PPVPNs is denial of service to one PPVPN user caused by the activities of another 😤 This can happen, for example, if one PPVPN user's activities are allowed to consume excessive network resources of any sort that are also needed to serve other PPVPN users.

The attacks described in the following sections may each have denial of service as one of their effects. Other DoS attacks are also possible 💜

4.2.2. Attacks on Service Provider Equipment via Management Interfaces

This includes unauthorized access to service provider infrastructure equipment, in order to, for example, reconfigure the equipment or extract information (statistics, topology, etc.) about one or more PPVPNs 🔑

This can happen through malicious entry into the systems, or as an inadvertent consequence of inadequate inter-VPN isolation in a PPVPN user self-management interface. (The former isn't necessarily a PPVPN-specific issue.)

4.2.3. Social Engineering Attacks on Service Provider Infrastructure

Attacks where the service provider network gets reconfigured or damaged, or where confidential information gets improperly disclosed, may be mounted by manipulating service provider personnel 🎭 These types of attacks are PPVPN-specific if they affect PPVPN-serving mechanisms. It may be observed that the organizational split (customer, service provider) that is inherent in PPVPNs may make such attacks easier to mount against provider-provisioned VPNs than against VPNs that the customer self-provisions at the IP layer 🫣

4.2.4. Cross-Connection of Traffic between PPVPNs ✨

okay so this one is about when the isolation between separate PPVPNs gets breached 😭 it's giving "who let this happen" energy. It covers stuff like:

• a site getting plugged into the "wrong" VPN 🙈,
• two or more VPNs getting improperly merged 💀,
• a point-to-point VPN connecting the wrong two points, or
• any packet or frame getting delivered outside the VPN it was sent in 🚫.

Cross-connection or misconnection can happen because the service provider or the equipment vendor messed up, or because an attacker did it on purpose 😈. The breach can be physical (like PE-CE links that got plugged in wrong) or logical (like a device that's configured improperly) 🔌.

Anecdotal evidence suggests that cross-connection is one of the biggest security worries for PPVPN users (or people who are thinking about becoming users) 😳 literally a top-tier fear 💅.

4.2.5. Attacks against PPVPN Routing Protocols 🛣️

This is about attacks on the routing protocols the service provider runs that directly support the PPVPN service 🧠. In layer 3 VPNs, that's usually about membership discovery or distributing per-VPN routes. In layer 2 VPNs, it's usually about membership and endpoint discovery. Attacks on using routing protocols to distribute backbone (non-VPN) routes are out of scope for this doc, so we're not going there 🙅‍♀️. The specific attacks on popular routing protocols have been studied a LOT and are described in [RFC3889] 📚 go read that if you want the deep dive 🤓.

4.2.6. Attacks on Route Separation 🚧

"Route separation" just means keeping each PPVPN's topology and reachability info separate from every other PPVPN, and making sure nobody else can get to it (unless the service provider specifically meant to allow it) 🔒. This is only a distinct security concern for layer-3 VPN types where the service provider is involved in routing inside the VPN, which means VR, BGP-MPLS, and the routed version of IPsec 👑. A breach in route separation can reveal topology and addressing info about a PPVPN 👀. It can also cause black hole routing (where traffic just vanishes 🕳️) or unauthorized data plane cross-connection between PPVPNs 🍝.

4.2.7. Attacks on Address Space Separation 🏠

In layer-3 VPNs, the IP address spaces of different VPNs have to stay separate 🧱. In layer-2 VPNs, the MAC address and VLAN spaces of different VPNs have to stay separate too 🎀. If the control plane gets breached in this addressing separation, it can lead to unauthorized data plane cross-connection between VPNs 😱 not it 🙅‍♀️.

4.2.8. Other Attacks on PPVPN Control Traffic 🎭

Besides routing and management protocols (which we covered in the earlier sections 💁‍♀️), there are a bunch of other control protocols that might be directly involved in delivering the PPVPN service 🧚. They're used for things like membership discovery and tunnel establishment, depending on the PPVPN approach. These include, but may not be limited to:

• MPLS signaling (LDP, RSVP-TE),
• IPsec signaling (IKE) ,
• L2TP,
• BGP-based membership discovery, and
• Database-based membership discovery (e.g., RADIUS-based).

Attacks might mess with or disrupt what these protocols are doing, for example through impersonation or DoS attacks 🥺 lowkey scary stuff 🚨.

5. Defensive Techniques for PPVPN Service Providers 🛡️

The defensive techniques in this document are here to describe ways some security threats can be dealt with 🌸. They are NOT meant as requirements for every PPVPN implementation 🙌. The PPVPN provider should figure out which of these techniques apply to their specific service offerings, and the PPVPN user might want to check how valuable these techniques are for their own VPN needs 🧐.

The techniques covered here include encryption, authentication, filtering, firewalls, access control, isolation, aggregation, and other techniques 🧰.

Nothing is ever 100% secure 💀 so defense is about protecting against the attacks that are most likely to happen or that could have the most dire consequences 📉. Absolute protection is rarely achievable, so it's often enough to make the cost of a successful attack higher than what the attacker is willing to spend 💸.

Successfully defending against an attack doesn't always mean the attack has to be stopped from happening or from reaching its target 🎯. In lots of cases, the network can be designed to withstand the attack instead ✨. For example, the introduction of non-authentic packets could be defended against by stopping them from getting in in the first place, or by making it possible to identify and get rid of them before they reach the PPVPN user's system 🗑️. The second option is frequently a much easier task 🫶.

5.1. Cryptographic Techniques 🔐

PPVPN defenses against a wide variety of attacks can get a major glow-up with the proper use of cryptographic techniques ✨. These are the same cryptographic techniques that apply to general network communications 🌐. Generally, these techniques can provide confidentiality (encryption) of communication between devices, authentication of the devices' identities, and detection of a change to the protected data during transit 🕵️‍♀️.

Privacy is a key part (the middle name!) of any Virtual Private Network 💜. In a PPVPN, privacy can be provided by two mechanisms: traffic separation and encryption 🔑. This section focuses on encryption, and traffic separation gets addressed separately 🙂.

Several aspects of authentication are covered in some detail in a separate "Authentication" section 📝.

Encryption adds complexity, so it may not be a standard offering within every PPVPN service 🤷‍♀️. There are a few reasons for this. Encryption adds extra computational burden to the devices doing the encrypting and decrypting 🥵. That can reduce how many user VPN connections a device can handle, or otherwise reduce the device's capacity, which can drive up the provider's costs 💰. Configuring encryption on devices usually makes the device configuration more complex and adds incremental labor cost 🛠️. Encrypting packets typically increases packet lengths, which increases the network traffic load and the likelihood of packet fragmentation, with its increased overhead 📦. (Packet length increase can often be mitigated to some extent by data compression techniques, but that comes with additional computational burden 🗜️.) Finally, some PPVPN providers may already use enough other defensive techniques, like physical isolation or filtering/firewall techniques, that they don't see much extra benefit from encryption 🤔.

The trust model among the PPVPN user, the PPVPN provider, and other parts of the network is a KEY element in deciding whether encryption applies to any specific PPVPN implementation 🔍.

It specifically determines where encryption should be applied, as follows 👇.

• If the data path between the user's site and the provider's PE is not trusted, then encryption may be used on the PE-CE link 🔗.
• If some part of the backbone network is not trusted, particularly in implementations where traffic may travel across the Internet or multiple provider networks, then the PE-PE traffic may be encrypted 🌍.
• If the PPVPN user does not trust any zone outside of its premises, it may require end-to-end or CE-CE encryption service 🫣. This service fits within the scope of this PPVPN security framework when the CE is provisioned by the PPVPN provider 📋.
• If the PPVPN user requires remote access to a PPVPN from a system that is not at a PPVPN customer location (for example, access by a traveler ✈️), there may be a requirement for encrypting the traffic between that system and an access point on the PPVPN or at a customer site. If the PPVPN provider provides the access point, then the customer must cooperate with the provider to handle the access control services for the remote users 🧳. These access control services are usually implemented using encryption as well 🔐.

⚠️ Okay bestie, this part is a big deal. Although CE-CE encryption gives confidentiality against third-party interception, if the PPVPN provider has complete management control over the CE (encryption) devices, then it may be possible for the provider to get into the user's VPN traffic or internal network 👀. Encryption devices can potentially be configured to use null encryption, to bypass encryption processing altogether, or to provide some means of sniffing or diverting unencrypted traffic 😱. So a PPVPN implementation using CE-CE encryption has to consider the trust relationship between the PPVPN user and provider 🤝. PPVPN users and providers may want to negotiate a service level agreement (SLA) for CE-CE encryption that gives an acceptable split of responsibilities for managing encryption on the CE devices 📜.

The split of responsibilities may also be affected by what the CE devices can do 🧩. For example, the CE might support some partitioning of management or a configuration lock-down ability, or it might let both parties verify the configuration 🔒. In general, if the managed CE-CE model is used, the PPVPN user has to have a pretty high level of trust that the PPVPN provider will properly provision and manage the CE devices 🥹💜.

5.1.1. IPsec in PPVPNs ✨

okay bestie, IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the security protocol of choice for encryption at the IP layer (Layer 3), as discussed in [RFC3631]. It gives robust security for IP traffic between pairs of devices 🔐. Non-IP traffic has to be turned into IP packets first, or it can't ride over IPsec. Encapsulation is a common way to do that conversion 🎀.

In the PPVPN model, IPsec can protect IP traffic between PEs, between a PE and a CE, or from CE to CE 🦋. CE-to-CE IPsec can be used in either a provider-provisioned or a user-provisioned model. The user-provisioned CE-CE IPsec model is outside the scope of this document and outside the scope of the PPVPN Working Group, so we're not going there today 🙈. Data encryption done inside the user's site is also out of scope, since the PPVPN just handles it as regular user data. And IPsec can protect IP traffic between a remote user and the PPVPN too 🌸.

IPsec doesn't itself specify an encryption algorithm, which is kind of iconic 💅. It can use a bunch of encryption algorithms with different key lengths, like AES encryption. There are trade-offs between key length, computational burden, and the level of security of the encryption ⚖️. A full discussion of those trade-offs is beyond the scope of this document, so don't come for me 😭. If a PPVPN user wants to assess the level of security a particular IPsec-based PPVPN service offers, they may want to know the specific encryption algorithm and effective key length the provider uses. But honestly, in practice, any currently recommended IPsec encryption offers enough security to substantially reduce the likelihood of being directly targeted by an attacker 🛡️. The other, weaker links in the chain of security are likely to get attacked first, ngl. So PPVPN users may be better off using a Service Level Agreement (SLA) that spells out the service provider's responsibility for ensuring data confidentiality, instead of digging into the specific encryption techniques used in the PPVPN service 📜.

For a lot of the PPVPN provider's network control messages, and some PPVPN user requirements, cryptographic authentication of messages without encryption of the message contents may be totally acceptable security 🧚. With IPsec, message authentication comes from the Authentication Header (AH) or from the Encapsulating Security Protocol (ESP) with authentication only. When control messages need authentication but don't use IPsec, other cryptographic authentication methods are available 💜. The message authentication methods currently considered secure are based on hashed message authentication codes (HMAC) [RFC2104], implemented with a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1) [RFC3174] 🔥.

One recommended mechanism for getting a combination of confidentiality, data origin authentication, and connectionless integrity is using AES in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV) [RFC3602], as the IPsec ESP ✨. Iconic combo, literally.

PPVPNs that provide differentiated services based on traffic type may run into some conflicts with IPsec encryption 😬. Encryption hides the content of the packets, so it may not be possible to tell the encrypted traffic apart the same way as unencrypted traffic. DiffServ markings do get copied to the IPsec header and can provide some differentiation, but not all traffic types can be accommodated by that mechanism 💀.

---

5.1.2. Encryption for Device Configuration and Management 🍓

okay so for configuring and managing PPVPN devices, encryption and authentication of the management connection at a level comparable to what IPsec provides is desirable 🫶.

Several methods of transporting PPVPN device management traffic offer security and confidentiality, and they're all giving main character energy:

• Secure Shell (SSH) offers protection for TELNET [STD8] or terminal-like connections, so you can configure devices safely 🐚.
• SNMP v3 [STD62] provides encrypted and authenticated protection for SNMP-managed devices 🔐.
• Transport Layer Security (TLS) [RFC2246] and the closely-related Secure Sockets Layer (SSL) are widely used for securing HTTP-based communication. That means they can support most XML- and SOAP-based device management approaches 🌈.
• As of 2004, a lot of work was happening in several organizations (OASIS, W3C, WS-I, and others) on securing device management traffic within a "Web Services" framework 🧠. This work uses a wide variety of security models, and it supports multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. So many options, bestie 😭.
• IPsec provides services with security and confidentiality at the network layer 🦋. For device management, its current use is mostly focused on in-band management of user-managed IPsec gateway devices 🎀.

---

5.1.3. Cryptographic Techniques in Layer-2 PPVPNs 🌸

Layer-2 PPVPNs generally won't be able to use IPsec to encrypt the entire network, and that's a vibe check 🙅‍♀️. They may be able to use IPsec for PE-PE traffic where it's encapsulated in IP packets. But IPsec will generally not be applicable for CE-PE traffic in Layer-2 PPVPNs.

Encryption techniques for Layer-2 links are widely available, but they're not within the scope of this document or IETF documents in general 🙈. Layer-2 encryption could be applied to the links from CE to PE, or from CE to CE, as long as the intervening PE devices can handle the encrypted Layer-2 packets properly 🧚‍♀️. On top of that, the user can encrypt the upper-layer traffic carried by the Layer-2 VPN. In that case, confidentiality is maintained 🔒, but it's transparent to the PPVPN provider, so it's also outside the scope of this document. Iykyk 💖.

5.1.4. End-to-End vs. Hop-by-Hop Encryption Tradeoffs in PPVPNs

okay so in a PPVPN, encryption could get slapped on the VPN traffic at a bunch of different spots 🌸 this section spills the tea on the tradeoffs when you set up encryption between different devices in the PPVPN 💅

Encryption usually involves a pair of devices that encrypt the traffic passing between them. The devices might be directly connected (one "hop" apart), or there might be other devices in the middle that carry the encrypted traffic between the pair 🦋 The two extreme cases are hop-by-hop encryption between every adjacent pair of devices along a path, or "end-to-end" encryption only between the end devices along a path. To keep things inside PPVPN territory, we count the "end to end" case as CE to CE rather than fully end to end 🫶

Figure 2 shows a simplified PPVPN topology: the Customer Edge (CE) devices, the Provider Edge (PE) devices, and a variable number of Provider core (P) devices that might sit on the path between two sites in a single VPN, run by a single service provider (SP). In the picture below there are three P devices, but it can be any number ✨

Site_1---CE---PE---P---P---P---PE---CE---Site_2

Figure 2: Simplified PPVPN topology

So, assuming the P devices aren't involved with encryption, there are four basic feasible configurations for encrypting connections among the devices 👑

1. Site-to-site (CE-to-CE): Encryption is configured between the two CE devices, so the traffic is encrypted all the way through the SP's network 🔐
2. Provider edge-to-edge (PE-to-PE): Encryption is configured between the two PE devices. Traffic arrives unencrypted at one PE from the customer's CE, then gets encrypted to cross the SP's network to the other PE, where it's decrypted and sent on to the other CE 🌈
3. Access link (CE-to-PE): Encryption is configured between the CE and PE on each side (or on just one side) 🎀
4. Configurations 2) and 3) combined: Encryption runs from CE to PE, then PE to PE, then PE to CE. Literally the full sandwich 🥪

Across these four options, the key tradeoffs to think about are:

• Vulnerability to link eavesdropping: If an attacker can watch the data moving over the links, would it still be protected by encryption? 👀
• Vulnerability to device compromise: If an attacker can get into a device (or freely change its configuration), would the data still be protected? 😭
• Complexity of device configuration and management: Given Nce, the number of sites per VPN customer, and Npe, the number of PEs participating in a given VPN, how many device configurations have to be created or maintained, and how do they scale? 🧩
• Processing load on devices: How many encryption or decryption operations have to happen, given P packets? This affects device capacity and maybe end-to-end delay 🐢
• Ability of SP to provide enhanced services (QoS, firewall, intrusion detection, etc.): Can the SP look inside the data so it can provide these services? 🔍

We'll break these down for each configuration now 💖

1) Site-to-site (CE-to-CE) Configurations

• Link eavesdropping: Protected on all links. 🔒
• Device compromise: Vulnerable to CE compromise. 💀
• Complexity: Single administration, responsible for one device per site (Nce devices), but the overall configuration per VPN scales as Nce**2. 📈
• Processing load: On each of the two CEs, each packet is either encrypted or decrypted (2P).
• Enhanced services: Severely limited. Typically only DiffServ markings are visible to the SP, which allows some QoS services. 🎧

2) Provider edge-to-edge (PE-to-PE) Configurations

• Link eavesdropping: Vulnerable on CE-PE links; protected on the SP's network links. 👀
• Device compromise: Vulnerable to CE or PE compromise. 💀
• Complexity: Single administration; Npe devices to configure. (Multiple sites may share a PE device, so Npe is typically much less than Nce.) The scalability of the overall configuration depends on the PPVPN type. If the encryption is separate per VPN context, it scales as Npe**2 per customer VPN. If the encryption is per PE, it scales as Npe**2 for all customer VPNs combined. 🧮
• Processing load: On each of the two PEs, each packet is either encrypted or decrypted (2P).
• Enhanced services: Full. The SP can apply any enhancements based on a detailed view of the traffic. 🌟

3) Access link (CE-to-PE) Configuration

• Link eavesdropping: Protected on the CE-PE link; vulnerable on the SP's network links. 🙈
• Device compromise: Vulnerable to CE or PE compromise. 💀
• Complexity: Two administrations (customer and SP), with device configuration on each side (Nce + Npe devices to configure). There's no mesh, though, so the overall configuration scales as Nce. 🙌
• Processing load: On each of the two CEs, each packet is either encrypted or decrypted. On each of the two PEs, each packet is either encrypted or decrypted (4P).
• Enhanced services: Full. The SP can apply any enhancements based on a detailed view of the traffic. 🌟

4) Combined Access link and PE-to-PE (essentially hop-by-hop)

• Link eavesdropping: Protected on all links. 🔒
• Device compromise: Vulnerable to CE or PE compromise. 💀
• Complexity: Two administrations (customer and SP), with device configuration on each side (Nce + Npe devices to configure). The scalability of the overall configuration depends on the PPVPN type. If the encryption is separate per VPN context, it scales as Npe**2 per customer VPN. If the encryption is per PE, it scales as Npe**2 for all customer VPNs combined. 🫠
• Processing load: On each of the two CEs, each packet is either encrypted or decrypted. On each of the two PEs, each packet is both encrypted and decrypted (6P). 🥵
• Enhanced services: Full. The SP can apply any enhancements based on a detailed view of the traffic. 🌟

Okay, so after looking at all that, a few conclusions pop out ✨

• Configurations 2 and 3, which are subsets of 4, may be good alternatives to 4 under certain threat models. The rest of these conclusions compare 1 (CE-to-CE) with 4 (combined access links and PE-to-PE). 🦋
• If protection from link eavesdropping is the most important thing, then configurations 1 and 4 are equivalent. 🔐
• If protection from device compromise is the most important thing and the threat is to the CE devices, both cases are equivalent. If the threat is to the PE devices, configuration 1 is best. 🛡️
• If reducing complexity is the most important thing and the network is very small, configuration 1 is the best. Otherwise, comparing options 1 and 4 gets pretty complex 🌀, depending on things like how close the CE-to-CE communication is to a full mesh, and what tools are used for key management. Option 1 requires configuring keys for each CE-CE pair that communicates directly. Option 4 requires configuring keys on both the CE and PE devices, but it may benefit from the fact that the number of PEs is generally much smaller than the number of CEs 🧠

Also, under some PPVPN approaches, the scaling of 4 gets further improved by sharing the same PE-PE mesh across all VPN contexts. The scaling characteristics of 4 may go up or down in any given situation if the CE devices are simpler to configure than the PE devices, or vice versa. Furthermore, with option 4, the impact of operational error may be significantly increased. 😬

• If the overall processing load is a key factor, then 1 is best. 🏎️
• If the availability of enhanced services support from the SP is the most important thing, then 4 is best. 💅

Lowkey the quick overall takeaway is this: CE-to-CE encryption gives you greater protection against device compromise, but it costs you enhanced services and adds operational complexity because of the Order(n**2) scaling of the mesh 💀

This analysis of site-to-site vs. hop-by-hop encryption tradeoffs doesn't explicitly cover cases where multiple providers team up to deliver a PPVPN service, public Internet VPN connectivity, or remote access VPN service. Still, a lot of the tradeoffs will be similar 🌍

---

5.2. Authentication

okay so to stop security issues from certain denial-of-service attacks or from malicious misconfiguration, it's critical that devices in the PPVPN should only accept connections or control messages from valid sources 🚨 Authentication is about the methods that make sure message sources are properly identified by the PPVPN devices they talk to. This section focuses on figuring out the scenarios where sender authentication is required, and it recommends authentication mechanisms for those scenarios 🔑

Heads up: cryptographic techniques (authentication and encryption) do NOT protect against every type of denial-of-service attack. They don't stop resource exhaustion attacks based on CPU or bandwidth exhaustion. In fact, the processing needed to decrypt or check authentication may, in some cases, make these resource exhaustion attacks worse 😭 Cryptographic techniques may, however, help against resource exhaustion attacks based on exhaustion of state information (e.g., TCP SYN attacks) ✨

5.2.1. VPN Member Authentication

This category covers techniques for CEs to verify that they're connected to the expected VPN 🎀 It also includes techniques for CE-PE authentication, so each specific CE and PE can confirm that it's actually talking to its expected peer 🫶

5.2.2. Management System Authentication

Management system authentication includes authenticating a PE to a centrally-managed directory server when directory-based "auto-discovery" is used. It also includes authenticating a CE to its PPVPN configuration server when a configuration server system is used 🗂️

5.2.3. Peer-to-Peer Authentication

Peer-to-peer authentication covers peer authentication for network control protocols (e.g., LDP, BGP), plus other peer authentication, meaning one IPsec security gateway authenticating another 🤝

5.2.4. Authenticating Remote Access VPN Members 🧳

okay so this part is about checking who's actually connecting when a remote user shows up to a VPN from any random Internet address, like a traveler at an airport ✈️ Authenticating each individual connection is a key requirement for making remote access to a PPVPN work at all, bestie 🫶

There are several widely used standards-based protocols for remote access authentication. These include RADIUS [RFC2865] and DIAMETER [RFC3588]. Digital certificate systems also provide authentication. On top of that, there's been a ton of development and deployment of ways to securely carry individual remote access connections inside tunneling protocols, including L2TP [RFC2661] and IPsec 🔐

Remote access means connecting to a gateway device that gives you access to the PPVPN. The gateway might be managed by the user at a user site, or by the PPVPN provider at one of several possible spots in the network. The user-managed case is of limited interest within the PPVPN security framework, so it is not considered at this time 🙈

Now here's the tricky part 👀 When the PPVPN provider manages authentication at the remote access gateway, the authentication databases will have to be referenced securely by the provider. These databases are usually extremely confidential and user-managed, so it's a big deal. This can be handled with proxy authentication services. They accept an encrypted authentication credential from the remote access user, pass it to the PPVPN user's authentication system, and receive a yes/no answer on whether the user has been authenticated. So the provider never gets its hands on the actual authentication database, but it can still use it on behalf of the PPVPN user to provide remote access authentication. iykyk, it's giving "I can use your key without ever holding it" 💅

Specific cryptographic techniques for handling authentication are described in the following sections ✨

5.2.5. Cryptographic Techniques for Authenticating Identity 🪪

Cryptographic techniques offer several mechanisms for authenticating the identity of devices or individuals. These include shared secret keys, one-time keys generated by accessory devices or software, user-ID and password pairs, and a range of public-private key systems. Another approach is to use a hierarchical Certificate Authority system to provide digital certificates 🌈

This section describes, or provides references to, the specific cryptographic approaches for authenticating identity. These approaches provide secure mechanisms for most of the authentication scenarios required in operating a PPVPN. Slay 💖

---

5.3. Access Control Techniques 🔐

Access control techniques include packet-by-packet or packet flow by packet flow access control, done with filters and firewalls. They also include admitting a "session" for a control, signaling, or management protocol that is being used to implement PPVPNs. Enforcement of access control by isolated infrastructure addresses is discussed elsewhere in this document 🧚

We distinguish between filtering and firewalls mainly by the direction of traffic flow. Filtering applies to unidirectional traffic, whereas a firewall can analyze and control both sides of a conversation. Two big corollaries come from this definition 👑

• Routing or traffic flow symmetry: A firewall typically requires routing symmetry. This is usually enforced by placing the firewall where the network topology guarantees that both sides of a conversation pass through it. A filter can then operate on traffic flowing in one direction without looking at traffic in the reverse direction 🦋
• Statefulness: Because a firewall receives both sides of a conversation, it can obtain a lot of information about that conversation and use it to control access. A filter can maintain some limited state on a unidirectional flow of packets, but it can't determine the state of the bi-directional conversation as precisely as a firewall can 💀

5.3.1. Filtering 🧹

It is relatively common for routers to filter data packets. Routers can look for particular values in certain fields of the IP header or higher-level headers (like TCP or UDP). Packets that match a filter's criteria may be either discarded or given special treatment 🌸

When we talk about filters, it helps to separate the filter characteristics (what decides whether a packet matches) from the packet actions (what happens to packets that match) 🎀

• Filter Characteristics 💜
  • Filter characteristics are used to determine whether a particular packet or set of packets matches a particular filter.
  • In many cases, filter characteristics may be stateless. A stateless filter decides whether a packet matches based solely on the filter definition, on normal forwarding information (such as the next hop for a packet), and on the characteristics of that individual packet. Typically, stateless filters may consider the incoming and outgoing logical or physical interface, information in the IP header, and information in higher-layer headers such as TCP or UDP. The IP header info can include source and destination IP address, the Protocol field, the Fragment Offset, and the TOS field. Filters may also look at fields in the TCP or UDP header, like the Port fields and the SYN field in the TCP header 👀
  • Stateful filtering keeps packet-specific state information to help decide whether a filter has been met. For example, a device might apply stateless filters to the first fragment of a fragmented IP packet. If that filter matches, the data unit ID may be remembered, and the other fragments of the same packet may then be considered to match the same filter. Stateful filtering is more commonly done in firewalls, although firewall technology may be added to routers 🧠
• Actions Based on Filter Results 🔥
  • If a packet, or a series of packets, matches a specific filter, there are a variety of actions that may be taken. Examples include Discard, Set CoS, Count Packets and/or Bytes, Rate Limit, and Forward and Copy.
  • Discard: Filters may be set to catch certain undesirable packets. Examples include packets with forged or invalid source addresses, packets that are part of a DoS or DDoS attack, or packets trying to access forbidden resources (such as network management packets from an unauthorized source). When these filters are activated, it is common to silently discard the packet or set of packets that match. The discarded packets may also be counted and/or logged, of course 🙅‍♀️
  • Set CoS: A filter may be used to set the Class of Service associated with the packet ⭐
  • Count Packets and/or Bytes 🔢
  • Rate Limit: The set of packets that match a particular filter may be limited to a specified bandwidth. Packets and/or bytes are counted and forwarded normally up to the specified limit. Excess packets may be discarded or marked, for example by setting a "discard eligible" bit in the IP ToS field or the MPLS EXP field 🍓
  • Forward and Copy: It is sometimes useful not only to forward a set of packets normally, but also to send a copy to a specified other address or interface. For example, this may be used to implement a lawful intercept capability, or to feed selected packets to an Intrusion Detection System 🕵️‍♀️
• Other Issues Related to Packet Filters 🌈
  • There may be a very wide variation in the performance impact of filtering. This can happen because of differences between implementations, and because of differences between the types or numbers of filters deployed. For filtering to be useful, the performance of the equipment has to be acceptable in the presence of filters 💅
  • What counts as "acceptable" may vary from service provider to service provider, and may depend on the intended use of the filters. For example, a filter may be turned on all the time to set CoS, to prevent an attack, or to mitigate the effect of a possible future attack. In that case, the service provider will likely want the filter to have minimal or no impact on performance. In other cases, a filter may be turned on only in response to a major attack, such as a major DDoS attack. Here, a greater performance impact may be acceptable to some service providers 🫠
  • A key consideration with packet filters is that they can provide few options for filtering packets carrying encrypted data. Because the data itself is not accessible, only packet header information or other unencrypted fields can be used for filtering 🔒

5.3.2. Firewalls ✨

okay so firewalls are the bouncers 💅 of the PPVPN world. They control traffic going between different trusted zones, or between a trusted zone and an untrusted one 🚧. They're way more powerful than filters because they can look at whole flows and do detailed analysis, not just check one packet at a time 🧠. They can even do threshold-driven denial-of-service protection, virus scanning, or act as a TCP connection proxy 🛡️. Just like every other access control technique, a firewall only works if you really understand the PPVPN core network, the user networks, and the threat model 🗺️. And it only works if the topology has a clearly defined inside (secure) and outside (not secure) 🏰. No vibes-based security here, bestie 🙅‍♀️.

Inside a PPVPN, traffic usually isn't allowed to pass between the different user VPNs 🚫. That inter-VPN isolation isn't really the firewall's job. It's just part of the basic VPN mechanism 🫧. The big exception is "extranets" 💌, which let specific outside access into a user's VPN, maybe even from a different VPN altogether. Firewalls can be used to provide the services a secure extranet needs 🔐.

In a PPVPN, firewalls can sit between the public Internet and user VPNs, especially when the provider is offering Internet access to the VPN user sites 🌐. Firewalls may also sit between VPN user sites and any shared network-based services the PPVPN provider offers 🏢.

Firewalls may be used to help protect the PPVPN core network functions from attacks coming from the Internet or from PPVPN user sites 🛡️. But honestly? Other defensive techniques will usually be the ones doing this job 🙃.

When firewalls protect user VPN sites from the Internet, different VPN users (and even different sites of the same VPN user) can have totally different firewall requirements 🎀. The overall PPVPN logical and physical topology, plus what the firewall devices can actually do, will make a huge difference in whether these varied offerings are feasible and manageable 😤.

One more thing: firewalls don't have many options when it comes to encrypted packets 🔒. The actual data is hidden from them, so they can only work with packet headers, other unencrypted fields, or the analysis of the flow of encrypted packets when deciding whether to accept or reject that traffic 🕵️‍♀️.

5.3.3. Access Control to Management Interfaces 🔧

Most security problems with management interfaces can be solved with the authentication techniques from the authentication section 🔑. But you can add extra security by controlling access to management interfaces in other ways too ✨.

Management interfaces, especially console ports on PPVPN devices, can be set up so they're only reachable out of band 🔌. That means through a system that's physically or logically separated from the rest of the PPVPN infrastructure 🧱. Iconic behaviour 👑.

If management interfaces can be reached in-band within the PPVPN domain, filtering or firewalling can block unauthorized in-band traffic from getting to them 🚷. Depending on what the devices can do, these filters or firewalls can be set up either on other devices the traffic might pass through, or on the individual PPVPN devices themselves 🧚.

---

5.4. Use of Isolated Infrastructure 🏝️

One way to protect the infrastructure that supports VPNs is to separate the VPN support resources from the resources used for other stuff (like supporting Internet services) 🫶. Sometimes this means using physically separate equipment for VPN services, or even a physically separate network 💜.

For example, PE-based L3 VPNs might run on a separate backbone that isn't connected to the Internet 🌸. They could also use separate edge routers from the ones that support Internet service. Private IP addresses (local to the provider and not routable over the Internet) are sometimes used for extra separation 🎀.

It's pretty common for CE-based L3VPNs to use CE devices dedicated to one specific VPN 💅. In many or most cases, CE-based VPNs may use normal Internet services to connect their CE devices together 🌈.

5.5. Use of Aggregated Infrastructure 🧩

Honestly, using a completely separate set of resources for every single VPN is generally not feasible 😭. Sharing resources between multiple users (including multiple VPNs) is literally one of the main reasons VPN services exist 🤝. So even if VPN services use a network separate from Internet services, there will still be multiple VPN users sharing the same network resources 🫧. Sometimes VPN services even share network resources with Internet services or other services 🌐.

That's why it's super important for VPN services to protect resource use between different VPNs 🛡️. A well-behaved VPN user should be shielded from possible misbehavior by other VPNs 🙌. This means there have to be limits on how much of the resources any one VPN can use 📏. For example, both control traffic and user data traffic may be rate limited 🚦. In some cases, or in parts of the network where lots of queues are available, each VPN (and, optionally, each VPN and CoS within the VPN) may get its own separate queue 🎟️. Control-plane resources like link bandwidth, CPU, and memory can also be reserved on a per-VPN basis 💎.

The techniques used to provision resource protection between multiple VPNs served by the same infrastructure can also protect VPN services from Internet services 🔥.

Using aggregated infrastructure lets the service provider benefit from stochastic multiplexing of multiple bursty flows 📈. It may also, in some cases, thwart traffic pattern analysis by mixing data from multiple VPNs together 🕶️. Clever, right? 😏

5.6. Service Provider Quality Control Processes 📋

Deploying provider-provisioned VPN services takes a LOT of configuration from the service provider 😵‍💫. For example, the provider has to configure which VPN each site belongs to, plus the QoS and SLA guarantees 📑. All that required configuration means misconfiguration is a real possibility 😬.

So the service provider needs operational processes in place to reduce the potential impact of misconfiguration 🛠️. CE-to-CE authentication may also be used to detect misconfiguration when it happens 🕵️‍♀️.

5.7. Deployment of Testable PPVPN Service 🧪

This section is about solutions that can be easily tested for correct configuration ✅. For example, with a point-point VPN, checking that the intended connectivity works pretty much guarantees there isn't connectivity to some unintended site 🎯. Testability is giving peace of mind 🫶.

---

6. Monitoring, Detection, and Reporting of Security Attacks 🚨

A PPVPN service can get hit by attacks from all sorts of security threats 😰. Many threats are covered elsewhere in this document 📖. A lot of the defensive techniques described here (and elsewhere) give strong protection against a variety of threats 💪. But on top of silently using defenses, PPVPN services can add real value for both providers and customers by running security-monitoring systems that detect and report any security attacks that happen, whether or not the attacks actually succeed 👀✨.

Attackers usually start by probing and analyzing defenses first 🕵️. So systems that can detect and properly report these early stages of attacks can be a huge benefit 🫧.

Information about attack incidents is really useful for defending against more attacks, especially if it's available quickly ⚡. It can help identify attackers and their specific targets early on 🎯. That knowledge can then be used to strengthen defenses against specific attacks or attackers, or to improve the defensive services for specific targets as needed 💅. Information collected on attacks can also help identify and develop defenses against brand-new attack types 🧬.

Monitoring systems that detect security attacks in PPVPNs will typically work by collecting information from Provider Edge (PE), Customer Edge (CE), and/or Provider backbone (P) devices 📡. Security monitoring systems should be able to actively retrieve information from devices (e.g., SNMP get) or passively receive reports from devices (e.g., SNMP notifications) 📥📤. The exact information exchanged depends on what the devices can do and on the type of VPN technology 🧩. Care should be taken to secure the communications channel between the monitoring systems and the PPVPN devices 🔐.

The CE, PE, and P devices should use efficient methods to gather and send the information the security monitoring systems need ⚙️. It's important that the way PPVPN devices talk to security monitoring systems is designed so it won't disrupt network operations 🙏. For example, multiple attack events can be reported in one message, instead of letting each attack event trigger its own message 📨. Otherwise you'd get a flood of messages, which could turn into a denial-of-service attack against the monitoring system or the network itself 😱.

The mechanisms for reporting security attacks should be flexible enough to meet the needs of VPN service providers, VPN customers, and regulatory agencies 🏛️. The specific reports depend on the devices' capabilities, the security monitoring system, the type of VPN, and the service level agreements between the provider and customer 📝.

7. User Security Requirements 🎀

This section defines a list of security-related requirements that PPVPN service users may have for their service 💭. Usually, these turn into requirements for the provider when it comes to offering the service 🧾.

The following sections go into the various requirements that keep a given trusted zone secure 🔒. Real life has different levels of security, so a PPVPN may fulfill any or all of these security requirements 🌈. This document does not say that a PPVPN must fulfill all of these requirements to be secure 🙅‍♀️. As mentioned in the Introduction, it's not in scope for this document to define the specific requirements each VPN technology must meet to be secure 🫶.

7.1. Isolation 🫧

A virtual private network usually defines "private" as being isolated from other PPVPNs and from the Internet 🔐. More specifically, isolation has several components, which the following sections cover 💜.

7.1.1. Address Separation 🌸

A given PPVPN can use the full Internet address range, including private address ranges [RFC1918], without interfering with other PPVPNs that use PPVPN services from the same service provider(s) 🦋. When Internet access is provided (for example, by the same service provider offering the PPVPN service), NAT functionality may be needed 🔄.

In layer-2 VPNs, the same requirement applies to layer 2 addressing schemes, such as MAC addresses 🧚‍♀️.

7.1.2. Routing Separation 🛣️

okay bestie, so a PPVPN core must maintain routing separation between the trusted zones. That means routing information must not leak from any trusted zone to any other, unless the zones are specifically engineered this way (e.g., for Internet access.) 💅

In layer-2 VPNs, the switching information must be kept separate between the trusted zones, so that switching information of one PPVPN does not influence other PPVPNs or the PPVPN core. 🫶

7.1.3. Traffic Separation 🚧

Traffic from a given trusted zone must never leave this zone, and traffic from another zone must never enter this zone. Exceptions are made where zones are specifically engineered that way (e.g., for extranet purposes or Internet access.) ✨

7.2. Protection 🛡️

The common perception is that a completely separated "private" network has defined entry points and is only subject to attack or intrusion over those entry points. By sharing a common core, a PPVPN appears to lose some of these clear interfaces to networks outside the trusted zone. Thus, one of the key security requirements of PPVPN services is that they offer the same level of protection as private networks. 🔐

7.2.1. Protection against Intrusion 🚪

An intrusion is defined here as the penetration of a trusted zone from outside. This could be from the Internet, another PPVPN, or the core network itself.

The fact that a network is "virtual" must not expose it to additional threats over private networks. Specifically, it must not add new interfaces to other parts outside the trusted zone. Intrusions from known interfaces such as Internet gateways are outside the scope of this document. 🙈

7.2.2. Protection against Denial-of-Service Attacks 🌊

A denial-of-service (DoS) attack aims at making services or devices unavailable to legitimate users. In the framework of this document, only those DoS attacks are considered that are a consequence of providing network service through a VPN. DoS attacks over the standard interfaces into a trusted zone are not considered here.

The requirement is that a PPVPN is not more vulnerable against DoS attacks than it would be if the same network were private. 💪

7.2.3. Protection against Spoofing 🎭

It must not be possible to violate the integrity of a PPVPN by changing the sender identification (source address, source label, etc) of traffic in transit. For example, if two CEs are connected to the same PE, it must not be possible for one CE to send crafted packets that make the PE believe those packets are coming from the other CE, thus inserting them into the wrong PPVPN. 😤

7.3. Confidentiality 🤫

This requirement means that data must be cryptographically secured in transit over the PPVPN core network to avoid eavesdropping. 🔒

7.4. CE Authentication 🪪

Where CE authentication is provided, it is not possible for an outsider to install a CE and pretend to belong to a specific PPVPN to which this CE does not belong in reality. 🚫

7.5. Integrity 🧱

Data in transit must be secured in such a manner that it cannot be altered or that any alteration may be detected at the receiver. ✅

7.6. Anti-replay 🔁

Anti-replay means that data in transit cannot be recorded and replayed later. To protect against anti-replay attacks, the data must be cryptographically secured. 🎬

Note: Even private networks do not necessarily meet the requirements of confidentiality, integrity, and anti-reply. Thus, when private and "virtually private" PPVPN services are compared, these requirements are only applicable if the comparable private service also included these services. However, the fact that VPNs operate over a shared infrastructure may make some of these requirements more important in a VPN environment than in a private network environment. 🤔

8. Provider Security Requirements 👑

In this section, we discuss additional security requirements that the provider may have in order to secure its network infrastructure as it provides PPVPN services.

The PPVPN service provider requirements defined here are the requirements for the PPVPN core in the reference model. The core network can be implemented with different types of network technologies, and each core network may use different technologies to provide the PPVPN services to users with different levels of offered security. Therefore, a PPVPN service provider may fulfill any number of the security requirements listed in this section. This document does not state that a PPVPN must fulfill all of these requirements to be secure. 🧩

These requirements are focused on 1) how to protect the PPVPN core from various attacks outside the core, including PPVPN users and non-PPVPN alike, both accidentally and maliciously, and 2) how to protect the PPVPN user VPNs and sites themselves. Note that a PPVPN core is not more vulnerable against attacks than a core that does not provide PPVPNs. However, providing PPVPN services over such a core may lead to additional security requirements, if only because most users are expecting higher security standards in a core delivering PPVPN services. 🌟

8.1. Protection within the Core Network 🏰

8.1.1. Control Plane Protection 🎛️

• Protocol Authentication within the Core:

PPVPN technologies and infrastructure must support mechanisms for authentication of the control plane. For an IP core, IGP and BGP sessions may be authenticated by using TCP MD5 or IPsec. If an MPLS core is used, LDP sessions may be authenticated by using TCP MD5. In addition, IGP and BGP authentication should also be considered. For a core providing layer-2 services, PE to PE authentication may also be used via IPsec.

With the cost of authentication coming down rapidly, the application of control plane authentication may not increase the cost of implementation for providers significantly, and it will improve the security of the core. If the core is dedicated to VPN services and there are no interconnects to third parties, then it may reduce the requirement for authentication of the core control plane. 💸

• Elements protection

Here we discuss means to hide the provider's infrastructure nodes.

A PPVPN provider may make the infrastructure routers (P and PE routers) unreachable by outside users and unauthorized internal users. For example, separate address space may be used for the infrastructure loopbacks. 🫣

Normal TTL propagation may be altered to make the backbone look like one hop from the outside, but caution should be taken for loop prevention. This prevents the backbone addresses from being exposed through trace route; however, it must also be assessed against operational requirements for end-to-end fault tracing. 🕵️

An Internet backbone core may be re-engineered to make Internet routing an edge function, for example, by using MPLS label switching for all traffic within the core and possibly by making the Internet a VPN within the PPVPN core itself. This helps detach Internet access from PPVPN services. 🔀

PE devices may implement separate control plane, data plane, and management plane functionality in terms of hardware and software, to improve security. This may help limit the problems when one particular area is attacked, and it may allow each plane to implement additional security measurement separately. 🧠

PEs are often more vulnerable to attack than P routers, since, by their very nature, PEs cannot be made unreachable to outside users. Access to core trunk resources can be controlled on a per-user basis by the application of inbound rate-limiting/shaping. This can be further enhanced on a per-Class of Service basis (see section 8.2.3). 🚦

In the PE, using separate routing processes for Internet and PPVPN service may help improve the PPVPN security and better protect VPN customers. Furthermore, if the resources, such as CPU and memory, may be further separated based on applications, or even on individual VPNs, it may help provide improved security and reliability to individual VPN customers. 🧁

Many of these were not particular issues when an IP core was designed to support Internet services only. Providing PPVPN services introduces new security requirements for VPN services. Similar considerations apply to L2 VPN services. 🙌

8.1.2. Data Plane Protection 📦

PPVPN using IPsec technologies provides VPN users with encryption of secure user data.

In today's MPLS, ATM, and Frame Relay networks, encryption is not provided as a basic feature. Mechanisms can be used to secure the MPLS data plane and to secure the data carried over the MPLS core. Additionally, if the core is dedicated to VPN services and there are no external interconnects to third party networks, then there is no obvious need for encryption of the user data plane. 🕰️

Inter-working IPsec/L3 PPVPN technologies or IPsec/L2 PPVPN technologies may be used to provide PPVPN users with end-to-end PPVPN services. 🔗

8.2. Protection on the User Access Link 🔌

Peer/Neighbor protocol authentication may be used to enhance security. For example, BGP MD5 authentication may be used to enhance security on PE-CE links using eBGP. In the case of an inter-provider connection, authentication/encryption mechanisms between ASes, such as IPsec, may be used. 🤝

WAN link address space separation for VPN and non-VPN users may be implemented to improve security in order to protect VPN customers if multiple services are provided on the same PE platform. 🗺️

Firewall/Filtering: Access control mechanisms can be used to filter out any packets destined for the service provider's infrastructure prefix or to eliminate routes identified as illegitimate. 🧱

Rate limiting: Rate limiting may be applied to the user interface/logical interfaces against DDoS bandwidth attack. This is very helpful when the PE device is supporting both VPN services and Internet services, especially when it supports VPN and Internet services on the same physical interfaces through different logical interfaces. 🌪️

8.2.1. Link Authentication 🗝️

Authentication mechanisms can be employed to validate site access to the PPVPN network via fixed or logical (e.g., L2TP, IPsec) connections. When the user wishes to hold the 'secret' associated to acceptance of the access and site into the VPN, then PPVPN based solutions require the flexibility for either direct authentication by the PE itself or interaction with a customer PPVPN authentication server. Mechanisms are required in the latter case to ensure that the interaction between the PE and the customer authentication server is controlled, for example, by limiting it simply to an exchange in relation to the authentication phase and with other attributes (e.g., optional filtering of RADIUS). 🎀

8.2.2. Access Routing ✨

okay so routing protocols like RIP, OSPF, and BGP 🛣️ can be used to add control between the CE and the PE. bestie, this is giving protection on the routing side. Per-neighbor and per-VPN routing policies can make things more secure and cut down the damage from an attack on the PE, whether it's malicious or just an accident 🫶. These are the mechanisms you should consider:

• Limiting the number of prefixes that may be advertised into the PE on a per-access basis. If a limit gets exceeded, the PE can take action. For example, it might shut down the peer session to the CE 🙅‍♀️
• Applying route dampening at the PE on received routing updates 🌊
• Defining a per-VPN prefix limit. Once it's hit, extra prefixes won't get added to the VPN routing table 🧱

when it comes to inter-provider connections, access protection, link authentication, and routing policies like the ones above can all get applied 💖 inbound and outbound firewall and filtering mechanisms can also be used between ASes. proper security procedures must be implemented in inter-provider VPN interconnection so that the providers' network infrastructure and their customer VPNs stay protected 🔐. this can be custom designed for each inter-provider VPN peering connection, and both providers must agree on it. no cap, it's a team effort 🤝

---

8.2.3. Access QoS 🎀

PPVPN providers that offer QoS-enabled services need mechanisms that check each access against its subscribed QOS profile. those mechanisms also need to make sure each access only gets core resources that match its service profile 💅. one option for this level of control is per-Class of Service rate limiting or traffic shaping on ingress to the PPVPN core. these mechanisms may require the per-Class of Service profile to be enforced by marking, remarking, or discarding any traffic that falls outside of the profile. it's giving strict bouncer energy, and I'm here for it 🚪✨

8.2.4. Customer VPN Monitoring Tools 👀

end users who want to see VPN-specific statistics on the core (like the routing table, interface status, or QoS statistics) create requirements for the PE. the PE has to validate the incoming user, and it also has to limit what that particular user's VPN can see 🔍. mechanisms should also be considered so that this kind of access can't be used to create a DoS attack on the PE itself, whether that's malicious or accidental 😭. one way to do it is to separate these resources inside the PE. another way is to rate-limit this traffic on a per-VPN basis 🧚

---

8.3. General Requirements for PPVPN Providers 💜

the PPVPN providers must support the users' security requirements as listed in Section 7. depending on which technologies are used, these requirements may include the following:

• User control plane separation: Routing isolation.
• User address space separation: Supporting overlapping addresses from different VPNs.
• User data plane separation: One VPN traffic cannot be intercepted by other VPNs or any other users.
• Protection against intrusion, DoS attacks and spoofing.
• Access Authentication.
• Techniques highlighted through this document identify methodologies for the protection of PPVPN resources and infrastructure.

hardware or software bugs in equipment that lead to security breaches are outside the scope of this document. not me going "that's not our problem" 🙈

---

9. Security Evaluation of PPVPN Technologies 🌈

this section gives you a short template for evaluating and summarizing how a given PPVPN approach (solution) measures up against the PPVPN Security Framework. an evaluation using this template should appear in the applicability statement for each PPVPN approach 📋✨

9.1. Evaluating the Template 🧐

the first part of the template is a list of security assertions. for each assertion, the approach gets assessed, and one or more of these ratings gets assigned:

• The requirement is not applicable to the VPN approach because ... (fill in reason).
• The base VPN approach completely addresses the requirement by ... (fill in technique).
• The base VPN approach partially addresses the requirement by ... (fill in technique and extent to which it addresses the requirement).
• An optional extension to the VPN approach completely addresses the requirement by ... (fill in technique).
• An optional extension to the VPN approach partially addresses the requirement by ... (fill in technique and extent to which it addresses the requirement).
• The requirement is addressed in a way that is beyond the scope of the VPN approach. (Explain.) (One example of this would be a VPN approach in which some aspect, such as membership discovery, is done via configuration. The protection afforded to the configuration would be beyond the scope of the VPN approach.).
• The VPN approach does not meet the requirement.

9.2. Template 📝

these assertions ask for responses of the types listed in the previous section 💅

1. The approach provides complete IP address space separation for each L3 VPN.
2. The approach provides complete L2 address space separation for each L2 VPN.
3. The approach provides complete VLAN ID space separation for each L2 VPN.
4. The approach provides complete IP route separation for each L3 VPN.
5. The approach provides complete L2 forwarding separation for each L2 VPN.
6. The approach provides a means to prevent improper cross-connection of sites in separate VPNs.
7. The approach provides a means to detect improper cross-connection of sites in separate VPNs.
8. The approach protects against the introduction of unauthorized packets into each VPN:
   • a. in the CE-PE link,
   • b. in a single- or multi-provider PPVPN backbone, or
   • c. in the Internet used as PPVPN backbone.
9. The approach provides confidentiality (secrecy) protection for PPVPN user data:
   • a. in the CE-PE link,
   • b. in a single- or multi-provider PPVPN backbone, or
   • c. in the Internet used as PPVPN backbone.
10. The approach provides sender authentication for PPVPN user data:
    • a. in the CE-PE link,
    • b. in a single- or multi-provider PPVPN backbone, or
    • c. in the Internet used as PPVPN backbone.
11. The approach provides integrity protection for PPVPN user data:
    • a. in the CE-PE link,
    • b. in a single- or multi-provider PPVPN backbone, or
    • c. in the Internet used as PPVPN backbone.
12. The approach provides protection against replay attacks for PPVPN user data:
    • a. in the CE-PE link,
    • b. in a single- or multi-provider PPVPN backbone, or
    • c. in the Internet used as PPVPN backbone.
13. The approach provides protection against unauthorized traffic pattern analysis for PPVPN user data:
    • a. in the CE-PE link,
    • b. in a single- or multi-provider PPVPN backbone, or
    • c. in the Internet used as PPVPN backbone.
14. The control protocol(s) used for each of the following functions provides message integrity and peer authentication:
    • a. VPN membership discovery.
    • b. Tunnel establishment.
    • c. VPN topology and reachability advertisement:
      • i. PE-PE.
      • ii. PE-CE.
    • d. VPN provisioning and management.
    • e. VPN monitoring, attack detection, and reporting.
    • f. Other VPN-specific control protocols, if any (list).

the following questions ask for free-form answers 🦋

15. Describe the protection, if any, the approach provides against PPVPN-specific DoS attacks (i.e., inter-trusted-zone DoS attacks):
    • a. Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in a private (PPVPN user) network and aimed at PPVPN mechanisms.
    • b. Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in the Internet and aimed at PPVPN mechanisms.
    • c. Protection of PPVPN users against Data Plane or Control Plane DoS attacks originated from the Internet or from other PPVPN users and aimed at PPVPN mechanisms.
16. Describe the protection, if any, the approach provides against unstable or malicious operation of a PPVPN user network:
    • a. Protection against high levels of, or malicious design of, routing traffic from PPVPN user networks to the service provider network.
    • b. Protection against high levels of, or malicious design of, network management traffic from PPVPN user networks to the service provider network.
    • c. Protection against worms and probes originated in the PPVPN user networks, sent toward the service provider network.
17. Is the approach subject to any approach-specific vulnerabilities not specifically addressed by this template? If so, describe the defense or mitigation, if any, that the approach provides for each.

---

10. Security Considerations 🔐

security considerations are the sole subject of this memo, so they show up all the way through it 🫶. here we recap what's been covered and explain, at a very high level, the role each type of consideration plays in an overall secure PPVPN system. the document describes a number of potential security threats. some of them have already shown up in running networks, and others are still mostly theoretical right now 🔮

DoS attacks and intrusion attacks from the Internet against service provider infrastructure have been seen 😳. DoS "attacks" (typically not malicious) have also been seen, where CE equipment overwhelms PE equipment with high quantities or rates of packet traffic or routing information 💀. service providers name operational and provisioning errors as one of their biggest concerns 🙃

the document describes a variety of defensive techniques that may be used to counter the suspected threats. every technique presented involves mature, widely implemented technologies that are practical to implement 💪✨

the document also explains why it matters to detect, monitor, and report both successful and unsuccessful attacks. these activities are essential for "understanding one's enemy", mobilizing new defenses, and getting metrics on how secure the PPVPN service is 🧠. that makes them vital components of any complete PPVPN security system 💜

the document evaluates PPVPN security requirements from both a customer perspective and a service provider perspective. these sections re-evaluate the identified threats from the perspectives of the various stakeholders. they're meant to help equipment vendors and service providers, who must ultimately decide which threats to protect against in any given equipment or service offering 🎀

finally, the document includes a template that authors of PPVPN technical solutions can use to evaluate how their solutions measure up against the security considerations presented in this memo 🌸

11. Contributors ✨

okay so the people who made MAJOR contributions to this doc are Michael Behringer, Ross Callon, Fabio Chiussi, Jeremy De Clerque, Paul Hitchen, and Paul Knignt 🫶 (yes, "Knignt" is how it's spelled in the original, bestie 😭)

Here are their contact cards, plus two extra names from the list:

Michael Behringer
Cisco
Village d'Entreprises Green Side,  Phone: +33.49723-2652
400, Avenue Roumanille, Bat. T 3   EMail: mbehring@cisco.com
06410 Biot, Sophia Antipolis
France

Ross Callon
Juniper Networks
10 Technology Park Drive           Phone: 978-692-6724
Westford, MA  01886                EMail: rcallon@juniper.net

Fabio Chiussi                      Phone: 1 978 367-8965
Airvana                            EMail: fabio@airvananet.com
19 Alpha Road
Chelmsford, Massachusetts 01824

Jeremy De Clercq
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen  EMail: jeremy.de_clercq@alcatel.be
Belgium

Mark Duffy
Sonus Networks
250 Apollo Drive                   Phone: 1 978-614-8748
Chelmsford, MA 01824               EMail: mduffy@sonusnet.com

Paul Hitchen
BT
BT Adastral Park
Martlesham Heath                   Phone: 44-1473-606-344
Ipswich IP53RE                     EMail: paul.hitchen@bt.com
UK

Paul Knight
Nortel
600 Technology Park Drive          Phone: 978-288-6414
Billerica, MA 01821                EMail: paul.knight@nortel.com

12. Acknowledgement

the author and contributors also want to give a huge shoutout 📣 to Paul Hoffman, Eric Gray, Ron Bonica, Chris Chase, Jerry Ash, and Stewart Bryant 🌸 for their helpful comments and suggestions. legends, all of them 💜

13. Normative References

these are the docs this one needs in order to make sense, so read them first, no skipping 🎀

• [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
• [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
• [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
• [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
• [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
• [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
• [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
• [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
• [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
• [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
• [STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
  • Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
  • Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
  • Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
  • Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
  • Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
  • Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
  • Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
• [STD8] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.

14. Informative References

these ones are just extra reading if you want the full picture, bestie 🦋

• [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
• [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
• [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
• [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security Mechanisms for the Internet", RFC 3631, December 2003.
• [RFC3889] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 3889, October 2004.
• [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
• [RFC4031] Carugi, M. and D. McDysan, Eds., "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005.
• [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", RFC 4110, July 2005.

Author's Address

the author, Luyuan Fang 💜, can be reached here:

Luyuan Fang
AT&T Labs.
200 Laurel Avenue, Room C2-3B35
Middletown, NJ 07748

Phone: 732-420-1921
EMail: luyuanfang@att.com

Full Copyright Statement

---

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

the IETF takes no position on whether any Intellectual Property Rights (or other rights) might be claimed to cover the tech in this doc, or whether licenses for those rights are available, and it doesn't claim to have checked for any such rights either 🔥 info on how RFC docs handle rights is in BCP 78 and BCP 79.

copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses, and the results of any attempt to get a general license or permission to use proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org. 🌈

Acknowledgement

funding for the RFC Editor function is currently provided by the Internet Society. 💅