RFC 4381

Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)

📅 published February 2006, from ietf

RFC 4381 🎀 Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) 💖

okay so this RFC is from February 2006 and it's written by M. Behringer from Cisco Systems Inc 💅 It's filed in the Network Working Group stream as Informational (so it's just giving info, not a standard, no cap). The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Status of This Memo 🌸

This memo gives information to the Internet community. It is not a standard of any kind, and it doesn't specify one. Distribution of this memo is unlimited 🦋

Copyright (C) The Internet Society (2006). 🫶

IESG Note 🙈

okay this part is lowkey important bestie. This RFC was at one point looked at by the IETF, so it might look like current IETF work or something that's already been published. It is NOT a candidate for any level of Internet Standard 💀 The IETF doesn't vouch for whether it's fit for any purpose, and it especially doesn't say it was reviewed for things like security, congestion control, or messing up with protocols that are already deployed. The RFC Editor picked to publish it at their discretion, so readers should be careful about how much they trust it before implementing or deploying anything. See RFC 3932 for more info 👑

Abstract ✨

this doc breaks down how secure the BGP/MPLS IP VPN architecture is, the one described in RFC 4364, for both service providers and VPN users 🧚

and the verdict is giving: BGP/MPLS IP VPN networks can be just as secure as the traditional layer-2 VPN services that use Asynchronous Transfer Mode (ATM) or Frame Relay. literally iconic 🔥

Table of Contents 📋

   1. Scope and Introduction ..........................................3
   2. Security Requirements of VPN Networks ...........................4
      2.1. Address Space, Routing, and Traffic Separation .............4
      2.2. Hiding the Core Infrastructure .............................5
      2.3. Resistance to Attacks ......................................5
      2.4. Impossibility of Label Spoofing ............................6
   3. Analysis of BGP/MPLS IP VPN Security ............................6
      3.1. Address Space, Routing, and Traffic Separation .............6
      3.2. Hiding of the BGP/MPLS IP VPN Core Infrastructure ..........7
      3.3. Resistance to Attacks ......................................9
      3.4. Label Spoofing ............................................11
      3.5. Comparison with ATM/FR VPNs ...............................12
   4. Security of Advanced BGP/MPLS IP VPN Architectures .............12
      4.1. Carriers' Carrier .........................................13
      4.2. Inter-Provider Backbones ..................................14
   5. What BGP/MPLS IP VPNs Do Not Provide ...........................16
      5.1. Protection against Misconfigurations of the Core
           and Attacks 'within' the Core .............................16
      5.2. Data Encryption, Integrity, and Origin Authentication .....17
      5.3. Customer Network Security .................................17
   6. Layer 2 Security Considerations ................................18
   7. Summary and Conclusions ........................................19
   8. Security Considerations ........................................20
   9. Acknowledgements ...............................................20
   10. Normative References ..........................................20
   11. Informative References ........................................20

1. Scope and Introduction ✨

so MPLS is getting way more popular for delivering IP VPN services, which means the security of the BGP/MPLS IP VPN architecture is a bigger deal for service providers and VPN customers every day 💅 This doc gives an overview of that security, as described in RFC 4364 [1], and compares it to the security of traditional layer-2 services like ATM or Frame Relay 🦋

here's the term we're using: the "MPLS core" is the set of Provider Edge (PE) and provider (P) routers that deliver a BGP/MPLS IP VPN service, usually run by one single service provider (SP) 🌈 This doc assumes the MPLS core network is trusted and secure. So it does NOT cover basic stuff like locking down network elements against unauthorised access, misconfigurations of the core, or attacks coming from inside the core 🙈 A customer who doesn't trust the service provider's network has to add extra security on top, like IPsec running over the MPLS infrastructure 🔥

this doc only looks at the security features of BGP/MPLS IP VPNs. It is not about routing protocol security in general, and IPsec isn't covered either, except to point out how combining MPLS VPNs with IPsec works 💜

a system's overall security has three parts: the architecture, the implementation, and the operation. Security problems can show up in any of them. This doc only analyses the architectural security of BGP/MPLS IP VPNs, not implementation or operational issues 🫶

the target audience is technical staff at service providers and enterprises. You need to already know the basic BGP/MPLS IP VPN architecture from RFC 4364 [1] to get through this. For specific Layer 3 VPN terminology and reference models, check out [11] 🧚

quick map of the rest: Section 2 lists the typical VPN requirements a VPN user might have, and Section 3 analyses how RFC 4364 [1] handles those requirements. Section 4 covers specific security issues in multi-AS (Autonomous System) MPLS architectures, and Section 5 lists security features this architecture does NOT cover, so they have to be handled separately. Section 6 points out potential layer 2 security issues that could affect the overall security of a BGP/MPLS IP VPN service. Section 7 wraps up the findings 🎀

2. Security Requirements of VPN Networks 💖

both service providers offering any kind of VPN service and the customers using them have specific security demands 👑 Mostly they compare MPLS-based solutions with the traditional layer 2 VPN solutions like Frame Relay and ATM, since those are widely deployed and trusted. This section lays out the typical security requirements for VPN networks. The next section looks at whether and how BGP/MPLS IP VPNs meet these requirements, for both the MPLS core and the connected VPNs 💅

2.1. Address Space, Routing, and Traffic Separation 🌸

non-intersecting layer 3 VPNs of the same VPN service are assumed to have independent address spaces. For example, two non-intersecting VPNs can each use the same 10/8 network addresses with no conflict 🦋 Also, traffic from one VPN must never get into another VPN. That means routing protocol information has to be separated too, so routing tables must also be separate for each VPN ✨ Specifically:

  • Any VPN must be able to use the same address space as any other VPN.
  • Any VPN must be able to use the same address space as the MPLS core.
  • Traffic, including routing traffic, from one VPN must never flow to another VPN.
  • Routing information, as well as distribution and processing of that information, for one VPN instance must be independent from any other VPN instance.
  • Routing information, as well as distribution and processing of that information, for one VPN instance must be independent from the core.

from a security point of view, the core requirement is to stop packets aimed at a host a.b.c.d inside a given VPN from reaching a host with that same address in another VPN or in the core. It's also about stopping routing packets from reaching another VPN, even if that VPN doesn't have the destination address 🫶

Confidentiality, as defined in the L3VPN Security Framework [11], goes beyond just isolating VPNs. It protects against eavesdropping on any transmission medium, and encryption is the tool used to get it 🔐 This doc treats confidentiality as an optional VPN requirement, since lots of existing VPN deployments don't encrypt transit traffic 🙈

2.2. Hiding the Core Infrastructure 🧚

the internal structure of the core network (the MPLS PE and P elements) should not be visible from the outside. Breaking this isn't a security problem by itself, but lots of service providers think it's a plus if internal addresses and network structure stay hidden from the outside world 💜 The argument is that denial-of-service (DoS) attacks on a core router are way easier to pull off if the attacker knows the router addresses. Addresses can always be guessed, but attacks are harder when the addresses aren't known 😭 The core should be as invisible to the outside world as a comparable layer 2 infrastructure (for example, Frame Relay or ATM). Core network elements also should not be reachable from inside a VPN 🌈

security should never rely entirely on obscurity, meaning hiding information. Services should stay equally secure even if the implementation is public knowledge 💅 However, there's a strong market perception that hiding details is helpful, and this section is here to address that perception 🎀

2.3. Resistance to Attacks ⭐

there are two basic kinds of attacks: DoS attacks, where resources become unavailable to authorised users, and intrusions, where resources become available to unauthorised users 🔥 BGP/MPLS IP VPN networks must provide at least the same level of protection against both forms of attack as current layer 2 networks do.

for intrusions, there are two basic ways to protect the network. First, harden the protocols that could be abused (for example, Telnet into a router). Second, make the network as inaccessible as possible. That's done with a mix of packet filtering or firewalling and address hiding, which we talked about above 🦋

DoS attacks are easier to pull off, since one known IP address might be enough info to attack a machine. This can be done with normal "permitted" traffic just by sending higher-than-normal packet rates, so other users can't reach the targeted machine 😭 The only way to be totally invulnerable to this kind of attack is to make sure machines aren't reachable at all, again with packet filtering and optionally with address hiding 🫶

this doc focuses on protecting the core network from attacks from the "outside", meaning the Internet and connected VPNs. Protection against attacks from the "inside", meaning an attacker with logical or physical access to the core network, is not discussed here 🙈

2.4. Impossibility of Label Spoofing ✨

Okay so, assuming the address and traffic separation we just covered 🦋, an attacker might try to get into other VPNs by slipping in packets with a label they don't "own" 👀. This could come from the outside, like another Customer Edge (CE) router or straight from the Internet, or from inside the MPLS core. The core case isn't getting a deep dive here 💅, because we're assuming the core network is provided securely. If you do need protection against an insecure core, you'd need security protocols like IPsec running across the MPLS infrastructure, at least from CE to CE, since the PEs belong to the core 🔐.

Depending on how CE routers connect to PE routers, it might be possible to sneak into a VPN that's on the same PE using layer 2 attack mechanisms, like 802.1Q-label spoofing or ATM VPI/VCI spoofing 🙈. Layer 2 security gets its own discussion in section 6 🎀.

It is required that VPNs cannot abuse the MPLS label mechanisms or protocols to gain unauthorised access to other VPNs or the core 🚫🔥.

3. Analysis of BGP/MPLS IP VPN Security 🔍

In this section we're checking how the BGP/MPLS IP VPN architecture holds up against the security requirements from above 💜.

3.1. Address Space, Routing, and Traffic Separation 🌸

BGP/MPLS lets distinct IP VPNs use the same address space, and that space can even be private address space (RFC 1918 [2]) 🧩. The trick is adding a 64-bit Route Distinguisher (RD) to each IPv4 route, so VPN-unique addresses also end up unique in the MPLS core 🔑. That "extended" address is also called a "VPN-IPv4 address". So customers don't need to change their current addressing plan, which is iconic ✨.

Each PE router keeps a separate Virtual Routing and Forwarding instance (VRF) for every connected VPN 🗂️. A VRF includes the addresses of that VPN, plus the addresses of the PE routers the CE routers are peering with. All addresses in a VRF, including those PE addresses, logically belong to the VPN and are accessible from the VPN. Having PE addresses reachable by the VPN isn't an issue if static routing is used between PE and CE, because packet filters can block access to all the VRF's addresses on the PE router 🛡️. If dynamic routing protocols are used, the CE routers need the peer PE router's address in the core configured. In an environment where the service provider manages the CE routers as CPE, this can be invisible to the customer 👀. The address space on the CE-PE link (including the peering PE address) is considered part of the VPN address space. Since address space can overlap between VPNs, CE-PE link addresses can overlap too. For practical management reasons, SPs typically address CE-PE links from a global pool, which keeps them unique across the core 🌍.

Routing separation between VPNs can also be achieved 🛤️. Each VRF is populated with routes from one VPN, either through statically configured routes or through routing protocols running between the PE and CE router. Since each VPN is tied to its own VRF, there is no interference between VPNs on the PE router 🙅‍♀️.

Across the core to the other PE routers, separation is maintained with unique VPN identifiers in multiprotocol BGP: the Route Distinguishers (RDs) 🏷️. VPN routes, including the RD, are exclusively exchanged between PE routers by Multi-Protocol BGP (MP-BGP, RFC 2858 [8]) across the core 💌. These BGP routing updates are not re-distributed into the core, only to the other PE routers, where the information is stored again in VPN-specific VRFs. So routing across a BGP/MPLS network is separate per VPN 💖.

On the data plane, traffic separation is achieved by the ingress PE prepending a VPN-specific label to the packets 🏷️. The packets carrying the VPN labels are sent through the core to the egress PE, where the VPN label is used to select the egress VRF 🎯.

Given the addressing, routing, and traffic separation across a BGP/MPLS IP VPN core network, it can be assumed that this architecture offers the same security as a layer-2 VPN in this respect 👑. It is not possible to intrude from a VPN or the core into another VPN unless this has been explicitly configured 🚫.

If and when confidentiality is required, it can be achieved in BGP/MPLS IP VPNs by overlaying encryption services over the network 🔐. However, encryption is not a standard service on BGP/MPLS IP VPNs. See also section 5.2 🫶.

3.2. Hiding of the BGP/MPLS IP VPN Core Infrastructure 🥷

Service providers and end-customers don't normally want their network topology revealed to the outside 🙈. This makes attacks more difficult to pull off: if an attacker doesn't know a victim's address, they can only guess the IP addresses to attack. Since most DoS attacks don't provide direct feedback to the attacker, attacking the network would be difficult. It has to be mentioned specifically that information hiding as such does not provide security 🚨. However, in the market this is a perceived requirement 💅.

With a known IP address, a potential attacker can launch a DoS attack more easily against that device 😬. So the ideal is to not reveal any information about the internal network to the outside world 🤐. This applies to the customer network and the core. A number of additional security measures also have to be taken: most of all, extensive packet filtering 🧱.

For security reasons, it is recommended for any core network to filter packets from the "outside" (Internet or connected VPNs) destined to the core infrastructure 🛑. This makes it very hard to attack the core, although some functionality, such as pinging core routers, will be lost 🏓. Traceroute across the core will still work, since it addresses a destination outside the core 🗺️.

MPLS does not reveal unnecessary information to the outside, not even to customer VPNs 🤫. The addressing of the core can be done with private addresses (RFC 1918 [2]) or public addresses. Since the interface to the VPNs as well as the Internet is BGP, there is no need to reveal any internal information. The only information required in the case of a routing protocol between PE and CE is the address of the PE router. If no dynamic routing is required, static routing on unnumbered interfaces can be configured between the PE and CE. With this measure, the BGP/MPLS IP VPN core can be kept completely hidden 🫥.

Customer VPNs must advertise their routes to the BGP/MPLS IP VPN core (dynamically or statically) to ensure reachability across their VPN 📣. In some cases, VPN users prefer that the service provider have no visibility of the addressing plan of the VPN 🙏. A few things to note: first, the information known to the core is not about specific hosts, but networks (routes), which offers a degree of abstraction 🧠. Second, in a VPN-only BGP/MPLS IP VPN network (no Internet access), this is equal to existing layer-2 models, where the customer has to trust the service provider 🤝. Also, in a Frame Relay or ATM network, routing and addressing information about the VPNs can be seen on the core network 📡.

In a VPN service with shared Internet access, the service provider will typically announce the routes of customers who wish to use the Internet to its upstream or peer providers 📢. This can be done directly if the VPN customer uses public address space, or via Network Address Translation (NAT) to obscure the addressing information of the customers' networks 🎭. In either case, the customer does not reveal more information than would be revealed by a general Internet service. Core information will not be revealed, except for the peering address(es) of the PE router(s) that hold(s) the peering with the Internet. These addresses must be secured as in a traditional IP backbone 🔒.

In summary, in a pure MPLS-VPN service, where no Internet access is provided, information hiding is as good as on a comparable FR or ATM network 💯. No addressing information is revealed to third parties or the Internet. If a customer chooses to access the Internet via the BGP/MPLS IP VPN core, they will have to reveal the same information as required for a normal Internet service. NAT can be used for further obscurity. Being reachable from the Internet automatically exposes a customer network to additional security threats. Appropriate security mechanisms have to be deployed, such as firewalls and intrusion detection systems 🚨. This is true for any Internet access, over MPLS or direct 🌐.

A BGP/MPLS IP VPN network with no interconnections to the Internet has security equal to that of FR or ATM VPN networks 🦋. With Internet access from the MPLS cloud, the service provider has to reveal at least one IP address (of the peering PE router) to the next provider, and thus to the outside world 🌩️.

3.3. Resistance to Attacks ✨

okay bestie, so section 3.1 already proved you can't just barge into other VPNs 🙅‍♀️. the next idea an attacker might have is to go after the MPLS core and try to hit other VPNs from inside there 👀. but as we saw, you can't address a P router directly 💅. the only addresses a VPN or the Internet can reach are the peering addresses of the PE routers 🎀. so there are really two ways the BGP/MPLS IP VPN core could get attacked:

  1. by attacking the PE routers directly 💥
  2. by attacking the MPLS signaling mechanisms (mostly routing) 🧠

to attack anything in a BGP/MPLS IP VPN network, you first need to know its address 🕵️‍♀️. like we talked about in section 3.2, the core's addressing is hidden from the outside world 🙈. so an attacker can't know the IP address of any core router to target. they could try guessing addresses and sending packets to them 🎯, but because of MPLS address separation, every incoming packet gets treated as belonging to the customer's address space 🧁. so it's literally impossible to reach an internal router, even by guessing IPs 😤. there's only one exception: the peer interface of the PE router 🌸. that PE address is the only attack point from the outside (a VPN or the Internet) 🦋.

routing between a VPN and the BGP/MPLS IP VPN core can be configured in two ways:

  1. Static 🧭: the PE routers get static routes to the networks behind each CE, and the CEs statically point to the PE for any network in other parts of the VPN (usually a default route) 🍓. there are two sub-cases here: the static route can point at the PE's IP address, or at an interface on the CE router (like serial0) 🔌.
  2. Dynamic 🔄: a routing protocol (like RIP, OSPF, or BGP) swaps routing info between the CE and PE at each peering point 🫶.

with a static route pointing at an interface, the CE doesn't need to know any IP addresses of the core or even the PE router 🙌. yes, it means more (static) configuration to manage, but it's the most secure option, no cap 🔥. in this setup you can also put packet filters on the PE interface to deny any packet aimed at the PE interface 🛡️. that protects the router and the whole core from attack 👑.

in every other case, each CE router needs to know at least the router ID (RID, i.e., the PE's peer IP address) of the PE router in the core 🫣. that makes it a potential destination for an attack 😬. people could imagine all kinds of attacks on the services running on a router 💀. in practice though, you can limit access to the PE router over the CE-PE interface to just the required routing protocol using access control lists (ACLs) 🧱. that narrows the point of attack down to one routing protocol, like BGP 🎯. a potential attack could be sending a huge number of routes or flooding the PE router with routing updates 🌊. both could lead to a DoS, but neither leads to unauthorised access 🙅‍♀️.

to lower that risk, you need to configure the routing protocol on the PE router to run as securely as possible 🔐. here's how:

  • by accepting only routing protocol packets, and only from the CE router 📬. the inbound ACL on each CE interface of the PE router should allow only routing protocol packets going from the CE to the PE 🚦.
  • by configuring MD5 authentication for routing protocols 🔑. it's available for BGP (RFC 2385 [6]), OSPF (RFC 2154 [4]), and RIP2 (RFC 2082 [3]), for example 💜. this stops packets being spoofed from other parts of the customer network besides the CE router 🙅‍♀️. it means the service provider and customer have to agree on a shared secret between all CE and PE routers 🤝. this has to be done for all VPN customers 🌈. doing it only for the customer with the highest security requirements is NOT enough 😭.
  • by tuning the routing protocol parameters to lock down this communication even more 🔒. for example, the rate of routing updates should be restricted where possible (in BGP, through damping) ⏱️. a maximum number of routes accepted per VRF and per routing neighbour should be configured where possible 📏. and the Generalized TTL Security Mechanism (GTSM; RFC 3682 [10]) should be used for all supported protocols 🧚.

so to sum it all up: you can't intrude from one VPN into other VPNs, or into the core 🙌. but it's theoretically possible to attack the routing protocol port and run a DoS attack against the PE router 😵. that could hurt other VPNs on the same PE router too 💔. which is why PE routers must be extremely well secured, especially on their interfaces to CE routers 🏰. ACLs must be configured so access is limited to the routing protocol's port(s), and only from the CE router 🚧. on top of that, routing protocol security mechanisms like MD5 authentication, maximum prefix limits, and Time to Live (TTL) security mechanisms should be used on all PE-CE peerings 💅. with all of these measures in place, the only possible attack left is a DoS attack against the routing protocol itself 🥲. BGP has a bunch of countermeasures built in, like prefix filtering and damping, to help with stability 🧸. and it's also easy to track down the source of a potential DoS like that 🕵️‍♀️. without dynamic routing between CEs and PEs, the security is equivalent to that of ATM or Frame Relay networks 🦋.

3.4. Label Spoofing 🎭

okay so this is basically IP spoofing's cousin 👯‍♀️. in IP spoofing, an attacker fakes the source IP address of a packet. with MPLS, it's theoretically possible to spoof the label of an MPLS packet too 🫢. back in the first section we assumed the core network is trusted. if that assumption can't be made, IPsec must be run over the MPLS cloud 🔐. so in this section we focus on whether an outside attacker can insert packets with spoofed labels into the MPLS network, i.e., from a VPN (through the CE router) or from the Internet 🕵️‍♀️.

the interface between a CE router and its peering PE router is an IP interface, meaning no labels 🧃. the CE router has no idea the MPLS core exists and thinks it's just sending IP packets to another router 🤷‍♀️. all the "intelligence" lives in the PE device, which picks the label based on configuration and prepends it to the packet 🧠. this is true for all PE routers, whether they face CE routers or the upstream service provider 🌐. every interface into the MPLS cloud only needs IP packets, without labels 🎀.

for security reasons, a PE router should NEVER accept a labelled packet from a CE router 🙅‍♀️. RFC 3031 [9] says it plainly: "Therefore, when a labeled packet is received with an invalid incoming label, it MUST be discarded, UNLESS it is determined by some means (not within the scope of the current document) that forwarding it unlabeled cannot cause any harm." 📜 accepting labels on the CE interface could let packets sneak into other VPNs, so the RFC doesn't allow it 🚫.

so yes, it's impossible for an outside attacker to send labelled packets into the BGP/MPLS IP VPN core 🙌.

there's still the possibility of spoofing the IP address of a packet being sent to the MPLS core 🎭. but since there's strict address separation inside the PE router, and each VPN has its own VRF, this can only harm the VPN the spoofed packet came from 🫣. so a VPN customer can only attack themselves 💅. MPLS doesn't add any extra security risk here 🧁.

the Inter-AS and Carrier's Carrier cases are special, since packets with labels are typically exchanged on the interfaces between providers 🦋. see section 4 for an analysis of those architectures 📖.

3.5. Comparison with ATM/FR VPNs 🥊

ATM and FR VPN services have a seriously high reputation for security 👑. ATM and FR VPNs can be provided securely, but it has been reported that these technologies can also have security vulnerabilities [14] 😬. in ATM/FR, as in any networking technology, security depends on the network being configured securely, and errors can also lead to security problems 🙈.

4. Security of Advanced BGP/MPLS IP VPN Architectures 🌸

okay so the BGP/MPLS IP VPN architecture described in RFC 2547 [7] defines the PE-CE interface as the only external interface seen from the service provider network 🙌. in this setup, the PE treats the CE as untrusted and only accepts IP packets from the CE 🛡️. the IP address range is treated as belonging to the CE's VPN, so the PE keeps full control over VPN separation 👑.

RFC 4364 [1] later defined a more complex architecture with more open interfaces 🦋. these interfaces allow exchanging label information and labelled packets to and from devices outside the service provider's control 😳. this section talks about the security implications of this advanced architecture 🔍.

4.1. Carriers' Carrier 🎀

in the Carriers' Carrier (CsC) architecture, the CE is linked to a VRF on the PE 🔗. the CE may send labelled packets to the PE 📦. the label was previously assigned by the PE to the CE, and represents the label switched path (LSP) from this CE to the remote CE through the carrier's network 🛤️.

RFC 4364 [1] specifies for this case: "When the PE receives a labeled packet from a CE, it must verify that the top label is one that was distributed to that CE." 📜 this means the CE can only use labels the PE correctly associates with the corresponding VPN 💖. packets with incorrect labels get discarded, so label spoofing is impossible 🙅‍♀️.

the use of label maps on the PE leaves control of the label information entirely with the PE, so it has no impact on the security of the solution 🧠.

the packet underneath the top label will, as in standard RFC 2547 [7] networks, stay local to the customer carrier's VPN and won't be inspected in the carriers' carrier core 🔒. any potential spoofing of subsequent labels or IP addresses stays local to the carrier's VPN 🏡. it has no implication on the carriers' carrier core or on other VPNs in that core ✨. this is specifically stated in section 6 of RFC 4364 [1] 📖.

note that if the PE and CE are connected using a shared layer 2 infrastructure, like a switch, attacks are possible on layer 2 ⚠️. that could let a third party on the shared layer 2 network intrude into a VPN on that PE router 😱. so RFC 4364 [1] specifies that either all devices on a shared layer 2 network have to be part of the same VPN, or the layer 2 network must be split logically to avoid this issue 🧩. this will be discussed in more detail in section 6 🎀.

in the CsC architecture, the customer carrier needs to trust the carriers' carrier for correct configuration and operation 🫶. so the carrier's customer implicitly needs to trust both their carrier and the carriers' carrier 🥹.

in summary, a correctly configured carriers' carrier network gives the same level of security as comparable layer 2 networks or traditional RFC 2547 [7] networks 🌈.

4.2. Inter-Provider Backbones ✨

okay bestie, so RFC 4364 [1] lays out three sub-cases for the inter-provider backbone (Inter-AS) situation 🫶

a) VRF-to-VRF connections at the autonomous system border routers (ASBRs). 💅

So in this one, each PE sees the other PE as a CE 🙈 Neither one accepts labeled packets, and there's no signaling between the PEs except inside the VRFs on both sides. That means the separation of the VPNs on both sides, and their security, is the same as on a single AS RFC 2547 [7] network. It's already been shown to have the same security properties as traditional layer 2 VPNs 🔥

This one has possible scalability issues though 😭 The ASBRs need a VRF per VPN, and every VRF has to hold all the routes of its specific VPN. So an ASBR can run into memory problems that hit all the VPNs if one single VRF holds too many routes. The service providers need to make sure the ASBRs are properly dimensioned and use security measures like limiting the number of prefixes per VRF ✨

The two service providers connecting their VPNs this way have to trust each other 🤝 Since the VPNs are separated on different (sub-)interfaces, all signaling between the ASBRs stays inside a given VPN. So dynamic cross-VPN security breaches are impossible 🦋 It's still conceivable that a service provider plugs a specific VPN into the wrong interface, which ends up interconnecting two VPNs that should never be connected. This must be controlled operationally 👑

b) EBGP redistribution of labeled VPN-IPv4 routes from AS to neighboring AS. 🌸

