Information Risk Management Plc. - MPLS Security Overview

MPLS Security Overview

Download a PDF of this whitepaper here

Executive Summary

MPLS (Multi-Protocol Label Switching) is a switching technology, which forwards packets in a network according to so-called labels attached to the packets. These labels are attached as soon as the packet enters the MPLS core and are potentially modified as the packet traverses the network. The final label is removed as soon as the packet leaves the core. For the purposes of this report, the 'core' network refers to core and edge devices in the MPLS cloud. This is to try and avoid confusion over the various naming conventions that exist for these devices.

There are a number of advantages over traditional IP routing with this approach, mostly regarding speed, because forwarding decisions do not have to be made at every single hop, they are only made once, at the entry of the packet into the core.

Another promised advantage is security, as MPLS offers VPN (Virtual Private Network) functionality by traffic separation. Traffic engineering is another of the most commonly advertised features which drive a number of service providers and maintainers of large corporate network infrastructures towards MPLS-based configurations.

Even though security is one of the 'promises' of MPLS, it must be noted that configuration mistakes can still have detrimental effects, leading to hosts outside the MPLS core gaining access to services to which they should not have a valid network path.

In addition, MPLS suffers from a number of security issues as soon as an attacker successfully penetrates the core, for example by physically placing a device on the core that forwards data streams. Also, the VPNs implemented using MPLS do not establish VPNs in the sense that they would offer the protection of confidentiality or integrity, as they would with IPSec VPN technology.

This paper provides an overview of the potential security issues and makes suggestions about how to mitigate the corresponding risks. In addition, the author presents a small suite of tools which can be used to demonstrate the security issues as they currently stand.

Abstract

This paper provides an analysis of the security risks associated with implementing MPLS (Multi-Protocol Label Switching) and the measures that can be introduced to mitigate these risks. It follows a number of extensive MPLS security evaluations performed by IRM Plc. This has involved the development of a number of tools, which can be used to demonstrate how an attacker could manipulate the MPLS core infrastructure. The research that resulted in this paper is not exhaustive, but the intention is to promote further research in this area, as little has been written on the subject previously.

What is MPLS?

Multi Protocol Label Switching provides a mechanism by which traffic can be routed more efficiently through a network to provide traffic engineering functionality. In addition, traffic can be segregated in such a way as to provide VPN functionality.

Figure 1 shows an example of an MPLS infrastructure that transports IP traffic over an Ethernet network.

Figure 1 - Example MPLS Infrastructure

In a conventional IP network, packets are routed, based on their IP addresses and via the most appropriate route. The definition of 'most appropriate' is made by every intermediate router in the infrastructure. Often, routes are advertised between routers dynamically by routing protocols.

In an MPLS network, a decision is made as to the route a packet will take through the infrastructure at the point the packet enters the core network. When the packet enters the network the LER (Label Edge Router) makes a decision as to the path through the network that the packet should take. All packets that share the same path through a MPLS network are said to be in the same FEC (Forward Equivalence Class). The forwarding decision may be based on many factors, such as destination port, destination IP address, interface on which the packet was received, etc. Once this decision has been made a label (an additional header on the packet) or stack of labels is attached to the packet between the IP header and Ethernet frame header. Each label dictates the path at each hop in the core network that a packet should take.

Figure 1 shows that the FEC associated with a packet sent from Workstation 1 to Workstation 2 results in the label '10' being attached to the packet by Router A, which means that the path that the traffic will take is via Router B to Workstation 2, represented by the red path. The blue path represents the flow of a packet between Workstation 3 and Workstation 4, based on the FEC which resulted in label '40' being attached to the packet header by Router C. Note that labels are only locally significant between two label switching devices. A set of devices which engages in MPLS forwarding interaction is also known as a MPLS domain.

MPLS allows traffic to be routed through a network by the inspection of a simple label at each hop rather than the more processor-intensive technique of full IP packet header inspection used in conventional routing. Furthermore, by controlling the path packets take though the network, traffic can be adequately segregated in order to provide VPN functionality. It must be noted that the only VPN functionality provided by MPLS is traffic segregation - no authentication or encryption services are offered.

