| ID Number: T-15-4547 |
Do MPLS VPNs Deserve to Be Called Private?
5 March 2002 Neil Rickard Many enterprises are considering multiprotocol label switching for virtual private networks. This can be as private as frame relay, but enterprises must check the security of the network implementation.
* | Recipients who do not own this document will receive a summary only.
| Browse Topics
| Advanced Search
| Ask an Analyst
| Rate This Document
| Downloads:
|  | 104889.pdf (39KB) |

# Do MPLS VPNs Deserve to Be Called Private?

Many enterprises are considering multiprotocol label switching for virtual private networks. This can be as private as frame relay, but enterprises must check the security of the network implementation.

Bottom Line

Key Issues How will network services evolve to meet the changing needs of enterprises? What role will the Internet play in enterprise networks?

Many enterprises are considering using multiprotocol label switching (MPLS) for their WANs. IP-based virtual private networks (VPNs) using MPLS services are being aggressively marketed by network operators, backed by network equipment vendors (particularly Cisco Systems). Although these networks have a number of attractive features (see "MPLS VPN Services: A Better Frame Relay," T-11-5615), enterprises must carefully evaluate the level of privacy they offer. What Constitutes Private? Gartner believes that a "private" network should offer a similar degree of privacy to a traditional private network based on leased lines or frame relay. At the very least, other users connected to the network should not be able to reach the traffic in the VPN. Traffic will still be vulnerable to the operator or its staff, or to physical line tapping with "sniffer" devices. For most enterprises, this level of privacy will be adequate, however, some of the most security-sensitive enterprises, such as the defense sector and some financial services providers, have not been prepared to accept this level of risk and have encrypted their private networks. If an enterprise encrypted its frame relay networks, it will also need to encrypt its MPLS networks. Why Is This an Issue for MPLS Services? VPNs using MPLS do not create encrypted tunnels, instead they create "label-switched paths," similar to the permanent virtual circuits used between end points, based on individual edge routing tables for each enterprise. The edge routing table only contains the private IP addresses for other locations within the same enterprise, so enterprises have no access to the underlying addressing of the MPLS network. It is, therefore, impossible to send packets between one enterprise and another enterprise, or to the operator's network management systems, without the operator's intervention. Up to this point, MPLS operates in the same way as frame relay or asynchronous transfer mode (ATM). The issue with MPLS is that the underlying network is IP, not frame relay or ATM. Determining just how secure the underlying IP network is forms the key to understanding how private the MPLS VPN will be. MPLS Deployment Options Different operators have different deployment approaches to MPLS VPNs. One approach is to deploy a dedicated IP network for MPLS VPNs only. This approach is similar to, and essentially as secure as, frame relay. However, some operators may be tempted to attempt to consolidate their various IP networks and, in particular, to integrate Internet traffic with MPLS VPN traffic. They may deploy an IP network that delivers enterprise MPLS VPNs, in which Internet traffic is treated as just another MPLS VPN. Again, this approach offers essentially the same degree of privacy as frame relay. However, the complexity of running one topology for the underlying MPLS paths and another for the complex routing of the Internet has led several operators to create backbones in which MPLS traffic, in label-switched paths, is shared with native Internet traffic. This raises some serious security issues. Risks With a Shared Internet-MPLS Backbone The problem with shared backbones is that Internet hackers can attempt to gain access to the enterprise's data via the Internet. Because the enterprise's traffic travels inside label-switched paths, hackers cannot simply send traffic to the enterprise network end points. However, hackers could try to access the maintenance ports of a router carrying the traffic and take control of it. A hacker could also try to fool the router into receiving a routing table update, which would cause it to divert its traffic to a destination of the hacker's choice, or the hacker could try and attack systems connected to the routers, such as management, accounting and authentication servers. Assessing Operator Responses to the Risks of a Shared Internet/MPLS Backbone Operators can take a number of measures to address each of the threats identified here. Lock down management access to the router, limiting management to specific ports and addresses and requiring strong authentication and encryption of the management traffic Limit routing table updates to verified sources Protect their management systems behind firewalls Unfortunately, there are no established standards for such a secure configuration. Some operators have attempted to obtain certification by adapting well-established security techniques, such as the Common Criteria for Information Technology Security Evaluation. This certification is from a recognized agency, but the operators still have to define the threat profiles themselves. Therefore, such measures should be taken as a positive indicator, but one that requires further investigation by the enterprise. Some operators are also providing a security service-level agreement — again, a positive indicator, but not a substitute for detailed assessment. This assessment should be undertaken by skilled network security experts either from the enterprise itself or from a truly independent external organization (not the operator or its equipment provider). Before entrusting its traffic to an MPLS VPN using a shared backbone, an enterprise must ensure that the operator has addressed all of the security concerns listed here, and also that its staff training and procedures are sufficiently rigorous to ensure that the network will be maintained to the specified standard. Even if an enterprise is satisfied that the network operator has taken all of the appropriate measures, a shared backbone with the Internet still represents a higher risk than a dedicated backbone. Even the best operators can only guard against known threats and can never fully anticipate attacks that may be developed in the future. Only a network that is physically separate from the Internet can completely avoid this risk. Denial-of-Service Attacks In addition to security risks, MPLS VPNs may be subject to different types of denial-of-service attacks. These can be divided into backbone traffic attacks, and attacks on shared VPN resources. In a MPLS network with a shared Internet backbone, excessive traffic may not just be the result of a deliberate attack — it could be the result of a traffic spike because of a major event. Backbone traffic management can ensure that the MPLS traffic is not overwhelmed by general Internet traffic, but operators also need to protect against a single VPN consuming all of the bandwidth allocated to one or more MPLS service classes. VPN resource attacks occur when a malicious party on one VPN attempts to bring down as much as possible of the operator's entire MPLS infrastructure. This attack exploits the fact that many MPLS VPN customers share a small number of operator edge routers. The attacker attempts to crash those routers by generating infinitely long routing tables until the shared router runs out of memory or by changing routing table entries so rapidly that the router runs out of processing resources. Operators can mitigate these risks by limiting the routing table size for each MPLS VPN customer and by limiting the rate at which routing tables can be updated. In addition to satisfying themselves that the operator has taken all possible steps to mitigate denial-of-service attacks, enterprises should also ensure that their availability service-level agreement includes outages resulting from denial-of-service attacks. This will motivate the operator to address any vulnerabilities. Encrypting MPLS Where an enterprise cannot satisfy itself that an Internet shared backbone is secure (or where it encrypts all its WAN traffic anyway), it can encrypt its MPLS traffic. However, this will require the enterprise to purchase and configure a complete IP Security (IPsec) overlay network on top of the MPLS VPN. If the enterprise would not otherwise have encrypted its traffic, then this additional cost should be counted against the operator that has compromised on its backbone design. A new standard is being proposed to the primary MPLS standard body (the Internet Engineering Task Force), that would enable traffic to be encrypted between operators' edge routers without the need for a full IPsec overlay. This will increase the security of shared backbone MPLS VPNs, but will still leave traffic unencrypted over the network access lines. Is IPsec Safer Than MPLS? With all of the warnings against MPLS networks, enterprises may be tempted to think of IPsec VPNs as safer than MPLS VPNs. This is not necessarily the case. With IPsec, traffic is encrypted across the backbone and enterprises need not fear if the routers are compromised. However the end points of the IPsec network are Internet connections and, therefore, vulnerable to penetration attempts and denial-of-service attacks. Therefore, enterprises must check if the IPsec VPN end devices have been configured correctly, rather than whether the MPLS operator has secured the routers properly. IPsec and MPLS are both vulnerable to new attacks. If the IPsec VPN is being provided as a managed service, the same people may be responsible for checking the security of both MPLS routers and IPsec end devices.

Bottom Line MPLS networks with dedicated IP backbones are as private as other techniques such as frame relay. MPLS networks with backbones that are shared with Internet traffic can be configured to be almost as private as frame relay, and comparable in security to IPsec Internet VPNs. However, because there are no established standards for how to achieve this, the enterprise must make a detailed investigation itself before proceeding, and decide if it can tolerate the incremental risk.

Acronym Key ATM Asynchronous transfer mode IPsec IP Security MPLS Multiprotocol label switching VPN Virtual private networks

This research is part of a set of related research pieces. See AV-15-5757 for an overview.

| Browse Topics: Multiprotocol Label Switching Network Architecture and Design WAN Systems VPN Software |
| © 2004 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice. |

Resource Id: 353371