In this one, the ASBRs on both sides hold full routing information for all the shared VPNs on both sides. It isn't kept in separate VRFs, it lives in the BGP database instead (this is typically limited to the Inter-AS VPNs through filtering). The separation inside the PE is kept up through VPN-IPv4 addresses 💜 The control plane between the ASBRs uses Multi-Protocol BGP (MP-BGP, RFC 2858 [8]). It exchanges VPN routes as VPN-IPv4 addresses, the ASBR addresses as BGP next-hop IPv4 addresses, and the labels to be used in the data plane 🧚

The data plane is separated with a single label, which represents a VRF or a subset of one. RFC 4364 [1] says an ASBR should only accept packets with a label it has assigned to this router. That stops packets with unknown labels from getting inserted 🙅‍♀️ But a service provider can still use any label the other provider's ASBR has passed on. So one provider can insert packets into any VPN of the other provider that it has a label for. Not it 💀

This solution also has to think about the security on layer 2 at the interconnection. The RFC states this type of interconnection should only be implemented on private interconnection points. See section 6 for more details 🎀

RFC 4364 [1] also says a trust relationship between the two connecting ASes must exist for this model to work securely. Basically, every AS interconnected this way forms one single zone of trust ⭐ The VPN customer has to trust all the service providers involved in provisioning their VPN in this architecture 🫣