An important type of protocol used in conjunction with MPLS is LDP (Label Distribution Protocol). LDP is used to communicate the labels associated with different FECs to other LSRs (Label Switching Routers) within the MPLS infrastructure. This functionality is analogous to routing protocols in IP networks, such as BGP (Border Gateway Protocol).

Note that a customer is never supposed to see a labelled packet. The labelling of packets and operations on these labels (like popping and swapping) is only ever performed within the MPLS core. When the packet reaches the customer's router, the final remaining label has been popped from the label stack by the penultimate device on the route.

In order to carry information about VPN sites across a MPLS core, there is the option to 'piggyback' traditional routing protocols like BGP. Internal BGP is commonly encountered in this role, and BGP connections are established between the devices located on the edge of the MPLS infrastructure to relay information about VPNs.

Note that even though in this paper an IP network running over Ethernet is assumed, MPLS is not limited to these technologies. In fact, service providers increasingly implement MPLS to complement technologies like ATM and SONET. Also, MPLS allows for traffic engineering (TE) and even for VPNs crossing multiple providers. These areas are not covered in this paper.

Where are the Security Issues?

Devices outside the Core

Label Information Disclosure - The segregation of traffic and the traffic engineering within a MPLS infrastructure is based on the labels attached to the data packets. If the correct labels are known, they can possibly be attached to data packets before they are sent to the MPLS device, potentially allowing for two attack scenarios to be realised: Rogue Path Switching and Rogue Destination Switching.

Rogue Path Switching - If traffic follows a path that it was not intended to, we can call this path a 'rogue path'. If attackers outside the MPLS core were to know the label information for such a rogue path, attaching those labels beforehand could allow them to predetermine the path of their traffic along that rogue path. That way, they could be able to circumvent the traffic engineering setup of the service provider, for example to ensure that their online gaming traffic is forwarded along the parts of the infrastructure originally reserved for real-time video conferencing of a business.

Rogue Destination Switching - If traffic reaches a destination host which it was not intended to, we can call this destination a 'rogue destination'. If malicious users outside the MPLS core were to know the label information for such a rogue destination, attaching those labels beforehand could allow them to predetermine the destination of their traffic to be that rogue destination. That way they could be able to circumvent the traffic segregation setup of the service provider, for example to reach a server with traffic generated by remote exploit code.

Enumeration of Labels - If an MPLS device accepts labelled packets from outside the core, an attacker could be able to enumerate labels, potentially allowing for two attack scenarios to be realised: Enumeration of Label Paths and Enumeration of Targets. For either of these attacks to work, a label brute-forcing mechanism is derived which attaches incrementing labels (or label stacks) to a type of packet to which a reply can be expected. TCP SYN packets or ICMP Echo Requests are good examples.

The brute-forcing mechanism attaches the label, encodes the actual label in a portion of the packet that allows it to be preserved in the corresponding reply, for example the TCP sequence number. This is necessary because the reply will have all labels remove by the MPLS device. Then the packet is sent and all replies are captured.

Enumeration of Label Paths -If a target's IP address was known and knowledge of the labels for the LSP to reach it is desired, a fixed IP address could be used for the packets sent, then the labels incremented until a reply from the target was received. The reply would then be decoded to retrieve the preserved label switching path information

Enumeration of Targets - It might be desirable to locate a certain type of target on an MPLS network, for example all web servers. If this is the case, the process is analogous to the one described above, but in addition, the target TCP port number is always set to 80 and the target IP address is incremented over time.

It should be noted that both of the previous attacks are likely to require a significant amount of time given the amount of packets that might need to be sent.

Label Information Base Poisoning - Label Distribution Protocols are generally not authenticated. This means that if an MPLS device accepts LDP routing information from the outside, it might be possible for an attacker outside the core to manipulate the Label Information Base (LIB) of one or more MPLS devices. With this technique, an attacker could realise any of the following attacks: Denial of Service conditions and 'Malicious Collaborator'.

