Carriers' Carrier
Consider VPN customers of an MPLS carrier who would like to offer VPNs themselves to their customers. To separate the customers' traffic, they could use a label, as in a normal MPLS network. However, the interface to their carrier would normally be IP. If the carrier would allow them to use labels for their VPN, they could put another label underneath and pass their VPN customers' traffic end to end. This architecture is called Carriers' Carrier (CsC).
Figure 4-29 shows the CsC architecture. It is a hierarchical structure where the hierarchy is also reflected in the data plane: VPN labels are stacked (though the full label stack is not shown here). The main difference between this and a standard RFC 2547 network is that the CsC-CE routers need to support MPLS.
Figure 4-29. CsC Architecture
NOTE
For ease of reference, in this section we use the term "Carrier" for the top-level MPLS provider and "Internet service provider" or "ISP" for the second-level provider or customer of the carrier.
In this model, the interface between the CsC-PE and the CsC-CE allows labeled packets. In the Inter-AS section, we mention that this fact puts separation of "inside" and "outside" of the MPLS core in question. However, the CsC architecture has a fundamental difference that allows it to run securely: the connections from the ISP are terminated on the carrier's core CsC-PE in a VRF, not in the global table.
On the control plane, eBGP is used between the CsC-PE and CsC-CE to exchange routing and to assign labels to the ISP. This session needs to be secured with all the mechanisms described in the previous section: peer authentication, GTSM, maximum prefix limitation (here also for a VRF), prefix filters, and so on.
NOTE
Recommendation
Secure the BGP session between the CsC-PE and CsC-CE as tightly as possible, configuring all possible security features. Of particular importance are route flap damping and the configuration of maximum prefix levels per VRF and BGP peer.
The CsC-PE assigns a VPN label to the CsC-CE that is then used like a VPN label on a standard RFC 2547 backbone. This way, the carrier keeps traffic from different ISPs separate.
On the data plane, there are two types of traffic:
BGP over IP between the CsC-PE and CsC-CE
Labeled packets for the data traffic
Therefore, IP traffic can and should be restricted to only BGP traffic, and the routing protocol should be secured as previously described. This secures the IP data plane.
For labeled packets, the CsC-PE checks that the top labels received on the data plane were actually assigned to that CsC-CE on the control plane. This way, the top label cannot be spoofed.
Anything underneath the top label can be spoofed by the ISP; however, the carrier's network does not look underneath the top label: it only needs the top label to forward the packet to the egress CsC-PE and into the right VRF there.
RFC 2547bis states for data plane security that a backbone router does not accept labeled packets over a particular data link unless 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 in the CsC architecture.
Therefore, if anything underneath the top label is faked, it can only affect the VPN of the ISP itself. So the security of the CsC architecture is equivalent to the security of a standard RFC 2547 network, even though labeled packets are exchanged at the edge.
Because the security of CsC is very good, this solution can also be considered to extend MPLS to the customer site. Often, this requirement is stated as a "PE at the customer site."
It is not recommended to position a PE at a customer site. The reason is that if the PE gets compromised, all VPNs of that MPLS core can be intruded. A PE router must be under complete physical control of the service provider to avoid problems such as password recovery through the console port. See Chapter 3, "MPLS Security Analysis," for more details on this issue.
However, the requirement in such cases is not, strictly speaking, to have a PE at the customer site, but to extend MPLS to the customer site. The CsC solution offers this in a secure fashion: MPLS can be extended to the customer site without jeopardizing the security of the PE, which remains in a secure environment at the carrier.
NOTE
Recommendation
Never put a PE router on customer premises. Physical access to the PE routers must be fully controlled to avoid unauthorized password recovery. Where MPLS to the customer site is required, use the CsC architecture, which provides a secure solution while keeping the PE in a secure service provider location.
In summary, CsC is an architecture that can be deployed securely, even to nontrusted parties (customers and other providers, for example). It is ideal for cases where MPLS is required to the customer's premises.
NOTE
In both Inter-AS and CsC architectures, there is a threat that is often ignored. While considering all details at Layer 3, remember that the lower layers are also important. In fact, a wrong design, for example, on the switching interconnection between two service providers might endanger the security of all VPNs.
