Location of the IPsec Termination Points

In an MPLS VPN environment, IPsec can be applied at various points of the network:

• Within the VPN sites? For example, end-to-end IPsec security. (This case will not be discussed further here because here security is completely independent of MPLS.)

• Between CE routers of the VPN? In this case, the MPLS core is also not involved in the security services. The trust of this solution depends on whether the party who manages the CE is trusted or not.

• Between PE routers within the MPLS VPN core? Here, the service provider is managing the IPsec services and the VPN customer has no visibility of it.

• Between a point in the VPN and the PE? This is a special case and is usually used for remote access of PC clients (for example, teleworkers) into an MPLS VPN.

Figure 6-4 shows where IPsec can be applied in an MPLS VPN environment.

Figure 6-4. IPsec Termination Points in an MPLS VPN Environment

[View full size image]

Different termination points provide different security properties. A fundamental principle is that the IPsec gateway must be within a trusted zone and operated by a trusted party.

In the following sections, the various options to provide IPsec on an MPLS VPN infrastructure are discussed in detail. This is followed by an overview of the options, with a discussion of where the different scenarios are applicable.

CE-CE IPsec

If IPsec is used between the CEs, the entire path between the CEs is protected?the access lines (between CE and PE), as well as the entire MPLS core consisting of PEs, Ps, and lines. The assumption for this model is that the CE is located in the trusted zone?that is, the office building with access control and physical security. The operator of the gateway must be trusted: either it is an employee of the VPN customer, or the outsourcing partner is trusted. The outsourcing partner could be the service provider. Figure 6-5 outlines the CE-CE IPsec model.

Figure 6-5. IPsec from CE to CE

[View full size image]

CE-CE IPsec is an appropriate solution for securing the VPN customer's traffic across an untrusted infrastructure. Two key requirements are typically the reason for using CE-CE IPsec:

• Traffic must be secured whenever it is outside a trusted zone (office). This includes the access lines, the core lines, but also potential sniffing directly on core devices. This requirement can come from the company's security policy, but it could also be a legal requirement, such as when personal data are transmitted over public networks.

• The MPLS VPN service provider is not trusted. As discussed in Chapter 3, "MPLS Security Analysis," in a standard MPLS VPN network the customer must trust the service provider. The service provider can make any VPN insecure by misconfiguring a PE router, for example. If the VPN customer protects all data in transit with IPsec CE-CE, however, this trust can be very limited. Not even misconfiguration is an issue because all packets are verified to come from a trusted source.

IPsec CE-CE protects against the following threats (note in brackets the service that provides the feature):

• Eavesdropping anywhere between the CEs. Note that the most critical part to protect is typically the access line: it is usually easier to find and record traffic on the access line than in the core. (confidentiality)

• Insertion of bogus packets into the network. (authenticity)

• Change of packets in transit. (integrity)

• Replay of legitimate, recorded packets (anti-replay)

By protecting against these basic threats, IPsec CE-CE also provides implicit protection in the following cases:

• Insertion of a bogus CE into the VPN: this cannot happen because the bogus CE would not be able to authenticate against a legitimate CE.

• Leakage of other VPNs' traffic into the secured VPN: if through misconfiguration traffic from another VPN were redirected to a CE, this traffic would be discarded because the packets cannot be authenticated.

• Leakage of traffic from the secured VPN into another, nontrusted VPN: traffic from the secured VPN in transit would be encrypted, and the nontrusted VPN would not be able to see the clear-text traffic.

IPsec CE-CE does not protect against the following threats:

• Denial of service (DoS) from outside the trusted VPN into the VPN? IPsec does not improve the availability of a service. In fact, it has been argued that IPsec gateways themselves might become a target for DoS attacks. While this is theoretically true, availability is a difficult issue for any type of service, and IPsec does not make an exception here.

• Threats within the trusted zone? An example would be a worm outbreak within the VPN that would be carried over the IPsec tunnels, just as legitimate traffic.

Overall, CE-CE IPsec provides an ideal means of securing an MPLS VPN beyond the standard security of MPLS networks. It is the technique of choice for providing additional security such as traffic encryption to an MPLS VPN.

Opponents to MPLS would, at this point, argue that because IPsec provides all necessary VPN functions and indeed more than standard MPLS (encryption, for example), MPLS is not really required. In considering this argument, two topics have to be discussed separately: security and packet transport. Even if IPsec would be sufficient, the IPsec packets have to be transported from one CE to another. In most cases, MPLS VPN services are cheaper for this type of service than general IPsec service for all office sites. It should also be noted that at the time of this writing most MPLS VPN services were not additionally secured with IPsec, meaning that most MPLS VPN customers do trust their service providers and do not require encryption over the wide area network.

