MPLS over IP Operational Considerations: L2TPv3

In addition to running MPLS with label-based forwarding in the core, there are quite a few options for the deployment of MPLS over IP, such as:

• MPLS directly over IP

• MPLS over "Full" GRE/IP

• MPLS over "Simple" GRE/IP

• MPLS over L2TPv3 w/BGP Tunnel Subsequent Family Address Identifier(SAFI)

• Each of the above with IPsec

On an MPLS core with label-based forwarding it is not possible to insert spoofed packets from the outside of the core because labeled packets are not accepted on outside interfaces (Inter-AS presents an exception here; see Chapter 3 for details). If IP-based forwarding is used on the core, however, this architectural separation no longer exists. Additional security measures must be taken to protect packet spoofing from the outside.

MPLS over GRE, for example, relies 100 percent on L3 ACLs on outside-facing interfaces to protect the VPNs from spoofed data. In this scenario, a service provider IP address can be discovered or easily guessed. The GRE header contains constant, well-known values, and the MPLS VPN label is 20 bits of variant data that must be guessed by the hacker.

How quickly can a hacker guess a correct 20-bit MPLS label? The hacker can launch an attack as follows:

• 100 packet-per-second attack rate

• 100 active VPN labels (routes) on a PE

Answer:

It takes only 1 minute, 45 seconds to find a valid VPN label! However, this attack form has some serious limitations:

• The hacker does not know which VPN has been intruded.

• While the VPN label is being guessed, it is hard to insert significant traffic into a VPN; usually this attack is limited to a single or few packets entering.

• In addition to guessing a valid VPN label, it is necessary to craft a valid and meaningful IP packet underneath the guessed label. This means the hacker must either guess or find out about IP addressing in the VPN.

The hacker does not see any return traffic because the reverse direction does not work. However, even single packets can be a security threat, for example in the spreading of worms. In order to avoid becoming a transit point for packets inserted into a customer VPN, IP ACLs alone are not a robust solution because they are hard to maintain 100 percent correct on all entry points. IPsec may be used with any MPLS over IP tunnel type; this is a very secure solution, but may be rather expensive to deploy; however, this is a decision for the customer to make. What is still required is an additional layer of protection to make spoofing far more difficult than it is today with GRE, but without the overhead of IPsec.

Figure 5-1 illustrates a blind insertion attack for VPN access.

MPLS over L2TPv3

L2TPv3 provides an efficient method to make simple packet spoofing attacks harder. Protection occurs at the most important point, right before entering the customer VPN.

There is no requirement for encryption hardware to use MPLS over L2TPv3.

Rather than checking an IP source or destination address, L2TPv3 "seeds" each packet with a random value selected by each PE and advertised to other PEs in the VPN via the BGP Tunnel SAFI. This function is somewhat analogous to an ACL, but easier to manage and hard for a hacker to guess.

To spoof VPNs over L2TPv3 tunnels, we assume the following: The L2TPv3 session ID may be known, as it could be predictable or even hard-coded to a constant for some services in order to optimize forwarding.

How quickly can a hacker guess a correct 64-bit L2TPv3 cookie? The hacker can launch an attack as follows:

• 10 Mbps attack rate

• Any VPN labels is considered valid

Answer: 60,000 years!

Therefore, if an MPLS core uses IP-based traffic forwarding and if IPsec between the PEs is too expensive to deploy, then the best alternative for MPLS over IP is the use of L2TPv3.

Table 5-4 compares these security factors amongst the various MPLS over IP types.