c) PEs exchange labeled VPN-IPv4 routes, ASBRs only exchange loopbacks of PEs with labels. 🦋

Here there are effectively two control connections between the ASes. The route reflectors (RRs) swap the VPN-IPv4 routes over multihop eBGP 🌈 The ASBRs only exchange the labeled addresses of those PE routers that hold VPN routes shared between those ASes. This keeps the ASBRs scalable, since they never need to know the VPN-IPv4 routes ✨

In this solution, the top label specifies an LSP to an egress PE router, and the second label specifies a VPN connected to that egress PE. The security of the ASBR connection has the same constraints as in solution b): an ASBR should only accept packets with top labels it has assigned to the other router, which verifies that the packet is addressed to a valid PE router. Any label that was assigned to the other ASBR will be accepted 🥲 It's impossible for an ASBR to tell apart different egress PEs or different VPNs on those PEs. A malicious service provider in one AS could introduce packets into any VPN on a PE of the other AS. It only needs a valid LSP on its ASBR and PEs to the corresponding PE on the other AS 😱 The VPN label can be statistically guessed from the theoretical label space, which allows unidirectional traffic into a VPN. Yikes, periodt 💀

This means an ASBR-ASBR connection like this can only be made with a trusted party over a private interface, just like in b) 🔒

On top of that, this solution exchanges labeled VPN-IPv4 addresses between route reflectors (RRs) via MP-eBGP. The control plane itself can be protected with routing authentication (RFC 2385 [6]), which makes sure the routing information was originated by the expected RR and wasn't modified in transit 🛡️ But the received VPN information can't be verified, same as the previous case. So a service provider can introduce bogus routes for any shared VPN 😬 The ASes need to trust each other to configure their own networks correctly. All the ASes in this design form one trusted zone, and the customer needs to trust all the service providers involved 🫶

