Specific Carrier's Carrier Considerations
The Carrier's Carrier (CsC) architecture is described in RFC 2547bis, and can best be described as hierarchical MPLS VPNs: CsC provides an MPLS VPN service that other carriers use to resell their services.
How CsC Works
Figure 3-13 shows how the CsC architecture looks. The first-level service provider is commonly called the backbone carrier; the second-level provider is called the customer carrier.
)
Figure 3-13 CsC
From a security point of view, the model is similar to standard RFC 2547 networks, with the exception that here on the interface between PE and CE, labeled packets instead of IP packets are exchanged. Although in the standard RFC 2547 network, all labeled packets can be discarded on ingress into the MPLS core, this model allows them.
There are two main cases for the application of CsC:
- The customer carrier is an Internet service provider (ISP).
- The customer carrier is an MPLS VPN provider.
If the customer carrier is an ISP, Internet traffic will be sent across the entire ISP network (spanning several VPN sites). For this to work, each router on the path must know all Internet routes. This includes the ISP's routers, but also the backbone carrier's PEs. For the backbone carrier, this does not scale: the PE would need to keep the entire Internet routing table for each VRF.
The solution is to use LSPs over the backbone carrier's network, essentially tunneling the Internet traffic over the core. This way, the PEs only need to know the address of the LSP endpoints, instead of the entire Internet routing table. In this solution the PE passes prefixes with a label to the CE, so the CE must be able to receive prefixes with labels and must be able to send labeled packets.
If the customer carrier is an MPLS VPN provider, the requirement is to connect VPN users transparently on several sites of the customer carrier's network. This can also be done with standard RFC 2547 MPLS, but it would require the backbone carrier also to configure on the core a VRF per customer of the customer carrier: essentially the VPN user would have to be configured on both the customer carrier network as well as the backbone carrier network. In addition, this does not scale well.
The solution is to exchange only Interior Gateway Protocol (IGP) loopback addresses with labels over the backbone, such that the CE will impose a new label for the traffic between sites. This way, the PEs from the customer carrier run MP-iBGP (interior BGP) sessions directly, and the backbone never sees the VPN user information. Figure 3-14 shows this behavior.
)
Figure 3-14 CsC: Hierarchical VPN
The original IP packet from the customer is encapsulated with a VPN label on the customer carrier's network. For this purpose, the customer's carrier has a VPN configured for each customer. This is exactly as in normal RFC 2547. The backbone carrier again configures a VPN for each customer's carrier on the customer's PE, the effect of which is that packets are again encapsulated on the backbone carrier's network.
There are several ways to configure the CsC solution for each case, but they are not discussed here because they do not differ from a security point of view: for security considerations, the important point is that the CE-PE interface now allows labeled packets. Therefore, CsC—like Inter-AS—is an exception to the general rules discussed in previous sections.
Security of CsC
To examine the security of the CsC solution, we address again both the control plane and the data plane. The interface between customers and the customer's carrier is a standard RFC 2547 interface and follows the considerations of the previous sections. The new part in the CsC architecture is the connection between the backbone PE and the customer carrier CE.
On the control plane, this interface has two basic options:
- To configure an Interior Gateway Protocol (IGP) with LDP or TDP. The IGP distributes the routes, while the LDP/TDP distributes labels for those routes.
- To configure BGP with label distribution, which combines the two tasks in one protocol.
All of these protocols can be appropriately secured, and this is described in detail in Chapter 5. The key concept is to ensure that the control connection is made with a known peer. This can be done using the MD5 authentication, which is available for all these protocols.
Label distribution on this interface is controlled in all cases by the backbone carrier. RFC 2547bis states for the CsC case: "The PE must not distribute the same label to two different CEs" (with some exceptions) for the control plane. For the data plane, it specifies that "when the PE receives a labeled packet from a CE, it must verify that the top label is one that was distributed to that CE."
This means the backbone carrier issues the label uniquely and then, on the data plane, controls all packets so that they use only the label(s) issued to them. This makes spoofing from the customer carrier impossible.
Attacks against the backbone carrier can be carried out with the protocols in use (IGP plus LDP/TDP or BGP), so they must be secured against DoS attacks and against propagation of false information. The backbone cannot be attacked through the exchanged packets, however, because the packets sent from the CE to the PE are not interpreted. Only label swapping takes place, which, again, is controlled by the backbone carrier. RFC 2547bis states for this case that packets cannot break the VPN separation if "it is known that such packets will leave the backbone before the IP header or any labels lower in the stack will be inspected." This is the case on the backbone level.
In CsC Layer 2, as in the Inter-AS architecture, security is paramount for any critical interface. Therefore, we repeat this warning:
The Carrier's Carrier architecture provides a secure way to operate multilevel VPNs, assuming correct implementation and operation. It is the backbone carrier that assigns and polices policy for the customer carrier, as the customer carrier does for its customers. On both levels the "customer" has no way to break the VPN separation of the level above. On both levels the lower level needs to trust the upper level to correctly implement and operate the network. For the end customer, this trust is transitive: the customer needs to trust the customer carrier, and implicitly also the backbone carrier.