IPSec

IPSec and MPLS are not competing technologies. In fact, as you learned in Chapter 6, "Remote Access and IPSec Integration with MPLS VPNs," IPSec can be deployed with MPLS. Regulatory policies, such as those in the banking sector or government agencies, might dictate the use of IPSec and end-to-end encryption for implementation. Guidelines for the use of IPSec and MPLS are as follows:

• Encryption of traffic

• Direct authentication of CEs

• Integrity of traffic

• Replay detection

• Enhanced traffic separation from the standard level offered by the service provider

Various deployment options are available for IPSec, such as CE-to-CE via cryptomap, hub and spoke via dynamic cryptomap, and full mesh with tunnel endpoint discovery (TED). In fact, MPLS VPN and TED are a recommended combination due to the scalability and the requirement for direct CE authentication. A service provider could also provide an additional site-to-site or spoke encryption service to its customers, as shown in Figure 7-5.

Figure 7.5. Enhanced Security Services Site-to-Site Encryption

The IPSec standards specify a requirement to "copy down" the original IP DSCP values into the encapsulating IPSec header. This copy function is performed automatically by the crypto engines.

In the case of Generic Routing Encapsulation (GRE) +IPSec, the encapsulation is done by the GRE process to perform a copy down of the differentiated services code point (DSCP) from the original IP header. Subsequently, IPSec performs encryption (usually in transport mode such that another IP encapsulation is not done) and retains the IP DSCP provided by the GRE/IP packet.

Regarding QoS implementations using classic IPSec tunneling, the transit routers (that is, the PE devices) have visibility only to the DSCP and the IPSec tunnel end points. These transit routers have no visibility to other protocols. For this reason, the QoS mappings must be accurate before reaching the encryption engines.

Regarding QoS on the CE, the CE and PE are generally able to work on aggregate queues only (that is, all the point-to-point IPSec flows in a common set of queues). The CE performing the encryption can have visibility to other protocols prior to encryption (that is, IP protocol, source port, and destination port). However, most customers simply use the DSCP for queuing to achieve general QoS consistency.

MPLS VPN (BGP VPN) Security Issues and Options

Typically, the most important security requirement for VPN users is that their traffic is kept separate from other VPNs' traffic. This refers to both the VPN's own traffic not being seen in other VPNs and the other VPNs' traffic not intruding into the user's VPN. Referring to the threat model from the previous chapter, this section analyzes a threat against a VPN, specifically intrusions into and from other VPNs.

Another requirement is that each VPN can use the complete IP address space without affecting or being affected by other VPNs or the core.

The service provider has the requirement that the core remains separate from the VPNs in the sense that the address space in use does not conflict with any VPN and that VPN traffic remains separate on the core from the control plane traffic on the core.

In other words, a given VPN must be completely separate from other VPNs or the core in terms of traffic separation as well as address space separation. To analyze how the standard addresses these requirements, let's first examine how addressing, data, and control traffic are kept architecturally separate.

The purpose of the route distinguisher (RD) is to allow the entire IPv4 space to be used in different contexts, such as in our example for VPNs. On a given router, a single RD can define a VRF in which the entire IPv4 address space can be used independently.

Note

IETF RFC 4364 defines a semantic for RDs, but this serves only administrative purposes to make selecting unique RDs easier. For security considerations, it is important only to understand that the RD makes the IPv4 routes of a VPN unique on the MPLS VPN core.

Due to the architecture of MPLS VPNs (BGP VPNs), only the PE routers have to know the VPN routes. Because PE routers use exclusively VPN-IPv4 addresses for VPNs, the address space is separated between VPNs. They use IPv4 internally in the core, which is a different address family from the VPN-IPv4 address family, so the core also has address space independent from the VPNs. VPNs use the VPN-IPv4 address family, whereas the RDs are used to distinguish between VPNs. The core uses the IPv4 address family, which is architecturally separated from other address families. This provides a clear separation between VPNs and between VPNs and the core.

There is only one special case in this model: The attachment circuit on a PE, which connects a VPN CE, is part of the VRF of that VPN and thus belongs to this VPN. However, the address of this PE interface is part of the VPN-IPv4 address space of the VPN, and therefore, inaccessible from other interfaces on the same PE, from other core routers, and from other VPNs.

For practical purposes, this means address space separation between VPNs and between a VPN and the core is still perfect because this PE interface to the CE belongs to the VPN and is treated as a VPN address. However, this also means that addresses exist in the VPN that belong to a PE. Consequently, a PE can by default be reached from a VPN, which might be used to attack that PE from the VPN.

VPN traffic consists of VPN data plane and control plane traffic. This section examines both. The VPN user's requirement is that his traffic (both types) not mix with other VPNs' traffic or with core traffic. Specifically, his packets must not be sent to another VPN and other VPNs cannot send traffic into his VPN.