The difference between case b) and case c) is this: in b), the ASBRs act as iBGP next-hops for their AS. So each SP only needs to know the addresses of the other SP's ASBRs, not the rest of its core 🧁 In case c), the SPs exchange the loopback addresses of their PE routers. So each SP reveals information about its PE routers to the other, and those routers have to be accessible from the other AS 👀 As said above, accessibility doesn't necessarily mean insecurity, but networks should never rely on "security through obscurity" 🙅‍♀️ This shouldn't be an issue if the PE routers are appropriately secured. Still, there's an increasing perception that network devices should generally not be accessible, so it's giving caution 🍓

There are also scalability considerations for case c). A bunch of BGP peerings have to be set up for the overall network, including all the ASes linked this way. SPs on both sides need to work together to define a scalable architecture, probably with route reflectors 🌸

So in summary: all of these Inter-AS solutions logically merge several provider networks. In every Inter-AS configuration, all the ASes form a single zone of trust, and service providers need to trust each other. For the VPN customer, the security of the overall solution is equal to the security of traditional RFC 2547 [7] networks, but the customer needs to trust all the service providers involved in provisioning this Inter-AS solution 💖

5. What BGP/MPLS IP VPNs Do Not Provide 🙈

5.1. Protection against Misconfigurations of the Core and Attacks 'within' the Core

