Cisco - Analysis and Comparisons of MPLS-Based IP VPN Security

Enterprises are replacing their Layer 2 virtual private networks (L2VPNs), such as Frame Relay and Asynchronous Transfer Mode (ATM), with Multiprotocol Label Switching (MPLS)-based VPNs, spurred by the service benefits and potential cost savings. Before migrating, enterprises need assurance that MPLS VPNs offer comparable network security to L2VPNs. Specific concerns include whether data and routes can pass reliably and unhindered to all appropriate endpoints, how MPLS VPNs can completely separate data and routes between enterprise customers in a shared network infrastructure, and the overall security integrity of the MPLS-based IP VPN.

"MPLS as next-generation networking: MPLS is widely viewed as the next-generation network services, which will replace Frame Relay and also do what was intended to be done by ATM—deliver multiple, guaranteed service levels over a single network infrastructure."¹

MPLS-based VPNs do, in fact, provide comparable security to L2VPNs such as Frame Relay and ATM. This white paper, written primarily for enterprise users who are considering or have recently migrated to MPLS VPNs, analyzes the security aspects of the Internet Engineering Task Force (IETF) RFC 2547bis MPLS IP VPN architecture, especially in comparison with other VPN technologies such as Frame Relay and ATM. The first section of this white paper defines general requirements for secure VPN services and evaluates MPLS VPN security against these requirements. The second section examines deployment options for MPLS VPNs, presenting the implications of each architecture for implementation, network security, and operation. The white paper concludes with a set of criteria that enterprises can use to evaluate MPLS VPN service offerings.

Enterprise Security Requirements in a Shared Network Environment

Enterprises that use VPNs in a shared network environment as their wide-area network, and rely on it for mission-critical applications, have certain basic security requirements. These requirements apply whether the shared network infrastructure is based on a L2VPN, such as Frame Relay or ATM, or a Layer 3 MPLS-based VPN technology. Note that some of these requirements pertain to the cost-effectiveness of the shared network environment rather than to network security itself.

Ability to Maintain Existing Network Addressing Plans

To help ensure a smooth, nondisruptive transition to shared networks while containing costs, enterprises should not need to make major configuration changes to desktops or servers. For example, if the enterprise presently uses a private addressing plan for the network, it should have the option to retain the same addressing plan when it migrates to a shared network environment.

What's more, multiple enterprises that choose to use the same public or private addressing plans should each have the option to retain their existing plans as they migrate to a VPN service in a shared network environment, with no effect on security. That is, a packet addressed to a host a.b.c.d. within a given VPN should not be able to reach a host of the same address in another VPN or the core of the shared network.

MPLS allows distinct IP VPNs to use the same address space, including private address spaces as defined in RFC 1918. It enforces routing separation by adding a 64-bit route distinguisher to each IPv4 route, so that even a shared address appears unique within the MPLS core (Figure 1). With this extended address, sometimes called a VPN-IPv4 address, enterprises are spared the need to change their current addressing schemes, even if other organizations in the same shared network infrastructure use the identical scheme.

VPN-IPv4 Address Combines a 64-Bit Route Distinguisher and a 32-Bit IPv4 Address

"Using MPLS, VPNs have become much easier to deploy and scale. This technology not only creates a more efficient network, it allows service providers to accommodate virtually any customer's requirement for remote access, intranets, extranets, and Internet access."²

Data and Routing Separation Between VPNs

It is a requirement for enterprises that the address space between the MPLS core and all VPNs on the same shared network be independent, so that each customer can use the same address space without interfering with other customers. That is, every VPN customer and the core itself must be able to use the entire IPv4 address range completely independently. Similarly, data traffic from each VPN must remain separate, never flowing to another VPN. A related requirement is that routing information for one VPN instance must be independent from any other VPN instance and from the core. This requirement applies as well to distribution and processing of routing information.

Routing Separation

To achieve routing separation among VPNs, MPLS VPNs apply the following principles:

•

