IP VPN Services

An IP VPN is commonly defined as a routed link between two or more points across a heterogeneous network topology with various degrees of security that ensure privacy for all parties. The idea behind the IP VPN is to leverage the Internet's reach-and low cost-to eliminate the more expensive dedicated links common today. Some industry experts also claim IP VPNs will guarantee secure data transmission for businesses and, in the process, allow service providers to offer more-profitable value-added services.

You can set up VPNs in several ways, but Customer Premises Equipment (CPE)-based IP VPNs and network-based IP VPNs are the most common approaches. The difference lies in the network architecture: In CPE-based VPNs, the routing intelligence resides at an end-user site, while in carrier-based VPNs, it resides at the provider's edge, where it can be extended out to many end- user locations.

What Kind Of VPN Do You Need?

There are three types of VPNs. First, remote-access VPNs allow telecommuters or home workers who use DSL, cable, dial up, or wireless to access their corporate data networks. Second, site-to-site VPNs connect remote offices over the Internet. Site-to-site VPNs use secure point-to-point connections in a mesh topology overlaid on the Internet or even on a single provider's network.

Third, extranet VPNs connect a "community of interest," such as a company, its partners , suppliers, and customers, and so on, to an enterprise network and perhaps other relevant destinations. In extranet VPNs, an authorized third-party user arrives at the enterprise firewall after traversing the public network, and the destination (often the home office) VPN gateway terminates the traffic and grants trans-firewall access where appropriate.

When it's time to engineer your VPN, you need to consider many issues, such as the timeline for deployment and what applications the VPN will serve. For intranet and extranet users, you need to consider what type of data is involved and whether you ought to set priority levels based on the type of traffic. You need to know the number of users, how many classes of users you have, and what specific restrictions apply to these user groups. These concerns might include limiting user access to a specific location or during certain times of the day or week. You might also consider the type of resource access to grant, such as connectivity to a particular server, to a subnet, or to the whole network, as well as assigning QoS levels.

Next, decide whether to use a CPE- or network-based solution. Each approach has pros and cons (see "IP VPNs: The Next Wave," Network Magazine February 2001, page 96), but remember that most first-generation network-based solutions encrypt data only from service provider edge to service provider edge-the access link isn't secured. Of course, it's also possible for service providers to install devices they own and control on the customer premises. Alternatively, some software overlay VPNs (see "VPN Overlay Networks: An Answer to Network-based IP VPNs?" Network Magazine June 2001, page 48) offer a mix of CPE- and network-based equipment or service options.

ESP Tunnel Mode. In ESP tunnel mode, the header data is neither encrypted nor authenticated, so traffic can traverse a Network Adress Translation (NAT) device.

Types Of VPN

IPSec is the predominant standard for creating IP VPNs. IPSec handles these three types of VPNs by using either a gateway-to-gateway (GTG) or client-to-gateway (CTG) approach to create an overlay network on top of the Internet. IPSec requires each site to run a gateway that routes data to the Internet in a virtual tunnel that both verifies the authenticity of the parties at both endpoints and encrypts the data. GTG is used for site-to-site VPNs and designates tunnel endpoints at the WAN interface of the VPN gateway. Traffic between these endpoints is encrypted and authenticated, but the LANs behind the gateway are left alone, since these are supposedly already secured subnets.

CTG configurations are designed for mobile remote workers or telecommuters who need secure access to corporate data. This approach moves one of the tunnel endpoints onto the end user's machine. The client software supports the same IPSec authentication, encryption, and security association mechanisms as the VPN gateway.

You'll want to consider the network topology of your VPN overlay network, too. Scalability and performance are the key issues that determine whether to use a partially or fully meshed, distributed topology or a hub-and-spoke (HAS) topology, or some combination of these. A fully meshed network is hard to scale because it requires a link between each device and every other one with attendant encrypted-vs.-clear-traffic processing issues, configuration complexity, high availability requirements, high demand for knowledge of related security features, and the need to implement numerous QoS parameters. All of these factors may vary by user. It will often be better to use a partially meshed network, which establishes inter-spoke connections as needed. In both cases, the key is to keep the number of tunnels well within the VPN gateway's performance capabilities. One way to simplify configuration and improve scalability is to have the gateways use a dynamic tunnel endpoint discovery mechanism.

The most scalable topology is the HAS model, since the headend or hub can grow if spoke end-user capacity requirements increase. All traffic goes through the hub site, so spokes can interconnect with other spokes without using a direct link, but this may require fat pipes to provide enough bandwidth for spoke-to-spoke, as well as spoke-to-hub traffic. This approach may be too costly, especially since some headend VPN devices don't support direct spoke-to-spoke intercommunication. In cases where endpoints are more spread out across regions , or most traffic doesn't demand access to networks through the hub site, a distribution layer to decrease the bandwidth requirements at the headend and improve scalability might make sense.

