MPLS VPN and Security

One of the reasons MPLS VPNs, or specifically BGP-VPNs, are easy to provision is that MPLS VPNs are not connection oriented. Whereas most traditional VPN types consist of a number of provisioned point-to-point connections, MPLS is connectionless.

The connectionless nature of MPLS VPNs has many implications for the scalability of the overall MPLS network, but also for security: On an ATM network, for example, a VPN customer is typically presented with a number of virtual connections from a given router to all other routers that need to be connected. However, the customer needs to configure her router to use these virtual connections. The disadvantage here is that many virtual connections have to be configured on both the customer side and the service provider side. The advantage is that the customer has full visibility of her VPN and controls the connections. On an MPLS network, the same customer router is in most cases presented with a single connection into the MPLS network, and it is the MPLS network itself that decides where to forward packets. The customer loses the view of the connections through the core. The advantage of this approach is scalability: The provisioning complexity is reduced to a single connection for each customer router. However, the customer does not have visibility of the core network anymore. A service provider could maliciously or inadvertently introduce a router that does not belong there into the VPN of a customer. The customer might not detect this and might lose the integrity of her network.

VPN users have certain expectations and requirements for their VPN service. In a nutshell, they want their service to be private and secure. Neither concept is black or white, and the concepts need to be defined for a real-world implementation. In discussions about MPLS security, a number of questions typically arise that are outside the scope of the MPLS architecture. This means that these issues have nothing to do with the standards and can therefore not be controlled by the architecture. The following list describes these issues and explains why they are outside the scope of the architecture:

• Protection against misconfiguration or operational mistakes The standards describe the architecture, define the protocols, and recommend best practices for both the architecture and protocols. This chapter examines MPLS VPNs based on this architecture. This architecture can also be misapplied, leading to security issues. For example, as long as the PE is configured correctly according to the standard, the solution is secure. However, any operator could misconfigure a PE, thus breaking the security. This is not an architectural issue, but an operational issue.

• VPN data confidentiality, integrity, and origin authentication VPN users have no guarantee that packets are not read or corrupted when in transit over the MPLS core. MPLS as such does not provide any of the previously listed services. It is important to understand that a service provider has the technical possibility to sniff VPN data, and the VPN user can either choose to trust the service provider(s) not to use her data inappropriately or encrypt the traffic over the MPLS core (for example with IPSec, as discussed later in this chapter).

• Attacks from the Internet through an MPLS backbone If the MPLS backbone provides any Internet access to a VPN, attacks from the Internet into this VPN are outside the scope of MPLS. The task of the MPLS core is to forward packets from the Internet to the VPN, and vice versa. This includes potential attacks. It is, however, within the scope of MPLS security to ensure that an attack against a given VPN does not affect other VPNs or the core itself.

  Also outside the scope of the MPLS architecture is any kind of firewalling required for such cases.

• Customer network security Every attack that originates in a customer VPN and terminates in that same VPN is outside the scope of MPLS security. The MPLS VPN architecture forwards packets between VPN sites; it is not concerned with the nature of these packets, which could also be attack packets. This also includes IP spoofing within a VPN.

Note

When discussing the security of MPLS VPN networks, care should be taken to maintain a balanced view on the overall risks to a customer. It is irrelevant to argue about the chances of an attacker sniffing a core line if the customer network has unsecured wireless access points. It is also not important to worry about a service provider misconfiguring a PE when attackers have uncontrolled physical access to hosts in an enterprise.

Security is a question of balance: There is no point in putting extra locks on the door of your house if the windows are left open.

Many enterprises have been using VPN services based on Frame Relay or ATM in the past and are considering a move to MPLS VPNs. Unfortunately, the discussion of this topic has often been emotional and unbalanced. Table 7-1 compares all the aspects of VPN security for the various VPN technologies.

Table 7-1. Security Comparison Between MPLS and ATM/Frame Relay

	MPLS	ATM/Frame Relay
VPN separation	Yes	Yes
Robustness against attacks	Yes	Yes
Hiding of the core infrastructure	Yes	Yes
Impossibility of VPN spoofing	Yes	Yes
CE-CE visibility	Not in MLPS IP VPNs; yes for MPLS pseudowire emulation	Yes

1 Reference: http://www.miercom.com/?url=reports/&v=16&tf=-3&st=v

New MPLS users are often concerned about the fact that an MPLS VPN service has a control plane on Layer 3. The typical VPN security requirements are

• VPN separation (addressing and traffic)

• Robustness against attacks

• Hiding the core infrastructure spoofing protection against VPN spoofing

BGP-VPN (for Layer 3 MPLS VPN) permits a separation between address and data plane constructs, whereas hiding the core infrastructure (that is, the service provider or a large enterprise implementing MPLS) is paramount to overall MPLS security (as depicted in Figures 7-1 and 7-2). Note that in both examples, the vulnerable security point is between the service provider PE and customer edge connection. The amount of topological informationfor example, from the Interior Gateway Protocol (IGP)announced outside a trust domain or leaked outside a trust domain is what is important.

Figure 7-1. Address Planes: True Separation

Figure 7-2. Hiding of the MPLS Core

We discuss attack scenarios in the next section, followed by the best practices for defending against attacks.