VPNs: Virtually Anything?

Pick up any six press releases and you're bound to read six different definitions of "VPN" - Virtual Private Network. In an industry obsessed with acronyms, vendors and service providers twist and stretch this label as needed to fit product offerings. Woe to the consumer who simply wants to know what this acronym means. Unfortunately, a single, practical working definition of "VPN" remains elusive - like beauty, the true meaning of VPN is in the eye of the beholder.

Going Virtual

What can we say that is generally true of all VPN products and services? Well, certainly the goal of all VPN products is to enable deployment of logical networks, independent of physical topology. That's the virtual part - allowing a geographically distributed group of hosts to interact and be managed as a single network, extending the user dynamics of LAN or workgroup without concern as to physical location.

Some interpret private simply as a closed user group - any virtual network with controlled access. This definition lets the term VPN fit a wide variety of carrier services, from traditional Frame Relay and ATM networks to emerging MPLS-based networks. Others interpret private as secure - virtual networks that provide confidentiality, message integrity, and authentication among participating users and hosts. In this paper, I focus on Secure VPNs.

VPN Applications

Just as there are an endless variety of physical network topologies, so too are there an infinite set of VPN topologies. At their core, however, most VPN topologies try to satisfy one of three applications.

• Private workgroups can be provided with secure Site-to-Site connectivity, even when LANs that comprise that workgroup are physically distributed throughout a corporate network or campus. Intranet services can be offered to entire LANs or to a select set of authorized hosts on several LANs - for example, allowing accounting users to securely access a payroll server over a network segments that are not secured. In Site-to-Site VPNs, dedicated site-to-site WAN links are replaced by shared network infrastructure - a service provider network or the public Internet.
  
  
• Low-cost, ubiquitous, and secure Remote Access can be offered by using the public Internet to connect teleworkers and mobile users to the corporate Intranet, thus forming a Virtual Private Dial Network (VPDN). In Remote Access VPNs, privately-operated dial access servers are again replaced by shared infrastructure - the dial access servers at any convenient ISP POP.
  
  
• Site-to-Site and Remote Access topologies can also be used to provide business partners and customers with economical access to Extranet or Business-to-Business services. In Extranet and B2B VPNs, a shared infrastructure and the associated soft provisioning of sites and users makes it possible to respond more rapidly and cost-effectively to changing business relationships.

Increasingly today, any of these VPN applications can be outsourced to a commercial service provider, be it a regional ISP, top-tier network access provider, public carrier, or an *SP specializing in managed security services. In such Outsourced VPNs, the service provider is responsible for VPN configuration (provisioning) and monitoring. Service Providers may locate their VPN devices at customer premises or at the carrier's POP.

Enabling Technologies

Each of these VPN applications is supported by secure, network-to-network, host-to-network, or host-to-host tunnels - virtual point-to-point connections. VPN tunnels may offer three important security services: Authentication, to prove the identity of tunnel endpoints, Encryption, to prevent eavesdropping or copying of sensitive information transferred through the tunnel, and Integrity checks, to ensure that data are not changed in transit.

Tunnels can exist at several protocol layers.

• Layer 2 tunnels carry point-to-point data link (PPP) connections between tunnel endpoints in remote access VPNs. In a compulsory mode, an ISP's network access server intercepts a corporate user's PPP connections and tunnels these to the corporate network. In a voluntary mode, VPN tunnels extend all the way across the public network, from dial-up client to corporate network. Two layer 2 tunneling protocols are commonly used today. The Point-to-Point Tunnel Protocol (PPTP) provides authenticated, encrypted access from Windows desktops to Microsoft or third-party remote access servers. The IETF standard Layer 2 Tunneling Protocol (L2TP) also provides authenticated tunneling, in compulsory and voluntary modes. However, L2TP by itself does not provide message integrity or confidentiality. To do so, it must be combined with IPsec (see below).
  
  
• Layer 3 tunnels provide IP-based virtual connections. In this approach, normal IP packets are routed between tunnel endpoints that are separated by any intervening network topology. Tunneled packets are wrapped inside IETF-defined headers that provide message integrity and confidentiality. These IP Security (IPsec) protocol extensions, together with the Internet Key Exchange (IKE), can be used with many authentication and encryption algorithms (e.g., MD5, SHA1, DES, 3DES). In site-to-site VPNs, a security gateway - an IPsec-enabled router, firewall, or appliance - tunnels IP from one LAN to another. In remote access VPNs, dial-up clients tunnel IP to security gateways, gaining access to the private network behind the gateway.
  
  
• Companies with "email only" or "web only" security requirements may consider other alternatives, such as Secure Shell (SSH, or SecSH). SSH was originally developed as a secure replacement for UNIX "r" commands (rsh, rcp, and rlogin) and is often used for remote system administration. But SSH can actually forward any application protocol over an authenticated, encrypted client-server connection. For example, SSH clients can securely forward POP and SMTP to a mail server that is running SSH. SSH can be an inexpensive method of providing trusted users with secure remote access to a single application. But it does require installing SSH client software.
  
  
• A far more ubiquitous alternative is Netscape's Secure Sockets Layer (SSL). Because SSL is supported by every web browser today, it can be used to secure HTTP without adding client software. SSL evolved into IETF-standard Transport Layer Security (TLS), used to "add security" application protocols like POP, SMTP, IMAP, and Telnet. Both SSL and TLS provide digital certificate authentication and confidentiality. In most cases, SSL clients (e.g., browsers) authenticate SSL servers (e.g., eCommerce sites). This is sometimes followed by server-to-client sub-authentication (e.g., user login). SSL or TLS can be a simple, inexpensive alternative for secure remote access to a single application - for example, secure Extranet "portals".