The security mechanisms discussed here assume the network elements of the core network (PE and P routers) are configured correctly. Deliberate or accidental misconfiguration can lead to serious security leaks 😭

Quick note: this paragraph is specifically about the core network, meaning the PE and P elements. Misconfigurations of any customer-side elements, like the CE router, are covered by the security mechanisms above 💅 So a potential attacker has to get access to either a PE or a P router to gain anything from misconfigurations. If an attacker has access to core elements, or can insert extra equipment into the core, they can attack both the core network and the connected VPNs. So the following is important:

  • To avoid the risk of misconfigurations, the equipment needs to be easy to configure, and SP staff need the right training and experience when configuring the network. Proper tools are required to configure the core network 🛠️
  • To minimise the risk of "internal" attacks, the core network must be properly secured. This includes network element security, management security, physical security of the service provider infrastructure, access control to service provider installations, and other standard SP security mechanisms 🔐

BGP/MPLS IP VPNs can only provide a secure service if the core network is provided in a secure fashion. This document assumes that to be the case 🎀

There are various approaches to control the security of a core if the VPN customer cannot or does not want to trust the service provider. IPsec from customer-controlled devices is one of them 🦋 The document "CE-to-CE Member Verification for Layer 3 VPNs" [13] proposes a CE-based authentication scheme using tokens, aimed at detecting misconfigurations in the MPLS core. The document "MPLS VPN Import/Export Verification" [12] proposes a similar scheme based on using MD5 routing authentication. Both schemes aim to detect and prevent misconfigurations in the core 🧚

