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.