Each VPN is assigned to a Virtual Routing and Forwarding (VRF) instance—Every provider-edge router maintains a separate VRF instance for each connected VPN. Each VRF on the provider-edge router is populated with routes from one VPN, either through statically configured routes or through routing protocols that run between the provider-edge and the customer-edge router. Because every VPN is associated with a separate VRF, there is no interference among the VPNs on the provider-edge router.

•

Unique VPN identifiers—To maintain routing separation across the core to the associated provider-edge routers, unique VPN identifiers such as the route distinguisher are added to the multiprotocol Border Gateway Protocol (BGP). VPN routes are exchanged across the core only by multiprotocol BGP. This BGP information is not distributed again to the core network, but only to the associated provider-edge routers, which keep the information in VPN-specific VRFs. Thus, routing across a MPLS network remains separate for each VPN.

Traffic Separation

MPLS-based VPNs adhere to the "true peer VPN" model—that is, they perform traffic separation at Layer 3 through the use of separate IP VPN forwarding tables. MPLS-based VPNs enforce traffic separation between customers by assigning a unique VRF to each customer's VPN. Forwarding within the service provider backbone is based on labels; MPLS sets up label-switched paths (LSPs), which begin and terminate at the provider-edge routers. (Normal routing, in contrast, is performed by customer-edge routers). The provider-edge router determines which forwarding table to use when handling a packet because each incoming interface on a provider-edge router is associated with a particular VPN. Therefore, a packet can enter a VPN only through an interface that is associated with that VPN.

By maintaining separation among addressing plans, routing, and traffic, the MPLS IP VPN core network architecture offers the same security as comparable ATM- or Frame Relay-based L2VPNs. It is not possible to intrude into other VPNs or the core through the MPLS IP VPN network, unless this capability has been specifically configured.

"Virtual Router" Principle

Figure 2 illustrates the concept of a "virtual router," which is central to MPLS. MPLS uses a unique VRF instance on the provider-edge router for each connected customer or group of customer sites, allowing customers to use either a global or private address space in each VPN. Each customer belongs to a particular VPN, so the only requirement is that the address space be unique within that VPN. Uniqueness of addresses is not required among VPNs except when two VPNs that use the same private address space want to communicate with each other.

•

Rules that control the import and export of routes from and into the VPN routing table

•

A set of routing protocols and peers, which provide route information to the VPN routing table

•

Router variables associated with the routing protocol used to populate the VPN routing table

Concealment of the Core Infrastructure

Concealment of the core infrastructure from the outside world renders the network much more difficult to attack—an important consideration for enterprise customers because it affects VPN service availability. When the core is concealed, the provider-edge and provider elements of the network are not visible to outside networks, including the Internet and any other connected VPN. Separation of the MPLS core and VPN networks typically makes it impossible to send traffic directly to a core router—and thus, impossible to make direct attacks. Examples of well-concealed infrastructures are ATM and Frame Relay networks. Note that hiding information is not, on its own, an effective security tactic, and should not be a factor in selecting one service provider over another. Concealment simply makes the network more difficult to attack.

MPLS uses two concealment techniques—filtering packets and not revealing network information to the outside—to help hide the core infrastructure. Extensive packet filtering prevents exposure of any information about the VPN customer internal network or the MPLS core to the outside, making attacks much more difficult. In addition, MPLS does not reveal unnecessary information to the outside, not even to customer VPNs. Because only the provider-edge routers contain VPN-specific information, it is not necessary to reveal any internal network topology information. Rather, the service provider only needs to reveal the address of the provider-edge router, which is required by dynamic routing protocols between the provider edge and customer edge. Alternatively, static routing can be configured between the provider edge and customer edge, to keep the MPLS core completely hidden.

Customer VPNs do need to advertise their routes to the MPLS core, to help ensure they can be reached across the MPLS network. Advertising routes does not compromise network security because the information known to the core is about network routes, not specific hosts, which offers a degree of abstraction. In a VPN-only MPLS network—one without shared Internet access—the security is equivalent to that in existing L2VPN models, such as Frame Relay or ATM networks, in which routing information about the VPNs can also be seen on the core network.

