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.