IPSec or MPLS: understanding technology choices in virtual private networks. (Internet).

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).

Another key factor to consider when selecting an IPSec solution is interoperability. Most customers looking to add or expand VPN deployments will almost certainly have a unique mixture of existing CPE devices. And, as one would expect, customers will likely want to reuse as much of that equipment as possible to drive down costs. Although the most efficient way to solve this problem is to implement the same CPE devices at each location, this is not always possible. While interoperability is not as big a problem today, it is still an issue that must be considered when contemplating an IPSec VPN solution.

Provisioning is another issue that must be addressed, particularly since each IPSec tunnel must be established manually. Configuring a single IPSec tunnel is not a problem, but the time required to bring up a multi-site VPN increases dramatically as the size of the network grows. With a fully meshed network, it can take a number of days to configure the 21-node network, making support and troubleshooting efforts rather difficult.

The final element to address when considering an IPSec VPN is probably the most important: security. With an IPSec VPN, every CPE is accessible to the public Internet and relies on IPSec tunnels to securely transmit data between sites. Therefore, every CPE device must have security measures in place, such as a firewall, to protect each location. Due to the number of CPE devices generally required for large deployments, it is easy to see that more and more firewalls need to be maintained, resulting in more opportunities for security failures.

The MPLS Option

Unlike IPSec VPNs, MPLS VPNs do not rely upon encapsulation and encryption to maintain a high level of security. Delivered most effectively as a service offering from a service provider, MPLS VPNs use forwarding tables and "tag" the packets to create a secure VPN. This type of network architecture delivers intelligence within the core of its network (instead of on its edge).

Before proceeding, some terminology used with MPLS VPNs should be discussed. The CPE is referred to as a Customer Edge (CE) router. The CE router connects to a service provider's network through a Provider Edge (PE) router. A VPN consists of a group of CE routers connected to the service provider's PE routers. Only the PE routers are aware of the VPN. The CE routers do not see the underlying network and perceive that they are connected via a private network (see Figure 2).

Each VPN is associated with a VPN routing/forwarding instance (VRF). A VRF defines the VPN membership of a customer site attached to a PE router. A VRF consists of an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included into the routing table. A site can associate with one (and only one) VRF. A customer site's VRF contains all the routes available to the site from the VPN of which it is a member.

Packet forwarding information is stored in the IP routing table and the CEF table for each VRF. A separate set of routing and CEF tables is maintained for each VRF. These tables prevent information from being forwarded outside a VPN, and also prevent packets that are outside a VPN from being forwarded to a router within the VPN. This is the mechanism that makes the VPN secure. Within each VPN there is any-to-any connectivity and each site can send IP packets directly to any other site in the VPN, without having to go through a central site.

A Route Distinguisher (RD) identifies the IP addresses of each individual VPN. In Figure 2, three different VPNs are shown with Route Distinguishers 10, 20, and 30. An MPLS network can support hundreds of thousands of VPNs. The interior of an MPLS VPN network is made up of Provider (P) devices. These devices form the MPLS core and do not directly connect to a CE router. Provider Edge (PE) routers that surrounded the core of P devices enable the VPN functions of an MPLS VPN network. Both P and PE routers are considered Label Switch Routers (LSR). An LSR is a device that is capable of switching packets based on their labels. Customer sites are connected to the PE routers in many different ways: T1, Frame Relay, DSL, ATM and so on.

At the PE router, a VRF and route distinguisher is associated with each link to a customer site. The links may be physical links such as T1, individual Frame Relay or ATM virtual circuits, DSL links or other options. The Route Distinguisher is configured at the PE router as part of the set-up of a VPN site. It is not configured on the customer equipment and is not visible to the customer.

One of the greatest advantages of MPLS VPNs is that no intelligence is required in the CPE devices, since all of the VPN functions are performed at the core, meaning that customers may now use much less expensive CPE devices.

Latency is kept to a minimum, since packets are not encapsulated or encrypted. Encryption is not required since an MPLS VPN creates a private network. It is very similar to the security provided by a Frame Relay network. Latency is even reduced compared to non-MPLS IP networks due to the label switching. Moreover, it is very simple to create a full-mesh VPN network since there are no tunnels. The default configuration is in fact a full-mesh. Sites connect directly to a PE and then can reach any other sites in the VPN. If the hub-site should become unreachable, remote sites can still communicate with each other.

Provisioning is also much easier in an MPLS VPN. Provisioning only needs to be done on the core network equipment, and access to the CPE is not required. Once a site has been configured, it does not need to be revisited to add additional sites later. As new sites are added, configuration changes are only done to the PE they connect to.

In addition, security is much easier to implement with MPLS VPNs. A closed VPN is inherently secure since it has no connection to the public Internet. If Internet access is needed, one path may be set up to provide access. A single firewall is placed on this path to provide a secure connection for the entire VPN. This is much easier to manage, since policies will only need to be maintained on one firewall for the entire VPN.

A final feature of MPLS VPNs is that only one connection is required to each remote site. Imagine a traditional Frame Relay network with a hub and ten remote sites. A Frame Relay PVC would be required for each remote site, meaning ten PVCs would be needed at the hub site. Within an MPLS VPN network, only one PVC is needed at the hub location, which equates to a less expensive network.

Making the Right Choice

VPNs all provide the same basic function: to offer remote offices or users secure access to their organization's network. However, the performance, the cost to implement, and the cost to manage the VPN and underlying network elements are the driving force behind the different protocols and technologies that have emerged today. SIs and VARs who are looking to add a VPN solution to their portfolio must fully explore all of the "hidden" costs to determine the true fully burdened cost of delivering a high performance VPN solution to their customers.

Cliff Young is president of ClearPath Networks, Inc. (El Segundo, Calif.)

www.clearpathnet.com