5.2. Data Encryption, Integrity, and Origin Authentication

BGP/MPLS IP VPNs themselves do not provide encryption, integrity, or authentication service 🙅‍♀️ If these are required, IPsec should be used over the MPLS infrastructure. The same applies to ATM and Frame Relay: IPsec can provide these missing services 🔒

5.3. Customer Network Security

BGP/MPLS IP VPNs can be secured so that they are comparable with other VPN services 💖 However, the security of the core network is only one factor in the overall security of a customer's network. Threats in today's networks don't only come from an "outside" connection, they also come from the "inside" and from other entry points (modems, for example) 👀 To reach a good security level for a customer network in a BGP/MPLS infrastructure, MPLS security is necessary but not sufficient. The same applies to other VPN technologies like ATM or Frame Relay. See also RFC 2196 [5] for more information on how to secure a network ✨

6. Layer 2 Security Considerations 🌸

okay so this part is about layer 2 stuff 🫶 In most Inter-AS or Carrier's Carrier setups, a network gets hooked up to other networks through a point-to-point private connection, and third parties can't interfere with that. BUT ngl, using any shared-medium layer 2 tech for these links, like Ethernet switches, can bring extra security risks 🙈

There are two types of layer 2 risks, bestie:

a) Attacks against layer 2 protocols or mechanisms