For a comparison of these alternatives, visit http://www.corecom.com/external/vpn/compare.html.

Of course, combining approaches is also possible - and, to satisfy some security policies, absolutely necessary. L2TP does not provide message integrity or confidentiality. Standard IPsec does not provide user-level authentication. The Windows 2000 VPN client layers L2TP on top of IPsec to satisfy both of these secure remote access requirements. On the other hand, vanilla IPsec is more appropriate for site-to-site VPNs and SSL is often the simplest secure Extranet solution.

Deployment Considerations

All of these are VPNs, yet every one I've mentioned takes a different approach. Let's take a look at some of the trade-offs that should be considered when looking at VPN alternatives.

Difficulty of Deployment: Do you require multi-protocol support? Layer 2 VPNs are designed to tunnel any network protocol carried by PPP, while IPsec was designed specifically to tunnel IP. How will your existing devices involved in VPN deployment? Layer 2 VPN products require access server upgrades at the corporate WAN access router and/or ISP POP. IPsec VPN products run the gamut from router and firewall upgrades to drop-in "security appliances" to carrier-class IP service switches. Each of these alternatives has a different impact on network addressing, routing, firewall configurations, and packet filters.

Integration: Do you require legacy (e.g., RADIUS, SecurID, S/Key) user authentication? If so, shop carefully: many VPN products can be integrated with external authentication servers, but features vary widely. Must your VPN accommodate privately addressed networks? If so, look for a VPN product that also supports network address port translation (NAPT), or make sure you perform NAPT before your traffic hits the VPN.

Client Software: Compulsory Layer 2 remote access and IPsec site-to-site solutions do not add any client software. IPsec remote access clients are also embedded in enterprise-class operating systems like Windows 2000 and Solaris. Windows 95/98/ME/NT, Linux, and Mac desktops require add-on IPsec clients. However, because many vendors implement remote access extensions to standard IPsec, it is often necessary to deploy the IPsec client supplied with the gateway. Don't assume that you can use an open source Linux client or the built-in Windows 2000 client with every IPsec gateway. Situations in which you have no control over the desktop environment may demand a "client-less" solution like SSL.

Flexibility: Before shopping for a VPN product, review your corporate security policy to determine your authentication method, message integrity, and encryption algorithm requirements. Many VPN products support a wide variety of alternatives, enabling flexible deployment in response to changing requirements. But these products may also be more expensive and more challenging to configure. Narrowing your requirements up-front can reduce your total cost of deployment.

Performance: VPN technologies add packet overhead and make extensive use of encryption, which adds processing delay. However, VPN products can be engineered to minimize the performance impact of authentication and encryption - for example, by using ASICs or co-processor cards to perform encryption at wire speed. It is common to price VPN products based on encrypted throughput, concurrent tunnels, and the number of client licenses or users. These vendor specs can be useful for sizing, but remember that your own mileage will vary - trial the product in your own network to accurately assess capacity. Also consider future growth: are there crypto accelerators, RAM upgrades, or step-up products in the same family?

Transparency and Ease-of-Use: VPN solutions only provide security if they're used. Products that require technically demanding and intrusive user intervention at the desktop are more likely to be subverted than products that operate transparently. Is end-user security policy configuration required at the desktop, making installation and enforcement a support nightmare? Seek out VPN products that provide centralized client management features - for example, the ability to generate canned policies and "push" software updates.

Scalable Management: Basic configuration and monitoring tools are often fine in modest site-to-site VPNs. However, VPNs involving hundreds or thousands of users require more robust management and diagnostic tools. For example, configuring pre-shared secrets in a dozen IPsec gateways requires little automation or infrastructure. But large remote access VPNs can benefit from deploying a Public Key Infrastructure (PKI) to create, distribute, and track digital certificates on a per-user basis. Diagnostic tools that help ferret out VPN protocol configuration problems are invaluable for small and large deployments. Outsourcing is another way to deal with scale - managed VPN service providers already have the necessary infrastructure in place.

These are but a few of the issues that face VPN consumers. The VPN product landscape and supporting technologies are changing rapidly. Continuing refinements are underway - for example, improved compatibility with NAT and stronger IPsec support for remote access VPNs. L2TP and IPsec base standards have been finalized, bringing with them a wave of VPN products. Increasingly, IPsec will simply be embedded in host operating systems and network devices. Product focus has changed from basic functionality and interoperability to advanced features and increased scalability. We are now seeing third and fourth generation products that make VPNs a very credible alternative to private physical networks.

By Lisa A. Phifer
Last Update: April 2001


Visit our Technology Corner to read our VPN product reviews, columns, presentations, and white papers.