Denial of Service - The Label Information Base could be manipulated by an attacker in such a way as to inject paths into the network which cause Denial of Service conditions. An example for this would be to redirect traffic with real time requirement into congested paths, effectively rendering such services useless.

Malicious Collaborator - If attackers can poison the LIB of an MPLS domain, a device under their control might be established as a member of that domain. Taking advantage of this situation, the attackers might change the LIB to have 'interesting' traffic forwarded to a specific device, where this traffic can then be captured and stored for later perusal before forwarding it back into the MPLS infrastructure.

Unauthorised Access to the LER - If the network device (Label Edge Router) which provides access to the MPLS network for the customer, has not been adequately hardened, with respect to security, then unauthorised access can be gained, which could provide details of connectivity to the core infrastructure, e.g. Label Distribution information.

Devices inside the Core

An attacker might be able to physically compromise the infrastructure and place a device on the inside of the core, but without the ability to modify the MPLS devices themselves. An example for such a compromise would be connecting a laptop to a LSR's span port to intercept the traffic passing through the device.

All the attacks that were described above in 'Devices outside the Core' are of significance from inside the core in similar ways. In addition, the following attacks can be considered valid for an inside attacker only.

Plain IP traffic is still being forwarded - MPLS-enabled devices, if so configured, will still forward unlabeled IP traffic inside the core. This fact could be used by attackers inside the core to reach other core devices. The traffic engineering and VPN capabilities would not protect against this type of attack.

Forwarding traffic from the core to the outside - An attacker inside the core can still forward traffic outside the core, even if no plain IP traffic is being forwarded throughout the core, under the assumption that the labels needed to traverse a LSP are known.

When the attacker captures traffic e.g. on a span port, this traffic usually has had the labels removed by the LSR. In this case, the attacker can forward the traffic e.g. in the following way:

• The captured packet is encapsulated as the payload of an UDP packet with the desired target IP address and port of the receiver appropriately configured. The sender IP address and port are spoofed.

• The packet is then labelled and sent out to the MPLS device. MAC address spoofing might be required at this point if MAC-based filtering is implemented.

• The packet will now be forwarded through the infrastructure and received by the listener. The listener strips off the UDP header of the received packet and now holds an exact copy of the packet captured in the core.

Note that this attack removes the need for the attacker to retrieve up the packet capture device at a later point to recover the data.

Note also that the labels for the LSP in question need to be known. An enumeration attack to identify the details of a LSP was outlined in the previous section. If we can further assume that pre-labelled packets are accepted from the interface the inside attacker is located on, the forwarding of traffic across VPNs becomes feasible, since a definition of an MPLS VPN is based on traffic flow control, which in turn is based on labels.

Implementation Vulnerabilities

As with every networking technology, implementations differ across devices from different manufacturers. While there does not appear to be a publicly known security weakness in any MPLS implementation so far, the lack of documentation of security evaluations and tests might give reason to assume that such tests have been performed only very sparingly. Given that MPLS is a technology which is increasingly implemented by service providers, it would be reasonable to begin to focus on vulnerability testing of MPLS implementations. Such testing should follow clearly defined methodologies and should include, but probably not be limited to: fuzzing of input values; handling of input which is outside the limits of technological specifications and RFCs; standards compliance and interfacing of the MPLS plane with other parts of the LSR, for example the IP forwarding plane.

What can be done about these issues?

Confidentiality

Confidentiality in MPLS networks can refer to a number of areas, including confidentiality of the Label Information Base (LIB) and confidentiality of the traffic passing through the infrastructure.

Knowledge of the LIB can lead to a number of security issues, as outlined above, if the LSR accepts labeled packets from hosts outside the core. To mitigate brute-force enumeration of label values, it must be ensured that no labeled packets are accepted from outside the MPLS infrastructure.