Layer 2 can get hit by lots of different stuff: ARP attacks, VLAN trunking attacks, or CAM overflow attacks. For example, ARP spoofing lets an attacker redirect traffic between two routers through their own device, so they get access to every packet flowing between those two routers 💀

These attacks can be prevented with the right security measures, but these concerns get overlooked way too often 😤 It is of the utmost importance that if a shared medium (such as a switch) is used in the scenarios above, all the available layer 2 security mechanisms are used to stop layer 2 based attacks 🔥

b) Traffic insertion attacks

When lots of routers share a common layer 2 network (like at an Internet exchange point), a third party can introduce packets into a network. This has been abused before on traditional exchange points, when some service providers defaulted to another provider on that exchange. Basically they were sending all their traffic into the other SP's network, even though the control plane (routing) might not allow that 😭

So routers on exchange points (or other shared layer 2 connections) should only accept non-labeled IP packets into the global routing table. Any labeled packet must be discarded. This keeps connected networks secure ✨

Some of the designs above require the exchange of labeled packets. That means a third party could introduce labeled packets, and if they're crafted correctly, they might be associated with certain VPNs on a BGP/MPLS IP VPN network. That would effectively introduce false packets into a VPN 👀

The current recommendation is therefore to discard labeled packets on generic shared-medium layer 2 networks such as Internet exchange points (IXPs). Where labeled packets need to be exchanged, it is strongly recommended to use private connections 💜