In a VPN service with shared Internet access, the service provider typically announces the routes of customers that want to use the Internet to upstream or peer providers. To translate the private address space from the customer's network, the service provider can announce routes using a Network Address Translation (NAT) function. In this case, the enterprise customer reveals no more information to the general Internet than it would with a general Internet service. Core information is not revealed, except for the peering addresses of the provider-edge routers that peer with the Internet.

In summary, in a pure MPLS-based VPN environment, without Internet access, core network and addresses information concealment is comparable to that in Frame Relay or ATM networks. Thus, attackers are thwarted because no addressing information is revealed to third parties or the Internet. If an enterprise customer chooses also to access the Internet via the MPLS core, the customer reveals no more of its addressing structure than it would for a normal Internet service.

Resistance to Attacks

Resistance to attacks on a corporate network is essential for business continuity. Therefore, it is important for enterprise customers that the service provider ensures that its core network routers cannot be reached from outside the network to perpetrate a denial of service (DoS) attack. Service providers prevent their routers from being reachable by using packet filtering, and optionally by hiding addresses. Use of access control lists (ACLs) limits access only to the port(s) of the routing protocol, and only from the customer-edge router.

The following discussion of resistance to attacks in the MPLS core network focuses on attacks from the outside—that is, the Internet and connected VPNs. Any network can be attacked from the inside, by people who have logical or physical access to the core network. No particular layer or protocol grants any special protection against inside attacks.

Because it is not possible to directly intrude into MPLS VPNs, attackers might attempt to attack the MPLS core and use it to attack the VPNs. There are two basic ways the MPLS core can be attacked: by attacking provider-edge routers directly, or by attacking the signaling mechanisms of MPLS. Both types of attacks can be repelled by proper router configuration.

To attack an element of a MPLS network, the attacker must know its address, which is hidden from the outside world. Therefore, an attacker must resort to guessing at core router IP addresses and sending packets to these addresses. Unfortunately for the attacker, address separation mechanisms in MPLS result in each incoming packet being treated as belonging to the address space of the VPN customer. Therefore, it is not possible to reach an internal core router even through IP address guessing. The sole exception to this rule is the peer interface of the provider-edge router, which is known. The following paragraphs explain how service providers can prevent direct attacks to the interface of a provider-edge router.

Static Routing Considerations

With static routing, the provider-edge routers are configured with static routes to the networks behind each customer-edge router, and the customer-edge routers are configured to statically point to the provider-edge router or other parts of the VPN, usually a default route. The static route can point either to the IP address of the provider-edge router, or to an interface of the customer-edge router, such as serial0. With dynamic routing, in contrast, a routing protocol, such as Routing Information Protocol (RIP), Open Shortest Path First (OSPF), or BGP, is used to exchange routing information between the customer edge and the provider edge at each peering point.

In the case of a static route from the customer-edge router to the provider-edge router, which points to an interface, the customer-edge router does not need to know any IP addresses in the core network, not even the address of the provider-edge router. Although this option has the disadvantage of requiring a more extensive static configuration, it is ideal from a network security perspective. An ACL can be configured on the provider-edge router to block all traffic toward it, so that effectively the router does not accept any packet from the customer's site. This makes it impossible to intrude either from the customer side or the Internet.

Dynamic Routing Considerations

In all cases where dynamic routing protocols are used, each customer-edge router needs to know at least the router ID, also called the peer IP address, of the provider-edge router in the MPLS network, and therefore stores a potential destination for an attack. For example, various services on the router might be attacked. In practice, service providers can limit access to the provider-edge router over the customer-edge-to-provider-edge interface by taking advantage of the routing protocol, in the following ways:

•

Use ACLs to limit access only to the port(s) of the routing protocol, and only from the customer-edge router. In addition, no access other than that of the customer-edge should be allowed to the provider-edge router in the inbound ACL on each customer-edge interface.

•

Where available, configure Message Digest MD-5 authentication for routing protocols. MD-5 authentication is available for BGP (RFC 2385), OSPF (RFC 2154) and RIP2 (RFC 2082). It prevents packets from being spoofed from parts of the customer network other than the customer-edge router.

•

Where available, configure parameters of the routing protocol to further strengthen security. For example, the number of routing interactions should be limited, if possible. In BGP this can be accomplished through dampening. BGP provides the most advanced security capabilities for customer-edge-to-provider-edge routing, and should be preferred over other routing protocols if possible.

•

Configure a maximum number of routes accepted per VRF. This helps to ensure that a single VPN cannot flood the provider-edge router with too many routes.

In summary, while it is impossible to intrude from one VPN into other VPNs or the core, it is theoretically possible to exploit the routing protocol to execute a DoS attack against the provider-edge router. This, in turn, might have a negative effect on other VPNs on the same provider-edge router. For this reason, the service provider must secure its provider-edge routers very tightly, according to best practices, especially on their interfaces to the customer-edge routers. With these security measures in place, the only possible attack is a DoS attack against the routing protocol itself. If this occurs, BGP has multiple countermeasures to help ensure stability, such as prefix filtering and dampening. In addition, service providers can easily track the source of DoS attacks. When static routing, not dynamic routing, is configured between customer-edge and provider-edge routers, even this one theoretical attack point on the provider-edge router is eliminated, effectively securing the MPLS core against intrusions and DoS.

Impossibility of VPN Spoofing

Both Layer 2 and Layer 3 VPNs must be resistant to impersonation attacks, such as packet spoofing and replay attacks. To launch a VPN spoofing attack, the attacker provides false information about their identity to obtain unauthorized access to a VPN and its associated services. The attacker usually generates packets with bogus source addresses. Impersonation of devices is attempted by sending data packets that the receiver believes are valid but might have been spoofed. Typically, this type of attack is used to change routing information, gain access to authentication sequences, and then use this information to attain unauthorized access.

On IP networks, IP source address spoofing has been extensively abused by hackers and is a major security concern. In an MPLS environment, it is possible for a VPN customer to do IP source address spoofing, but because there is a strict separation between VPNs and between a VPN and the core, it is not possible to use this mechanism to attack other VPNs or the core. IP spoofing of this nature remains within the VPN where it originated.

Label spoofing is not possible in an MPLS environment: The interface between any customer-edge router and its peering provider-edge router is a pure IP interface without labels. If a labeled packet is sent from a VPN to a provider-edge router, the provider-edge router automatically drops it.

Optional Cryptographic Security Features: Authentication, Confidentiality, Integrity, Anti-Replay

In certain countries and industries, the law or regulatory agencies require that companies encrypt their customers' personal data when that data is sent over a public network, whether the infrastructure is Frame Relay, ATM, or MPLS. Companies in these situations—or that have extremely strict security requirements—can use IP Security (IPSec) in conjunction with their core network infrastructure. Note that MPLS and IPSec are complementary technologies that work very well in combination. IPSec can be provisioned from customer edge to customer edge either by the service provider or by the enterprise.

Table 1 compares MPLS to L2VPN technologies such as Frame Relay and ATM with respect to key security features, and Table 2 summarizes MPLS VPN myths and facts.

Table 1 Comparing MPLS Security Features to Frame Relay and ATM
SECURITY FEATURE	ATM/FR	MPLS
Address space separation	Yes	Yes
Routing separation	Yes	Yes
Resistance to attacks	Yes	Yes
Resistance to label spoofing	Yes	Yes

Table 2 MPLS VPN Myths and Facts
Myths	True or False	Explanation
"MPLS is IP-based and, therefore, intrinsically insecure"	False	MPLS augments native IP-based networks with a broad spectrum of data separation, route separation, packet filtering, and network concealment mechanisms. MPLS-based VPNs offer the same security as traditional VPN types, such as Frame Relay and ATM. An example of a popular MPLS-based service is company intranets.
"One MPLS VPN customer can intrude into another customer's VPN"	False	MPLS VPNs are completely isolated. It is impossible to intrude into a VPN either from the Internet or another VPN.
"MPLS VPNs are susceptible to DoS attacks from the outside"	False	Pure MPLS VPN networks are fully secured. MPLS VPNs that share access with the Internet are completely safe from DoS attacks if the provider-edge router provides VPN access only.
"Even a provider-edge router used exclusively for the VPN is susceptible to DoS attacks"	False	While this is true in theory, in practice it is false because it is very easy to identify and disconnect the offender and to prosecute.

Typical WAN Architectures and Provisioning Options

The MPLS IP VPN architecture as described in RFC 2547bis defines the interface between the provider edge and customer edge as the only external interface as seen from the service provider network. In this case, the provider edge treats the customer edge as untrusted, and only accepts pure IP packets from the customer edge. However, the IP range is treated as belonging to the VPN of the associated customer, and so the provider edge maintains full control over VPN separation.

In most MPLS VPN deployments, VPN services are offered with the option for Internet access over the same core. With Frame Relay and ATM cores, in contrast, providing both services requires two separate infrastructures, which increases costs. MPLS provides the flexibility to securely offer both VPN services and Internet access on one core, as long as the service provider takes appropriate security measures, as described in the following paragraphs.

Complete Separation Between VPN and Internet Access for a Single Site

Completely separate access for VPNs and the Internet follows the ATM and Frame Relay model, and is the most secure architectural option (Figure 3). The relative advantage of this option is resistance to DoS attacks. Even if the enterprise is the target of a DoS attack over its Internet service, the VPN service is not affected. The disadvantage of this option is relatively high cost for the enterprise, which needs to provision and maintain separate lines and routers for VPN access and Internet access.

Converged VPN and Internet Access at the Provider Edge

Some service providers offer a service in which VPN and Internet access converge at the service provider edge (Figure 4). That is, the same enterprise architecture described above—separate access lines and routers for VPN and Internet access—can map into a service provider architecture with a single provider-edge router for both VPN and Internet access. In this architecture, separation of VPN and Internet traffic by a common provider-edge router is as secure as it is with two separate VPN and Internet provider-edge routers. Resistance to DoS attacks is also effective, though slightly less than it is with completely separate access because a DoS attack from the Internet might also affect VPNs on the provider-edge router. Enterprises should, however, be aware that service providers can largely prevent DoS attacks by making the shared provider-edge router inaccessible from the Internet. Costs are slightly lower with this architecture because the provider needs to provision only one router for VPN and Internet traffic.

Single Access Line for VPN and Internet Service

The more common infrastructure components that the service provider can use for both VPN and Internet access, the lower the costs for enterprise customers. For example, the previous paragraph described a model in which the provider-edge router is shared. One of the most expensive components of the WAN service is the access line, so the service provider can cut costs by using only one access line. To be able to share a single access line for both VPN services and Internet access, the line must be logically separated. This is accomplished by configuring separate subinterfaces on both the customer-edge router and provider-edge router, as well as by providing logical separation on the line itself, using different Frame Relay logical links or different virtual LANs (VLANs), for example.

With Frame Relay configured as a delivery mechanism on the access line (Figure 5), one shared access link is logically separated into two logical links—one for VPN access and another for Internet access. Internet traffic is switched to the Internet customer-edge router while the VPN customer-edge router is maintaining separation for the VPN traffic via the VPN logical interface. That is, the customer-edge router never sees the Internet traffic on Layer 3.

The other option for logical separation of the line is to configure VRF-Lite on the customer-edge router (Figure 6). With this option, Internet and VPN traffic are kept separate through the use of two separate VRF forwarding instances. This option offers equivalent security to the Frame Relay switching option.

Architectural options that use a single access line make it impossible for an attacker to intrude into the Internet from the VPN, or from a VPN to the Internet. They are somewhat less resistant to DoS attack than options with separate access lines because the entire infrastructure—provider-edge router, access line, and customer-edge router—is shared. The risk is more theoretical than practical, however, because the service provider can control access by correctly configuring its provider-edge and customer-edge routers.

Hub-and-Spoke VPN with Internet Access