Where Should The VPN Terminate?

Another knotty question is where to terminate a VPN-at the corporate or branch office firewall, or on the end user's private network? The answer depends on the end user's security needs and how this relates to the network architecture. In a remote access application where end users are tunneling into the corporate network, VPN devices commonly sit parallel to an existing firewall, or behind that firewall. Less common approaches include terminating sessions in front of the firewall or on the firewall itself.

A parallel VPN device/firewall approach means the firewall doesn't have to be reconfigured for the VPN traffic, but it does add to the number of entry points into the private network. It's imperative that VPN devices block all non-VPN traffic in order to minimize the additional risk. This may require the VPN device to perform some degree of address translation, or to redirect such traffic to the corresponding firewall.

If you put the VPN device behind the firewall, that firewall will require modification and the ability to filter and forward the VPN traffic to the appropriate gateway. But this setup may allow you to use only one of the Ethernet ports on the VPN gateway, which reduces some complexity.

On the other hand, if you put the gateway in front of the firewall, the secured traffic must terminate in a public zone. This forces the network manager to assign specific static IP addresses. This allows the manager to control the traffic's destination through the existing firewall, but most VPN gateways can also perform this task.

Finally, running a VPN gateway on an existing firewall has the appeal of simplicity by keeping all security access functions at the network perimeter, but this requires the firewall to take on a heavy processing burden that may be beyond the firewall's capabilities. This approach is significantly less popular than a parallel or behind-the-firewall architecture.

IP Sec And NAT

Using Network Address Translation (NAT) with IPSec VPNs can also be tricky. One trouble spot is the Authentication Header (AH) protocol in IPSec, which computes a hash value for outgoing packets that includes both the data payload and the address headers, and inserts this value into the packet.

A NAT device between the IPSec endpoints will change the addresses and port numbers to those appropriate for the end network. In this case, the receiving VPN device, which is unaware of any NAT activity, will drop the incoming packets-the receiving device computes a hash value based on the incoming packet, and then tries to match that value to the hash value in the packet. No match, no access, no VPN.

The solution is to use the Encapsulating Security Payload (ESP) protocol in tunnel mode (see figure). This mode encrypts both the packet's data and its headers in a new packet with its own headers. In other words, the newly created packet's source address is the sending gateway and its destination address is the receiving VPN gateway. By using ESP with authentication, the whole packet is now encrypted. But the header values changed by NAT aren't locked in by the integrity-checking mechanism and the traffic can flow freely .

One tricky area remains, however. The third major component of IPSec, after AH and ESP, is the Internet Key Exchange (IKE). IKE, formerly referred to as the Internet Security Association and Key Management Protocol (ISAKAMP), with the arbitrary name "Oakley" attached-ISAKAMP/ Oakley- manages the creation, management, and distribution of cryptographic keys. (Security Associations [SAs] are the endpoints of IPSec links.) Before any data can be exchanged, IKE must first establish an SA to serve as an initial secure channel for exchanging keys. This initial IKE SA establishment is referred to as Phase 1, and can be accomplished with a main mode exchange or an aggressive mode exchange. Phase 2 is the establishment of an IPSec SA, and is known as quick mode. Possible main mode establishment mechanisms include X.509 digital certificates, preshared keys, and encrypted nonces. Preshared keys are symmetrical keys installed in advance on VPN endpoints. Encrypted nonces involve the generation of public/private key pairs on each endpoint and the manual copying of public keys to every other endpoint. As with AH traffic, NAT will bring down IKE if the keys or certificates exchanged by IKE bind a gateway's identity to its IP address.

IPSec would undoubtedly be much more widely used if PKI were more widely adopted. PKI digital certificates are the most straightforward way to create IPSec SAs. As digital certificates and certificate authorities become more established, we can expect to see more IP VPNs using IPSec technology.

Resources

Cisco Systems has a comprehensive discussion of VPN technology at: www.cisco.com/warp/public/cc/so/cuso/epso/sqfr/safev_wp.htm.

A good, concise VPN FAQ can be found at: www.zyxel.com/support/supportnote/zywall10/_faq/vpn_faq.htm.

Check out Virtela Communications' "IPSec VPN Tutorial" at www.virtela.com for more information on IPSec.

Numerous white papers address more general applications for VPNs at www.aplion.com. This company offers good high-level views of how VPNs should be used in the future.

This tutorial, number 165, by Doug Allen, was originally published in the April 2002 issue of Network Magazine.