7. Summary and Conclusions 👑

BGP/MPLS IP VPNs provide full address and traffic separation, just like traditional layer-2 VPN services 🎀 They hide the addressing structures of the core and other VPNs, and it's not possible to intrude into other VPNs by abusing the BGP/MPLS mechanisms. It's also impossible to intrude into the MPLS core, if the core is properly secured. HOWEVER, there's a big difference between BGP/MPLS-based IP VPNs and, for example, FR- or ATM-based VPNs. The control structure of the core is layer 3 in the case of MPLS. This caused serious skepticism in the industry towards MPLS, since it might open the architecture to DoS attacks from other VPNs or from the Internet (if connected) 😬

As shown in this document, it is possible to secure a BGP/MPLS IP VPN infrastructure to the same level of security as a comparable ATM or FR service ✨ It's also possible to offer Internet connectivity to MPLS VPNs in a secure manner, and to interconnect different VPNs via firewalls. ATM and FR services have a strong reputation for security, but it has been shown that security problems can exist in these networks too [14] 🙈

When it comes to attacks from within the MPLS core, all VPN classes (BGP/MPLS, FR, ATM) have the same problem. If an attacker can install a sniffer, they can read information in all VPNs. And if the attacker has access to the core devices, they can run a large number of attacks, from packet spoofing to introducing new peer routers 💀 There are a number of precautionary measures outlined above that a service provider can use to tighten the security of the core. But the security of the BGP/MPLS IP VPN architecture depends on the security of the service provider. If the service provider is not trusted, the only way to fully secure a VPN against attacks from the "inside" of the VPN service is to run IPsec on top, from the CE devices or beyond 🔐

This document discussed many aspects of BGP/MPLS IP VPN security. It has to be noted that the overall security of this architecture depends on all components, and it is determined by the security of the weakest part of the solution. For example, a perfectly secured static BGP/MPLS IP VPN network with secured Internet access and secure management is still open to many attacks if there is a weak remote access solution in place 🥲

8. Security Considerations 🛡️

The entire document is discussing security considerations of the RFC 4364 [1] architecture. (Yep, the whole thing is security, bestie 💖)

9. Acknowledgements 🫶

The author would like to thank everybody who has provided input to this document 🌈 Special thanks go to Yakov Rekhter for his continued strong support, and to Eric Rosen, Loa Andersson, Alexander Renner, Jim Guichard, Monique Morrow, Eric Vyncke, and Steve Simlo for their extended feedback and support 💜

10. Normative References 📚

[1]   Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
      (VPNs)", RFC 4364, February 2006.

11. Informative References 📖

[2]   Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
      Lear, "Address Allocation for Private Internets", BCP 5,
      RFC 1918, February 1996.

[3]   Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5
      Authentication", RFC 2082, January 1997.

[4]   Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital
      Signatures", RFC 2154, June 1997.

[5]   Fraser, B., "Site Security Handbook", RFC 2196, September 1997.

[6]   Heffernan, A., "Protection of BGP Sessions via the TCP MD5
      Signature Option", RFC 2385, August 1998.

[7]   Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
      March 1999.

[8]   Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
      "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

[9]   Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
      Switching Architecture", RFC 3031, January 2001.

[10]  Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
      Security Mechanism (GTSM)", RFC 3682, February 2004.

[11]  Fang, L., "Security Framework for Provider-Provisioned Virtual
      Private Networks (PPVPNs)", RFC 4111, July 2005.

[12]  Behringer, M., Guichard, J., and P. Marques, "MPLS VPN
      Import/Export Verification", Work in Progress, June 2004.

[13]  Bonica, R. and Y. Rekhter, "CE-to-CE Member Verification for
      Layer 3 VPNs", Work in Progress, September 2003.

[14]  DataComm, "Data Communications Report, Vol 15, No 4: Frame
      Relay and ATM: Are they really secure?", February 2000.

Author's Address 🦋

Michael H. Behringer
Cisco Systems Inc
Village d'Entreprises Green Side
400, Avenue Roumanille, Batiment T 3
Biot - Sophia Antipolis  06410
France

EMail: mbehring@cisco.com
URI:   http://www.cisco.com

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.

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

Intellectual Property 🧠

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

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

Acknowledgement 💖

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) ✨

📦 where this page comes from