The reason why CE-CE IPsec is not that widely implemented today was until recently, to a large extent, due to the complexity of implementing an IPsec overlay network: there were scalability issues that made large IPsec deployments complex. New deployment models, such as DMVPN and GD01 significantly improve scalability. Later in this chapter, we discuss the various types of IPsec deployments and their scalability.

To work around the scalability issues of CE-based IPsec VPNs, some consultants have proposed the usage of PE-based IPsec services. This would make IPsec a network service; however, there are potential security problems with this model.

PE-PE IPsec

Quite often, PE-PE IPsec is seen as a way to avoid the VPN customer having to set up CE-based IPsec. Some consultants position this as an architecture similar in security but much easier to implement, especially for the customer. Figure 6-6 displays PE-based IPsec services.

Figure 6-6. IPsec from PE to PE

[View full size image]

The perception is that the main threat for VPN security is eavesdropping on the MPLS core. In practice, this is not correct: it is much easier for an attacker to find a local loop close to an office building and to sniff traffic on this line than it is to do the same on the MPLS core.

The Internet Draft "Use of PE-PE IPsec in RFC2547 VPNs" (draft-ietf-l3vpn-ipsec-2547-03.txt) describes how IPsec can be used to encrypt data between PEs. This document is clear about the aforementioned issue: "IPsec Security Associations that associate ingress PE routes with egress PE routers do not ensure privacy for VPN data."

In this mode, the LSPs in the MPLS core are replaced with IPsec tunnels. Therefore, it is also an alternative for running RFC 2547bis networks over a non-MPLS infrastructure. Figure 6-7 shows the encapsulation used:

IPsec PE-PE provides adequate protection for the following threats:

• Eavesdropping on lines between the PEs or P routers?specifically, if the MPLS core is routed over untrusted areas such as the public Internet.

• Misbehavior of P routers, which can lead to packets being changed or routed to the wrong egress PE.

It does not, however, provide VPN security.

There are a few security-related special cases where PE-PE IPsec is applicable and usable.

In the United States, ILEC market state carriers hold local VPN connections on their PE routers. To connect to another VPN site in another state, the carriers need to traverse a public network. PE-PE IPsec is an adequate technology for securing this transit. In this case, however, the MPLS core as such cannot be assumed to be a closed, trusted zone. Using IPsec provides this security, and it is largely transparent to the VPN customers because they perceive that they are connected to an overall trusted MPLS VPN core.

In a European country, the government was connecting various ministries to a national government backbone. At the time, there was no MPLS service available, so the government built a network of leased lines and connected routers to them. Because the government wanted to provide VPNs to the ministries, it built its own MPLS core, connected by those leased lines. The PEs were all located in secure government buildings, but the lines were not secure, so PE-PE IPsec encryption was also chosen in this special case. Note that this deployment is not comparable to normal service provider MPLS VPN deployments because in this case the "Provider Edge" routers are really customer edge equipment and, therefore, from a logical point of view, IPsec is applied from customer site to customer site. This deployment model does provide customer security.

The alternative would be to run IPsec between CEs, but this situation would be more complex because typically the number of CEs is significantly higher than the number of PEs.

Except in special cases, PE-PE IPsec currently is not much used for security reasons. It is clearly not a generic solution for VPN security. CE-CE IPsec should be used in those cases.

Apart from using IPsec between CE-CE and PE-PE, there is a third form of using IPsec: as a way of remotely accessing a VPN.

Remote Access IPsec into an MPLS VPN

In enterprise networks, teleworkers connect to their home networks via VPN: this used to be dialup; however, today most traveling employees use IPsec to connect from wireless hot spots, hotels, and conference buildings to their offices. In the traditional setup, an enterprise provisions a VPN concentrator in its own network. If an enterprise is already a customer on an MPLS VPN service, it is easy to outsource the IPsec remote access to the service provider. Figure 6-8 shows this setup.

Figure 6-8. IPsec Remote Access into MPLS VPN

[View full size image]

The IPsec tunnel from the remote user is terminated on the PE router, where, based on the user's identity, he or she is mapped into the VPN. The PE router therefore fulfills two tasks: IPsec remote access termination and MPLS PE.

In this application, IPsec serves mainly as a secure access method into the VPN of the user. The protection of IPsec secures the data on transport over any untrusted infrastructure, such as public wireless hot spots or the Internet.

All options for using IPsec have their special applications, pros and cons. The various ways to apply IPsec are summarized in Table 6-1.

Table 6-1 illustrates that all three IPsec models have completely different applicability and therefore are not mutually replaceable: CE-CE IPsec protects a VPN against threats from the outside; PE-PE IPsec has very special and limited applications, as described in the previous section; and IPsec remote access is a very special use of IPsec, rather than a generic security solution, in that it protects only the access into the VPN and not general VPN traffic.

Now it should be clear where to implement the IPsec endpoints. The next consideration is how the IPsec tunnels are established. There are various ways to deploy IPsec tunnels, and the next section discusses these options.