Chapter 6: How IPSec Complements MPLS

Cisco Press

1 2 Page 2
Page 2 of 2
  • 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

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

Protection AgainstCE-CEPE-PERemote Access
Eavesdropping on coreYesYes
Eavesdropping on access lineYesNo
Receiving traffic from outside a VPNYesNo
Sending VPN traffic outside the VPNYesNo
Intrusion via fake CEYesNo
Access securityYes
DoS against the VPNNoNo

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

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

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.


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.

Learn more about this topic

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2007 IDG Communications, Inc.

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