Chapter 6: How IPSec Complements MPLS

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

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

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

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

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.

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

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.

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

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

IPsec Encapsulation for PE-PE Security

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

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 Summary of IPsec Applications on MPLS

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.

Deploying IPsec on MPLS

The models discussed in the previous section describe where IPsec tunnels are established (for example, PE-PE), but not how the tunnels get established, which is the second design consideration when deploying IPsec networks. The main options for IPsec tunnel establishment are

• Static IPsec—In this model, every IPsec node is configured statically with all its IPsec peers, the authentication information, and the security policy. This is the oldest way of configuring IPsec. It is hard to configure because each IPsec node requires significant configuration; but because this is the oldest way of configuring IPsec, it is supported on most platforms today. Static IPsec is described in RFC 2401–2412. It can be applied CE-CE and PE-PE.

• Dynamic IPsec—In hub-and-spoke environments, the hub can be configured without specific information for each spoke; only the spokes know how to reach the hub, and an IPsec tunnel is established only if the spoke can authenticate itself. Remote access IPsec uses a similar idea, but authentication is usually done on an AAA server. Dynamic IPsec is supported today also, and can be used for CE-CE as well as PE-PE.

• Dynamic Multipoint VPN (DMVPN)—This model works with the principle of the Next Hop Resolution Protocol (NHRP): Every IPsec node holds information about how to reach a next hop server, which returns the address of the target IPsec node to the originating node. This is a very scalable way to dynamically establish IPsec tunnels on demand. DMVPN works CE-CE and PE-PE.

• Group Domain of Interpretation (GDOI)—All the previous models maintain an IPsec security association per peer, even if the peer is found dynamically. This sets limits to the number of nodes that can be within one IPsec domain because every node must keep state for every active peer. GDOI maintains only a single security association for the whole group of IPsec nodes, such as for all nodes within a VPN. This means that all IPsec nodes in a group must share the same encryption/authentication key. The key is managed by a secure key server. Each node establishes a static IPsec connection to the key server; the rest of the group is dynamic and does not require state. GDOI is described in RFC 3547. GDOI was not yet available at the time of writing this book.

These various IPsec designs can be quite complex, with many suboptions for each model. This book can only give an overview. For more information on IPsec technology, refer to https://www.cisco.com/go/ipsec/.

As explained in Chapter 1, “MPLS VPN Security: An Overview,” the overall security of a solution depends on three parts: correct architecture, operation, and implementation. This section discusses the architecture and its features. To make the overall network secure, the IPsec service must also be implemented and operated correctly.

Using Other Encryption Techniques

IPsec is not the only way to secure data in transit. Long before IPsec became widely available, link encryption devices were used for this purpose. Also, SSL has become more widely used recently.

Link encryption has been used for many years, and a variety of solutions exist on the market for specific link layer protocols. The problem is that link encryption only secures a single link and does not provide end-to-end security from a VPN perspective. Link encryption devices, therefore, are not commonly used in MPLS VPN environments.

The Secure Sockets Layer (SSL) has received a lot of attention over the last few years. Both IPsec and SSL provide secure transport but at different points in the stack: IPsec acts at the network layer, which means that it is, just like IP, independent of the transport medium and of the applications that run on top. That means that IPsec can be used on an endpoint without making any change to the applications or to the lower layers in the stack. SSL, however, is based on transport layer security and located at Layer 4 in the stack. This is ideal for applications such as the Hypertext Transport Protocol (HTTP), which is located on top of the TCP layer. However, other protocols have to be mapped onto SSL. Figure 6-9 depicts both protocols and their locations in the stack.

Figure 6-9

IPsec and SSL

SSL has found application in VPN gateways where limited application support is required, such as when the VPN access is only used to access web pages. The advantage in those scenarios is that SSL does not require a client on the PC.

In MPLS VPN environments, SSL is not used for CE-CE or PE-PE security, but it may be used as a remote access technology. Wherever VPN-level security is required, IPsec is today’s key technology, with all its deployment options.

There are cases of encryption boxes, which are located in the customer network, behind the CE. These typically fulfill a mixed firewall/encryption function and are sometimes based on SSL. The MPLS network, including the CEs, is not involved in the encryption in this case: it just transports IP packets, which happen to be encrypted.

Summary

IPsec and MPLS VPNs are complementary technologies: MPLS VPNs help service providers scale their VPN networks. This advantage is passed on to the customer as a lower price tag. MPLS offers full VPN separation but no cryptographic security. IPsec helps VPN customers to further secure their VPNs if required. Both technologies work together well.

Before considering specific IPsec solutions over MPLS, the goals should be clearly defined: what are the threats, and what must be protected? With a clear threat model, it is usually easy to find an IPsec deployment model. For example, if the goal is to secure VPN traffic against intrusion, eavesdropping, and misconfiguration of the service provider, the solution must be within the trusted zone of the VPN. This excludes IPsec deployment on PEs. The typical deployment is therefore CE-CE.

There are various options for establishing IPsec tunnels for each of the deployment scenarios. Refer to specific IPsec literature for details; examples are listed in Appendix B.

Copyright © 2007 Pearson Education. All rights reserved.