Chapter 6: How IPSec Complements MPLS

Cisco Press

When the idea of MPLS VPNs was first discussed, there was a strong notion of competition between MPLS VPNs and IPsec VPNs. Many people voiced concern that MPLS VPN technology does not add significant advantages over IPsec VPNs and, indeed, that it is inferior in some respects: by default, MPLS VPNs do not provide confidentiality on the network, for example.

Today, there is at least a strong market perception that MPLS VPNs are useful. Indeed, both MPLS VPNs and IPsec VPNs have significant deployments, and that suggests that both types have their benefits, albeit in different scenarios. The benefits of MPLS VPNs are primarily on the service provider side, where this technology allows highly scalable VPN architectures, with integrated QoS support. The VPN customer benefits indirectly through lower prices because the service provider can offer a VPN service more cheaply. IPsec VPNs have their main benefit in customer network security: data in transit are encrypted, authenticated, and integrity is maintained.

We will not engage here in an argument about which of the VPN technologies is better or more suitable for a given network. Instead, we will provide technical arguments on how the two VPN technologies can be used together. Both have advantages for different target groups—the VPN customer and the service provider. The combination of the two can result in a very compelling overall VPN architecture.

The first section of this chapter gives an overview of various deployment scenarios of IPsec together with MPLS. The subsequent sections give more detail on each of them. Finally, some practical decision guidelines are given on how to decide which way of mapping IPsec onto MPLS is the best for a given case.

IPsec Overview

IPsec is a technology that offers security services across an IP network:

  • Confidentiality through the use of encryption

  • Authenticity through the use of peer and message authentication

  • Integrity through the use of message integrity checks

  • Anti-replay, by using authenticated sequence numbers, to guarantee freshness of a message

One of the key advantages of IPsec is that its security services are all applied in Layer 3, the network layer, just as with IP. This way, the security services remain independent of the underlying transport mechanism as well as the protocols and applications used on top of the stack.

Note - IPsec addresses most typical security requirements, such as confidentiality, as just discussed. An important requirement that IPsec does not provide an answer to, however, is availability. The use of IPsec typically does not make networks less vulnerable to DoS attacks.

IPsec can, in principle, be applied end to end, for example, between a client and a server. IPsec transport mode can be used for this. However, the most widespread use of IPsec today is between specific IPsec gateways—in a company network, for example. In that case, traffic within an office (a trusted zone) is usually in clear, with the IPsec gateways securing the traffic over the public network. In this case, tunnel mode is used to tunnel packets securely from one office to the other. Figure 6-1 shows both transport mode and tunnel mode with their typical applications.

Note - In colloquial language, IPsec "encrypts" packets. Here we use the term "secure" instead because encryption is only one of several features of IPsec.

Figure 6-1

Figure 6-1

IPsec Transport Mode and Tunnel Mode

With those two connection modes, there are two ways to map clear-text IP packets into an IPsec packet. In tunnel mode, the entire clear-text IP packet is secured, and a new IP header is prepended, followed by an IPsec header that identifies the logical connection between the IPsec gateways. In transport mode, the original IP header is preserved, and the IPsec header is inserted before the secured IP packet. Figure 6-2 displays these two packet formats.

Figure 6-2

Figure 6-2

IPsec Packet Formats

A single IPsec tunnel connects two sites. By adding more tunnels, a VPN can be constructed between the IPsec gateways. This can be done in a full mesh topology, a hub-and-spoke topology, or any mixture of the two. Figure 6-3 shows basic VPN topologies that can be built using IPsec.

Figure 6-3

Figure 6-3

IPsec VPN Topologies

When securing a network—for example, let's say a bank network with two central offices and 100 branch offices—the key design criterion is where to place the IPsec gateways. In most designs, the offices of the bank each would be considered a trusted zone, with the communication infrastructure between them being untrusted from the VPN customer's point of view. In such a design, the IPsec gateways must be inside the trusted zones for the overall VPN to remain protected with the IPsec services.

When designing an IPsec overlay network, two main topics must be discussed:

  • Where should the IPsec tunnels be applied?

  • How should the tunnels be established?

For both questions, there are a number of options. So, we'll first discuss the location of the IPsec termination points; later, we'll discuss the way tunnels are established between those sites.

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

Figure 6-4

IPsec Termination Points in an MPLS VPN Environment

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.


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

Figure 6-5

IPsec from CE to CE

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.

Recommendation - If encryption is required or the service provider is not trusted (misconfiguration and related issues), then IPsec between CEs under the operational control of the VPN customer is the recommended way to secure the VPN.

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.


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

Figure 6-6

IPsec from PE to PE

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.

Recommendation - If the purpose of the IPsec deployment is VPN security, then PE-based IPsec does not address all the requirements: specifically, the local loop (CE-PE) is not secured.

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:

  1. The VPN label is prepended to the VPN packet as in normal MPLS; however, IPsec can only secure IP packets, not labeled packets.

  2. Therefore, the labeled packet is first encapsulated in Generic Routing Encapsulation (GRE).

  3. The GRE packet can then be secured with IPsec. Because the endpoints of the GRE tunnel are the same as for the IPsec tunnel, transport mode can be used, and this reuses the GRE header.

Figure 6-7

Figure 6-7

IPsec Encapsulation for PE-PE Security

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

1 2 Page 1
Page 1 of 2
IT Salary Survey 2021: The results are in