There are two primary components of the inter-provider MPLS VPN architecture: Carrier Supporting Carrier (CsC) and Inter-AS VPNs. CsC is a hierarchical VPN model that enables downstream service providers (DSP), or customer carriers, to interconnect their geographically dispersed IP or MPLS networks over an upstream SP’s MPLS VPN backbone.
This eliminates the need for customer carriers to build and maintain their own private MPLS backbone.
Inter-AS is a peer-to-peer model that enables customer VPNs to be extended through multiple provider or multidomain networks. Using Inter-AS VPN techniques, SPs peer with one another and offer end-to-end VPN connectivity over extended geographical locations for those VPN customers who may be out of reach for a single SP. The threats against both of these inter-provider VPN technologies are described next.
Carrier Supporting Carrier Threats
Within the CsC model, customer carriers (or DSPs) may offer Internet or MPLS VPN services, or both, to their customers. The challenge in supporting this model with native MPLS VPNs is the potential number of IP prefixes that must be carried within the
104 Chapter 2: Threat Models for IP Networks
associated VRF table on the PE routers. Because the customer carrier is itself an SP, it may carry both the IP prefixes of its own VPN customers and the global Internet routing table if it offers Internet transit services. This potential volume of prefixes would limit the number of customers that may be supported on the PE router because VPN routes is one of the limiting factors in scaling the PE router. The CsC model reduces the number of routes carried within the CsC-PE VRF table by enabling MPLS on the CsC-PE to CsC-CE link between the backbone carrier (CsC-PE) and customer carrier (CsC-CE), as illustrated in Figure 2-16. Applying MPLS on this link eliminates the need for the customer carrier to advertise its external IP and VPN prefixes to the backbone carrier.
In this way, the CsC-PE VRF table only carries the internal IP prefixes of the customer carrier.
Within this CsC model, the CsC-PE router is not receiving IP packets from the CsC-PE but rather MPLS labeled IP packets. Label distribution between the CsC-CE and CsC-PE may be done through either MPLS LDP (RFC 3036) or BGP+Labels (RFC 3107). Using only BGP, the CsC control plane operates similarly to native MPLS VPNs. MPLS LDP provides an alternate control plane protocol for label distribution between the CsC-CE and CsC-PE.
From a security perspective, the CsC-PE is subject to the same threats as outlined in the
“Threats Against the Provider Edge” section above. Similarly, the CsC-CE is subject to the same threats as outlined in the “Threats Against the Customer Edge” section above. The customer carrier (or DSP) is itself an SP and, hence, the CsC-CE is also a core (P) router from the perspective of the DSP’s customers. The potential threats against the CsC-CE as a customer carrier core (P) router depends upon whether the DSP offers Internet transit or MPLS VPN services or both. The threats associated with both of these scenarios were described in the “Threats Against IP Network Infrastructures” and “Threats Against the Provider Core” sections above.
Despite the CsC-CE forwarding and receiving MPLS labeled data plane IP packets to and from the CsC-PE router, the CsC-PE assures routing and addressing separation of the customer carrier VPN using the same techniques outlined in the “MPLS VPN Threat Models” section above including VPN-IPv4 addressing, VRF instances, and M-iBGP.
The CsC-PEs also implement an automatic MPLS label spoofing avoidance mechanism that prevents the CsC-CE from using spoofed MPLS labels to transmit unauthorized packets into another customer VPN. MPLS packets with spoofed labels that are associated with another customer VPN are automatically discarded upon ingress of the CsC-PE. This is possible because, within Cisco IOS, the labels distributed from the CsC-PE to the CsC-CE using either LDP or RFC 3107 (BGP) are VRF-aware. Hence, CsC provides addressing and routing separation between VPNs equivalent to native MPLS VPNs.
Threats Against IP VPN Network Infrastructures 105
Figure 2-16 Carrier Supporting Carrier MPLS VPN Model
Inter-AS VPN Threats
As outlined at the start of the “Threats Against the Inter-Provider Edge” section, Inter-AS VPNs are intended to expand a single customer VPN through multiple provider networks.
Section 10 of RFC 4364 outlines several techniques to achieve this, which are widely known within the industry as options (a), (b), and (c). Each has trade-offs in terms of scalability, security, and service awareness. The following list reviews the security threats associated with each option and assumes that the interconnection between MPLS VPN networks is under the control of different SPs—hence, untrusted. Conversely, if both networks are within the control of one SP, then the security threats outlined may not apply because the interconnect may be considered trusted.
• Option (a):Within option (a), the ASBR router of each SP network effectively operates as a PE router. Each ASBR, however, sees the peer ASBR as a CE router.
A physical (or logical) interface is used for each VPN that requires inter-provider connectivity. Each interface is then configured with the associated VRF and eBGP routing. This is also applied on both ends of the link, which results in back-to-back
SP IP/MPLS Core Network
LDP
LDP
LDP
VRF1
VRF2 VRF1
VRF2
LDP LDP
LDP
LDP LDP
CsC-CE Router
CsC-PE Router PE Router CE Router
CsC- PE Router
P Router P Router
P Router
CsC-CE Router
CE Router
VPN Customer CsC VPN Customer
CsC VPN Customer VPN Customer
M-iBGP
M-iBGP M-iBGP
iBGP IP Route + Label
Distribution
IP Route + Label Distribution
106 Chapter 2: Threat Models for IP Networks
(or peer-to-peer) VRFs, as illustrated in Figure 2-17. The IP control and data planes of this model are identical to that of native MPLS VPNs. Hence, this model introduces no additional threats. Each SP network operates independently (no shared IGP) and only IP reachability between Inter-AS VPN sites is exchanged. SPs have no reachability into each other’s core networks. The most significant potential threat remains collateral damage and operator misconfiguration. However, the use of distinct interfaces per Inter-AS VPN facilitates resource management within the ASBR per VPN, which may limit any impact of collateral damage.
Figure 2-17 Inter-AS Option (a): Back-to-Back VRFs
• Option (b):Within option (b), the ASBR routers use a single M-eBGP session to exchange all Inter-AS customer VPN prefixes over a single interface between SPs, as illustrated in Figure 2-18. Although this improves ASBR scaling, it prevents resource management within the ASBR per VPN. Hence, there is a much greater risk with option (b) for one Inter-AS VPN to adversely impact connectivity of another. Also, because no VRF configurations are applied on the ASBR, MPLS label spoofing avoidance checks similar to CsC cannot be applied. Thus, routing and address separation between Inter-AS VPNs depends entirely on the peer SP, because VPN label spoofing avoidance techniques are not available with option (b). Given this set of issues, this model is deemed insecure for Inter-AS VPN connectivity between different SPs.
VPN Customer
VPN Customer
CE Router
PE Router
CE Router
VRF1
VRF2 VRF2
VRF1 VRF3
ASBR VRF4
Router
LDP
SP AS-1 SP AS-2
ASBR Router
PE Router
VPN Customer
VPN Customer CE Router
CE Router
VRF4
VRF3 LDP
Threats Against IP VPN Network Infrastructures 107
Figure 2-18 Inter-AS VPN Option (b): M-eBGP
• Option (c):Within option (c), the ASBR routers exchange only PE /32 loopback addresses and associated label information using either MPLS LDP or BGP+Labels (RFC 3107). VPN prefixes are then exchanged between route reflectors within each AS using multihop M-eBGP, as illustrated in Figure 2-19. This option requires IP reachability between each SP’s route reflectors (RR), which exposes not only the RRs but also the core networks of each peer to one another. Similar to option (b), because no VRF configurations are applied on the ASBR, MPLS label spoofing avoidance checks similar to CsC cannot be applied. Thus, routing and address separation between Inter-AS VPNs depends entirely on the peer SP, because VPN label spoofing avoidance techniques are also not available with option (c). Given this set of issues, this model is deemed insecure for Inter-AS VPN connectivity between different SPs.
Although MPLS VPNs provide addressing and routing separation between VPNs similar to FR and ATM VPNs, they do not provide cryptographic privacy. The next section reviews IPsec and the threats against IPsec VPNs. Note that the MPLS VPN architecture is compatible with the use of cryptography on a CE-CE basis, if that is desired.
VPN Customer
VPN Customer
CE Router
PE Router
CE Router
VRF1
VRF2 ASBR
Router
LDP
SP AS-1 SP AS-2
ASBR Router
PE Router
VPN Customer
VPN Customer CE Router
CE Router
VRF4
VRF3 LDP
M-eBGP
108 Chapter 2: Threat Models for IP Networks
Figure 2-19 Inter-AS VPN Option (c): Multihop M-eBGP