IPSec or MPLS: understanding technology choices in virtual private networks - Internet

Computer Technology Review, April, 2003 by Cliff Young

Having gained momentum and industry acceptance over the past several years, virtual private networks (VPNs) are currently one of the hottest selling technologies in the market. Recognizing this trend, a growing number of systems integrators and value added resellers are looking to add some type of VPN offering to their product portfolio. However, given the amount of "buzz" surrounding VPNs, and the seemingly endless number of solutions available, it can be somewhat daunting to determine which VPN solution is right for a reseller and its customers.

Currently, two of the most popular types of VPN technology are known as IPSec VPNs and multi-protocol label switching (MPLS) VPNs. But from a technology, performance, implementation and cost perspective, how do these two different VPN approaches compare, and what does this mean for resellers?

IPSec Approach

To begin this discussion, let's examine "traditional" VPNs, which rely on an encapsulation (tunneling) and an encryption model to securely transport data between two locations. This type of VPN is an overlay of point-to-point tunnels on top of an existing IP network. There are many different types of VPN protocols such as GRE, PPTP, L2TP, and IPSec. They all rely on tunneling of some form, and usually employ encryption. For this discussion, we will focus on the IPSec protocol since it is the most widely used today. Generally, the same features identified with IPSec are applicable to the other traditional VPN protocols as well. Resellers interested in these types of VPNs can choose to implement their own solution (hardware or software) or resell services offered by a managed services provider.

Figure 1 is a simple example of an IPSec VPN tunnel between two sites. Site A connects to Site B through a service provider network, or the public Internet, using IPSec with 3DES encryption.

One of the key concerns with IPSec VPNs is performance degradation. For example, working from the Figure 1 diagram, imagine a packet sent from Computer A to Computer B. The packet is sent from Computer A to Customer Premise Equipment (CPE) A. CPE A examines the packet and forwards it to CPE B. In a non-IPSec VPN environment, the packet would now be on its way to CPE B. However, with IPSec, CPE A must perform numerous tasks before this can be accomplished. First, the packet is encrypted, which takes time to perform, thus causing the packet to be delayed (latency). Next the packet is put into another IP packet (encapsulated) taking even more time, hence adding more latency. Now the packet is sent to the service provider network (or public Internet).

Another holdup may occur at this point, which is commonly known as fragmentation. If the newly formed packet is bigger than the MTU (maximum transmission unit) size of any of the links between CPE A and CPE B then the packet will need to be fragmented into two packets. Once the packet arrives at CPE B it will de-encapsulate and de-encrypt the packet causing additional latency. Finally CPE B will forward the packet to Computer B.

The amount of actual latency experienced will depend on the CPE involved. Low-end CPE devices typically perform all IPSec functions in software and have the slowest performance. More expensive CPEs will perform the IPSec functions in hardware. Pricing can range from $400 to $3,000 for remote locations and up to $50,000 for Hub-site CPE devices.

IPSec VPNs are essentially an "overlay networks," meaning they ride on top of another IP network. Because of this, a tunnel must be established between every site. The two most common configurations are known as a hub and spoke or a fully meshed configuration.

As the name suggests, the hub and spoke configuration consists of one central (hub) site connected to many remote (spoke) sites. This is the most practical configuration for an IPSec VPN network. The hub site CPE is usually a fairly expensive piece of equipment (depending on the number of spokes). Every spoke establishes an IPSec tunnel to the hub site. If there are 20 remote sites then 20 IPSec tunnels will be terminated at the hub site. Unfortunately, this model is not optimal for spoke-to-spoke communications. Packets coming from one spoke to another spoke must first pass through the hub, requiring the hub to perform its steps of deencapsulating, de-encrypting, determining a forwarding path, encrypting and encapsulating every single packet. This is in addition to the encapsulation/encryption performed at the spokes. In effect, each packet traverses two IPSec tunnels, which greatly adds to each packet's latency. The latency would be roughly double compared to what it would be if the two sites communicated directly.

One option to replace a hub and spoke configuration is to create a fully meshed network. Benefits of this type of network architecture include any-to-any connectivity and redundancy, as important application servers may be "mirrored" in multiple locations ensuring no interruption in service if the primary "hub" site access should experience connectivity problems. However, this type of configuration must be carefully considered due to its scalability concerns. The number of tunnels needed to support a fully meshed IPSec network geometrically increases with the number of sites. For example, the 20-site plus network discussed earlier would require 210 IPSec tunnels. As each site would need CPE that is capable of terminating 20 IPSec tunnels, this network configuration would require each site to have high-end (more expensive) CPE. And when you get into deployments around the 100-site number, a fully meshed configuration is not feasible (a 100-site VPN would require 4,950 tunnels).