MPLS is commonly advertised as providing VPN functionality. But unlike common VPN technology, for example IPSec or SSL VPNs, MPLS VPNs do not provide any traffic confidentiality. If an attacker was to capture traffic - e.g. on a span port on the LSR - they would be able to read the data just as they would on a traditional IP network. The solution to this problem is to use encrypted protocols, a typical example being HTTPS instead of HTTP, or to implement IPSec tunnels over the MPLS VPN.

An interesting feature of MPLS allows the network operators to hide details about their MPLS core. While a packet is traversing the network, only its labels are subject to manipulation. This means that header fields like a packet's TTL (time to live) do not change over time. Even though the MPLS Architecture RFC says that the MPLS egress device should adjust the original packet's TTL according to the number of hops traversed in the MPLS core, ignoring this requirement offers the opportunity to collapse the entire core into a single hop, e.g. along a user's traceroute . Note that tools like MPLS ping and MPLS traceroute are still available to the operator for diagnostic purposes.

Network operators should ensure that all devices and interfaces that are accessible by customers should be adequately hardened with respect to security to ensure that excessive information leakage associated with the network infrastructure is minimised.

Integrity

MPLS relies on trusted input to build up a Label Information Base. Based on this LIB, packet forwarding decisions are made. LDP information and updates should only be accepted from trustworthy sources. This can be ensured by two mechanisms:

Firstly, LDP updates must only be accepted from interfaces on which another LSR is known to reside. More specifically, this means that clients outside the MPLS core should not be able to action LDP updates.

In addition, to ensure that label information has not been altered by an attacker, authentication mechanisms need to be in place to protect the Label Distribution Protocol of choice within the MPLS network. LDP and the IP routing protocol BGP which can be used for label distribution offer varieties that employ MD5-based authentication. Wherever possible, these authentication mechanisms should be implemented to ensure the integrity of label information.

Availability

The idea of not accepting Label Distribution Protocol updates from unauthorized clients is also relevant to availability, since a 'malicious collaborator', as described above, could redirect traffic flows inside the core by making bogus updates. Such updates should only be accepted from authorised members in the MPLS domain.

Attention should be paid to the fact that the more complex a MPLS infrastructure becomes, the more protocols are likely to be involved, which tend to be classical IP-based protocols and which are therefore subject to the classical problems of IP-based protocols. One example is the usage of BGP for the establishment of routes between VPN sites. The involvement of these protocols means that they need to be secured separately and in conformance with common best practice regarding these protocols.

Finally, network operators should maintain devices within the core infrastructure at the most recent security patch level, as new vulnerabilities are constantly discovered in software and hardware. Vulnerabilities might also be identified within MPLS switches even though they might affect non-MPLS functionality of the same device.

Sample Tools

To complement this MPLS Security Overview paper, IRM have developed a small suite of tools which can be used to demonstrate some of the security issues that were identified in this paper. The suite is called ' irm-mpls-tools' and is available from the IRM website under the terms of the GNU General Public License.

At the point of writing, the package contains the source code for the following two tools, along with documentation and examples:

• 'mpls-fwd' , a MPLS forwarding 'sniffer'. This tool obtains packets from e.g. a LSR's span port, encapsulates them in an UDP packet, attaches MPLS labels and re-injects them back into the network. The main purpose of this tool is to sit on the MPLS core and sniff traffic from one MPLS VPN, and forward it out to a listener on another VPN.

• 'mpls-lbf' , a MPLS label brute-forcer designed to enumerate the labels used along a Label Switching Path (LSP). currently, this tool is not provided with an integrated listener, so a 'friendly' host on the receiving end will need to be configured. This tool works from the inside of the MPLS core as well from a misconfigured outside network.

While none of these tools offer the capability to undermine any of the fundamental security promises of MPLS, they can be used to demonstrate the importance of a well-configured and hardened MPLS core infrastructure.

Author - Thorsten Fischer - IRM Plc Technical Consultant