On the service provider network, this definition needs to be refined because VPN traffic must be transported on the MPLS core. Here we distinguish between control plane and data plane traffic, where the control plane is traffic originating and terminating within the core and the data plane contains the traffic from the various VPNs. VPN traffic consists of traffic from and to end stations in a VPN and traffic between CEs (for example, if IPSec is implemented between the CEs).

Each interface can belong only to one VRF, depending on its configuration. So for VPN customer "red," who is connected to the PE on a fast Ethernet interface, the interface command ip vrf forwarding <VPN> determines the VRF.

Traffic separation on a PE router is implemented differently, depending on which type of interface the packets enter the router through.

• NonVRF interface If the packet enters on an interface that is associated with the global routing table (the no ip vrf forwarding command), the forwarding decision is made based on the global routing table and the packet is treated like a normal IP packet. Only core traffic uses nonVRF interfaces, thus no further separation is required. (Inter-AS and Carrier's Carrier scenarios are exceptions to this rule and are discussed later in this chapter.)

• VRF interface If the packet enters on an interface that is linked to a VRF using the ip vrf forwarding <VPN> command, a forwarding decision is made based on the forwarding table (or forwarding information base [FIB]) of that VRF. The next hop from a PE perspective always points to another PE router, and the FIB entry also contains the encapsulation method for the packet on the core. Traffic separation between various VPNs is then achieved by encapsulating the received packet with a VPN-specific tag. You have various options for encapsulating and forwarding VPN packets on the core: Through a label switch path (LSP), an IPSec tunnel, an L2TPv3 tunnel, or a simple IPinIP or GRE tunnel. All the methods keep various VPNs separate, either by using different tunnels for different VPNs or by tagging each packet with a VPN-specific label.

P routers have no active role in keeping traffic from VPNs separatethey just connect the PE routers together through LSPs or the other methods, which were previously described. One of the key advantages of the MPLS VPN architecture is that P routers do not keep VPN-specific information. This aids the scalability of the core, but it also helps security: By not having any visibility of VPNs, they also have no way to interfere with VPN separation. Therefore, P routers have no impact on the security of an MPLS core. (As always in this chapter, we assume here correct operation and implementation.)

In summary, VPN users can expect their VPNs to be separate from other VPNs and the core because

• An interface on a PE (the user's attachment circuit) can belong only to a single VRF or the core.

• The attachment circuit to this interface belongs logically to the VPN of the user. No other VPN has access to it.

• On the PE, the address information of the VPN is held as VPN-IPv4 addresses, making each VPN unique through a unique route distinguisher.

• VPN traffic is forwarded through the core through VPN-specific paths or tunnels, typically tagging each packet with a VPN-specific label.

• P routers have no knowledge of VPNs and thus cannot interfere with VPN separation.

The service provider can expect her core to be separate from the VPNs because PE and P addresses are IPv4 addresses. VPNs use exclusively VPN-IPv4 addresses and cannot access PE and P routers.

We can therefore summarize the MPLS security requirements as follows:

• Address space and routing separation

• Hiding of the MPLS core structure

• Resistance to attacks

• Impossibility of VPN spoofing

In any network, security considerations devolve into essentially two sets of two types of issues. Compromises are either accidental (through misconfigurations, growth, or anticipated changes in the network) or deliberate (attacks by some entity bent on causing havoc). The risk vectors are either external (issues driven by events external to the network in question) or internal (problems that are sourced from within the network itself). Additionally, most security-related problems fall into the categories of DoS or intrusion. DoS events can be intentional or accidental, whereas intrusion issues are by definition intentional. It is essential to harden the network components and the system as a whole to minimize the likelihood of any of these scenarios. However, as with all resource-consuming features, a balance must be struck between maximizing security and offering the performance and usability the service is intended to provide. Clearly, a wholly disconnected host or router has total security, but its ability to forward data or provide services is substantially compromised.

The state of the network from an availability and security viewpoint can also differ with respect to the perspective of the interested party. That is, the concerns of the service provider and the customer are an intersecting, but not completely overlapping, set of needs. Indeed, the perspective of the current status of the network might not be identical for the two parties.

The service provider's concerns can be generalized into the following set of issues:

• Protecting the backbone infrastructure in terms of availability, accessibility, load, manageability, and so on

• Ensuring that committed service level agreements (SLA) are maintained

• Ensuring that billing support functions are uncompromised

• Maintaining segregation between different customer domains

• Verifying that customers are receiving the services to which they are entitledno more and no less

The customer has a somewhat differing perspective on the network from the service provider.

The customer's concerns include the following:

• Ensuring that data/routes are transferred reliably and unhindered to all appropriate end points.

• Ensuring that data/routes are not leaked to other service provider customers.

• Ensuring that the service provider is attaining committed SLAs in terms of availability and throughput.

• Expeditious troubleshooting of a network problem by the SP.

• Expeditious problem analysis by the customer.

• Protection mechanisms the customer can implement to protect him from service provider errors both initially and as the customer network grows due to an increase in the SP's customer base.

• Mechanisms/policies that the customer can implement to protect him from deliberate assaults originating from the service provider network.