Protection Against Spoofing

When the Internet was in its early stages, the source address of a packet itself was considered sufficient to prove that the packet was really sent by this IP address. In early versions of UNIX, there is a whole command suite, the so-called "r-commands," such as rlogin, rcp, rsh, and so on, which rely on the IP address for authentication.

Today, IP address spoofing is an everyday occurrence in various types of attacks, and engineers have learned not to rely on the IP source address.

Since MPLS is a Layer 3 technology, users are concerned about spoofing on the MPLS network, both on the IP level and with the labels used by the MPLS protocols. Questions asked include "Can another VPN user spoof my IP address range to get into my VPN?" and "Can someone spoof VPN labels to intrude into my VPN?"

These questions can be easily answered:

• IP address spoofing? As discussed previously and shown in Figure 3-2, each VPN can use the entire theoretical IP address space, from 0.0.0.0 to 255.255.255.255. A certain VPN site or host may indeed spoof IP addresses, but the spoofing will remain local to that VPN. This is, in fact, a strength of MPLS VPNs: the VPN user may use the entire address space, including fake addresses, and the VPN behaves like a physical network with just that VPN user. This is possible because the PE routers keep all packets within the VRF context, such that even fake packets cannot "escape" that VPN context. Therefore, IP address spoofing in a VPN does not affect VPN separation.

• Label spoofing? Within the MPLS core, packets of different VPNs are distinguished by prepending a VPN label to the packet. A malicious VPN user may try to create specifically crafted packets with a fake VPN label and insert those into the MPLS core, trying to get those packets into another VPN. This is also impossible because PEs do not accept labeled packets from CEs. Therefore, such a faked packet would simply be dropped by the PE.

But what if the packet with a spoofed VPN label is inserted within the core? Then this packet may really be routed to a random VPN, assuming the attacker knows (or can guess) some internal details of the MPLS core, such as VPN label numbers and egress PE label numbers.

The assumption made in this chapter is that the MPLS network is an integer (in other words, that the core is secure). This assumption includes the fact that the only interfaces into the network are the PE-CE interfaces. This may seem an unrealistic assumption at first, but in fact, any VPN technology is insecure if someone can insert packets in the core, because it would allow, for example, the insertion of random ATM cells with crafted virtual path and circuit information, and the same effect: getting packets into another VPN.

Therefore, the MPLS core is treated as a zone of trust where packets can only enter on well-known interfaces. See Chapter 1, "MPLS VPN Security: An Overview," for more details on zones of trust and this concept.

Assuming that packets can only enter the MPLS core through defined PE-CE interfaces, spoofing is not possible. RFC 2547, the first version of the standard for BGP/MPLS IP VPNs, describes only IP interfaces into the core, which allows this relatively simple security analysis.

RFC 2547bis, the second version of the standard, however, adds another form of interface?the Inter-AS and Carriers' Carrier architectures?which allow labeled packets entering the core. This changes the security exposure significantly and is therefore discussed in the following two sections in more detail.