RFC 4176
Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management
RFC 4176: Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management ✨
okay bestie, let's get into RFC 4176 💖 It's an Informational doc from October 2005, published under the Network Working Group. The editor is Y. El Mghazli (Alcatel), and the other authors are T. Nadeau (Cisco), M. Boucadair (France Telecom), K. Chan (Nortel), and A. Gonguet (Alcatel). The header doesn't list any RFCs that it obsoletes or updates 🦋
Status of This Memo 🌸
This memo gives information to the Internet community. It is not a standard of any kind. Distribution is unlimited, so share it with everyone 🫶
Copyright Notice 🎀
Copyright (C) The Internet Society (2005).
Abstract 🌈
This doc is a framework for operating and managing Layer 3 Virtual Private Networks (L3VPNs) 💅 The goal is a coherent description of the big technical issues that matter when you design L3VPN management solutions. Picking specific approaches, and choosing between information models and protocols, is outside the scope of this document, so don't look for that here 🙈
Table of Contents 🧚
1. Introduction ................................................. 2
1.1. Terminology ............................................ 2
1.2. Management functions ................................... 4
1.3. Reference Models ....................................... 5
2. Customer Service Operations and Management ................... 7
2.1. Customer Service Management Information Model .......... 7
2.2. Customer Management Functions .......................... 8
2.2.1. Fault Management ............................... 8
2.2.2. Configuration Management ....................... 9
2.2.3. Accounting ..................................... 9
2.2.4. Performance Management ......................... 10
2.2.5. Security Management ............................ 10
2.3. Customer Management Functional Description ............. 11
2.3.1. L3VPN Service Offering Management .............. 11
2.3.2. L3VPN Service Order Management ................. 12
2.3.3. L3VPN Service Assurance ........................ 12
3. Provider Network Manager ..................................... 12
3.1. Provider Network Management Definition ................. 12
3.2. Network Management Functions ........................... 13
3.2.1. Fault Management ............................... 13
3.2.2. Configuration Management ....................... 14
3.2.3. Accounting ..................................... 17
3.2.4. Performance Management ......................... 17
3.2.5. Security Management ............................ 17
4. L3VPN Devices ................................................ 18
4.1. Information Model ...................................... 18
4.2. Communication .......................................... 18
5. Security Considerations ...................................... 19
6. Acknowledgements ............................................. 19
7. Normative References ......................................... 191. Introduction ✨
1.1. Terminology 📖
In this doc, these terms are used and defined as follows:
VPN: Virtual Private Network 🔐 It's a set of transmission and switching resources that run over a shared infrastructure to process the (IP) traffic that makes up communication services between the sites or premises linked by this VPN. See [RFC4026].
L3VPN: An L3VPN connects sets of hosts and routers based on their Layer 3 addresses. See [RFC4026].
VPN Instance: From a management standpoint, a VPN instance is the collection of configuration information for one specific VPN, living on a PE router 💜
VPN Site: A VPN customer's location that connects to the Service Provider network over a CE-PE link, and that can access at least one VPN 🏠
VPN Service Provider (SP): A Service Provider that offers VPN-related services 💼
VPN Customer: A customer who bought VPNs from a VPN service provider 🛍️
Customer Agent: The entity responsible for requesting customer-specific VPN information 🙋♀️
Service Level Agreement (SLA): A contract between the Service Provider and the Customer. It includes qualitative and quantitative metrics that define service quality guarantees, plus the retribution procedures for when service levels aren't being met. That's the spicy part 😭
Service Level Specifications (SLS): Internally-focused service performance specifications that the Service Provider uses to manage customer service quality levels 🔧
1.2. Management functions 🎀
So for any kind of Layer-3 VPN (PE-based or CE-based VPNs), it's recommended to have a management platform where VPN-related information can be collected and managed 🌸 The Service and Network Management System can centralize information about the instances of a VPN and let users configure and provision each instance from one central location. Main character energy 👑
An SP must be able to manage the capabilities and characteristics of its VPN services. Customers should have ways to make sure the VPN service they subscribed to is actually being fulfilled 🫶 As far as possible, automated operations and interoperability with standard management protocols should be supported ⭐
Two main management functions are identified:
A customer service management function: This function gives a customer the means to query, configure, and receive (events/alarms) customer-specific VPN service information. That info includes data about contact, billing, site, access network, IP address, routing protocol parameters, etc. It may also include confidential data, such as encryption keys 🔑 A few solutions could be used:
- Proprietary network management system
- SNMP manager
- PDP function
- Directory service, etc.
A provider network management function: This function is responsible for planning, building, provisioning, and maintaining network resources so it can meet the VPN service-level agreements outlined in the SLA offered to the customer 🛠️ It mostly consists of (1) setup and configuration of physical links, (2) provisioning of logical VPN service configurations, and (3) life-cycle management of VPN service, including adding, modifying, and deleting VPN configurations ✨
There may be relationships between the customer service and provider network management functions, since the provider network is managed to support, realize, and provide the customer service 🦋 One example of this relationship is providing VPN-SLS assurance to verify that the subscribed VPN agreement is being fulfilled. That's giving teamwork 🥰
1.3. Reference Models 🧩
okay so the ITU-T Telecommunications Management Network has this generic requirements structure, and it's giving layers 🍰
- Engineer, deploy and manage the switching, routing, and transmission resources supporting the service from a network perspective (network element management);
- Manage the VPNs deployed over these resources (network management);
- Manage the VPN service (service management);
Here's the PE-based picture, which is honestly so clean 😍
- - - - - - - - - - - - - - - - - - - - - - - -:- - - - - - - - -
Service +-------------+ : +----------+
Management | Service |<------------------:----->| Customer |
Layer | Manager | : | Agent |
+-------------+ : +----------+
- - - - - - - - - - ^ - - - - - - - - - - - - -:- - - - - - - - -
Network | +------------+ :
Management | | Provider | :
Layer | | Network | Customer
+------>| Manager | Interface
+------------+ :
- - - - - - - - - - - - - - - - - ^ - - - - - -:- - - - - - - - -
Network Element | :
Management | +------+ : +------+
Layer | | | : | CE |
+->| PE | : |device|
|device| : | of |
| |--:--|VPN A|
+------+ : +------+
---------------------------------------------->:<----------------
SP network : Customer Network
Figure 1: Reference Model for PE-based L3VPN ManagementAnd the CE-based version, which is basically the same energy with a twist 🦋
- - - - - - - - - - - - - - - - - - - - - - - -:- - - - - - - - -
Service +-------------+ : +----------+
Management | Service |<------------------:----->| Customer |
Layer | Manager | : | Agent |
+-------------+ : +----------+
- - - - - - - - - - ^ - - - - - - - - - - - - -:- - - - - - - - -
Network | +------------+ :
Management | | Provider | :
Layer | | Network | Customer
+------>| Manager | Interface
+------------+ :
- - - - - - - - - - - - - - - -^- - - -^- - - -:- - - - - - - - -
Network Element | +-------:---------------+
Management | +------+ : +------+ |
Layer | | | : | CE | |
+---->| PE | : |device|<----+
|device| : | of |
| |--:--|VPN A|
+------+ : +------+
---------------------------------------------->:<----------------
SP network : Customer Network
Figure 2: Reference Model for CE-based L3VPN ManagementSo Figures 1 and 2 are the reference models for PE and CE-based L3VPN management, both built on that generic structure we just talked about ✨
In both models, the service manager handles the customer-specific stuff: customer Identifier (ID), personal information (e.g., name, address, phone number, credit card number, etc.), subscription services and parameters, access control policy information, billing and statistical information, etc. 💅
In the PE-based model, the provider network manager administrates device attributes and their relationships, covering PE devices and other devices that construct the corresponding PE-based VPN 🌸
In the CE-based model, the provider network manager administrates device attributes and their relationships, covering PE and CE devices that construct the corresponding CE-based VPN 🌈
Network and customer service management systems that manage VPN networks have a bunch of challenges, depending on which type(s) of VPN network they're required to manage. Lowkey a lot to juggle 💀
2. Customer Service Operations and Management ✨
Services offered by providers can be viewed from the customer's or the provider's perspective. This section describes service management from the customer's perspective, focusing on the Customer Management function 🎀
The Customer Management function's goal is to manage the service-based operations like service ordering, service subscription, activation, etc. 📦
The Customer Management function lives in the L3VPN service manager at the Service Management Layer (SML). It mainly consists of defining the L3VPN services offered by the SP, collecting and consolidating the customer L3VPN services requirements, as well as performing some reporting for the customer. This function is correlated with the Network Management function at the Network Management Layer (NML) for initiating the L3VPN services provisioning, and getting some service reporting 🧚
2.1. Customer Service Management Information Model 💜
This section presents a framework that's used for L3VPN customer service management at the SML. The information framework represents the data that need to be managed, and the way they are represented. At the SML, the information framework that is foreseen is composed of Service Level Agreements (SLA) and Service Level Specifications (SLS) 📋
Services are described through Service Level Agreements (SLA), which are contractual documents between customers and service providers. The technical part of the service description is called the Service Level Specification (SLS). The SLS groups different kinds of parameters. Some are more related to the description of the transport of the packets, and some to the specification of the service itself 🍓
A Service Level Specification (SLS) may be defined per access network connection, per VPN, per VPN site, and/or per VPN route. The service provider may define objectives and the measurement intervals, for at least the SLS, using the following Service Level Objective (SLO) parameters:
- QoS and traffic parameters
- Availability for the site, VPN, or access connection
- Duration of outage intervals per site, route, or VPN
- Service activation interval (e.g., time to turn up a new site)
- Trouble report response time interval
- Time to repair interval
- Total incoming/outgoing traffic from a site or a (VPN) route, or that has transited through the whole VPN
- Measurement of non-conforming incoming/outgoing traffic (compliance of traffic should deserve some elaboration because of many perspectives - security, QoS, routing, etc.) from a site or a (VPN) route, or that has transited through the whole VPN
The service provider and the customer may negotiate contractual penalties in the case(s) where the provider does not meet a (set of) SLS performance objective(s). Big accountability energy 😤
Traffic parameters and actions should be defined for incoming and outgoing packets that go through the demarcation between the service provider premises and the customer's premises. For example, traffic policing functions may be activated at the ingress of the service provider's network, while traffic shaping capabilities could be activated at the egress of the service provider's network 🚦
2.2. Customer Management Functions 🛠️
This section presents detailed customer management functions in the traditional fault, configuration, accounting, performance, and security (FCAPS) management categories 🫶
2.2.1. Fault Management 🚨
The fault management function of the Customer Service Manager relies upon the manipulation of network layer failure information, and it reports incidents to the impacted customers. Such reports should be based upon and related to the VPN service offering to which the customer is subscribed. The Customer Management function support for fault management includes:
- Indication of customer's services impacted by failure
- Incident recording or logs
- Frequency of tests
- Ability to invoke probes from the customer and provider
- Ability to uncover faults before the customer notices them 👀
2.2.2. Configuration Management ⚙️
The configuration management function of the Customer Manager must be able to configure L3VPN service parameters with the level of detail that the customer is able to specify, according to service templates defined by the provider 🎯
A service template contains fields which, when instantiated, yield a definite service requirement or policy. For example, a template for an IPsec tunnel [RFC2401] would contain fields such as tunnel end points, authentication modes, encryption and authentication algorithms, shared keys (if any), and traffic filters 🔐
Other examples: a BGP/MPLS-based VPN service template would contain fields such as the customer premises that need to be interconnected via the VPN, and a QoS agreement template would contain fields such as one-way transit delay, inter-packet delay variation, throughput, and packet loss thresholds 💖
2.2.3. Accounting 🧾
The accounting management function of the Customer Manager is provided with network layer measurements information and manages this information. The Customer Manager is responsible for the following accounting functions:
- Retrieval of accounting information from the Provider Network Manager
- Analysis, storage, and administration of measurements
Some providers may require near-real time reporting of measurement information, and may offer this as part of a customer network management service ⏱️
If an SP supports "Dynamic Bandwidth Management" service, then the schedule and the amount of the bandwidth required to perform requested bandwidth allocation change(s) must be traceable for monitoring and accounting purposes. Receipts all the way down 🧾✨
Solutions should state compliance with accounting requirements, as described in section 1.7 of [RFC2975] 📚
2.2.4. Performance Management 📈
From the Customer Manager's perspective, performance management includes functions involved in the determination of the conformance level with the Service Level Specifications, such as QoS and availability measurements. The objective is to correlate accounting information with performance and fault management information to produce billing that takes into account SLA provisions for periods of time where the service level objectives are not met 💅
The performance information should reflect the quality of the subscribed VPN service as perceived by the customer. This information could be measured by the provider or controlled by a third party. The parameters that will be used to reflect the performance level could be negotiated and agreed upon between the service provider and the customer during the VPN service negotiation phase 🌟
Performance management should also support analysis of important aspects of an L3VPN, such as bandwidth utilization, response time, availability, QoS statistics, and trends based on collected data. Data bestie energy, fr fr 🔥
2.2.5. Security Management 🔒✨
okay so from the Customer Manager's point of view, security management is all about making sure the VPN is actually safe 🔐💖. That covers keeping the devices secure, protecting configuration data, and locking down access connections 🫶. Authentication and authorization (aka access control) live in this bucket too 👑.
2.2.5.1. Access Control 🚪
Management access control decides what privileges a user has for particular applications and parts of the network 💅. ngl, without it, only the data and control traffic is protected, which leaves the devices providing the L3VPN network unprotected among other equipment or resources 😭. Access control is what keeps those devices safe, making sure users can only touch the resources and applications they've been granted 🔒.
2.2.5.2. Authentication 🪪
Authentication is the process of verifying the identity of a VPN user 🦋.
2.3. Customer Management Functional Description 🗺️
This section gives a high-level example of an architecture for the L3VPN management framework, looking at the SML layer 🧚. The goal is to map the customer management functions from Section 2.2 onto architectural yet functional blocks, and to describe how they communicate with the other L3VPN management functions 💜.
+ - - - - - - - - - - - - - - - - - - - - - - - - - +
| Service +----------------+ +----------------+ |
| Management | VPN Offering| | VPN Order | |
| | Management | | Management | |
| +----------------+ +----------------+ |
| +----------------+ +----------------+ |
| | VPN | | VPN-based | |
| | Assurance | | SLS Management | |
| +----------------+ +----------------+ |
+ - - - - - - - - - - - - - - - - - - - - - - - - - +
Figure 3: Overview of the Service ManagementA customer must have a way to peek at the topology, operational state, order status, and other parameters tied to the VPN service offering they've subscribed to 👀✨.
All aspects of management information about CE devices and customer attributes of an L3VPN, manageable by a SP, should be capable of being configured and maintained by an authenticated, authorized Service manager 🛡️💅.
A customer agent should be able to make dynamic requests to change the parameters that describe a service 🔄. A customer should be able to receive responses from the SP network to these requests (modulo the existence of necessary agreements) 📨. Communication between customer Agents and (VPN) service providers will rely upon a query/response mechanism 💬.
A customer who may not be able to afford the resources to manage its CPEs should be able to outsource management of the VPN to the service provider(s) supporting the network 🫧🧚.
2.3.1. L3VPN Service Offering Management 🛍️
Hopefully the VPN deployment meets the customer's needs 🤞. So the provider must have a way to advertise the VPN-based services it offers, and then potential customers can pick the one they want to subscribe to 🎀. Extra features could be tied to this subscription phase too, like picking a level of quality for delivering the VPN service, how much of the VPN service the SP manages, security options, etc. 💖
2.3.2. L3VPN Service Order Management 📦
This operation handles the requests customers start and keeps track of how far along the related operations are 📋. Activating an order depends on having resources that meet the customer's requirements with the agreed guarantees (note that this could come out of a negotiation phase between the customer and the provider) 🤝✨.
2.3.3. L3VPN Service Assurance 📊
The customer may want a way to check whether the provider is living up to the contracted SLA 🧐. So the provider should monitor, measure, and hand the customer statistical information, as long as both parties agree on the measurement methodology and on the corresponding (set of) quality of service indicators 📈🌈.
3. Provider Network Manager 🛰️
3.1. Provider Network Management Definition 🌐
When a VPN architecture is set up within a domain (or a set of domains managed by a single SP), the SP must have a way to view the physical and logical topology of the VPN premises, the VPN operational status, the VPN service ordering status, the VPN service handling, the VPN service activation status, and other aspects tied to each customer's VPN 👑.
From a provider's perspective, managing a VPN service mostly comes down to:
- Managing the customers (the term "customer" describes a role rather than the end user, so an SP could be a customer too) and end-users in terms of SLA 🤓
- Managing the VPN premises (especially creating, modifying, and deleting operations, editing the related information for a specific link, or supervising the AAA [RFC2903] [RFC2906] operations) 🏢
- Managing the CE-PE links (particularly creating, modifying, and deleting links, and editing the related information for a specific VPN) 🔗
- Managing the service ordering, such as Quality of Service, in terms of supported classes of service, traffic isolation, etc. 🎟️
Right now, proprietary methods are often used to manage VPNs 😩. Making operators use multiple proprietary, configuration-related management methods (e.g., Command Line Interface (CLI) languages) to get into these systems is not recommended, because it bumps up the overall cost of the service (exploitation costs included), especially when multiple vendor technologies (and so multiple expertise) are used to support the VPN service offering 💸. So devices should provide standards-based interfaces 🙌. From this angle, extra requirements on possible interoperability issues and the availability of these standardized management interfaces need to be investigated 🔍.
3.2. Network Management Functions ⚙️
On top of that, the SP can offer internal services to meet customer service requirements 🪄. Some of these may include dynamic deployment of resources to support the customer-visible services, high-availability service for the customer (which may be supported by automatic failure detection), and automatic switchover to back-up VPNs 🔁. These are accomplished by working together with the FCAPS capabilities of the Provider Network Manager 🤝💕.
3.2.1. Fault Management 🚨
The Provider Network Manager's support for fault management includes:
- Fault detection (incident reports, alarms, failure visualization) 👀
- Fault localization (analysis of alarm reports, diagnostics) 🕵️♀️
- Corrective actions (data path, routing, resource allocation) 🛠️
Since L3VPNs rely on a common network infrastructure, the Provider Network Manager provides a way to tell the Service Manager which VPN customers are affected by a failure in that infrastructure 📣. The Provider Network Manager should provide pointers to the related customer configuration information to help with fault isolation and deciding on corrective actions 🧭.
It is desirable to detect faults caused by configuration errors, because they may cause VPN service to fail or not meet other requirements (e.g., traffic and routing isolation) 🙈. One approach could be a protocol that systematically checks that all constraints have been taken into account and that consistency checks have been enforced during the tunnel configuration process 🧩.
A capability that checks IP reachability within a VPN must be provided for diagnostic purposes 📡.
A capability that checks the configuration of a VPN device must be provided for diagnostic purposes 🔧.
3.2.2. Configuration Management 🎛️
The Provider Network Manager must support configuration management capabilities in order to deploy VPNs 🚀. To do that, a Provider Network Manager must provide configuration management that provisions at least the following L3VPN components: PE, CE, hierarchical tunnels, access connections, routing, and QoS, as detailed in this section 💜. If access to the Internet is provided, this option must also be configurable 🌍.
Adding or removing VPN customer premises should be as automated as possible 🤖✨.
Finally, the Provider Network Manager must make sure these devices and protocols are provisioned consistently and correctly 🫶. The solution should provide a way to check whether a service order is correctly provisioned, which would be one method of diagnosing configuration errors 🩺. Configuration errors can come from a variety of reasons: manual configuration, intruder attacks, and conflicting service requirements 😬.
Requirements for L3VPN configuration management are:
- The Provider Network Manager must support configuration of VPN membership 🎀.
- The Provider Network Manager should use identifiers for SPs, L3VPNs, PEs, CEs, hierarchical tunnels, and access connections 🏷️.
- Tunnels must be configured between PE/CE devices. This requires coordination of tunnel identifiers, paths, VPNs, and any associated service information, for example, a QoS service 🌉.
- Routing protocols running between PE routers and CE devices must be configured. For multicast services, multicast routing protocols must also be configurable 📻.
- Routing protocols running between PE routers, and between PE and P routers, must also be configured 🛣️.
PE-based only:
- Routing protocols running between PE routers and CE devices, if any, must be configured on a per-VPN basis. The Provider Network Manager must support configuration of a CE routing protocol for each access connection 🧁.
- The configuration of a PE-based L3VPN should be coordinated with the configuration of the underlying infrastructure, including Layer 1 and 2 networks that interconnect components of an L3VPN 🧵.
3.2.2.1. Provisioning Routing-based Configuration Information 🧭
If an IGP is running within the L3VPN, the Provider Network Manager must provision the related parameters 📍. This includes metrics, capacity, QoS capability, and restoration parameters 🌸.
3.2.2.2. Provisioning Access-based Configuration Information 🔌
The Provider Network Manager must provision network access between SP-managed PE and CE equipment 💡.
3.2.2.3. Provisioning Security Services-based Configuration Information 🔐🌟
When a security service is requested, the Provider Network Manager must provision the entities and associated parameters involved in delivering the service 🛡️. For example, IPsec services, tunnels, options, keys, and other parameters should be provisioned at the CE and/or the PE routers 🗝️. For an intrusion detection service, the filtering and detection rules should be provisioned on a VPN basis 🚨💖.
3.2.2.4. Provisioning VPN Resource Parameters ✨
Okay bestie, a service provider should have a way to dynamically provision the resources tied to VPN services 💅. For example, in a PE-based service, the number and size of the virtual switching and forwarding table instances should be provisioned 🌸.
If an SP supports a "Dynamic Bandwidth Management" service, then the dates, times, amounts, and intervals needed to make the requested bandwidth allocation change(s) may be traceable for accounting purposes 💜.
If an SP supports a "Dynamic Bandwidth Management" service, then the provisioning system must be able to make requested changes within the ranges and bounds specified in the Service Level Specifications. Examples of QoS parameters are the response time and the probability of being able to service such a request 🔥.
Dynamic VPN resource allocation is crucial 😭 because customers keep asking for changes (like sites joining or leaving a VPN), and it's also how you get scalability 🦋. The PE routers should be able to dynamically assign the VPN resources. This capability is especially important for dial-up and wireless VPN services 🧚.
3.2.2.5. Provisioning Value-Added Service Access 🎀
An L3VPN service provides controlled access between a set of sites over a common backbone. However, many service providers also offer a range of value-added services, like Internet access, firewall services, intrusion detection, IP telephony and IP Centrex, application hosting, backup, etc. It is outside the scope of this document to define if and how these different services interact with the VPN service offering. Still, the VPN service should be able to provide access to these various types of value-added services 💖.
A VPN service should allow the SP to supply the customer with different kinds of well-known IP services (e.g., DNS, NTP, RADIUS, etc.) needed for ordinary network operation and management. The provider should be able to provide IP services to multiple customers from one or many servers 🌈.
A firewall function may be required to restrict access to the L3VPN from the Internet [Y.1311] 🛡️.
Managed firewalls may be supported on a per-VPN basis, although multiple VPNs will be supported by the same physical device. In such cases, managed firewalls should be provided at the access point(s) of the L3VPN. Such services may be embedded in the CE or PE devices, or implemented in stand-alone devices 💅.
The Provider Network Manager should allow a customer to outsource the management of an IP service to the SP providing the VPN or to a third party 🫶.
The management system should support the collection of information necessary for optimal allocation of IP services in response to customers' orders, in correlation with provider-provisioned resources supporting the service 📊.
If Internet access is provided, reachability to and from the Internet from/to sites within a VPN should be configurable by an SP. Configuring routing policy to control distribution of VPN routes advertised to the Internet may realize this 🌸.
3.2.2.6. Provisioning Hybrid VPN Services 🦋
Configuration of interworking L3VPN solutions should also be supported, taking security and end-to-end QoS issues into account. Hybrid stuff is giving complicated but also giving important 💜.
3.2.3. Accounting 🧾
The Provider Network Manager is responsible for the measurements of resource utilization 📈.
3.2.4. Performance Management ⭐
From the Provider Network Manager's perspective, performance management includes functions involved in monitoring and collecting performance data regarding devices, facilities, and services. Main character energy 👑.
The Provider Network Manager must monitor the devices' behavior to evaluate performance metrics associated with an SLS. Different measurement techniques may be necessary, depending on the service for which an SLA is provided. Example services are QoS, security, multicast, and temporary access. These techniques may be either intrusive or non-intrusive, depending on the parameters being monitored 🔍.
The Provider Network Manager must also monitor aspects of the VPN that are not directly associated with an SLS, such as resource utilization, status of devices and transmission facilities, as well as control of monitoring resources, such as probes and remote agents at network access points used by customers and mobile users 🧚.
Devices supporting L3VPN whose level of quality is defined by SLSes should have real-time performance measurements that have indicators and threshold crossing alerts. Such thresholds should be configurable 🔔.
3.2.5. Security Management 🔐
From the Provider Network Manager's perspective, the security management function of the Provider Network Manager must include management features to guarantee the preservation of the confidentiality of customers' traffic and control data, as described in [RFC3809]. This part is serious, bestie 😤.
3.2.5.1. Authentication Management 🪪
The Provider Network Manager must support standard methods for authenticating users attempting to access VPN services.
Scalability is critical, as the number of nomadic/mobile clients is increasing rapidly. The authentication scheme implemented for such deployments must be manageable for large numbers of users and VPN access points 📱.
Support for strong authentication schemes needs to be supported to ensure the security of both VPN access point-to-VPN access point (PE to PE) and client-to-VPN Access point (CE-to-PE) communications. This is particularly important to prevent VPN access point (VPN AP) spoofing. VPN Access Point Spoofing is the situation where an attacker tries to convince a PE or a CE that the attacker is the VPN Access Point. If an attacker succeeds, then the device will send VPN traffic to the attacker (who could forward it on to the actual (and granted) access point after compromising confidentiality and/or integrity). Not me sending my data to a random hacker 💀.
In other words, a non-authenticated VPN AP can be spoofed with a man-in-the-middle attack, because the endpoints rarely verify each other. A weakly authenticated VPN AP may be subject to such an attack. However, strongly authenticated VPN APs are not subject to such attacks, because the man-in-the-middle cannot authenticate as the real AP, due to the strong authentication algorithms 🔒.
4. L3VPN Devices 🧸
4.1. Information Model 📚
Each L3VPN solution must specify the management information (MIBs, PIBs, XML schemas, etc.) for network elements involved in L3VPN services. This is an essential requirement in network provisioning. The approach should identify any L3VPN-specific information not contained in a standards track MIB module 🧾.
4.2. Communication 💬
The deployment of a VPN may span a wide range of network equipment, potentially including equipment from multiple vendors. Therefore, the provisioning of a unified network management view of the VPN shall be simplified by means of standard management interfaces and models. This will also facilitate customer self-managed (monitored) network devices or systems 🫶.
In cases where significant configuration is required whenever a new service is to be provisioned, it is important, for scalability reasons, that the NMS provides a largely automated mechanism for the relevant configuration operations. Manual configuration of VPN services (i.e., new sites, or re-provisioning existing ones) could lead to scalability issues, and should be avoided. It is thus important for network operators to maintain visibility of the complete picture of the VPN through the NMS system. This should be achieved by using standards track protocols such as SNMP. Use of proprietary command-line interfaces is not recommended 🙅♀️✨.
Intellectual Property ✨
okay so the IETF is basically like "not my drama" 🙅♀️ about whether any rights could be claimed over the tech in this doc, or whether you'd even be able to get a license for it. It also isn't saying it checked for any of that 💅. If you want the full lore on how rights work for RFCs, go read BCP 78 and BCP 79 🎀
copies of IPR disclosures sent to the IETF Secretariat are a whole thing, and so are any assurances of licenses that get promised, or the results of trying to score a general license or permission for implementers and users to use those proprietary rights. all of that lives in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️🔥
the IETF also really wants to hear from anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. so if that's you, send it to ietf-ipr@ietf.org 📬🫶
Acknowledgement
funding for the RFC Editor function is currently provided by the Internet Society. the Internet Society is literally keeping the RFC Editor running, so shoutout to them 🌈💜
📦 where this page comes from
- ietf: rfc4176 2005-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms