Analyzing MPLS VPN Security

This chapter is from the book

MPLS VPN Security

Learn More Buy

This chapter is from the book

This chapter is from the book 

MPLS VPN Security

Learn More Buy

Specific Inter-AS Considerations

The drawback of RFC 2547 is that it requires a single autonomous system (AS) to provide VPNs across it. RFC 2547bis allows VPNs to be provided across several ASs and thus several service providers. The standard describes three basic models for Inter-AS connectivity (models A, B, and C) that have different security properties.

Model A: VRF-to-VRF Connections at the AS Border Routers

This model is the simplest one, as it uses interfaces or subinterfaces between autonomous system border routers (ASBRs) to keep the VPNs separate. Figure 3-7 shows this principle: the two ASBRs each hold a VRF for each VPN that is shared between the autonomous systems. The ASBRs are then connected, and subinterfaces are used to link the VRFs directly.

Figure 3-7 Inter-AS Model A

This model is equivalent in security to the standard RFC 2547 implementation because all external interfaces (seen from either AS) are IP interfaces.

In fact, an ASBR in this model behaves exactly like a normal PE router, and the configuration on an ASBR is also exactly the same as if it connected to a CE router in each VRF. Figure 3-8 shows how an ASBR in this model sees the other connections around it.

Figure 3-8 Inter-AS Model A: How an ASBR Sees Its Peers

Therefore, all the considerations from the previous sections apply also in this model: there is strict separation between VRFs, label spoofing is impossible because no labeled packets are accepted by the ASBR from the other ASBR, and the other AS cannot "see" the core.

A further advantage of Inter-AS model A is that existing provisioning systems require little or no changes to support this model because the ASBR is essentially a normal PE, with attachment circuits to untrusted routers. To the provisioning system, such an Inter-AS connection looks like a number of normal CE connections.

For the same reasons, this model is also the easiest in other aspects, such as quality of service (QoS): everything that is possible on a subinterface can be supported automatically in this model. Because consistent QoS is important, especially when several service providers are involved in the provisioning of a VPN, it is important to have clear interfaces.

A service provider can deploy this model without further security implications over the standard MPLS VPN model, just as it would deploy more CE connections.

A VPN user in a single-AS RFC 2547 network has to trust the service provider for correct implementation and operation of the core. In Inter-AS model A, the user must trust all service providers that provide parts of the user's MPLS VPN in this way, but there is no further risk of interference with third parties. The only potential risk is that a service provider connects the VPNs from the other service provider wrongly, but this problem also exists in standard single-AS MPLS networks and has to be controlled operationally.

Inter-AS model A is the most secure interconnection model, but it has scalability issues on the ASBR: the ASBR must be configured with all shared VPNs (VPNs spanning more than one AS) and thus hold all VPN routes of shared VPNs. VPNs that exist only on one AS do not need to be kept on the ASBR. Furthermore, the interface between the ASBRs is not very flexible: a new subinterface must be configured on both sides for each new shared VPN.

The limiting scalability factor in Inter-AS model A is the number of interfaces or subinterfaces required, the number of VRFs required, and the memory required to hold all the routes from the various shared VPNs. Only Inter-AS model A has VRFs configured, so VRF memory is a deciding factor between the different Inter-AS types.

Two more MPLS interconnection models are defined in RFC 2547bis, with the goal of making the interconnection between ASs more scalable. Model B removes the need for separate subinterfaces, and model C even removes the need for configuring VRFs on the ASBRs. Both models are more scalable than model A, but this scalability has security consequences.

Model B: EBGP Redistribution of Labeled VPN-IPv4 Routes from AS to Neighboring AS

Model B removes the need for separate (sub-) interfaces per shared VPN on the ASBR. Here, only a single interface is required between the ASBRs. To be able to still distinguish the data packets from each VPN, packets must now be labeled on the data plane. This essentially creates a type of "tunnel" for each VPN on the single connection, defined by the label. These labels could be configured manually, but for ease of use, the control plane controls the labels in use. The Multi-Protocol Exterior Border Gateway Protocol (MP-eBGP) is used to pass VPN routes between ASBRs, and it assigns the labels to be used for each VPN prefix.

How Model B Works

Figure 3-9 illustrates model B: On the control plane, a single instance of MP-eBGP is used, exchanging all VPN-IPv4 routes, together with the required parameters (RD, label, and so on). On the data plane, all VPN packets are labeled to distinguish the VPN they belong to. In model B, the ASBR still needs to keep all VPN routes of the exchanged VPNs, as in model A, but here there is only a single interconnection.

Figure 3-9 Inter-AS Model B

The standard for Multi-Protocol extensions for BGP (MP-BGP) is defined in RFC 2858. Although BGP only uses IPv4, MP-BGP uses the concept of an address family to enable BGP to carry VPN-IPv4 routes as a new address type. For this purpose, MP-BGP introduces two new attribute types, MP_REACH_NLRI and MP_UNREACH_NLRI, to announce and withdraw multiprotocol Network Layer Reachability Information (NLRI). The NLRI contains the VPN-IPv4 prefix (which in turn contains the RD) and the label. Example 3-3 shows how VPN label information can be seen on an ASBR.

Example 3-3. show ip bgp vpnv4 vrf A labels

PE#   sh ip bgp vpnv4 vrf A labels
   Network          Next Hop      In label/Out label
Route Distinguisher: 100:1 (A)
   10.10.10.10/32   192.168.10.10   10/12

This model makes the security between the service providers somewhat more complex. For the VPN user, however, nothing changes in comparison to model A: The VPN user must still trust both service providers, but third parties still can not interfere with this solution.

Security of Model B

To analyze the security between service providers, we examine the data plane and control plane separately.

On the control plane, there is a single MP-eBGP session between ASBRs, nothing else. Specifically, there is no Tag Distribution Protocol (TDP) or Label Distribution Protocol (LDP) running between ASBRs. This session can be and should be secured as any other BGP session: peer authentication with message digest 5 (MD5), maximum route limits per peer and per VRF, dampening, and so on. In addition, prefix filters can be deployed to control which routes can be received from the other AS. Details on how to secure such BGP sessions are discussed in Chapter 5, "Security Recommendations."

With the Chapter 5 recommendations implemented on the two ASBRs, the MP-eBGP control plane does not increase the security exposure over model A and can be considered sufficiently secure for both service provider and VPN user.

On the data plane, labeled packets are exchanged. The label is derived from the MP-eBGP session; therefore, the ASBR announcing a VPN-IPv4 prefix controls and assigns the label for each prefix it announces. On the data plane, the incoming label is then checked to verify that this label on the data plane has really been assigned on the control plane. Therefore, it is impossible to introduce fake labels from one AS to another.

This control on the data plane means that packets with labels that were not assigned to the other ASBR will be dropped; however, it is not possible to check which of the correctly assigned labels is being used.

As an example, assume that an ASBR has announced two prefixes: one from VPN A with label 20, and another prefix from VPN B with label 21. On the data plane, packets with labels other than 20 or 21 can be dropped, but it is not possible to verify that a packet with label 21 really belongs to VRF B.

However, in reality, this does not add a new security exposure: each service provider involved in the provisioning of a VPN has the power to make each VPN insecure (which is not a specific MPLS problem). This does not change when VPNs are shared. As previously mentioned, the VPN user must trust all service providers involved in the provisioning of the VPN.

There is one more potential issue to look at: Layer 2 security. All the considerations so far have been exclusively on Layer 3 and above. However, for a Layer 3 service such as MPLS VPNs to be secure, the lower layers must be secure as well. We have already discussed one Layer 1 issue: a wiretap on core lines or CE-PE lines reveals VPN data, unless encryption is used on top of MPLS.

A potential Layer 2 issue relates to using a shared switch to interconnect various MPLS networks in the Inter-AS model: if the connection between the ASBRs is provided (for example, on an Ethernet switch), Layer 2 security must be taken into consideration. This type of security threat is detailed in Chapter 4, "Secure MPLS/VPN Designs." (A quick summary here: VLANs can usually be assumed to be separate from other traffic on the switch, but within a VLAN there are security issues such as a third party inserting labeled traffic.

In comparison with model A, model B is more scalable in that it requires only one connection between the ASBRs over which all VPNs are propagated. For this to work, MP-eBGP must be run between the ASBRs, and traffic is exchanged with labels. This can be secured adequately, but with more configuration the likelihood of error and a subsequent security breach increases.

Model B still requires each ASBR to hold the VPN routes for each shared VPN, and this is another scalability concern. To solve this issue, model C was invented.

Model C: Multihop eBGP Redistribution of Labeled VPN-IPv4 Routes Between Source and Destination ASs, with eBGP Redistribution of Labeled IPv4 Routes from AS to Neighboring AS

Model C was introduced in RFC 2547bis to remove the requirement to hold VPN-specific information on the ASBR. In this model, the VPN-specific information is propagated between the ingress PE on AS 1 and the egress PE on AS 2 directly. To improve scalability further, it allows the usage of route reflectors (RRs). ^[6]

How Model C Works

Figure 3-10 depicts model C without RRs. The PEs of both autonomous systems have visibility of each other through a multihop MP-BGP connection, and they exchange the VPN-specific information (VPN-IPv4 NLRIs, labels, and so on) end to end, using the loopback addresses of the PEs without involving the ASBRs. This means that the ASBRs do not need to hold VPN-specific information.

Figure 3-10 Inter-AS Model C, Without Route Reflectors

The ASBRs need only to exchange host routes (/32) to the PE routers involved in the VPN, with the labels needed to get there. In this way they facilitate the multihop BGP connection between the PE routers on both sides.

A Label Switch Path (LSP) is built from the ingress PE router in AS 1 to the egress PE in AS 2 (using loopback addresses). VPN traffic uses this LSP to reach the other AS. As far as the data plane is concerned, the ASBRs act as P routers, with no knowledge about the VPNs concerned. Also, between ASBRs the VPN traffic looks like traffic between P routers: each data packet is prepended with the VPN label and then with an egress-PE label.

Model C can be further scaled by using route reflectors in each AS. Figure 3-11 depicts this mode of operation. Because many networks require RRs internally, MPLS VPN model C also usually uses RRs.

Figure 3-11 Inter-AS Model C, with Route Reflectors

Here, the PEs in both autonomous systems maintain an MP-BGP peering only with the RRs in their own AS. The RRs in turn maintain an external MP-BGP peering. LSPs are established end to end from ingress PE to egress PE, as before.

Security of Model C

The security of this model is considerably more open than in models A and B.

On the control plane, model C has two interfaces between autonomous systems:

• The ASBRs exchange IPv4 routes with labels via eBGP. The purpose is to propagate the PE loopback addresses to the other AS so that LSPs can be established end to end. This route exchange and the whole BGP session can be controlled as in standard BGP. On this connection, no VPN information is passed on—only information relevant to the two ASs. Details on how to secure this connection are explained in Chapter 5, "Security Recommendations."
• The RRs exchange VPN-IPv4 routes with labels via multihop MP-eBGP. The prefixes exchanged can be controlled through route maps, equally the route targets. This makes it possible to ensure that only the required VPNs are exchanged, and within the VPNs, only specific prefixes.

On the data plane, the traffic exchanged between the ASBRs contains two labels:

• VPN label— Is set by the ingress PE to identify the VPN
• PE label— Specifies the LSP to the egress PE

Model C is considerably more open in terms of security than the previous models, for the following reasons:

• To be able to establish end-to-end LSPs, the service provider must be able to reach all PEs of the other AS, which hold connections of shared VPNs. This can be a considerable number of PEs, exposing important parts of the normally internal infrastructure of an AS to the other AS. This also means that considerations that are usually local to an AS in terms of addressing need to be coordinated with the other AS. It also means that traffic can be sent to a number of internal addresses from the outside, making possible attacks from the outside. The recommendation is to filter IP packets into the core as tightly as possible to prevent these issues. Labeled packets cannot be filtered currently.
• The ASBR does not hold any VPN information. This is a scalability advantage, but at the same time it prevents the ASBR from checking the VPN label for its validity. This means that it is impossible to verify the VPN label in the data path. (In model B, the ASBR holds this information and can therefore validate the VPN label.) The egress PE cannot verify the packet anymore because at this point the origin of the packet can no longer be determined.

Considering these reasons, a potential attack could be AS 1 sending labeled traffic into AS 2, where the top label represents the label to a valid egress PE in AS 2. AS 1 holds PE labels for all those PEs in AS 2, on which it has shared VPNs. However, because the VPN label cannot be checked by the ASBR, AS 1 could send packets with random VPN labels into AS 2 without AS 2 having a way to block this. Figure 3-12 illustrates this vulnerability. AS 1 has an LSP to the egress PE in AS 2. This PE has two VPNs configured: VPN A, which is shared with AS 1, and VPN B, which is not shared with AS 1. By sending the packet shown in Figure 3-12 with a VPN label for VPN B, the packet will be forwarded into VPN B. At the time of writing this book there was no solution to this issue.

Figure 3-12 Case C Security Issue

But how dangerous is this issue? First of all, AS 1 would need to know the VPN label for VPN B. The MPLS VPN network does not expose the label externally, so there are two ways of getting it: by espionage, or simply by trying the entire label space. A label has 20 bits, yielding 2²⁰ = 1,048,576 potential label values. Assuming a single packet attack with a 500-byte packet size, in the worst case an attacker would need to send 524 MB, which would take approximately 7 minutes on a 10 Mbps link, and 9 hours on a 128 k link. Note that in practice this number would be statistically smaller, and also, label numbering is not random, so intelligent guessing could reduce this number significantly.

Then, a malicious user in AS 1 could only send traffic into the VPN, but not receive a reply. However, there are a large number of examples in the history of security where a single unidirectional packet was enough to propagate a worm, for example. So while this limits the scope of an attack, it does not rule it out. In any case, the potential attacker would not receive feedback as to whether the attack was successful.

Therefore, it is not easy to carry out a sophisticated attack against a VPN from a given AS. But a single-packet unidirectional attack, as frequently used in the propagation of worms, is possible, even though statistically unlikely.

The consequence of this is that in model C the service providers must trust each other also in areas that are not shared. Therefore, model C is most commonly used today where a single operator uses several ASs on the backbone. In this case, implicit trust exists between the ASs because they have the same operational control.

As in model B, Layer 2 security between the ASBRs is extremely important. Therefore, here again is the recommendation from the previous section:

Since the various Inter-AS connectivity options are confusing and their differences often subtle, the next section puts all options in context for easy comparison.

Comparison of Inter-AS Security Considerations

Table 3-1 compares the three Inter-AS connectivity options in simple terms.

Table 3-1. Properties of Inter-AS Models

So which Inter-AS option is the right one for you? Here are some decision guidelines, from a security perspective:

• If the number of shared VPNs and prefixes is small, consider model A. ("Small" is a relative term, depending on your ASBR capabilities.) It is simple, most provisioning systems easily support it, and it is the most secure option because of its simplicity: the more complex a solution, the more risk for errors and security issues. Model A has almost nothing to configure and no global protocols running (only possibly inside the VRFs). In security, nothing can beat simplicity! If the number of VPNs and prefixes is too large for model A, consider one of the other models.
• If you are peering with another operator, that is, the other AS is not under your direct control and you cannot fully trust it, use model B. If you cannot fully trust the other side, you need to control the interface. Model B has a clear-cut interface, which is relatively easy to control. Model C is not recommended here.
• If you are a single operator controlling all involved ASs, feel free to use model C. In this case, all your ASs behave a bit like a single AS, where ingress and egress PEs are in direct contact. The boundaries between ASs are less clear, but if there is one operator for all ASs, this is controllable.

A number of risks exist in any environment and are independent of the Inter-AS model:

• Service provider 1 sends faked or crafted IP packets into any shared VPN on AS 2: this cannot be prevented. The VPN user must trust both service providers.
• Service provider 1 can bring a fake CE into any shared VPN, endangering the integrity of that VPN: this also cannot be prevented. Again, the service providers are trusted.
• A service provider can sniff traffic on any trunk, endangering the confidentiality of the VPN data. Here, too, the VPN user must trust the provider.

This appears to be quite an insecure model, but in fact the same risks exist in any VPN technology, although sometimes these trust issues are not clear. The service provider must always be trusted. The only solution if the service provider cannot be trusted is to provide additional security on top of MPLS, such as through IPsec. Chapter 6, "How IPsec Complements MPLS," describes this option.

Another model involving several providers is the Carrier's Carrier model. It allows a hierarchical structure, where a service provider resells a service from an MPLS provider. The next section covers this case.