Hiding the Core Infrastructure
Traditional Layer 2 VPNs such as Frame Relay or ATM have the characteristic that the VPN user cannot "see" the core infrastructure. In these cases, the reason is that the user connects a Layer 3 device to a Layer 2 network, such that the Layer 2 infrastructure is mostly hidden to the user. In general, most VPN users prefer to have details of the core hidden to them.
MPLS VPN networks hide most of their core infrastructure in the architecture. As shown previously in Figure 3-5, only the peering PE addresses are exposed to the VPN user; P routers are completely hidden. It is important to understand that the hiding of the core is not due to ACLs but to the intrinsic way of handling separate address spaces on an MPLS core: even if an address of a P router would be known to an outsider, this address does not belong to the address space of the VPN user, and therefore it not reachable.
){kind=link}
The only exception to this is the peering address of the PE router. However, the address space of the CE-PE attachment circuits belongs to the VPN, not to the core. In fact, the same CE-PE address space could be used in several VPNs without address conflicts. Therefore, even though a PE address might be visible to the VPN, strictly speaking, no core information is passed to the outside because the address in question is VPN address space.
However, in reality, the reason to keep core infrastructure hidden is to avoid attacks against it. Therefore, considering which address space the PE peering address belongs to can be seen as mainly academic.
There is, however, a way to completely hide the PE routers from the VPN user: by using unnumbered address space and static routing between PE and CE. Here, an ACL could be applied to all PE peering interfaces of that VRF (where they exist), dropping any IP packet to the PEs' peering addresses (don't forget that all PE peering addresses toward all CEs of the VPN have to be secured this way).
In many cases, there are advantages to keeping the attachment circuit numbered—to monitor the health of the link, for example. Figure 3-6 shows a numbering scheme for such a case.
)
Figure 3-6 PE-CE Addressing
Example 3-2 shows how to implement this complete access control to the PE.
Example 3-2. ACL to Protect PE Peering Interfaces
access-list 101 remark 192.168.1.0/24 is the space used for PE-CE addressing access-list 101 remark throughout this particular VPN, which is connected to access-list 101 remark interface serial 0/1. access-list 101 deny ip any 192.168.1.0 0.0.0.255 access-list 101 remark The next line permits transit traffic (important!) access-list 101 permit ip any any ! interface serial 0/1 ip access-group 101 in
In this example, the first line in the ACL covers all the PE-CE address space of that particular VPN. Note the following:
- In many real life implementations, this would require more lines to cover all the PE-CE address spaces (attachment circuits).
- Don't forget the last line: it permits all transit traffic.
- Other PE addresses, which do not belong to the VPN, do not have to be included, nor does any P addressing, because they are not reachable by architecture.
- This example assumes static routing (that is, no routing protocol) between CE and PE. If routing is required, the specific protocol must be permitted in the above ACL.
- The ACL as described here also blocks access to the interfaces of the CEs that are facing the PEs (see Figure 3-6). For example, 192.168.1.5 belongs to a CE, but this address is blocked by the ACL. Therefore, other CEs cannot ping that address. Also, a ping from this CE across the MPLS core would not work because return packets would be blocked, unless another source IP was chosen manually for the ping (using extended ping). This might not be desirable if, for example, a network management station pings these CE interfaces. To avoid that, you can either list all PE addresses of the VPN separately as host entries (/32) or ping loopback addresses on the CEs instead.
Implementing Example 3-2 for a given VPN, the core is entirely protected from that VPN.
Should routing be required, then the required ports need to be permitted from the CE and only the CE. This is described in more detail with examples in Chapter 5, "Security Recommendations." In this case, the peering PE address is not hidden, but as mentioned before, the address space belongs to the VPN.
Regarding core hiding, the main goal of service providers is to provide higher resistance against attacks. The previous section shows that even with the peering PE address exposed, sufficient security can be achieved.
VPN users asking for core hiding usually want to keep the network as simple as possible. The fact that a routing relationship with the PEs might be required is usually not seen as a strong impediment against using an MPLS service.