The previous sections described options for connecting a single enterprise site to a service provider's shared network. Many enterprises have hub sites as well as spoke sites—for instance, a financial institution with two or three central hub locations and hundreds of branch offices. Typically, mainly for cost and management reasons, only the central sites connect to the Internet; when spokes need Internet access, they connect via the hub sites (Figure 7). This approach enables the enterprise to control companywide Internet access at the hub sites only, saving considerable capital and operational expenses.

Enterprises that need the ability to provide Internet access to spoke sites via hub sites typically provision separate VPN and Internet access at the hub. Spokes and the hub can talk to each other through the VPN, and spokes can communicate with each other directly.

Note that Figure 7 illustrates just one example of an architecture for enterprises with multiple remote sites. MPLS provides a wide range of connectivity and service options with customer sites. Enterprises that prefer direct Internet access from all sites, including spokes, can do so, although they usually do not because of the expense and management burden of deploying a separate firewall for each site.

Questions to Ask Your ISP

To evaluate the security aspects of a service provider offering MPLS VPN services, consider the following criteria.

In principle, that MPLS can provide all types of services over the same network is an advantage because it generally translates to lower costs for enterprise customers. While a VPN-only service is most secure because there is no possibility of a DoS attack from the Internet, a shared core network is certainly secure enough for the vast majority of enterprises. It is a common practice in most MPLS deployments.

A converged provider-edge router offers just slightly higher risk of exposure to DoS attacks, because DoS attacks over the converged provider-edge router from the Internet might, in the worst case, affect VPNs. However, the level of risk is probably acceptable to most enterprises customers, and separate provider-edge routers usually come at a higher monthly cost. For both shared and separate provider-edge routers, VPN separation cannot be breached.

If a service provider follows standard recommendations for securing an MPLS network, the network and the provided VPNs are as secure as Frame Relay and ATM. The recommendations are provided in the book "Cisco ISP Essentials," available from Cisco Press� publishers at http://www.ciscopress.com. To supplement the usual security recommendations, an especially easy and effective way to secure large MPLS core networks is to place infrastructure ACLs, which block packets targeted toward the core network infrastructure, therefore making intrusions into the core network impossible and DoS attacks against the core network very difficult.

Finding Service Providers

To find MPLS service providers that offer high security standards, look for the Cisco Powered Network logo. Service providers that display the Cisco Powered Network logo are committed to using Cisco� equipment in their networks end to end and meet high standards of operational excellence and customer service and support. They supply reliable, industry-leading outsourced services that enable advanced applications based on Cisco end-to-end network equipment and technology. About 400 of the most successful service providers around the world are members of the Cisco Powered Network Program. Situated in more than 60 countries, these program members offer a wide range of services—over networks built with Cisco products and solutions—for small and large businesses alike.

For more information about the Cisco Powered Network Program, visit http://www.cisco.com/cpn. This site includes a convenient search tool for identifying a local service provider with the Cisco Powered Network designation, as well as descriptions of all of the types of services that can carry the Cisco Powered Network designation.

Conclusion

Similar to L2VPN services, MPLS VPN networks provide full address and traffic separation, and hide addressing structures of the core network and the VPNs. It is not possible from the outside to intrude into the core network or VPNs by abusing the MPLS mechanisms. Neither is it possible to intrude into a properly secured MPLS core.

There is, in fact, just one significant difference between VPNs based on MPLS and those based on Frame Relay or ATM. That is, the control structure of the core is on Layer 3. This initially raised concerns that the architecture could be open to DoS attacks from other VPNs or the Internet. And yet, as this white paper has demonstrated, it is possible to secure an MPLS infrastructure to the same degree as a comparable ATM or Frame Relay VPN service. It is also possible to offer Internet connectivity to MPLS-based VPNs in a secure manner.

The corporate network for Cisco Systems� in Europe, Middle East and Africa (EMEA) is in full production status over an MPLS network—proof that Cisco believes in the security of MPLS technology for enterprise networks.

To find a recommended service provider with an MPLS-based VPN service offering, visit:

Table Of Contents

White Paper

Analysis of MPLS-Based IP VPN Security: Comparison to Traditional L2VPNs Such as ATM and Frame Relay, and Deployment Guidelines

Executive Summary