RFC 5920
Security Framework for MPLS and GMPLS Networks
RFC 5920: Security Framework for MPLS and GMPLS Networks 💖
Okay bestie, let's talk about RFC 5920 🎀 It's from the IETF (Internet Engineering Task Force), and it was published in July 2010. The lead editor is L. Fang, Ed., from Cisco Systems, Inc. It's Informational (so it's published for info, not as a Standards Track spec 🧚). Its header doesn't have any Obsoletes or Updates lines, so it doesn't replace or change any other RFC. The ISSN is 2070-1721 ✨
Abstract ✨
Okay so this doc gives you a whole security framework for MPLS (Multiprotocol Label Switching) and GMPLS (Generalized Multiprotocol Label Switching) networks 🦋 It covers the security stuff that actually matters for those networks. It walks through the threats, the defensive techniques, and the ways to detect and report attacks. The big focus is on RSVP-TE and LDP security, plus inter-AS and inter-provider security, which is all about keeping networks safe when they're built and run across different domains or different Service Providers 💜
Status of This Memo 🌈
This document is not an Internet Standards Track specification. It's published for informational purposes 🌸
It's a product of the IETF, so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 💅
For info about the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5920. 🔥
Copyright Notice 💜
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved ✨
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read those carefully, because they spell out your rights and restrictions for this document 🫶 Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get a proper license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be made outside it either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈
Table of Contents 🍓
1. Introduction ....................................................4
2. Terminology .....................................................5
2.1. Acronyms and Abbreviations .................................5
2.2. MPLS and GMPLS Terminology .................................6
3. Security Reference Models .......................................8
4. Security Threats ...............................................10
4.1. Attacks on the Control Plane ..............................12
4.2. Attacks on the Data Plane .................................15
4.3. Attacks on Operation and Management Plane .................17
4.4. Insider Attacks Considerations ............................19
5. Defensive Techniques for MPLS/GMPLS Networks ...................19
5.1. Authentication ............................................20
5.2. Cryptographic Techniques ..................................22
5.3. Access Control Techniques .................................33
5.4. Use of Isolated Infrastructure ............................38
5.5. Use of Aggregated Infrastructure ..........................38
5.6. Service Provider Quality Control Processes ................39
5.7. Deployment of Testable MPLS/GMPLS Service .................39
5.8. Verification of Connectivity ..............................40
6. Monitoring, Detection, and Reporting of Security Attacks .......40
7. Service Provider General Security Requirements .................42
7.1. Protection within the Core Network ........................42
7.2. Protection on the User Access Link ........................46
7.3. General User Requirements for MPLS/GMPLS Providers ........48
8. Inter-Provider Security Requirements ...........................48
8.1. Control-Plane Protection ..................................49
8.2. Data-Plane Protection .....................................53
9. Summary of MPLS and GMPLS Security .............................54
9.1. MPLS and GMPLS Specific Security Threats ..................55
9.2. Defense Techniques ........................................56
9.3. Service Provider MPLS and GMPLS Best-Practice Outlines ....57
10. Security Considerations .......................................59
11. References ....................................................59
11.1. Normative References .....................................59
11.2. Informative References ...................................62
12. Acknowledgements ..............................................64
13. Contributors' Contact Information .............................651. Introduction 🎀
Okay, security is a big deal for every network, and MPLS and GMPLS networks are no exception 💖
MPLS and GMPLS are described in [RFC3031] and [RFC3945]. Lots of RFCs on these technologies have their own security considerations, but none of them covers the general security picture. So the goal of this document is to give MPLS and GMPLS networks one comprehensive, consistent security framework 🧚 Individual documents can point here for general security considerations, and then add their own notes for the specific tech they describe.
So here's the plan. We start with the security threats that matter for MPLS and GMPLS, plus the defensive techniques to fight them. We look at issues from malicious or incorrect behavior by users and other parties, and also from negligent or incorrect behavior by providers 👀 Detecting and reporting a security attack is a huge part of defense too, so that's covered here as well ✨
Then we get into what service providers should be required to do in an MPLS or GMPLS environment. Users expect certain security characteristics from these networks. That includes security requirements for the equipment that supports MPLS and GMPLS, and operational security requirements for providers. Service providers must protect their network infrastructure and keep it secure to the level needed to offer services over their MPLS or GMPLS networks 🔥
Inter-AS and inter-provider security get extra attention, because the risk factors are higher when providers connect to each other 💅 Inter-carrier MPLS security is also covered in [MFA-MPLS-ICI].
The degree of risk and the mitigation methods depend on which MPLS or GMPLS techniques you're using 🦋 This document covers the security aspects and requirements for certain basic MPLS and GMPLS techniques and interconnection models. It does not try to cover every current and future MPLS and GMPLS technology, because analyzing the security properties of specific technologies is outside its scope 🌸
Important: in this document, we only describe the providers' security requirements that apply to MPLS and GMPLS networks. We are not covering the connected user sites 🙈 For general network operation security, check out the "Security Best Practices Efforts and Documents" [OPSEC-EFFORTS] and "Security Mechanisms for the Internet" [RFC3631]. And it's not our intention to write precise "requirements" for each specific technology, meaning we aren't defining the exact mechanisms and techniques that must be implemented to meet those security requirements 💜
2. Terminology 💅
2.1. Acronyms and Abbreviations 🌈
Here's the acronym list, bestie. Keep it handy because this doc uses all of them 🧚
AS Autonomous System
ASBR Autonomous System Border Router
ATM Asynchronous Transfer Mode
BGP Border Gateway Protocol
BFD Bidirectional Forwarding Detection
CE Customer-Edge device
CoS Class of Service
CPU Central Processing Unit
DNS Domain Name System
DoS Denial of Service
ESP Encapsulating Security Payload
FEC Forwarding Equivalence Class
GMPLS Generalized Multi-Protocol Label Switching
GCM Galois Counter Mode
GRE Generic Routing Encapsulation
ICI InterCarrier Interconnect
ICMP Internet Control Message Protocol
ICMPv6 ICMP in IP Version 6
IGP Interior Gateway Protocol
IKE Internet Key Exchange
IP Internet Protocol
IPsec IP Security
IPVPN IP-based VPN
LDP Label Distribution Protocol
L2TP Layer 2 Tunneling Protocol
LMP Link Management Protocol
LSP Label Switched Path
LSR Label Switching Router
MD5 Message Digest Algorithm
MPLS Multiprotocol Label Switching
MP-BGP Multiprotocol BGP
NTP Network Time Protocol
OAM Operations, Administration, and Maintenance
PCE Path Computation Element
PE Provider-Edge device
PPVPN Provider-Provisioned Virtual Private Network
PSN Packet-Switched Network
PW Pseudowire
QoS Quality of Service
RR Route Reflector
RSVP Resource Reservation Protocol
RSVP-TE Resource Reservation Protocol with Traffic Engineering
Extensions
SLA Service Level Agreement
SNMP Simple Network Management Protocol
SP Service Provider
SSH Secure Shell
SSL Secure Sockets Layer
SYN Synchronize packet in TCP
TCP Transmission Control Protocol
TDM Time Division Multiplexing
TE Traffic Engineering
TLS Transport Layer Security
ToS Type of Service
TTL Time-To-Live
UDP User Datagram Protocol
VC Virtual Circuit
VPN Virtual Private Network
WG Working Group of IETF
WSS Web Services Security2.2. MPLS and GMPLS Terminology 🎀
okay so bestie, this section is basically the glossary for MPLS and GMPLS 💅 it uses a bunch of terms that are defined properly in [RFC3031] and [RFC3945], so if you want the full tea, go read those. but this section repeats the most important definitions so you don't have to jump around. no cap, it's giving organized 🫶
Core network: an MPLS/GMPLS core network is the central network infrastructure made of P and PE routers 🌸 it can be one or more networks that all belong to a single SP (service provider), so it's giving "one provider, maybe a few networks, same vibe" ✨
Customer Edge (CE) device: a CE device is a router or switch sitting in the customer's network, and it's the thing that talks to the service provider's network 💖
Forwarding Equivalence Class (FEC): a group of IP packets that all get forwarded the same way (like, over the same path, or with the same forwarding treatment) 🦋 the way that packets get grouped together here is so satisfying, literally iconic 😭
Label: a short, fixed length, physically contiguous identifier, and it's usually only meaningful locally 🧚
Label merging: this is when multiple incoming labels for one FEC get replaced with a single outgoing label 🌈 it's like everyone funneling into one lane, very main character energy 💜
Label Switched Hop: a hop between two MPLS nodes where the forwarding is done using labels 🍓
Label Switched Path (LSP): the path through one or more LSRs, at one level of the hierarchy, that packets in a particular FEC follow 🛤️✨ it's the route, bestie, the whole route 💅
Label Switching Routers (LSRs): an MPLS/GMPLS node that's assumed to have a forwarding plane that can (a) recognize either packet or cell boundaries, and (b) process either packet headers or cell headers 👑 it's a lot, but it's giving versatile 🔥
Loop Detection: a way of handling loops where loops are allowed to get set up and data can be sent over them, but the loop gets detected later 🙈 it's like letting the drama happen and then catching it after the fact 💀
Loop Prevention: a way of handling loops where data is never sent over a loop at all 🫶 the way this is the opposite of detection is so clean, iykyk 💖
Label Stack: an ordered set of labels 🎀
Merge Point: a node where label merging is done 🦋
MPLS Domain: a contiguous set of nodes that do MPLS routing and forwarding and are also in one Routing or Administrative Domain 🌸 they're all in the same friend group, lowkey 💜
MPLS Edge Node: an MPLS node that connects an MPLS domain with a node outside of the domain. this happens either because the outside node doesn't run MPLS, or because it's in a different domain 👀 note that if an LSR has a neighboring host that isn't running MPLS, then that LSR is an MPLS edge node 💅✨
MPLS Egress Node: an MPLS edge node in its role of handling traffic as it leaves an MPLS domain 🚪 bye bye traffic 👋
MPLS Ingress Node: an MPLS edge node in its role of handling traffic as it enters an MPLS domain 🚪 hello traffic 🌈
MPLS Label: a label carried in a packet header, which represents the packet's FEC 🧚♀️
MPLS Node: a node running MPLS. an MPLS node is aware of MPLS control protocols, runs one or more routing protocols, and is capable of forwarding packets based on labels 💖 it MAY also be capable of forwarding native IP packets 🫶
Multiprotocol Label Switching (MPLS): MPLS is an architecture for efficient data packet switching and routing 🔥 it gives data packets labels. instead of doing the longest match for each packet's destination like regular IP forwarding does, MPLS makes forwarding decisions based only on the label, without looking at the packet itself 🙈 this lets you build end-to-end circuits across any type of transport medium, using any protocols, and that is genuinely so powerful 😭✨
P: Provider Router. a Provider Router is a router in the Service Provider's core network that doesn't have interfaces directly towards the customer 🌸 P routers are used to interconnect the PE routers and/or other P routers inside the core network 🦋
PE: Provider Edge device. a Provider Edge device is the equipment in the Service Provider's network that interfaces with the equipment in the customer's network 💜 it's the edge bestie, the one at the border 🍓
PPVPN: Provider-Provisioned Virtual Private Network, including Layer 2 VPNs and Layer 3 VPNs 🎀
VPN: Virtual Private Network, which restricts communication between a set of sites, making use of an IP backbone shared by traffic not going to or not coming from those sites [RFC4110] 🌈 so the sites get their own private vibe even though they're sharing the backbone 🫶
3. Security Reference Models 🛡️
okay so this section is all about the security reference model for MPLS/GMPLS networks 👑 this is where we set the ground rules for who we trust, lowkey the foundation of the whole security situation 💅
This document defines each MPLS/GMPLS core in a single domain to be a trusted zone 💖 the main worry is breaches of security from the "outside" of a trusted zone getting to the "inside" of it 😬 Figure 1 shows the concept of trusted zones within the MPLS/GMPLS framework 🌸
/-------------\
+------------+ / \ +------------+
| MPLS/GMPLS +---/ \--------+ MPLS/GMPLS |
| user | MPLS/GMPLS Core | user |
| site +---\ /XXX-----+ site |
+------------+ \ / XXX +------------+
\-------------/ | |
| |
| +------\
+--------/ "Internet"
|<- Trusted zone ->|
MPLS/GMPLS Core with user connections and Internet connection
Figure 1: The MPLS/GMPLS Trusted Zone ModelThe trusted zone is the MPLS/GMPLS core in a single AS within a single Service Provider 🎀
A trusted zone contains elements and users with similar security properties, such as exposure and risk level 🦋 in the MPLS context, an organization is typically considered as one trusted zone 🫶
The boundaries of a trust domain SHOULD be carefully defined when analyzing the security properties of each individual network 🔍 e.g., the boundaries can be at the link termination, remote peers, areas, or quite commonly, ASes 🌈
In principle, the trusted zones should be separate 🙃 however, typically MPLS core networks also offer Internet access, in which case a transit point (marked with "XXX" in Figure 1) is defined 🧚 in the case of MPLS/GMPLS inter-provider connections or InterCarrier Interconnect (ICI), the trusted zone of each provider ends at the respective ASBRs (ASBR1 and ASBR2 for Provider A and ASBR3 and ASBR4 for Provider B in Figure 2) 💜
A key requirement of MPLS and GMPLS networks is that the security of the trusted zone MUST NOT be compromised by interconnecting the MPLS/GMPLS core infrastructure with another provider's core (MPLS/GMPLS or non-MPLS/GMPLS), the Internet, or end users 😱 this one is non-negotiable, bestie 🔥
In addition, neighbors may be trusted or untrusted 👀 neighbors may be authorized or unauthorized 🙈 an authorized neighbor is the neighbor one establishes a peering relationship with 🤝 even though a neighbor may be authorized for communication, it MAY not be trusted 💅 for example, when connecting with another provider's ASBRs to set up inter-AS LSPs, the other provider is considered an untrusted but authorized neighbor 🫶
+---------------+ +----------------+
| | | |
| MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS |
CE1--PE1 Network | | Network PE2--CE2
| Provider A ASBR2----ASBR4 Provider B |
| | | |
+---------------+ +----------------+
InterCarrier
Interconnect (ICI)
For Provider A:
Trusted Zone: Provider A MPLS/GMPLS network
Authorized but untrusted neighbor: provider B
Unauthorized neighbors: CE1, CE2
Figure 2: MPLS/GMPLS Trusted Zone and Authorized NeighborAll aspects of network security that don't depend on whether a network is an MPLS/GMPLS network are out of scope 🙅 for example, attacks from the Internet to a user's web-server connected through the MPLS/GMPLS network are not considered here, unless the way the MPLS/GMPLS network is provisioned could make a difference to the security of this user's server 🖥️✨
4. Security Threats 💀
okay this is the scary section, bestie, so buckle up 😭 it talks about the different network security threats that may endanger MPLS/GMPLS networks 🚨 RFC 4778 [RFC4778] already gave the best current operational security practices in Internet Service Provider environments, so go check that out too 📚
A successful attack on a particular MPLS/GMPLS network or on an SP's MPLS/GMPLS infrastructure may cause one or more of the following ill effects:
- Observation, modification, or deletion of a provider's or user's data. 👀
- Replay of a provider's or user's data. 🔁
- Injection of inauthentic data into a provider's or user's traffic stream. 😈
- Traffic pattern analysis on a provider's or user's traffic. 🕵️
- Disruption of a provider's or user's connectivity. 📴
- Degradation of a provider's service quality. 📉
- Probing a provider's network to determine its configuration, capacity, or usage. 🔍
It's useful to think about threats, whether malicious or accidental, as coming from different categories of sources 🧠 for example, they may come from:
- Other users whose services are provided by the same MPLS/GMPLS core. 👥
- The MPLS/GMPLS SP or persons working for it. 🏢
- Other persons who obtain physical access to an MPLS/GMPLS SP's site. 🚪
- Other persons who use social engineering methods to influence the behavior of an SP's personnel. 🎭
- Users of the MPLS/GMPLS network itself, e.g., intra-VPN threats. (Such threats are beyond the scope of this document.) 🙅
- Others, e.g., attackers from the Internet at large. 🌐
- Other SPs in the case of MPLS/GMPLS inter-provider connection. The core of the other provider may or may not be using MPLS/GMPLS. 🤷
- Those who create, deliver, install, and maintain software for network equipment. 💻
Given that security is generally a tradeoff between expense and risk, it's also useful to think about how likely different attacks are to happen 💸⚖️ there is at least a perceived difference in the likelihood of most types of attacks being successfully mounted in different environments, such as:
- An MPLS/GMPLS core interconnecting with another provider's core. 🤝
- An MPLS/GMPLS configuration transiting the public Internet. 🌍
Most types of attacks get easier to mount, and so more likely, as the shared infrastructure that provides service grows from a single SP to multiple cooperating SPs to the global Internet 📈 attacks that might not be worth worrying about in a closely controlled environment often deserve defensive measures in broader, more open environments 🛡️ in closed communities, it's often practical to deal with misbehavior after the fact 🧾 an employee can be disciplined, for example 💼
The following sections discuss specific types of exploits that threaten MPLS/GMPLS networks 💥 ✨
4.1. Attacks on the Control Plane 🛡️
okay so this category is all about attacks on the control structures that the SP runs for MPLS/GMPLS cores 🎀
quick thing to know: in MPLS the control plane uses the same links and network resources as the data plane, but the GMPLS control plane can run on totally separate resources. so it might be physically separate from the data plane 🦋
that split changes what an attacker can do. the big one is that the data plane can't get congested by an attack on a physically separate control plane, which could happen if they shared resources 😭 also, if the control plane uses different resources than the data plane, you can't assume the control plane is secure just because the data plane resources are. 💅
this section is about the outsider attack. the insider attack gets its own discussion in Section 4.4 🫶
4.1.1. LSP Creation by an Unauthorized Element
the unauthorized element can be a local CE or a router in another domain 👀 it can generate MPLS signaling messages, and at the very least that creates extra control plane and forwarding state. if it works, network bandwidth could get reserved for no reason. this can also lead to theft of service, or even compromise of the whole network 💀
4.1.2. LSP Message Interception
this threat could happen by monitoring network traffic, for example after a physical intrusion 🕵️♀️ without physical access, it could still happen through an unauthorized software modification. and tons of technologies like terrestrial microwave, satellite, or free-space optical links can be intercepted without any physical intrusion at all 😱 if it works, it could give the attacker info that leads to label spoofing attacks, and it also raises confidentiality issues 🔐
4.1.3. Attacks against RSVP-TE
RSVP-TE, described in [RFC3209], is the control protocol used to set up GMPLS and traffic engineered MPLS tunnels 🚇
there are two major kinds of denial-of-service (DoS) attacks against an MPLS domain based on RSVP-TE 🙈 the attacker can either set up loads of unauthorized LSPs or send a storm of RSVP messages. it has been shown that unprotected routers running RSVP can be effectively disabled by both kinds of DoS attack 💀
these attacks can even be combined ✨ the attacker uses the unauthorized LSPs to carry extra RSVP (or other) messages across routers that might otherwise filter them out. RSVP attacks can be aimed at adjacent routers on the attacker's border, or at non-adjacent routers inside the MPLS domain, if there's no effective way to filter them out 🫠
4.1.4. Attacks against LDP
LDP, described in [RFC5036], is the control protocol used to set up MPLS tunnels without TE 🧚
there are two significant attacks against LDP 😤 first, an unauthorized network element can set up an LDP session by sending LDP Hello and LDP Init messages. that could lead to an LSP being set up, plus extra LDP state table consumption. second, even without getting any LSPs up, an attacker can launch a DoS attack with a storm of LDP Hello messages or LDP TCP SYN messages. that can mean high CPU utilization or table space exhaustion on the target router 🔥
4.1.5. Denial-of-Service Attacks on the Network Infrastructure
DoS attacks can be pulled off with an MPLS signaling storm 🌪️ this causes high CPU utilization and could lead to control-plane resource starvation 💀
control-plane DoS attacks can target the specific mechanisms the SP uses to deliver its services, or the general infrastructure of the service provider, like P routers or shared parts of PE routers 🏗️ (an attack against the general infrastructure only falls in the scope of this document if it can happen in relation to the MPLS/GMPLS infrastructure. otherwise it isn't an MPLS/GMPLS-specific issue 🙃)
the attacks described in the following sections can each have denial of service as one of their effects, and other DoS attacks are possible too 🍓
4.1.6. Attacks on the SP's MPLS/GMPLS Equipment via Management Interfaces
this covers unauthorized access to an SP's infrastructure equipment 👀 the goal could be to reconfigure the equipment, or to pull info about the network like statistics or topology 📊
4.1.7. Cross-Connection of Traffic between Users
this is when the expected isolation between separate users (who might be VPN users) gets breached 😭 it includes cases like:
- A site being connected into the "wrong" VPN.
- Traffic being replicated and sent to an unauthorized user.
- Two or more VPNs being improperly merged together.
- A point-to-point VPN connecting the wrong two points.
- Any packet or frame being improperly delivered outside the VPN to which it belongs.
misconnection or cross-connection of VPNs can be caused by service provider or equipment vendor error, or by an attacker's malicious action 🙃 the breach can be physical (like PE-CE links that got misconnected) or logical (like improper device configuration) 🔌
anecdotal evidence suggests that cross-connection is one of the biggest security concerns for users (or would-be users) 💜
4.1.8. Attacks against Routing Protocols
this covers attacks against the underlying routing protocols the SP runs, the ones that directly support the MPLS/GMPLS core 🗺️ (attacks against using routing protocols to distribute backbone routes are out of scope for this document.) specific attacks on popular routing protocols have been studied a lot and are described in [RFC4593] 📚
4.1.9. Other Attacks on Control Traffic
besides routing and management protocols (covered in the earlier sections), a bunch of other control protocols can be directly involved in delivering services over the MPLS/GMPLS core ✨ these include, but may not be limited to:
- MPLS signaling (LDP, RSVP-TE) discussed above in subsections 4.1.4 and 4.1.3
- PCE signaling
- IPsec signaling (IKE and IKEv2)
- ICMP and ICMPv6
- L2TP
- BGP-based membership discovery
- Database-based membership discovery (e.g., RADIUS)
- Other protocols that may be important to the control infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE.
attacks might subvert or disrupt what these protocols do, for example through impersonation or DoS 😩
also, all of the data-plane attacks can be carried out against packets of the control and management planes too: insertion, spoofing, replay, deletion, pattern analysis, and the other attacks mentioned above 🙈
4.2. Attacks on the Data Plane 🎀
this category covers attacks on the provider's or end user's data 💖 from the MPLS/GMPLS network end user's point of view, some of this might actually be control-plane traffic, like routing protocols running from user site A to user site B over IP or non-IP connections, which could be some kind of VPN 🫶
4.2.1. Unauthorized Observation of Data Traffic
this is "sniffing" provider or end user packets and reading what's inside 👀 it can expose confidential info. it can also be a first step for other attacks (described below) where the recorded data gets modified and re-inserted, or just replayed later 🔁
4.2.2. Modification of Data Traffic
this is about changing the contents of packets as they travel through the MPLS/GMPLS core ✏️
4.2.3. Insertion of Inauthentic Data Traffic: Spoofing and Replay
spoofing means sending user packets, or inserting packets into a data stream, that don't belong there, with the goal of getting the recipient to accept them as legit 🎭 this category also includes inserting copies of once-legit packets that were recorded and replayed 🔁
4.2.4. Unauthorized Deletion of Data Traffic
this is causing packets to be dropped as they travel through the MPLS/GMPLS networks 🗑️ it's a specific type of denial-of-service attack 😔
4.2.5. Unauthorized Traffic Pattern Analysis
this is also "sniffing" provider or user packets, but looking at aspects or meta-aspects that stay visible even when the packets are encrypted 🔍 an attacker might learn useful stuff from the amount and timing of traffic, packet sizes, source and destination addresses, and so on. for most users this is considered way less of a concern than the other types in this section 🤷♀️
4.2.6. Denial-of-Service Attacks
denial-of-service (DoS) attacks are when an attacker tries to disrupt or stop legitimate users from using a service 😤 taking network devices out of service, changing their configuration, or swamping them with requests for service are a few of the ways to do it 🌊
swamping the network with requests for service, also known as a "resource exhaustion" DoS attack, can target any resource in the network, like link bandwidth, packet forwarding capacity, session capacity for various protocols, CPU power, table size, storage overflows, and more 💥
resource exhaustion DoS attacks on the data plane can be mounted against a particular provider or end user by trying to insert (spoof) a huge amount of inauthentic data into their network from outside the trusted zone 🚨 the possible results are exhausting the bandwidth available to that provider or end user, or overwhelming the cryptographic authentication mechanisms of the provider or end user 🔐
data-plane resource exhaustion attacks can also be mounted by flooding the service provider's general (MPLS/GMPLS-independent) infrastructure with traffic 🌧️ these attacks on the general infrastructure usually aren't an MPLS/GMPLS-specific issue, unless the attack comes from another MPLS/GMPLS network user in a privileged position. (for example, an MPLS/GMPLS network user might be able to monopolize data-plane resources and thus disrupt other users 😬)
lots of DoS attacks use amplification, where the attacker recruits innocent parties to boost the effect of the attack 📣 the attacker might send packets to a broadcast or multicast address with the spoofed source address of the victim, and then all of the recipients respond to the victim 😱
4.2.7. Misconnection
misconnection can happen through a deliberate attack, or through misconfiguration or misconnection of network resources 🔀 the likely result is data being delivered to the wrong destination, or being black-holed 🕳️
in GMPLS with physically diverse control and data planes, it may be possible for a data-plane misconnection to go undetected by the control plane 👻
in optical networks under GMPLS control, misconnection may create physical safety risks, since unprotected lasers may be switched on without warning ⚠️🔦
4.3. Attacks on Operation and Management Plane 🛠️
Okay so the Operation and Management (O&M) plane has been the main character of network security talk for like the last 20 years 💅 RFC 4778 [RFC4778] may serve as the best current operational security practices in Internet Service Provider environments. RFC 4377 [RFC4377] gave us the Operations and Management Requirements for MPLS networks. Also check the Security Considerations of RFC 4377 and Section 7 of RFC 4378 [RFC4378] 📚
O&M across the MPLS-ICI could also be a source of security threats 🚨 It can hit the provider's infrastructure and the service offered over the MPLS-ICI. A huge pile of O&M messages could overwhelm an ASBR's processing if the ASBR isn't properly protected 😩 Maliciously generated O&M messages could also bring down an otherwise healthy service (e.g., MPLS Pseudowire), so service security takes a hit 💀 LSP ping does not support authentication today, and that should be a subject for future considerations 🙈 Bidirectional Forwarding Detection (BFD), however, does have support for carrying an authentication object. It also supports Time-To-Live (TTL) processing as an anti-replay measure ✨ Implementations conformant with this MPLS-ICI should support BFD authentication and must support the procedures for TTL processing 🫶
Regarding GMPLS O&M considerations in optical interworking, there's a good discussion on security for management interfaces to Network Elements [OIF-Sec-Mag] 🌈
Network elements typically have one or more (in some cases many) O&M interfaces used for network management, billing and accounting, configuration, maintenance, and other administrative activities 🍓
Remote access to a network element through these O&M interfaces is frequently a requirement. Securing the control protocols while leaving these O&M interfaces unprotected opens up a huge security vulnerability 😭 Network elements are an attractive target for intruders who want to disrupt or gain free access to telecommunications facilities. Much has been written about this since the 1980s. In the 1990s, telecommunications facilities were identified in the U.S. and other countries as part of the "critical infrastructure", and more emphasis was placed on thwarting these attacks from a wider range of potentially well-funded and determined adversaries 🕵️
At one time, careful access controls and password management were a sufficient defense, but they no longer are 🙅 Networks using the TCP/IP protocol suite are vulnerable to forged source addresses, recording and later replay, packet sniffers picking up passwords, re-routing of traffic to facilitate eavesdropping or tampering, active hijacking of TCP connections, and a variety of denial-of-service attacks. The ease of forging TCP/IP packets is the main reason network management protocols lacking strong security have not been used to configure network elements (e.g., with the SNMP SET command) 🤯
Readily available hacking tools exist that let an eavesdropper on a LAN take over one end of any TCP connection, so that the legitimate party is cut off 🫣 In addition, enterprises and Service Providers in some jurisdictions need to safeguard data about their users and network configurations from prying. An attacker could eavesdrop and observe traffic to analyze usage patterns and map a network configuration. An attacker could also gain access to systems and manipulate configuration data or send malicious commands 👀
Therefore, in addition to authenticating the human user, more sophisticated protocol security is needed for O&M interfaces, especially when they're configured over TCP/IP stacks 🔐 Finally, relying on a perimeter defense, such as firewalls, is insufficient protection against "insider attacks" or against penetrations that compromise a system inside the firewall as a launching pad to attack network elements. The insider attack is discussed in the following section 🧚
4.4. Insider Attacks Considerations 🕵️♀️
The chain of trust model means that MPLS and GMPLS networks are particularly vulnerable to insider attacks. These can be launched by any malign person with access to any LSR in the trust domain. Insider attacks could also be launched by compromised software within the trust domain. Such attacks could, for example, advertise non-existent resources, modify advertisements from other routers, request unwanted LSPs that use network resources, or deny or modify legitimate LSP requests 😱
Protection against insider attacks is largely for future study in MPLS and GMPLS networks. Some protection can be obtained by providing strict security for software upgrades and tight OAM access control procedures. Further protection can be achieved by strict control of user (i.e., operator) access to LSRs. Software change management and change tracking (e.g., CVS diffs from text-based configuration files) helps in spotting irregularities and human errors. In some cases, configuration change approval processes may also be warranted. Software tools could be used to check configurations for consistency and compliance. Software tools may also be used to monitor and report network behavior and activity in order to quickly spot any irregularities that may be the result of an insider attack 🔍
Insider attacks are sneaky, bestie, so the vibe is "trust, but verify" 🚨
5. Defensive Techniques for MPLS/GMPLS Networks 🛡️
The defensive techniques discussed in this document are intended to describe methods by which some security threats can be addressed. They are not intended as requirements for all MPLS/GMPLS implementations. The MPLS/GMPLS provider should determine the applicability of these techniques to the provider's specific service offerings, and the end user may wish to assess the value of these techniques to the user's service requirements. The operational environment determines the security requirements. Therefore, protocol designers need to provide a full set of security services, which can be used where appropriate 💖
The techniques discussed here include encryption, authentication, filtering, firewalls, access control, isolation, aggregation, and others 🧰
Often, security is achieved by careful protocol design, rather than by adding a security method. For example, one method of mitigating DoS attacks is to make sure that innocent parties cannot be used to amplify the attack. Security works better when it is "designed in" rather than "added on" 🏗️
Nothing is ever 100% secure 💀 Defense therefore involves protecting against those attacks that are most likely to occur or that have the most direct consequences if successful. For those attacks that are protected against, absolute protection is seldom achievable. More often, it is sufficient just to make the cost of a successful attack greater than what the adversary will be willing or able to expend 💸
Successfully defending against an attack does not necessarily mean the attack must be prevented from happening or from reaching its target. In many cases, the network can instead be designed to withstand the attack. For example, the introduction of inauthentic packets could be defended against by preventing their introduction in the first place, or by making it possible to identify and eliminate them before delivery to the MPLS/GMPLS user's system. The latter is frequently a much easier task 🎯
5.1. Authentication 🪪
To prevent security issues arising from some DoS attacks or from malicious or accidental misconfiguration, it is critical that devices in the MPLS/GMPLS should only accept connections or control messages from valid sources. Authentication refers to methods to ensure that message sources are properly identified by the MPLS/GMPLS devices with which they communicate. This section focuses on identifying the scenarios in which sender authentication is required and recommends authentication mechanisms for these scenarios 🔐
Cryptographic techniques (authentication, integrity, and encryption) do not protect against some types of denial-of-service attacks, specifically resource exhaustion attacks based on CPU or bandwidth exhaustion. In fact, the software-based cryptographic processing required to decrypt or check authentication may in some cases increase the effect of these resource exhaustion attacks. With a hardware cryptographic accelerator, attack packets can be dropped at line speed without a cost to software cycles. Cryptographic techniques may, however, be useful against resource exhaustion attacks based on the exhaustion of state information (e.g., TCP SYN attacks) 🧠
The MPLS data plane, as presently defined, is not amenable to source authentication, as there are no source identifiers in the MPLS packet to authenticate. The MPLS label is only locally meaningful. It may be assigned by a downstream node or upstream node for multicast support 🏷️
When the MPLS payload carries identifiers that may be authenticated (e.g., IP packets), authentication may be carried out at the client level. But this does not help the MPLS SP, as these client identifiers belong to an external, untrusted network 🙃
5.1.1. Management System Authentication 🖥️
Management system authentication includes the authentication of a PE to a centrally managed network management or directory server when directory-based "auto-discovery" is used. It also includes authentication of a CE to the configuration server, when a configuration server system is used 📋
Authentication should be bidirectional, including PE or CE to configuration server authentication for the PE or CE to be certain it is communicating with the right server 👯
5.1.2. Peer-to-Peer Authentication 🤝
Peer-to-peer authentication includes peer authentication for network control protocols (e.g., LDP, BGP, etc.) and other peer authentication (i.e., authentication of one IPsec security gateway by another) 🦋
Authentication should be bidirectional, including PE or CE to configuration server authentication for the PE or CE to be certain it is communicating with the right server 💜
As indicated in Section 5.1.1, authentication should be bidirectional ✨
5.1.3. Cryptographic Techniques for Authenticating Identity 🔑
Cryptographic techniques offer several mechanisms for authenticating the identity of devices or individuals. These include the use of 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 Certification 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 securing an MPLS/GMPLS network 🌸
5.2. Cryptographic Techniques 🔐✨
okay so cryptography is basically the ultimate glow-up for MPLS/GMPLS defenses 💖 these same tools work for regular network traffic too, and they can do three big things: keep communication between devices confidential (encryption) 🤫, prove who the devices are 🪪, and catch when data got changed in transit or replayed from older messages 🚨.
Authentication gets its own deep dive in a separate "Authentication" section (Section 5.1), so go check that out too 🎀
Now, crypto isn't always the move, bestie 🙈 It adds complexity to a service, so it's not automatically the most practical choice in every situation. It adds extra computing work for devices, which can cut down how many user connections a device can handle, or otherwise lower its capacity, and that can push up the provider's costs 💸 Setting up encryption on devices usually makes their configuration more complicated and adds labor cost, and some key management system is usually needed too 🔑 Packets also tend to get bigger once they're encrypted or have integrity checks or replay counters added. That means more network traffic and a higher chance of packet fragmentation, which comes with more overhead 📦 (The length increase can often be eased a bit with data compression techniques, but that costs extra computing power too 🧮) And finally, some providers already use enough other defenses, like physical isolation or filtering and firewall techniques, that they may not see any extra benefit from encryption 🛡️
Users might want confidentiality end to end 🫶 Generally, encrypting for confidentiality has to come with cryptographic integrity checks too, so certain active attacks against the encrypted communications can't slip through 😭 On today's processors, encryption and integrity checks run extremely fast ⚡ but key management can be more demanding, both computationally and administratively 🧠
The trust model among the MPLS/GMPLS user, the MPLS/GMPLS provider, and the rest of the network is a huge factor in deciding whether cryptographic protection fits a specific MPLS/GMPLS implementation 👑 It basically decides where the protection should go:
- If the data path between the user's site and the provider's PE is not trusted, then it 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 providers' networks, then the PE-PE traffic may be cryptographically protected. One also should consider cases where L1 technology may be vulnerable to eavesdropping.
- If the user does not trust any zone outside of its premises, it may require end-to-end or CE-CE cryptographic protection. This fits within the scope of this MPLS/GMPLS security framework when the CE is provisioned by the MPLS/GMPLS provider.
- If the user requires remote access to its site from a system at a location that is not a customer location (for example, access by a traveler), there may be a requirement for cryptographically protecting the traffic between that system and an access point or a customer's site. If the MPLS/GMPLS provider supplies 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 protected cryptographically, as well.
Access control usually starts with authenticating the entity 🪪 If cryptographic services are part of the picture, it's important to bind the authentication to the key management. Otherwise, the protocol is vulnerable to being hijacked between the authentication and key management 😱
Here's the tea 🍵 CE-CE cryptographic protection can give integrity and confidentiality against third parties, but if the MPLS/GMPLS provider has complete management control over the CE (encryption) devices, the provider might be able to get into the user's traffic or internal network 👀 Encryption devices could potentially be reconfigured to use null encryption, bypass cryptographic processing altogether, reveal internal configuration, or provide some means of sniffing or diverting unencrypted traffic. So an implementation using CE-CE encryption needs to think carefully about the trust relationship between the MPLS/GMPLS user and provider 🧐 MPLS/GMPLS users and providers may want to negotiate a service level agreement (SLA) for CE-CE encryption that clearly draws the line on who handles management of cryptographic protection on the CE devices 📜 That line may also depend on what the CE devices can do. For example, the CE might support some partitioning of management, a configuration lock-down ability, or a shared capability to verify the configuration. In general, if the managed CE-CE model is used, the MPLS/GMPLS user needs a pretty high level of trust that the MPLS/GMPLS provider will properly provision and manage the CE devices 💅
5.2.1. IPsec in MPLS/GMPLS 🦋
IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC4309] [RFC2411] [IPSECME-ROADMAP] is the security protocol of choice for protection at the IP layer 👑 It gives robust security for IP traffic between pairs of devices. Non-IP traffic, like IS-IS routing, has to be converted to IP (for example, by encapsulation) before it can use IPsec 🔄 When MPLS is encapsulating IP traffic, IPsec covers encryption of the IP client layer. For non-IP client traffic, see Section 5.2.4 (MPLS PWs) 🧚
In the MPLS/GMPLS model, IPsec can be used to protect IP traffic between PEs, between a PE and a CE, or from CE to CE. CE-to-CE IPsec may be used in either a provider-provisioned or a user-provisioned model. IPsec protection of data inside the user's site is outside the scope of this document, since it's just handled as user data by the MPLS/GMPLS core 🏠 However, if the SP performs compression, pre-encryption will have a major effect on that operation 🗜️
IPsec doesn't specify cryptographic algorithms by itself 🙅♀️ It can use a variety of integrity or confidentiality algorithms (or even combined integrity and confidentiality algorithms) with different key lengths, like AES encryption or AES message integrity checks. There are trade-offs between key length, computational burden, and how strong the encryption is 🎭 A full discussion of those trade-offs is beyond the scope of this document. In practice, any currently recommended IPsec protection offers enough security to substantially reduce the likelihood of it being directly targeted by an attacker. Other weaker links in the chain of security are likely to get attacked first 🎯 MPLS/GMPLS users may want a Service Level Agreement (SLA) that spells out the SP's responsibility for ensuring data integrity and confidentiality, instead of digging into the specific encryption techniques used in the MPLS/GMPLS service 📑
Encryption algorithms generally come with two parameters: a mode, like Cipher Block Chaining, and a key length, like AES-192. (Don't mix this up with two other senses in which the word "mode" gets used: IPsec itself can run in Tunnel Mode or Transport Mode, and IKE [version 1] uses Main Mode, Aggressive Mode, or Quick Mode.) I really need to stress this one 🚨 IPsec encryption without an integrity check is a state of sin. 💀
For a lot of the MPLS/GMPLS provider's network control messages, and some user requirements, cryptographic authentication of messages without encrypting their contents may be enough security 🤍 With IPsec, message authentication comes from the Authentication Header (AH), or from the Encapsulating Security Protocol (ESP) with NULL encryption. When control messages need integrity but don't use IPsec, other cryptographic authentication methods are often available 🧩 The message authentication methods considered secure right now are based on hashed message authentication codes (HMAC) [RFC2104], implemented with a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1) [RFC3174]. No attacks against HMAC SHA-1 are likely to play out in the near future, but people may soon find SHA-1 collisions 😬 So it's important that mechanisms be designed to stay flexible about the choice of hash functions and message integrity checks 🔄 Also, many of these mechanisms don't include a convenient way to manage and update keys 🔑
A mechanism that combines confidentiality, data-origin authentication, and connectionless integrity is the use of AES in GCM (Counter with CBC-MAC) mode (RFC 4106) [RFC4106] 🌈 literal chef's kiss 👩🍳
5.2.2. MPLS / GMPLS Diffserv and IPsec 🍓
MPLS and GMPLS provide differentiated services based on traffic type, and they can run into some conflicts with IPsec encryption 🥺 Because encryption hides the contents of packets, it may not be possible to tell the encrypted traffic apart the same way as unencrypted traffic. Diffserv markings are copied to the IPsec header and can provide some differentiation, but not every traffic type can be accommodated this way 📉 Using IPsec without IKE or IKEv2 (the better choice) is not advisable 🙅♀️ IKEv2 handles IPsec Security Association creation and management, entity authentication, key agreement, and key update. It works with a variety of authentication methods, including pre-shared keys, public key certificates, and EAP 🎀 If DoS attacks against IKEv2 are considered an important threat to mitigate, the cookie-based anti-spoofing feature of IKEv2 should be used 🛡️ IKEv2 has its own set of cryptographic methods, but any of the default suites specified in [RFC4308] or [RFC4869] provides more than adequate security 💜
5.2.3. Encryption for Device Configuration and Management ✨
okay so for configuring and managing MPLS/GMPLS devices, you want encryption and authentication on the management connection that's basically on par with what IPsec gives you 🔐 that's the vibe we're going for, bestie 💅
there are a few ways to move device management traffic around that come with authentication, integrity, and confidentiality 🫶
- Secure Shell (SSH) protects TELNET [STD8] or terminal-like connections, so you can configure devices safely 💖
- SNMPv3 [STD62] gives you encrypted and authenticated protection for SNMP-managed devices 🦋
- Transport Layer Security (TLS) [RFC5246] and its close cousin, the Secure Sockets Layer (SSL), are everywhere for HTTP-based communication 🌈 so they can support most of the XML- and SOAP-based device management approaches. ngl that's giving main character energy ⭐
- since 2004, a bunch of orgs (OASIS, W3C, WS-I, and others) have been working hard on securing device management traffic inside a "Web Services" framework 🧚 they're using a wide variety of security models and supporting multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. so many options, it's a lot 😭
- IPsec gives you integrity and confidentiality at the network layer 🔥 when it comes to device management, though, it's mostly used for in-band management of user-managed IPsec gateway devices 🍓
- there's recent work in the ISMS WG (Integrated Security Model for SNMP Working Group) to define how to use SSH to secure SNMP 🎀 the reason? SNMPv3 hasn't been deployed much yet, and Kerberos might be an option too, especially for interfaces like TELNET where client code already exists 👑
5.2.4. Security Considerations for MPLS Pseudowires 💀
okay this section is seriously important, so pay attention 🙈
MPLS networks aren't just for IP traffic. they can also carry other services like Ethernet, ATM, Frame Relay, and TDM 🌸 the way that works is by setting up pseudowires (PWs), which tunnel the native service through the MPLS core by encapsulating it at the edges 🦋 the PWE architecture is defined in [RFC3985].
PW tunnels can be set up using the PWE control protocol, which is based on LDP [RFC4447]. so the security considerations for LDP will most likely apply to the PWE3 control protocol too 💜
PW user packets always have at least one MPLS label (the PW label) and might have one or more MPLS tunnel labels 🧚 after the label stack comes a four-byte control word (which is optional for some PW types), followed by the native service payload. it must be stressed that encapsulating MPLS PW packets in IP so you can use IPsec mechanisms is not a valid option 🚫 not me saying it's a bad idea, the spec literally says it's not valid 💀
here's a non-exhaustive list of PW-specific threats 😭
- unauthorized setup of a PW (e.g., to gain access to a customer network) 👀
- unauthorized teardown of a PW (thus causing denial of service) 💔
- malicious reroute of a PW 🌪️
- unauthorized observation of PW packets 👁️
- traffic analysis of PW connectivity 🔍
- unauthorized insertion of PW packets 💉
- unauthorized modification of PW packets ✏️
- unauthorized deletion of PW packets replay of PW packets 🔁
- denial of service or significant impact on PW service quality 📉
these threats aren't mutually exclusive, so, for example, rerouting can be used for snooping or insertion/deletion/replay, etc. 🕵️♀️ and multisegment PWs bring extra weaknesses at their stitching points 🧵
the PW user plane has some inherent security weaknesses too 🥺
- since the PW label is the only identifier in the packet, there's no authenticatable source address 🫠
- since guessing a valid PW label isn't difficult, it's relatively easy to introduce seemingly valid foreign packets 😬
- since the PW packet isn't self-describing, minor modification of control-plane packets makes the data-plane traffic useless 💥
- the control-word sequence number processing algorithm is susceptible to a DoS attack 🚨
and the PWE control protocol has its own weaknesses 😩
- no (secure) peer autodiscovery technique has been standardized yet, which is so unserious 🙃
- PE authentication isn't mandated, so an intruder can potentially impersonate a PE. after impersonating a PE, unauthorized PWs may be set up, eating up resources and maybe giving access to user networks 🫣
- alternatively, desired PWs may be torn down, which leads to denial of service 🥀
on the flip side, these characteristics of PWs can be considered security strengths 💪
- the most obvious attacks require compromising edge or core routers (although not necessarily the ones along the PW path) 🏰
- adequate protection of the control-plane messaging is sufficient to rule out many types of attacks 🛡️
- PEs are usually configured to reject MPLS packets from outside the service provider network, which rules out insertion of PW packets from the outside (since IP packets can't masquerade as PW packets) 🙌
that's the end of this part, but the story keeps going 🌈✨
5.2.5. End-to-End versus Hop-by-Hop Protection Tradeoffs in MPLS/GMPLS 🦋
okay so in MPLS/GMPLS, crypto protection could get slapped onto the traffic at a bunch of different spots 💅 This section spills the tea on the tradeoffs of doing encryption across different connection layouts between devices in an MPLS/GMPLS network ✨
Cryptographic protection usually involves a pair of devices protecting the traffic moving between them. The devices might be directly connected (over a single "hop"), or intervening devices might carry the protected traffic between the pair. The extreme cases are protection between every adjacent pair of devices along a path (hop-by-hop), or protection only between the end devices along a path (end-to-end). To keep this doc in its lane, the "end-to-end" case we look at here is CE-to-CE rather than fully end-to-end 🎀
Figure 3 gives us a simplified layout with the Customer Edge (CE) devices, the Provider Edge (PE) devices, and a variable number (three are shown) of Provider core (P) devices, which might sit along the path between two sites in a single VPN run by one service provider (SP) 🌸
Site_1---CE---PE---P---P---P---PE---CE---Site_2Figure 3: Simplified Topology Traversing through MPLS/GMPLS Core
Within this simplified topology, and assuming that the P devices are not involved with cryptographic protection, four basic, feasible configurations exist for protecting connections among the devices:
- Site-to-site (CE-to-CE): Apply confidentiality or integrity services between the two CE devices, so that traffic will be protected throughout the SP's network.
- Provider edge-to-edge (PE-to-PE): Apply confidentiality or integrity services between the two PE devices. Unprotected traffic is received at one PE from the customer's CE, then it is protected for transmission through the SP's network to the other PE, and finally it is decrypted or checked for integrity and sent to the other CE.
- Access link (CE-to-PE): Apply confidentiality or integrity services between the CE and PE on each side or on only one side.
- Combined: Configurations 2 and 3 above can also be combined, with confidentiality or integrity running from CE to PE, then PE to PE, and then PE to CE.
Among the four feasible configurations, the key tradeoffs in considering encryption include:
- Vulnerability to link eavesdropping or tampering: assuming an attacker can observe or modify data in transit on the links, would it be protected by encryption? 👀
- Vulnerability to device compromise: assuming an attacker can get access to a device (or freely alter its configuration), would the data be protected? 🚨
- Complexity of device configuration and management: given the number of sites per VPN customer as Nce and the number of PEs participating in a given VPN as Npe, how many device configurations need to be created or maintained, and how do those configurations scale? 📋
- Processing load on devices: how many cryptographic operations must be performed given N packets? This raises considerations of device capacity and perhaps end-to-end delay. ⏱️
- Ability of the SP to provide enhanced services (QoS, firewall, intrusion detection, etc.): can the SP inspect the data to provide these services? 🛡️
These tradeoffs are discussed for each configuration, below:
1) Site-to-site (CE-to-CE) 💖
- Link eavesdropping or tampering: protected on all links.
- Device compromise: vulnerable to CE compromise.
- Complexity: single administration, responsible for one device per site (Nce devices), but overall configuration per VPN scales as
Nce**2.
Though the complexity may be reduced: 1) In practice, as Nce grows, the number of VPNs falls off from being a full clique; 2) If the CEs run an automated key management protocol, then they should be able to set up and tear down secured VPNs without any intervention. 🧚
- Processing load: on each of the two CEs, each packet is cryptographically processed (2P), though the protection may be "integrity check only" or "integrity check plus encryption."
- Enhanced services: severely limited; typically only Diffserv markings are visible to the SP, allowing some QoS services. The CEs could also use the IPv6 Flow Label to identify traffic classes. 🙈
2) Provider Edge-to-Edge (PE-to-PE) 🌈
- Link eavesdropping or tampering: vulnerable on CE-PE links; protected on 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 smaller than Nce.) Scalability of the overall configuration depends on the PPVPN type: if the cryptographic protection is separate per VPN context, it scales as
Npe**2per customer VPN. If it is per-PE, it scales asNpe**2for all customer VPNs combined. - Processing load: on each of the two PEs, each packet is cryptographically processed (2P).
- Enhanced services: full; SP can apply any enhancements based on detailed view of traffic. ✨
3) Access Link (CE-to-PE) 🦋
- Link eavesdropping or tampering: protected on CE-PE link; vulnerable on 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), but because there is no mesh, the overall configuration scales as Nce.
- Processing load: on each of the two CEs, each packet is cryptographically processed, plus on each of the two PEs, each packet is cryptographically processed (4P).
- Enhanced services: full; SP can apply any enhancements based on a detailed view of traffic. 🔥
4) Combined Access link and PE-to-PE (essentially hop-by-hop) 👑
- Link eavesdropping or tampering: 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). Scalability of the overall configuration depends on the PPVPN type: if the cryptographic processing is separate per VPN context, it scales as
Npe**2per customer VPN. If it is per-PE, it scales asNpe**2for all customer VPNs combined. - Processing load: on each of the two CEs, each packet is cryptographically processed, plus on each of the two PEs, each packet is cryptographically processed twice (6P).
- Enhanced services: full; SP can apply any enhancements based on a detailed view of traffic. 💅
Given the tradeoffs discussed above, a few conclusions can be drawn:
- Configurations 2 and 3 are subsets of 4 that may be appropriate alternatives to 4 under certain threat models; the remainder of these conclusions compare 1 (CE-to-CE) versus 4 (combined access links and PE-to-PE).
- If protection from link eavesdropping or tampering is all that is important, then configurations 1 and 4 are equivalent.
- If protection from device compromise is most important and the threat is to the CE devices, both cases are equivalent; if the threat is to the PE devices, configuration 1 is better.
- If reducing complexity is most important, and the size of the network is small, configuration 1 is better. Otherwise, configuration 4 is better because rather than a mesh of CE devices, it requires a smaller mesh of PE devices. Also, under some PPVPN approaches, the scaling of 4 is further improved by sharing the same PE-PE mesh across all VPN contexts. The scaling advantage of 4 may be increased or decreased in any given situation if the CE devices are simpler to configure than the PE devices, or vice-versa.
- If the overall processing load is a key factor, then 1 is better, unless the PEs come with a hardware encryption accelerator and the CEs do not.
- If the availability of enhanced services support from the SP is most important, then 4 is best.
- If users are concerned with having their VPNs misconnected with other users' VPNs, then encryption with 1 can provide protection.
As a quick overall conclusion: CE-to-CE protection is better against device compromise, but this comes at the cost of enhanced services and at the cost of operational complexity due to the Order(n**2) scaling of a larger mesh. 🥺
This analysis of site-to-site vs. hop-by-hop tradeoffs does not explicitly include cases of multiple providers cooperating to provide a PPVPN service, public Internet VPN connectivity, or remote access VPN service, but many of the tradeoffs are similar. 🌸
In addition to the simplified models, the following should also be considered:
- There are reasons, perhaps, to protect a specific P-to-P or PE-to-P.
- There may be reasons to do multiple encryptions over certain segments. One may be using an encrypted wireless link under our IPsec VPN to access an SSL-secured web site to download encrypted email attachments: four layers.) 🥞
- It may be appropriate that, for example, cryptographic integrity checks are applied end to end, and confidentiality is applied over a shorter span.
- Different cryptographic protection may be required for control protocols and data traffic.
- Attention needs to be given to how auxiliary traffic is protected, e.g., the ICMPv6 packets that flow back during PMTU discovery, among other examples. 🔍
5.3. Access Control Techniques 🔐
okay access control is where we decide who gets past the bouncer 🧚 Access control techniques include packet-by-packet or packet-flow-by-packet-flow access control by means of filters and firewalls on IPv4/IPv6 packets, as well as by means of admitting a "session" for a control, signaling, or management protocol. Enforcement of access control by isolated infrastructure addresses is discussed in Section 5.4 of this document. 💜
In this document, we distinguish between filtering and firewalls based primarily on the direction of traffic flow. We define filtering as being applicable to unidirectional traffic, while a firewall can analyze and control both sides of a conversation. 🦋
The definition has two significant corollaries:
- Routing or traffic flow symmetry: A firewall typically requires routing symmetry, which is usually enforced by locating a firewall where the network topology assures that both sides of a conversation will pass through the firewall. A filter can operate upon traffic flowing in one direction, without considering traffic in the reverse direction. Beware that this concept could result in a single point of failure. ⚠️
- Statefulness: Because it receives both sides of a conversation, a firewall may be able to interpret a significant amount of information concerning the state of that conversation and use this information to control access. A filter can maintain some limited state information on a unidirectional flow of packets, but cannot determine the state of the bidirectional conversation as precisely as a firewall. 🧠
For a general description on filtering and rate limiting for IP networks, please also see [OPSEC-FILTER]. 🌈
5.3.1. Filtering 🔍
Okay so routers filtering packets is super common, bestie. They can look for specific values in certain fields of the IP header or in higher-level headers like TCP or UDP. Packets that match a filter's criteria can get discarded or get special treatment. And it's not just routers anymore, because most end hosts have filters too, and every instance of IPsec is also a filter [RFC4301] 🔐.
It helps to split up two things: the filter characteristics that decide whether a packet matches, and the packet actions that happen to the packets that do match. Let's go! 💅
Filter Characteristics 🧩
Filter characteristics (or rules) are what decide whether a particular packet, or set of packets, matches a particular filter.
In many cases, filter characteristics can be stateless ✨. A stateless filter decides if a packet matches based only on the filter definition, normal forwarding information (like the next hop for a packet), the interface the packet arrived on, and the contents of that one packet. Stateless filters can usually look at the incoming and outgoing logical or physical interface, info in the IP header, and info in higher-layer headers like TCP or UDP. The IP header info they can check includes source and destination IP addresses, the Protocol field, Fragment Offset, and TOS in IPv4, or Next Header, Extension Headers, Flow label, etc. in IPv6 🌸. Filters can also look at TCP or UDP header fields like the Port numbers and the SYN field in TCP, plus the ICMP and ICMPv6 type.
Stateful filtering keeps packet-specific state info to help figure out if a filter rule has been met 🧠. For example, a device might apply stateless filtering to the first fragment of a fragmented IPv4 packet. If that matches, the data unit ID can be remembered, and other fragments of the same packet can then be considered a match for the same filter. Stateful filtering is more common in firewalls, though firewall tech can also get added to routers. In IPv6, the data unit ID can be the Fragment Extension Header Identification field 🦋.
Actions based on Filter Results 🎬
If a packet, or a series of packets, matches a specific filter, a bunch of actions can happen. Examples include:
- Discard 🗑️: Filters are often set up to catch undesirable packets. Examples are packets with forged or invalid source addresses, packets that are part of a DoS or Distributed DoS (DDoS) attack, or packets trying to access unallowed resources (like network management packets from an unauthorized source). When these filters are activated, it's common to discard the matching packet or set of packets silently. The discarded packets can also be counted or logged, of course.
- Set CoS 🏷️: A filter may be used to set the class of service for the packet.
- Count packets or bytes 🔢
- Rate Limit 🚦: Sometimes the packets matching a filter may be limited to a specified bandwidth. In that case, packets or bytes get counted and forwarded normally up to the limit. Excess packets may be discarded or may be marked, for example by setting a "discard eligible" bit in the IPv4 ToS field, or by changing the
EXPvalue to identify traffic as being out of contract. - Forward and Copy 📬: Sometimes it's useful to forward some packets normally but also send a copy to a specified other address or interface. For example, this can be used to implement a lawful intercept capability or to feed selected packets to an Intrusion Detection System.
Other Packet Filters Issues ⚠️
Filtering performance can vary a lot depending on the implementation and the types and number of rules. Without acceptable performance, filtering isn't useful, bestie 😭.
What counts as "acceptable" can change from SP to SP, and it may depend on what the filters are for. For example, a filter may be 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 SP will probably want the filter to have minimal or no impact on performance. In other cases, a filter may only be turned on in response to a major attack (like a major DDoS attack). Then a bigger performance impact may be acceptable to some service providers.
A key thing to know about packet filters is that they can offer few options for filtering packets that carry encrypted data 🔒. Because the data itself isn't accessible, only packet header info or other unencrypted fields can be used for filtering.
5.3.2. Firewalls 🔥
Firewalls give you a way to control traffic passing between different trusted zones in the MPLS/GMPLS model, or between a trusted zone and an untrusted zone 🧱. They usually do way more than filters, because they can apply detailed analysis and logical functions to flows and not just to individual packets. They can offer complex services like threshold-driven DoS attack protection, virus scanning, acting as a TCP connection proxy, etc. 💖
As with other access control techniques, firewalls are only as good as your clear understanding of the topologies of the MPLS/GMPLS core network, the user networks, and the threat model 🗺️. Their effectiveness depends on a topology with a clearly defined inside (secure) and outside (not secure).
Firewalls may be applied to help protect MPLS/GMPLS core network functions from attacks coming from the Internet or from MPLS/GMPLS user sites, but other defensive techniques will typically be used for this purpose.
When firewalls are offered as a service to protect user VPN sites from the Internet, different VPN users, and even different sites of a single VPN user, may have different firewall requirements 👑. The overall PPVPN logical and physical topology, along with the capabilities of the devices running the firewall services, has a big effect on whether these varied firewall offerings are feasible and manageable.
Another thing to keep in mind is that firewalls can offer few options for handling packets that carry encrypted data 🙈. Because the data itself isn't accessible, only packet header info, other unencrypted fields, or analysis of the flow of encrypted packets can be used to decide whether to accept or reject encrypted traffic.
There are two approaches to using firewalls: move the firewall outside of the encrypted part of the path, or register and pre-approve the encrypted session with the firewall 🦄.
Handling DoS attacks has become increasingly important 📈. Useful guidelines include the following:
- Perform ingress filtering everywhere.
- Be able to filter DoS attack packets at line speed.
- Do not allow oneself to amplify attacks.
- Continue processing legitimate traffic. Over provide for heavy loads. Use diverse locations, technologies, etc.
5.3.3. Access Control to Management Interfaces 🎀
Most security issues related to management interfaces can be handled with the authentication techniques from the authentication section (Section 5.1) 🫶. Extra security can also come from controlling access to management interfaces in other ways.
The Optical Internetworking Forum has done relevant work on protecting these interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc. 🧚 Check out "Security for Management Interfaces to Network Elements" [OIF-SMI-01.0] and "Addendum to the Security for Management Interfaces to Network Elements" [OIF-SMI-02.1]. There's also the work in the ISMS WG, at http://datatracker.ietf.org/wg/isms/charter/ 💜.
Management interfaces, especially console ports on MPLS/GMPLS devices, can be set up so they're only accessible out-of-band, through a system that's physically or logically separated from the rest of the MPLS/GMPLS infrastructure 🔌.
When management interfaces are accessible in-band within the MPLS/GMPLS domain, filtering or firewalling techniques can be used to stop unauthorized in-band traffic from getting access to them 🚫. Depending on device capabilities, these filtering or firewalling techniques can be configured on other devices the traffic might pass through, or on the individual MPLS/GMPLS devices themselves.
5.4. Use of Isolated Infrastructure 🏝️
One way to protect the infrastructure that supports MPLS/GMPLS is to separate the resources used for MPLS/GMPLS services from the resources used for other purposes, like supporting Internet services 🌈. In some cases this might mean using physically separate equipment for VPN services, or even a physically separate network.
For example, PE-based IPVPNs may run on a separate backbone that isn't connected to the Internet, or they may use separate edge routers from the ones supporting Internet service 🍓. Private IPv4 addresses (local to the provider and non-routable over the Internet) are sometimes used to add extra separation. For a discussion of comparable techniques for IPv6, see "Local Network Protection for IPv6," RFC 4864 [RFC4864].
In a GMPLS network, the control plane can run on physically separate resources from the ones used by the data plane 🛰️. This means the data-plane resources can be physically protected and isolated from other equipment to protect users' data, while the control and management traffic uses network resources that operators can access to configure the network.
Be careful, though! Separating control and data traffic may lead an operator to think the network is secure just because the data-plane resources are physically secure. That's not the case if the control plane can be attacked through a shared or open network, so control-plane protection techniques must still be applied 💀✨.
5.5. Use of Aggregated Infrastructure ✨
Okay so, it's basically never feasible to give every service its own totally separate set of resources 🙈. The whole point of MPLS/GMPLS-enabled services is sharing resources between multiple services and multiple users 💅. So even if a service runs on a separate network from Internet services, there will still be multiple MPLS/GMPLS users sharing the same network resources. And in some cases, MPLS/GMPLS services share network resources with Internet services or other services too 🌈.
It's therefore super important for MPLS/GMPLS services to protect resources between different parties 🛡️. A well-behaved MPLS/GMPLS user should be protected from possible misbehavior by other users, and that takes several security measurements to be implemented. Resource limits can be placed on a per service and per user basis. Possibilities include using a virtual router or logical router to define hardware or software resource limits per service or per individual user, using rate limiting per Virtual Routing and Forwarding (VRF) or per Internet connection to provide bandwidth protection, or using resource reservation for control-plane traffic 🎀. Beyond bandwidth protection, separate resource allocation can be used to limit security attacks to only the directly impacted service(s) or customer(s) 🙌. Strict, separate, and clearly defined engineering rules and provisioning procedures can reduce the risks of network-wide impact from a control-plane attack, DoS attack, or misconfiguration 💀.
In general, 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 combining the data from multiple users 🦋. However, service providers must minimize security risks introduced from any individual service or individual users. No cap, that part is non-negotiable 😤.
5.6. Service Provider Quality Control Processes 👑
Deploying provider-provisioned VPN services usually takes a relatively large amount of configuration by the SP 📋. For example, the SP needs 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 it's important for the SP to have operational processes in place to reduce the potential impact of misconfiguration 🧚. CE-to-CE authentication may also be used to detect misconfiguration when it occurs 🔍. And CE-to-CE encryption may also limit the damage when misconfiguration does happen 🫶.
5.7. Deployment of Testable MPLS/GMPLS Service 🧪
This refers to solutions that can be readily tested to make sure they're configured correctly. For example, for a point-to-point connection, checking that the intended connectivity is working pretty much ensures there's no unintended connectivity to some other site 🌸.
5.8. Verification of Connectivity 🔎
To protect against deliberate or accidental misconnection, mechanisms can be put in place to verify both end-to-end connectivity and hop-by-hop resources. These mechanisms can trace the routes of LSPs in both the control plane and the data plane 🗺️.
It should be noted that if there's an attack on the control plane, data-plane connectivity test mechanisms that rely on the control plane can also be attacked 😱. That can hide faults through false positives, or disrupt functioning services through false negatives. Not me getting the plot twist of the century 🙈.
6. Monitoring, Detection, and Reporting of Security Attacks 🚨
MPLS/GMPLS networks and services may be subject to attacks from a variety of security threats 👀. Many threats are described in Section 4 of this document. Lots of the defensive techniques described in this document and elsewhere give significant levels of protection from a variety of threats 💜. But on top of employing defenses silently, MPLS/GMPLS services can also add value for both providers and customers by implementing security monitoring systems that detect and report on any security attacks, whether or not the attacks are effective ⭐.
Attackers often begin by probing and analyzing defenses 🕵️♀️, so systems that can detect and properly report these early stages of attacks can provide significant benefits. Main character early warning energy 🔥.
Information about attack incidents, especially if it's available quickly, can be super useful in defending against further attacks 🍓. It can help identify attackers or their specific targets at an early stage. That knowledge about attackers and targets can be used to strengthen defenses against specific attacks or attackers, or to improve defenses for specific targets on an as-needed basis. Information collected on attacks may also help identify and develop defenses against novel attack types 🧠.
Monitoring systems used to detect security attacks in MPLS/GMPLS typically operate by collecting information from the 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 to passively receive reports from devices (e.g., SNMP notifications). The systems may actively retrieve information from devices (e.g., SNMP get) or passively receive reports from devices (e.g., SNMP notifications) 🔁.
The specific information exchanged depends on the capabilities of the devices and on the type of VPN technology 🎀. Particular care should be given to securing the communications channel between the monitoring systems and the MPLS/GMPLS devices 🔐.
The CE, PE, and P devices should employ efficient methods to acquire and communicate the information the security monitoring systems need 💅. It's important that the communication method between MPLS/GMPLS devices and security monitoring systems be designed so it won't disrupt network operations 🙏. As an example, multiple attack events may be reported through a single message, rather than letting each attack event trigger a separate message. Otherwise you could get a flood of messages, which essentially becomes a DoS attack against the monitoring system or the network 😭.
The mechanisms for reporting security attacks should be flexible enough to meet the needs of MPLS/GMPLS service providers, MPLS/GMPLS customers, and regulatory agencies, if applicable 🌈. The specific reports should depend on the capabilities of the devices, the security monitoring system, the type of VPN, and the service level agreements between the provider and customer 📝.
SNMP/syslog type monitoring and detection mechanisms can detect some attacks (usually ones resulting from flapping protocol adjacencies, CPU overload scenarios, and so on) 🛎️. But for more detailed detection and reporting, other techniques such as netflow-based traffic fingerprinting are needed 🔬.
With netflow-based traffic fingerprinting, each packet forwarded within a device is examined for a set of IP packet attributes ✨. These attributes make up the IP packet identity or fingerprint of the packet, and they determine whether the packet is unique or similar to other packets 🪪.
The flow information is extremely useful for understanding network behavior and for detecting and reporting security attacks 💖:
- Source address tells you who is originating the traffic.
- Destination address tells you who is receiving the traffic.
- Ports characterize the application using the traffic.
- Class of service examines the priority of the traffic.
- The device interface tells how traffic is being utilized by the network device.
- Tallied packets and bytes show the amount of traffic.
- Flow timestamps let you understand the life of a flow; timestamps are useful for calculating packets and bytes per second.
- Next-hop IP addresses, including BGP routing Autonomous Systems (ASes).
- Subnet masks for the source and destination addresses are used for calculating prefixes.
- TCP flags are useful for examining TCP handshakes.
7. Service Provider General Security Requirements 📜
This section covers security requirements the provider may have for securing its MPLS/GMPLS network infrastructure, including LDP and RSVP-TE-specific requirements 💼.
The MPLS/GMPLS service provider's requirements defined here are for the MPLS/GMPLS 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 various services to users with different levels of offered security 🧩. So an MPLS/GMPLS service provider may fulfill any number of the security requirements listed in this section. This document does not state that an MPLS/GMPLS network must fulfill all of these requirements to be secure 🫶.
These requirements focus on two things: 1) how to protect the MPLS/GMPLS core from various attacks originating outside the core, including those from network users, both accidental and malicious, and 2) how to protect the end users 🦋.
7.1. Protection within the Core Network 🏰
7.1.1. Control-Plane Protection - General 🛡️
Filtering spoofed infrastructure IP addresses at edges 🚫
Okay bestie, a lot of attacks on protocols running inside a core are basically someone faking the source IP address of a core node (TCP-RST attacks are the classic example 💀). So it makes sense to apply anti-spoofing filtering at the edges, using strict unicast reverse path forwarding (uRPF) [RFC3704] and/or by blocking anyone from using infrastructure addresses as a source. If you do this comprehensively, the need to cryptographically secure these protocols gets way smaller 🔐 For a more elaborate breakdown, see [BACKBONE-ATTKS].
Protocol authentication within the core 🔑
The network infrastructure must support mechanisms for authentication of the control-plane messages. If an MPLS/GMPLS core is used, LDP sessions may be authenticated with TCP MD5. IGP and BGP authentication should also be considered 👀 For a core providing various IP, VPN, or transport services, PE-to-PE authentication may also be performed via IPsec. Remember the protocol security services we talked about earlier: authentication, integrity (with replay detection), and confidentiality. Protocols need to provide a complete set of these services so the SP can choose what it wants ✨ The important, but often more difficult, part is key management. Considerations, guidelines, and strategies for key management are discussed in [RFC3562], [RFC4107], and [RFC4808]. It's giving "hard part, but worth it" 🫶
With today's processors, applying cryptographic authentication to the control plane may not significantly increase the cost of deployment for providers, and it will help improve the security of the core 💪 If the core is dedicated to MPLS/GMPLS enabled services with no interconnects to third parties, then this may reduce the requirement for authentication of the core control plane 🌸
Infrastructure Hiding 🫥
Here we talk about ways to hide the provider's infrastructure nodes 🧚 An MPLS/GMPLS provider may make its infrastructure routers (P and PE) unreachable from outside users and unauthorized internal users. For example, separate address space may be used for the infrastructure loopbacks.
Normal TTL propagation may be altered so the backbone looks like one hop from the outside, but you need to be careful about loop prevention. This keeps backbone addresses from being exposed through trace route. However, this must also be assessed against operational requirements for end-to-end fault tracing, so don't skip that part 🙈
An Internet backbone core may be re-engineered so that Internet routing becomes an edge function. For example, it could use MPLS label switching for all traffic within the core and possibly make the Internet a VPN within the PPVPN core itself. This helps detach Internet access from PPVPN services, and honestly it's such a clean move 😌
Separating control-plane, data-plane, and management-plane functionality in hardware and software may be implemented on the PE devices to improve security. This may help limit the problems when one area is attacked, and it may allow each plane to implement additional security measures separately 🍓
PEs are often more vulnerable to attack than P routers, because PEs cannot be made unreachable from outside users by their very nature 😭 Access to core trunk resources can be controlled on a per-user basis by using inbound rate limiting or traffic shaping. This can be further enhanced on a per-class-of-service basis (see Section 8.2.3).
On the PE, using separate routing processes for different services, for example Internet and PPVPN service, may help improve PPVPN security and better protect VPN customers 💜 Furthermore, if resources such as CPU and memory can be further separated based on applications, or even individual VPNs, it may provide improved security and reliability to individual VPN customers. Main character energy for each VPN 👑
7.1.2. Control-Plane Protection with RSVP-TE 🎀
General RSVP Security Tools 🧰
Isolating the trusted domain is an important security mechanism for RSVP. It makes sure an untrusted element cannot access a router of the trusted domain. However, ASBR-ASBR communication for inter-AS LSPs needs to be secured specifically 👀 Isolation mechanisms might also be bypassed by an IPv4 Router Alert or by IPv6 packets using Next Header 0. One solution is to disable the processing of IP options. This drops or ignores all IP packets with IPv4 options, including the router alert option used by RSVP. However, this may have an impact on other protocols that use IPv4 options 🥲 An alternative is to configure access lists on all incoming interfaces that drop IPv4 protocol 46 (RSVP) or IPv6 next header 46 (RSVP).
RSVP security can be strengthened by deactivating RSVP on interfaces with neighbors who are not authorized to use RSVP, which protects against adjacent CE-PE attacks 🔒 However, this does not really protect against DoS attacks or attacks on non-adjacent routers. It has been demonstrated that substantial CPU resources are consumed just by processing received RSVP packets, even if the RSVP process is deactivated for the specific interface where those packets arrive 😩
RSVP neighbor filtering at the protocol level restricts the set of neighbors that can send RSVP messages to a given router, which protects against non-adjacent attacks. However, this does not protect against DoS attacks, and it does not effectively protect against spoofing of the source address of RSVP packets if the filter relies on the neighbor's address within the RSVP message 🙃
RSVP neighbor filtering at the data-plane level uses an access list to accept IP packets with port 46 only for specific neighbors. It requires Router Alert mode to be deactivated and does not protect against spoofing 🚧
Another valuable tool is RSVP message pacing, which limits the number of RSVP messages sent to a given neighbor during a given period. This allows blocking DoS attack propagation 🛑
Another approach is to limit the impact of an attack on control-plane resources 🧯
To keep the MPLS router running effectively even when an attack bypasses packet filtering mechanisms such as Access Control Lists in the data plane, it is important that routers have mechanisms to limit the impact of the attack. There should be a mechanism to rate limit the amount of control-plane traffic addressed to the router, per interface. This should be configurable on a per-protocol basis (and, ideally, on a per-sender basis) so that an attacked protocol or a single sender can't block all communications 🙅♀️ This requires the ability to filter and limit the rate of incoming messages of particular protocols, such as RSVP (filtering at the IP protocol level), and of particular senders. In addition, there should be a mechanism to limit the CPU and memory capacity allocated to RSVP, so other control-plane elements stay protected 🛡️ To limit memory allocation, it will probably be necessary to limit the number of LSPs that can be set up.
Authentication for RSVP messages 🔐
RSVP message authentication is described in RFC 2747 [RFC2747] and RFC 3097 [RFC3097]. It is one of the most powerful tools for protection against RSVP-based attacks 💥 It applies cryptographic authentication to RSVP messages based on a secure message hash using a key shared by RSVP neighbors. This protects against LSP creation attacks, at the expense of consuming significant CPU resources for digest computation. Also, if the neighboring RSVP speaker is compromised, it could be used to launch attacks using authenticated RSVP messages 😱 These methods, and certain other aspects of RSVP security, are explained in detail in RFC 4230 [RFC4230]. Key management must be implemented. Logging and auditing, as well as multiple layers of cryptographic protection, can help here. IPsec can also be used in some cases (see [RFC4230]).
One challenge with RSVP message authentication shows up in many cases where non-RSVP nodes are present in the network. There, the RSVP neighbor may not be known up front, so neighbor-based keying approaches fail, unless the same key is used everywhere, which is not recommended for security reasons 🙅♀️ Group keying may help in such cases. The security properties of various keying approaches are discussed in detail in [RSVP-key] 📚
7.1.3. Control-Plane Protection with LDP 🌈
The approaches to protect MPLS routers against LDP-based attacks are similar to those for RSVP. They include isolation, protocol deactivation on specific interfaces, filtering of LDP neighbors at the protocol level, filtering of LDP neighbors at the data-plane level (with an access list that filters the TCP and UDP LDP ports), authentication with a message digest, rate limiting of LDP messages per protocol per sender, and limiting all resources allocated to LDP-related tasks ✨ LDP protection could be considered easier in a certain sense. UDP port matching may be sufficient for LDP protection. Router alert options and beyond might be involved in RSVP protection, so LDP gets to be the chill one here 😎
7.1.4. Data-Plane Protection 🔏
IPsec can provide authentication, integrity, confidentiality, and replay detection for provider or user data. It also has an associated key management protocol 🗝️
In today's MPLS/GMPLS, ATM, or Frame Relay networks, encryption is not provided as a basic feature 🥀 Mechanisms described in Section 5 can be used to secure the MPLS data-plane traffic carried over an MPLS core. Both the Frame Relay Forum and the ATM Forum standardized cryptographic security services in the late 1990s, but these standards are not widely implemented. Sad, but we have options 💅
7.2. Protection on the User Access Link 🔗
Peer or 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. For inter-provider connections, cryptographic protection mechanisms such as IPsec may be used between ASes 🤝
If multiple services are provided on the same PE platform, different WAN address spaces may be used for different services (e.g., VPN and non-VPN) to enhance isolation 🫧
Firewall and Filtering: access control mechanisms can be used to filter any packets destined for the service provider's infrastructure prefix or to eliminate routes identified as illegitimate. Filtering should also be applied to prevent sourcing packets with infrastructure IP addresses from outside 🚫🧱
Rate limiting may be applied to the user interface/logical interfaces as a defense against DDoS bandwidth attacks. This is helpful when the PE device supports multiple services, especially VPN and Internet services, on the same physical interfaces through different logical interfaces 🌊
7.2.1. Link Authentication 🪪
Authentication can be used to validate site access to the network via fixed or logical connections, e.g., L2TP or IPsec, respectively. If the user wishes to hold the authentication credentials for access, then provider solutions require the flexibility of either direct authentication by the PE itself or interaction with a customer authentication server. In the latter case, mechanisms are required to ensure that the interaction between the PE and the customer authentication server is appropriately secured 🔐✨
7.2.2. Access Routing Control 🛣️
Okay so routing protocols like RIP, OSPF, or BGP can be used to control access between a CE and a PE 🔀. Per-neighbor and per-VPN routing policies can be set up to boost security and reduce the damage from a malicious or non-malicious attack on the PE 🛡️. These are the mechanisms you should especially consider:
- Limiting the number of prefixes that may be advertised on a per-access basis into the PE. Action may be taken if a limit gets exceeded, e.g., the PE shutting down the peer session to the CE 🚪
- Applying route dampening at the PE on received routing updates 🌊
- Defining a per-VPN prefix limit, after which extra prefixes won't get added to the VPN routing table 🧱
In an inter-provider connection, access protection, link authentication, and the routing policies above can all be applied 🤝. Inbound and outbound firewall or filtering mechanisms between ASes can also be used 🔥. Proper security procedures must be implemented in inter-provider interconnection to protect both providers' network infrastructure and their customers 💜. This can be custom designed for each inter-provider peering connection, but both providers have to agree on it 🫶.
7.2.3. Access QoS 🎀
MPLS/GMPLS providers that offer QoS-enabled services need ways to check that each access matches its subscribed QoS profile, so it only gets into the core resources that fit its service profile 🎟️. Two options for this level of control are per-class-of-service rate limiting and traffic shaping on ingress to the MPLS/GMPLS core ⚖️. These mechanisms may need the per-class-of-service profile to be enforced by marking, remarking, or discarding traffic that falls outside of the profile ✂️.
7.2.4. Customer Service Monitoring Tools 📊
End users who want specific stats from the core, e.g., routing table, interface status, or QoS statistics, put requirements on the PE's mechanisms. The PE has to validate the incoming user and also limit which views that particular user can see 👀. You should also think about making sure this access can't be used to build a DoS attack on the PE itself, whether that's on purpose or by accident 😬. This can be done by separating these resources inside the PE, or by rate limiting per physical interface or per logical connection 🚦.
7.3. General User Requirements for MPLS/GMPLS Providers 👑
MPLS/GMPLS providers must support end users' security requirements 💅. Depending on the technologies used, these requirements may include:
- User control plane separation through routing isolation when applicable, for example, in the case of MPLS VPNs 🏝️
- Protection against intrusion, DoS attacks, and spoofing 🚨
- Access Authentication 🔐
- Techniques highlighted throughout this document that identify methodologies for the protection of resources and the MPLS/GMPLS infrastructure 🛠️
Hardware or software errors in equipment that lead to security breaches are not in scope for this document. 🙅♀️
8. Inter-Provider Security Requirements 🌐
This section is all about the security capabilities that matter at MPLS/GMPLS inter-provider connections and on devices (including ASBR routers) that support those connections 🫧. The security capabilities here should be seen as complementary to the security considerations in individual protocol specifications or security frameworks 🧩.
Security vulnerabilities and exposures can spread across multiple networks when a vulnerability shows up in one peer's network 😭. Threats come from accidental, administrative, and intentional sources ⚠️. The intentional ones include things like spoofing and denial-of-service (DoS) attacks 🙈.
The level and nature of threats, plus security and availability requirements, can change over time and from network to network ⏳. So this section talks about the capabilities that need to be in equipment deployed to support the MPLS InterCarrier Interconnect (MPLS-ICI) 🦋. Whether any given capability gets used in a specific ICI is up to the service providers managing the PE equipment that offers or uses the ICI services 🤷♀️.
8.1. Control-Plane Protection 🧠
This section covers capabilities for control-plane protection, including protection of routing, signaling, and OAM capabilities 🎯.
8.1.1. Authentication of Signaling Sessions 🔏
Authentication may be needed for signaling sessions (i.e., BGP, LDP, and RSVP-TE) and routing sessions (e.g., BGP), as well as OAM sessions across domain boundaries 🚧. Equipment must be able to support the exchange of all protocol messages over IPsec ESP, with NULL encryption and authentication, between the peering ASBRs 🔒. Support for message authentication for LDP, BGP, and RSVP-TE authentication must also be provided ✅. Manual keying of IPsec should not be used 🙅♀️. IKEv2 with pre-shared secrets or public key methods should be used 🔑. Replay detection should be used 🔁.
Mechanisms to authenticate and validate a dynamic setup request must be available 🪪. For instance, if dynamic signaling of a TE-LSP or PW is crossing a domain boundary, there must be a way to detect whether the LSP source is who it claims to be and whether it's allowed to connect to the destination 🕵️♀️.
Message authentication support for all TCP-based protocols within the scope of the MPLS-ICI (i.e., LDP signaling and BGP routing) must be provided, and message authentication with the RSVP-TE Integrity Object must be provided too, so things keep interoperating with current practices 🤝. Equipment should be able to support the exchange of all signaling and routing (LDP, RSVP-TE, and BGP) protocol messages over a single IPsec association pair, in tunnel or transport mode, with authentication but NULL encryption, between the peering ASBRs 🧦. If IPsec is supported, it must be supported with HMAC-SHA-1 and, alternatively, with HMAC-SHA-2 and optionally SHA-1 🔐. It's expected that authentication algorithms will evolve over time, and support can be updated as needed 🌱.
OAM operations across the MPLS-ICI could also be a source of security threats, both for the provider infrastructure and for the service offered over the MPLS-ICI 😱. A huge volume of OAM messages could overwhelm an ASBR's processing if the ASBR isn't properly protected 🌪️. Maliciously generated OAM messages could also bring down an otherwise healthy service (e.g., MPLS Pseudowire), which hits service security 💀. LSP ping doesn't support authentication today, and adding that should be a subject for future consideration 🔮. Bidirectional Forwarding Detection (BFD), however, can carry an authentication object 🙌. It also supports Time-To-Live (TTL) processing as an anti-replay measure 🛡️. Implementations conformant with this MPLS-ICI should support BFD authentication, and they must support the procedures for TTL processing 💖.
8.1.2. Protection Against DoS Attacks in the Control Plane 🚫
Implementations must be able to prevent signaling and routing DoS attacks on the control plane, per interface and per provider 🧱. This prevention can come from rate limiting signaling and routing messages that a peer provider can send, according to a traffic profile, and from guarding against malformed packets 🚦.
Equipment must be able to filter signaling, routing, and OAM packets destined for the device, and must be able to rate limit those packets too 🗂️. Packet filters should be able to be applied separately per interface, and should have minimal or no performance impact ✨. For example, this lets an operator filter or rate limit the signaling, routing, and OAM messages a peer provider can send, and keep that traffic within a given profile 🎛️.
During a control-plane DoS attack against an ASBR, the router should guarantee enough resources for network operators to run network management commands and take corrective action, like turning on extra filters or disconnecting an interface under attack 🧯. DoS attacks on the control plane should not adversely affect data-plane performance 🏎️.
Equipment running BGP must be able to limit the number of BGP routes received from any particular peer 📉. Also, for IPVPN, a router must be able to limit the number of routes learned from a BGP peer per IPVPN 🎀. If a device has multiple BGP peers, it should be possible for the limit to vary between peers 🌈.
8.1.3. Protection against Malformed Packets 📦
Equipment should be robust when it sees malformed protocol packets 💪. For example, malformed routing, signaling, and OAM packets should be treated in accordance with the relevant protocol specification 📜.
8.1.4. Ability to Enable/Disable Specific Protocols 🔛
Equipment must be able to drop any signaling or routing protocol messages that are to be processed by the ASBR when the corresponding protocol isn't enabled on that interface 🚫.
Equipment must let an administrator enable or disable a protocol on an interface basis 🧑💻. By default, the protocol is disabled unless an administrator enables it 🔒.
Equipment must be able to drop any signaling or routing protocol messages that are to be processed by the ASBR when the corresponding protocol isn't enabled on that interface. This dropping should not adversely affect data-plane or control-plane performance 🏁.
8.1.5. Protection against Incorrect Cross Connection 🔀
The ability to detect and locate faults in an LSP cross-connect must be provided 🕵️. These faults can cause security violations because they send traffic to the wrong destinations 😵. This capability may rely on OAM functions 🛠️. Equipment must support MPLS LSP ping [RFC4379] 🏓. It can be used to verify end-to-end connectivity for the LSP (e.g., PW, TE Tunnel, VPN LSP, etc.), and to verify PE-to-PE connectivity for IPVPN services 🔗.
When routing information gets advertised from one domain to the other, operators must be able to guard against situations that cause traffic hijacking, black-holing, resource stealing (e.g., number of routes), etc. 🏴☠️ For instance, in the IPVPN case, an operator must be able to block routes based on their associated route target attributes 🚧. Mechanisms to defend against routing protocol attacks must also exist, so you can verify whether a route a peer advertises for a given VPN is actually valid, and whether the VPN has a site attached to or reachable through that domain 🔍.
Equipment (ASBRs and Route Reflectors (RRs)) that supports BGP operation must be able to restrict which route target attributes are sent to and accepted from a BGP peer across an ICI 🎯. Equipment (ASBRs, RRs) should also be able to tell the peer which route target attributes it will accept from that peer 📣, because sending an incorrect route target can cause an incorrect cross-connection of VPNs 💥. Sending inappropriate route targets to a peer may also disclose confidential information 🤫. This is another example of defense against routing protocol attacks 🛡️✨.
8.1.6. Protection against Spoofed Updates and Route Advertisements ✨
Okay bestie, so equipment must support route filtering 🫶 of routes received over a BGP peer session. You do this by applying policies that check one or more of these: AS path, BGP next hop, standard community, or extended community. 💅
8.1.7. Protection of Confidential Information 🙈
This one is a big deal, so pay attention 👀. You need to be able to spot and block messages that carry confidential info and try to leave the trusted domain. These are messages that could reveal how the network runs, like performance OAM messages or LSP ping messages. This ability is required 🔥. Also, SPs must have the flexibility to handle these messages at the ASBR 💖.
Next, equipment should be able to identify and restrict where it sends messages that could reveal confidential network operation info (like performance OAM messages and LSP Traceroute messages) ✨. Again, Service Providers must have the flexibility to handle these messages at the ASBR 🦋. For example, equipment that supports LSP Traceroute may limit which addresses replies can be sent to. Quick warning though: this capability should be used with care ⚠️. For instance, if an SP decides to ban LSP ping messages at the ICI, it may make it harder to debug incorrect cross-connection of LSPs or other problems 😭.
An SP may decide to pass these messages along if they come from a trusted provider and are aimed at specific, agreed-on addresses 🌸. Another provider might choose to traffic police them, reject them, or apply other policies 🚫. Solutions must enable providers to control the information that is relayed to another provider about the path that an LSP takes. Like, when you're using the RSVP-TE record route object or LSP ping / trace, a provider must be able to control the information contained in corresponding messages when sent to another provider 💜.
8.1.8. Protection against Over-provisioned Number of RSVP-TE LSPs and Bandwidth Reservation 👑
On top of the control-plane protections we already covered for RSVP-TE in the previous section, the ASBR must be able both to limit the number of LSPs that can be set up by other domains and to limit the amount of bandwidth that can be reserved 🧚. So if another provider's request comes in and their limits are already maxed out, the ASBR may deny an LSP setup request or a bandwidth reservation request sent by that provider 🙅♀️.
8.2. Data-Plane Protection 🌈
8.2.1. Protection against DoS in the Data Plane
Good news, this one's already handled. It's described in Section 5 of this document 🫶.
8.2.2. Protection against Label Spoofing 🕵️♀️
Equipment must be able to verify that a label received across an interconnect was actually assigned to an LSP arriving across that interconnect 💅. If a label that wasn't assigned to an LSP shows up at this router from the correct neighboring provider, the packet must be dropped 🗑️. This check can be applied to the top label only. The top label is the received top label, and every label that gets exposed by label popping is used for forwarding decisions 🦋.
Equipment must provide the capability to drop MPLS-labeled packets if all labels in the stack are not processed. This lets SPs guarantee that every label entering their domain from another carrier is actually assigned to that carrier 🔐.
The following requirements aren't directly reflected in this document, but they must be used as guidance for further work 📝.
Solutions must NOT force operators to reveal reachability information to routers within their domains. It's believed this requirement is met by the other requirements in this section, plus the normal operation of IP routing, which doesn't reveal individual hosts 🙈.
Mechanisms to authenticate and validate a dynamic setup request must be available. For example, if dynamic signaling of a TE-LSP or PW is crossing a domain boundary, there must be a way to detect whether the LSP source is who it claims to be and whether it's allowed to connect to the destination 👀.
8.2.3. Protection Using Ingress Traffic Policing and Enforcement 🚦
Here's a simple diagram of a potential security issue on the data plane across an MPLS interconnect 🧠:
SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1
| | | |
|< AS2 >|<MPLS interconnect>|< AS1 >|Traffic flow direction is from SP2 to SP1 ➡️.
In the case of downstream label assignment, ASBR1 allocates the transit label that ASBR2 uses, and then advertises it to ASBR2 (downstream unsolicited or on-demand) 🎀. This label is used for a service context (a VPN label, PW VC label, etc.), and this LSP normally terminates at a forwarding table belonging to the service instance on PE (PE1) in SP1 🌸.
In the example above, ASBR1 wouldn't know whether the label on an incoming packet from ASBR2 over the interconnect is a VPN label or a PSN label for AS1 🤔. So it's possible (though unlikely) that ASBR2 is accidentally or intentionally configured so the incoming label matches a PSN label (like LDP) in AS1. Then this LSP would end up on the global plane of an infrastructure router (P or PE1), and that could invite a unidirectional attack on the P or PE1 where the LSP terminates 💀.
To mitigate this threat, implementations should be able to do a forwarding path look-up for the label on an incoming packet from an interconnect in a Label Forwarding Information Base (LFIB) space that's only intended for its own service context. Or they can provide a mechanism on the data plane that ensures the incoming labels are what ASBR1 allocated and advertised 🛡️.
A similar concept has been proposed in "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)" [RFC5254] 🌟.
When using upstream label assignment, the upstream source must be identified and authenticated so the labels can be accepted as coming from a trusted source 🫶.
9. Summary of MPLS and GMPLS Security 📋
The following summary is a quick checklist of MPLS and GMPLS security threats, defense techniques, and best-practice outlines for MPLS and GMPLS deployment 💖.
9.1. MPLS and GMPLS Specific Security Threats 😱
9.1.1. Control-Plane Attacks
Here are the types of attacks on the control plane 🚨:
- Unauthorized LSP creation
- LSP message interception
Attacks against RSVP-TE are DoS attacks that set up unauthorized LSPs and/or LSP messages 💥. Attacks against LDP are DoS attacks with storms of LDP Hello messages or LDP TCP SYN messages 🌩️.
Attacks may come from external or internal sources, or through an SP's management systems 👀. They may target the SP's routing protocols or infrastructure elements 🎯.
In general, control protocols may be attacked through:
- MPLS signaling (LDP, RSVP-TE)
- PCE signaling
- IPsec signaling (IKE and IKEv2)
- ICMP and ICMPv6
- L2TP
- BGP-based membership discovery
- Database-based membership discovery (e.g., RADIUS)
- OAM and diagnostic protocols such as LSP ping and LMP
- Other protocols that may be important to the control infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE
9.1.2. Data-Plane Attacks
- Unauthorized observation of data traffic 👀
- Data-traffic modification ✏️
- Spoofing and replay 🎭
- Unauthorized deletion 🗑️
- Unauthorized traffic-pattern analysis 📊
- Denial of Service 🚫
9.2. Defense Techniques 🛡️
- Authentication:
- Bidirectional authentication
- Key management
- Management system authentication
- Peer-to-peer authentication
- Cryptographic techniques
- Use of IPsec in MPLS/GMPLS networks
- Encryption for device configuration and management
- Cryptographic techniques for MPLS pseudowires
- End-to-End versus Hop-by-Hop protection (CE-CE, PE-PE, PE-CE)
- Access control techniques:
- Filtering
- Firewalls
- Access Control to management interfaces
- Infrastructure isolation
- Use of aggregated infrastructure
- Quality control processes
- Testable MPLS/GMPLS service
- End-to-end connectivity verification
- Hop-by-hop resource configuration verification and discovery
9.3. Service Provider MPLS and GMPLS Best-Practice Outlines 🏆
9.3.1. SP Infrastructure Protection
- General control-plane protection:
- Filtering out infrastructure source addresses at edges
- Protocol authentication within the core
- Infrastructure hiding (e.g., disable TTL propagation)
- RSVP control-plane protection:
- RSVP security tools
- Isolation of the trusted domain
- Deactivating RSVP on interfaces with neighbors who are not authorized to use RSVP
- RSVP neighbor filtering at the protocol level and data-plane level
- Authentication for RSVP messages
- RSVP message pacing
- LDP control-plane protection (similar techniques as for RSVP) 🔁
- Data-plane protection:
- User access link protection
- Link authentication
- Access routing control (e.g., prefix limits, route dampening, routing table limits (such as VRF limits)
- Access QoS control
- Customer service monitoring tools
- Use of LSP ping (with its own control-plane security) to verify end-to-end connectivity of MPLS LSPs
- LMP (with its own security) to verify hop-by-hop connectivity.
9.3.2. Inter-Provider Security 🤝
Inter-provider connections are high security risk areas 🚨. Similar techniques and procedures as described for SP's general core protection are listed below for inter-provider connections 💅.
- Control-plane protection at inter-provider connections:
- Authentication of signaling sessions
- Protection against DoS attacks in the control plane
- Protection against malformed packets
- Ability to enable/disable specific protocols
- Protection against incorrect cross connection
- Protection against spoofed updates and route advertisements
- Protection of confidential information
- Protection against an over-provisioned number of RSVP-TE LSPs and bandwidth reservation
- Data-plane protection at the inter-provider connections:
- Protection against DoS in the data plane
- Protection against label spoofing
For MPLS VPN interconnections [RFC4364], in practice, inter-AS option a), VRF-to-VRF connections at the AS (Autonomous System) border, is commonly used for inter-provider connections 🫶. Option c), multi-hop EBGP redistribution of labeled VPN-IPv4 routes between source and destination ASes, with EBGP redistribution of labeled IPv4 routes from AS to a neighboring AS, is not normally used for inter-provider connections due to higher security risks 🙅♀️. For more details, please see [RFC4111] 📚.
10. Security Considerations ✨
okay bestie, this section is basically the recap episode 🎀 Security considerations are the whole point of this memo, so everything we went through earlier gets a little review here. We also zoom out and look at how each type of consideration fits into a secure MPLS/GMPLS setup, so you can see the big picture 🦋
Some of the threats in here have already shown up in real, running networks 😭. Others are more like "hmm, this could happen" for now 🧚
Real talk: DoS attacks and intrusion attacks coming in from the Internet against an SP's infrastructure have actually been seen 💀. There have also been DoS "attacks" that usually aren't malicious at all, where CE equipment floods PE equipment with a huge amount or rate of packet traffic or routing information 🙈. And honestly? SPs say operational or provisioning errors are one of their biggest worries 🍓
The document goes through a bunch of defensive techniques that might be used to counter the suspected threats 🛡️💜 The fun part is that every technique presented involves mature, widely implemented technology that is practical to implement ✨ So no, you don't need magic to be safe, just solid basics 💅
Detecting, monitoring, and reporting attacks is a whole big deal, whether they succeed or not 🔥 This is the "understanding one's enemy" part, the stuff that helps you mobilize new defenses and get metrics on how secure your MPLS/GMPLS network actually is 👑 Which is exactly why these activities are vital components of any complete PPVPN security system 🌈
Last bit: the document looks at MPLS/GMPLS security requirements from both the customer's perspective and the service provider's perspective 💖 Those sections re-check the identified threats from each stakeholder's point of view, and they exist to help equipment vendors and service providers decide which threats they must protect against in any given configuration or service offering 🫶
11. References 📚
11.1. Normative References 💜
- [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. 🎀
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. ✨
- [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001. 🦋
- [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. 🌸
- [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. 🧚
- [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. 🔥
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 👑
- [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 🌈
- [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 💅
- [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005. 🍓
- [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. 💖
- [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. ⭐
- [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. 🦋
- [RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007. 🎀
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 🫶
- [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007. 🌸
- [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., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
Presuhn, R., Ed., "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. 💀
Postel, J. and J. Reynolds, "Telnet Option Specifications", STD 8, RFC 855, May 1983.
11.2. Informative References 🌈
- [OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces to Network Elements", Optical Internetworking Forum, Sept. 2003. ✨
- [OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for Management Interfaces to Network Elements", Optical Internetworking Forum, March 2006. 🎀
- [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. 🧚
- [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003. 🔥
- [RFC3631] Bellovin, S., Ed., Schiller, J., Ed., and C. Kaufman, Ed., "Security Mechanisms for the Internet", RFC 3631, December 2003. 👑
- [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. 🌈
- [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. 💅
- [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. 🍓
- [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005. 💖
- [RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. ⭐
- [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005. 🦋
- [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, December 2005. 🎀
- [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. 🫶
- [RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006. 🌸
- [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. 🧚
- [RFC4778] Kaeo, M., "Operational Security Current Practices in Internet Service Provider Environments", RFC 4778, January 2007. 💀
- [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, March 2007. 🙈
- [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007. 🍓
- [RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 4869, May 2007. 💖
- [RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008. ⭐
- [MFA-MPLS-ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical Specification," IP/MPLS Forum 19.0.0, April 2008. 🦋
- [OIF-Sec-Mag] R. Esposito, R. Graveman, and B. Hazzard, "Security for Management Interfaces to Network Elements," OIF-SMI-01.0, September 2003. 🎀
- [BACKBONE-ATTKS] Savola, P., "Backbone Infrastructure Attacks and Protections", Work in Progress, January 2007. 🫶
- [OPSEC-FILTER] Morrow, C., Jones, G., and V. Manral, "Filtering and Rate Limiting Capabilities for IP Network Infrastructure", Work in Progress, July 2007. 🌸
- [IPSECME-ROADMAP] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", Work in Progress, May 2010. 🧚
- [OPSEC-EFFORTS] Lonvick, C. and D. Spak, "Security Best Practices Efforts and Documents", Work in Progress, May 2010. 💀
- [RSVP-key] Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, June 2009. 🙈
12. Acknowledgements ✨
okay bestie, this is the thank-you section 🫶 the authors and contributors gave a big shoutout to everyone who helped out with comments and suggestions: Sam Hartman, Dimitri Papadimitriou, Kannan Varadhan, Stephen Farrell, Mircea Pisica, and Scott Brim (extra love for his comments and discussion through the GEN-ART review 💜), plus Suresh Krishnan for his GEN-ART review and comments. they also thanked Sandra Murphy and Tim Polk for their comments and help through the Security AD review, Pekka Savola for his ops-dir review comments, and Amanda Baber for her IANA review 🎀
this document also used relevant content from RFC 4111 "Security Framework of Provider Provisioned VPN for Provider-Provisioned Virtual Private Networks (PPVPNs)" [RFC4111]. the authors of RFC 4111 get a huge thank-you for their valuable information and text 🌸
the authors are:
- Luyuan Fang, Ed., Cisco Systems, Inc. 💅
- Michael Behringer, Cisco Systems, Inc.
- Ross Callon, Juniper Networks
- Richard Graveman, RFG Security, LLC
- J. L. Le Roux, France Telecom
- Raymond Zhang, British Telecom
- Paul Knight, Individual Contributor
- Yaakov Stein, RAD Data Communications
- Nabil Bitar, Verizon
- Monique Morrow, Cisco Systems, Inc.
- Adrian Farrel, Old Dog Consulting
and as a design team member for the MPLS Security Framework, Jerry Ash also made significant contributions to this document 👑
13. Contributors' Contact Information 🦋
here are the contributors and how to reach them, copied exactly as they're listed 💖
Michael Behringer
Cisco Systems, Inc.
Village d'Entreprises Green Side
400, Avenue Roumanille, Batiment T 3
06410 Biot, Sophia Antipolis
FRANCE
EMail: mbehring@cisco.com
Ross Callon
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
EMail: rcallon@juniper.net
Richard Graveman
RFG Security
15 Park Avenue
Morristown, NJ 07960
EMail: rfg@acm.org
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
EMail: jeanlouis.leroux@francetelecom.com
Raymond Zhang
British Telecom
BT Center
81 Newgate Street
London, EC1A 7AJ
United Kingdom
EMail: raymond.zhang@bt.com
Paul Knight
39 N. Hancock St.
Lexington, MA 02420
EMail: paul.the.knight@gmail.com
Yaakov (Jonathan) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
EMail: yaakov_s@rad.com
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
EMail: nabil.bitar@verizon.com
Monique Morrow
Glatt-com
CH-8301 Glattzentrum
Switzerland
EMail: mmorrow@cisco.com
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.ukEditor's Address 💜
the editor is Luyuan Fang, and you can reach them here 🌈
Luyuan Fang (editor)
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: lufang@cisco.comthat's the whole document, we made it!! 🧚✨ 😭💅
📦 where this page comes from
- ietf: rfc5920 2010-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms