Welcome to the Core Competence

We receive many questions about VPNs. Many of these are electronic mail inquiries in response or reaction to columns and reviews we write for ISP-Planet, TechTarget, BCR, Internet Protocol Journal, and other publications. Other questions are raised when we present seminars and workshops at The Internet Security Conference (TISC), Interop, and on-site classes. We've cataloged some of the most common questions here, and will add to the list as we receive new questions from you. To be notified about VPN articles, workshops, and major updates to this page, subscribe to our monthly CornerStone e-newsletter.


Dave & Lisa


Last Update: May, 2001



The term "VPN" seems to be applied to lots of technologies and services. ATM and Frame Relay networks claim to be VPNs, ISPs call quality of service offerings "VPNs", and security vendors claim the only true VPN is IPsec? What exactly is a VPN?

Actually, *all* are Virtual Private Networks in the broadest sense. All are "virtual networks" -- logical overlays. Tunnels or virtual circuits are created to interconnect physical locations (e.g., branch offices, roaming users, business partners). The term "private" has at least two interpretations. For ATM and Frame Relay, private means that the virtual circuits connect a closed group or community of users. For IPsec and other protocols that use cryptography to provide authentication and confidentiality, the term "private" still means a closed user group. But it also means message confidentiality: traffic is encrypted so that no "man in the middle" can capture or modify information passed site-to-site or user-to-user. Further discussion can be found in our on-line white paper "VPNs: Virtually Anything?"


Are IPsec-based VPNs better than ATM or Frame Relay virtual networks?

They are really different beasts. A comparison can be made for site-to-site connectivity. ATM and Frame Relay networks provide quality of service (QOS), but don't provide authentication and encryption features of IPsec. You might call these "Virtual PERFORMANCE Networks" since the emphasis is on QOS, not security. Because ATM and Frame Relay networks ride over "private" circuits, used exclusively for your own intersite traffic, they usually take some time to deploy.

IPsec VPNs were developed to speed deployment and reduce cost by riding over any public network, including the Internet. Traffic to the Internet and to other sites can be co-mingled over dial-up, ISDN, DSL, cable, or even Frame Relay links used for Internet access. However, when IPsec VPNs use the public Internet today, they are often limited to "best effort" QOS.

Large providers offer high-performance IPsec VPNs. These premium VPN services increase cost but guarantee QoS by routing IPsec traffic over the ISP's own access links and backbone network. As ISPs roll out quality of service using MPLS (multiprotocol label switching), they will begin offering "differentiated" VPN services that span multiple networks. Customers will be able to choose -- and pay for -- either best effort or guaranteed service levels (e.g., low latency, low loss, committed throughput).


What is a "managed VPN service"? What is a "network-based VPN?" How do they differ?

A managed VPN service is one that is built and operated by a trusted third party, like an Internet Service Provider (ISP) or a Secure Application Service Provider (SASP). This third party designs the site-to-site or remote access VPN solution you need and manages it on your behalf.

The service may use a security gateway -- a firewall, router, or other VPN device -- located at your premises. This type of service is often referred to as a customer premises equipment (CPE) VPN. Today, dozens or hundreds of tunnels -- at most, a few thousand tunnels -- can be supported by each CPE device. With a managed service, the provider usually supplies, configures, and monitors the device. The provider may also need to visit your site for device installation or maintenance.

Network-based VPNs use carrier-class VPN switches, embedded at ISP points of presence (POPs) or telco central offices (COs). These switches are designed to support very large numbers of customers, with many sites and/or remote users -- hundreds of thousands of high-speed tunnels. Creating a network-based VPN is accomplished by reconfiguring the switch instead of placing equipment at your site. Sites are usually connected to the switch using DSL or Frame Relay -- access links that are assumed to pose little security risk. At the switch, IPsec tunnels are used to protect inter-site data sent over the provider's backbone or the public Internet.


Routers, switches, firewalls, security appliances, and servers all support IPsec? Which is the better implementation?

This is as much a religious issue as much as it is a marketing issue. In our view, deploying IPsec in routers isn't the best alternative because the primary purpose of a router is to "route" and "forward" IP datagrams as quickly as possible; IPsec encryption is very demanding and can seriously impact router throughput unless the vendor has (re-)designed the router to include hardware crypto-acceleration.

A software firewall running a general-purpose operating system like NT, Solaris, BSD, or Linux can also be adversely affected by software-based encryption. Again, some vendors add hardware acceleration in NICs to compensate.

Security appliances combine firewall features and tunneling protocols like IPsec; many of these are specifically designed with custom ASICs to encrypt and authenticate at high data rates. We believe that implementing IPsec on a hardware platform designed for this task has the best chance of acheiving optimum throughput.


We use 2-factor (token plus password) authentication in our company -- can we continue to use this with IPsec?

According to the existing IPsec standards, you can only use pre-shared keys, raw digital signatures, or digital certificates for IPsec tunnel endpoint authentication. We find the IETF IPsec working group's failure to accommodate "legacy" user authentication to be a serious oversight. Standard extensions are now being designed to address this omission, but there is little consensus on the best way to accomplish this objective.

But, many VPN products support two-factor authentication today, using proprietary and draft standard methods that limit multi-vendor interoperability. So, yes, you can use two-factor authentication with IPsec today, as long as you select a vendor that supports it, and use only that vendor's IPsec client software (e.g., not the Windows 2000 IPsec client).


Do I need to operate my own certification authority (CA) to support my IPsec VPN?

Strictly speaking, you don't have to use certificates. You can use pre-shared keys or raw digital signatures, if your vendor(s) support these authentication alternatives.

If you want to use certificates, you have several choices. (1) Use a third party CA service from Genuity, Verisign, etc. (2) Build your own CA using software from Entrust, XCert or Baltimore Technologies (to name just a few). Both choices provide a full-blown public key infrastructure (PKI), which is useful in very large organizations and when extending VPN access to business partners or customers.

If all you need is a few certificates for IPsec gateway authentication, then there is a third option. (3) Use what some vendors call an "internal CA" -- software that runs on one IPsec gateway, with administrative software that lets your admin create and revoke digital certificates for your VPN. This approach is more limited than a full-blown PKI, but can be less expensive to deploy and easier to manage. Consider an "Internal CA" if you're building a centrally-administered Intranet VPN.


My Extranets and Intranets use the security protocol provided with browsers? Can I use SSL/TLS for my e-business as well?

Absolutely. Many initially overlook Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) because of the attention IPsec draws. SSL can be very attractive for e-business because it may require no special software, hardware, or other infrastructure. Every browser supports server-side SSL today, but comparatively few desktops support IPsec today. Although new operating systems include IPsec, most desktops still require third-party client software -- and will for quite some time. Adding software can be a significant helpdesk issue for the e-business operator.

SSL is commonly used to support encrypted, authenticated connections between a web server and a browser client. In most (not all) cases, only the server is authenticated. Your browser trusts the server because it trusts the CA that issued the server's certificate. Once the SSL connection is established, the server may "sub authenticate" the client -- often with a username/password. These point-to-point secure connections are very useful for e-commerce, but are not by themselves a "network".

To create a true SSL VPN, use an "Extranet" and "single sign-on" product that operates as a network gateway. These gateways "proxy" SSL connections over untrusted links like the Internet, protecting information exchanged between e-business partners. Most SSL proxies support multiple authentication methods, including stronger user authentication than typically employed for e-commerce. SSL VPNs may or may not add client software to the desktop.


What's the difference between PPTP, L2F, and L2TP, and which should I use for secure remote access?

PPTP (Point to Point Tunneling Protocol) is a remote access tunneling protocol originally created by Microsoft. It offers compression, comparatively weak encryption, and is viewed by many as a "make do" remote access VPN solution. L2F (Layer 2 Forwarding) is Cisco's proprietary tunneling protocol, designed to provide authenticated (but not encrypted) remote access. Both have been superceded by L2TP/IPsec. New deployments no longer use L2F, and PPTP use is expected to dwindle.

L2TP is a standard Layer Two Tunneling Protocol defined by the IETF. Windows 2000 uses L2TP over IPsec for remote access; many other VPN vendors offer their own IPsec remote access client. Most new VPNs use either L2TP/IPsec or IPsec with vendor extensions (see two-factor authentication).

L2TP solves tunneling and user authentication aspects of remote access nicely, particularly for ISPs. But L2TP doesn't provide encryption. If you require confidentiality, run L2TP on top of IPsec. If you're running your own remote access servers, you may be able to use IPsec tunnels without L2TP.


What are some of the questions I should ask my VPN vendor before I buy into a VPN "solution"?

High on your list should be questions like "Do you use hardware acceleration for encryption?" and "What authentication methods do you support?" If you think you need PKI, ask "Can you support X.509 v3 certificates, and which CA products can you support?" If you expect to purchase products from more than one vendor, or to communicate with a business partner's VPN, ask for the list of other-vendor products your VPN vendor claims to interoperate with. Ask when, where, and with which version interoperability testing was performed. If you're going to deploy secure remote access, ask what third party IPsec client software is required, if the product interoperates with the Windows 2000 IPsec client, and whether there are known adapter limitations and dependencies. The list of relevant questions is quite lengthy, and differs for each enterprise. These are just a few to get you started.


Some IPsec vendors claim to be "standards-compliant", or "ICSA Certified". Others belong to a VPN Consortium and have a "Conformance" logo? What's the difference and which is most important?

In our opinion, "standards-compliant" alone is rather meaningless -- this really only says that the vendor used IETF RFCs when engineering the product.

According to the VPN Consortium's own web site, this group is an "international trade association for manufacturers in the VPN market." They issue conformance logos to member company products that have passed interoperability tests defined and agreed upon by the consortium. Interoperability testing provides an excellent opportunity to identify and fix pairwise problems. We definitely recommend interoperability testing, and would seriously question any product that has never been tested against others. But, in our opinion, consortium testing is not as stringent as independent third-party testing.

ICSA conformance tests verify correct implementation of features deemed important by user groups like the Automotive Network Exchange (ANX). Colleagues at ICSA tell us that many products don't pass conformance tests the first time, or even the second. We're thus inclined to believe the ICSA tests are rigorous. Perhaps the best thing about third-party conformance testing is that someone other than the vendor has performed quality assurance testing. For these reasons, we think third-party certification should carry more weight than consortium branding.

Your VPN product should first satisfy all your security policy and deployment criteria. Only then should you worry the issue of interoperability -- and you should make your vendor demonstrate in configurations that reflect your intended use before you sign. A useful paper on IPsec trouble-shooting for multi-vendor VPNs can be found at ICSA's website


I've heard that VPNs hurt performance, how badly?

This question is very product specific. Generally, products that perform crypto in software take a performance hit, whereas those that employ hardware encryption *should* operate faster than those that do not.

Many products claim "near-wirespeed" at up to 100 Mbps. Be cautious of such claims, because these tests are usually conducted with equipment that pushes bits through pipes, and the bit streams don't always exhibit the same characteristics (length and composition) that real data exhibits. Your best bet is to benchmark the equipment using actual workflows (or approximations) before you buy.


If I install a VPN appliance, can I get rid of my firewall?

This depends on the firewall features found in your VPN appliance. If your existing firewall supports stateful packet inspection, application proxies, content inspection, spam filtering, and effective logging, be sure your VPN appliance does all these just as well before you get rid of your firewall. If you keep your existing firewall, you have to decide where to put the VPN appliance -- in front of the firewall, behind it, or next to it. There are issues with each of these approaches, which we'll explore in a future FAQ.


If I move off my ATM and Frame Relay network and onto an IPsec VPN offered by my ISP, can I expect similar quality of service?

This depends entirely on the VPN service your ISP offers. Some ISPs have guaranteed Quality of Service and performance-differentiated services, backed by service level agreements (SLA). If you are concerned with QOS, be certain that you negotiate a stringent -- and meaningful -- SLA. Make sure your provider gives you simple, timely access to monitored performance metrics. Look for a provider that publishes its SLAs and offers pro-active service credits in the event of non-complaince. Some top-tier ISPs offer Site-to-Site VPNs with SLAs, including Genuity, MCI/UUNet, Sprint, and AT&T. Remote access VPN SLAs are less common, but do exist. Few SLAs today extend beyond the provider's own access links or backbone, although MPLS and SLA peering agreements may someday change this.



What is a network-based VPN? How does it differ from other VPNs?

The phrase "Network-based VPN" has been used to describe a wide variety of services. In this FAQ, we use the term to describe managed VPN services that tunnel from a provider's network edge, using carrier-class IP services routers sold by vendors like CoSine, Lucent (Spring Tide), and Nortel (Shasta).

Until very recently, most VPNs tunneled from the customer's network edge, using an IPsec-enabled access router, firewall, or gateway. In a managed VPN, customer premises equipment (CPE) is supplied, installed, and monitored by a service provider. As CPE VPNs grow in number and size, they become far more challenging to operate cost-effectively.

Network-based VPNs can speed service turn-up, increase flexibility, and scale more efficiently because they employ IP services routers -- large, robust boxes designed for use at an ISP POP or carrier CO. These platforms use "soft provisioned" virtual routers to support hundreds of customers and hundreds of thousands of tunnels on a single device.


Who are the major players in the network-based VPN market today?

Infonetics Research publishes a quarterly market share report on Service Provider Core and Edge Hardware. This report estimated a $339M market for IP services routers this year, shared by Nortel Networks, CoSine Communications, and Lucent Technologies.

In 1999, Nortel Networks acquired Shasta Networks and its 5000 Broadband Service Node (BSN). In 2000, Lucent acquired Spring Tide and its IP Service Switch 5000. CoSine's IP Service Delivery Platform is based on the home-grown IPSX 9000. Cisco also entered the virtual router market with the 5000 VPN concentrator series, acquired from Compatible Systems. Redback's EdgeSwitch is more an aggregator than an IP services router.


Who are the early adopters in this market?

According to Infonetics, 26% of tier 2 providers in the US have network-based tunneling now, and 43% expect to do so within a year. Customers announced by "the big three" include @Link, AduroNet, Arcor, AT&T Wireless, BellSouth, BroadBand Office, BroadWing, Broadslate, DefendNet, Ionex, JazzTel, Korea Telecom, Quebecor, Qwest, Savvis, Telstra, Vanion, and Zyan.

We recently interviewed AduroNet, Broadslate, and Savvis about their network-based VPN services. All are in early phases of deployment. If you're interested in reading what these early adopters had to say, visit www.isp-planet.com.


In CPE VPNs, there is a success-based cost model: you pay for the equipment as you sell the service, with no big up front charges. Don't network-based VPNs require a big capital investment?

There's no denying that CPE-class devices have a much smaller initial price tag. Enterprises that roll their own VPNs use CPE-class devices. And smaller providers do benefit from the "pay as you go" CPE model. Some even pass along the cost of CPE in managed VPN start-up fees. The CPE model also lets a provider experiment with emerging technology without committing to one vendor or platform.

But, in large deployments, operational costs often over-shadow initial investment in CPE. It's important to consider total cost of ownership and return-on-investment. Buying into an IP services router makes sense for larger ISPs and carriers that can afford to invest up-front for bigger returns down the road. Network-based VPNs can reduce cost by eliminating truck rolls, speeding service turn-up, and simplifying maintenance. As the customer base grows, so does the profit margin.


Don't site-to-site VPNs still require CPE, even with a network-based VPN?

Yes. But, when intelligence moves into the network, less expensive gear can be used at the customer premises. Inexpensive bridges can replace more sophisticated VPN-enabled access routers. Customer self-install and provider drop-ship become feasible. By replacing private Frame Relay and CPE VPN services with network-based offerings, Savvis actually cut their capital equipment costs by a factor of 5.


What kinds of services do carriers offer with network-based VPNs?

IP services routers can be used to offer managed VPN services similar to those deployed with CPE today: site-to-site VPNs, remote access VPNs, even Extranets. Soft provisioning makes adding application services like firewalls, anti-virus scanning and content filtering faster and less error-prone.

Software-defined services are also easily bundled. For example, a carrier might offer a "secure teleworker" service that combines a DSL subscriber line, corporate VPN access, Internet access, and basic firewall rules. The same platform might also be used to offer Frame Relay-IPsec interworking, helping customers transition from an existing private network to a less expensive VPN solution. An IP services router is only a delivery platform: carriers must find new ways to leverage this investment to create new revenue opportunities.


Won't lack of encryption on the last mile put carriers using network-based VPN technology at a competitive disadvantage?

CPE VPNs use IPsec tunnels to protect all data entering or leaving the enterprise network. Network-based VPNs usually rely on private layer 2 links -- usually DSL or Frame Relay connections -- between the customer site and the POP or CO. From that point, IPsec tunnels encrypt data sent over shared infrastructure: the provider's backbone network and the public Internet.

The network-based VPN providers we've interviewed say that most customers are comfortable limiting encryption to at-risk hops. Customers whose security policy is satisfied using FR or ATM are usually convinced that access circuits don't represent a risk -- they are really concerned about encrypting traffic over the public Internet.

But customers may want an *option* to encrypt traffic on the last mile, even if they don't usually exercise it. To meet this requirement, most IP services routers will accept tunnels from selected CPE -- and from IPsec clients for remote access. High-risk industries that need end-to-end encryption and/or authentication may not be satisfied by either CPE or network-based VPNs -- they may require client-to-server or peer-to-peer tunnels.


Is anyone testing interoperability between CPE and network-based VPN routers?

We are not aware of any third-party interoperability tests. Most vendors conduct pairwise tests as needed to meet customer requirements. For example, Nortel has certainly evaluated interoperability between the Contivity Extranet Switch and the Shasta 5000 BSN. And, according to Broadslate, Lucent resolved early interoperability issues between Spring Tide and Windows 2000.

ICSA Labs and the VPNC both conduct third-party conformance tests. CoSine and Lucent have passed VPNC's basic conformance test. VPNC would actually prefer to conduct interoperability tests, but has not yet persuaded its members to devote the required resources. But remember: conformance does not ensure interoperability!


How is quality of service controlled in a network-based VPN? As providers move to an IP-based core and technologies like MPLS, where will this leave network-based VPN routers?

Bandwidth management and traffic shaping services can be offered in network-based VPNs today. For example, the Shasta 5000 BSN can map DiffServ markings, applied at the customer premises, to ATM QoS across the backbone. DiffServ markings can also be used to control committed rate, burst size, and drop precedence within the BNS.

In the future, MPLS tags can be applied at the edge of a network-based VPN, based on DiffServ markings or QoS parameters configured for the VPN. The virtual router in the IP services platform will essentially play the role of an MPLS-enabled access router.


Doesn't the network-based VPN model require all traffic to be routed through central box, creating problems with scale and resiliency?

Moving intelligence into the network does not require hub-and-spoke routing. In a network-based VPN, physical networks can be constructed with any topology, including full mesh. With hundreds of customers being served by a single box, IP services routers are usually deployed in redundant pairs with link diversity. The providers we've interviewed all designed their networks with this kind of resilience in mind.

Furthermore, IP services routers are carrier-class boxes with built-in high-availability and redundancy. They use crypto accelerators to provide high-speed encryption for hundreds of thousands of tunnels. These vendors argue that network-based VPNs are more resilient and scalable because the nodes themselves are more robust. With any new product, this claim must be put to the test. Early beta success is not necessarily proof. We'll be more convinced once we see very large production networks in place.



What's the difference between remote access and a secure remote access VPN?

Traditionally, companies operated their own remote access servers and modem pools to provide enterprise network access to travelers, teleworkers, and day extenders. Unless the workforce is very localized, toll and 800# charges can really add up. Since the Internet is accessible from nearly everywhere today, many companies have started to provide remote access over the Internet. But this approach introduces new security threats, like unwanted disclosure of confidential data and increased risk of unauthorized access. Remote access VPNs apply use cryptographic techniques and tunneling protocols to neutralize these threats.


How much can a company save by using a secure remote access VPN?

Remote access costs depend upon a number of factors, including remote user population, the number of simultaneous users on-line, the number of local, domestic long distance, international long distance, and 800# hours / month / user, existing investment in RAS equipment and network infrastructure, corporate network topology, and bandwidth requirements. Telco charges dominate cost and thus account for most of the potential savings. Up-front investment is often less significant, recovered in a matter of months. One cost that is not usually diminished is "helpdesk" support. In many cases, overall savings can run 40-60%. To view a few examples, visit http://www.isp-planet.com/technology/vpn_roi1.html


What techniques are used to secure remote access VPNs?

When corporate data leaves the enterprise network perimeter, security measures are required to prevent eavesdropping, recording for later replay, message modification, and spoofing (masquerading as a legitimate user or host). Encryption algorithms like 3DES can be used to prevent sniffing. Hashed message authentication codes like MD5 can be used to protect message integrity. Authentication methods like shared secrets, public keys, digital certificates, one-time passwords, and hardware tokens can be used to verify system and user identities. These techniques protect data in transit, but must be combined with appropriate access controls and hardened platforms for complete security.


What is IPsec? How does it differ from L2TP?

IPsec extends the IP protocol to protect packets routed between IPsec-enabled hosts and security gateways, separated by any intervening IP network. Private packets are wrapped inside IETF-defined headers that provide message integrity and confidentiality. The Internet Key Exchange (IKE) authenticates tunnel endpoints and negotiates security parameters for IPsec. Together, IPsec and IKE can be used to create site-to-site VPNs, tunneling over the Internet from one enterprise LAN to another. IPsec and IKE are also used to create remote access VPNs, letting dial-up clients tunnel encrypted, authenticated IP to security gateways, thereby gaining access to the private network behind the gateway.


How does IPsec differ from L2TP?

IPsec and L2TP operate at two different layers of the protocol stack. Layer two tunneling protocols connect individual hosts to entire networks, using PPP. IPsec routes protected traffic across an IP network, carrying private packets into a network in accordance with gateway security policies. Because they are designed to carry PPP, layer two solutions provide native support for common remote access requirements like user-level authentication and dynamic address assignment. IPsec is designed to provide strong, flexible, per-packet security. To get both, L2TP can be combined with IPsec to provide secure remote access.


What technology does Microsoft use in its Dialup Networking VPN client?

For years, Microsoft has been shipping PPTP with Windows NT RRAS and Windows 9x dial-up networking. PPTP has undergone refinement over the years, in response to discovered security issues. You can find a cryptanalysis of PPTP MS-CHAPv2 in this Microsoft security bulletin at www.microsoft.com/technet/security/bulletin/MS98-012.asp. In Windows 2000, Microsoft added IPsec and L2TP to its Dialup Networking VPN client. Enterprises that want to use embedded Windows clients for secure remote access now have a choice of Microsoft's PPTP or IETF-standard L2TP over IPsec.


Can I purchase a secure remote access VPN from my service provider?

Some enterprises outsource Internet access but operate their own VPN remote access concentrators. Alternatively, there are many ISPs that offer managed remote access VPN services, including AT&T, Genuity, and MCI/UUNET. These providers offer secure tunneling services that run on top of vanilla Internet access, plus VPN client software, security policy configuration, 24/7 remote monitoring, and usage reporting. Some providers also offer service level agreements (SLAs) that specify metrics like availability and connect speed.


Can't SSL be used to enable secure remote access?

Enterprises that require only a secure web portal may be satisfied using ordinary browsers and SSL. Like IPsec, SSL provides authentication, encryption, and message integrity. However, SSL operates at the application layer, securing an HTTP stream. Typically, the browser client authenticates the server, but the server does not authenticate the client. Mutual strong authentication with SSL requires a browser add-on. SSL can be an attractive alternative for enterprises that don't have control over the remote desktop (for example, in Extranets), and where the application to be accessed can be hidden behind a web front-end.


Can secure mail programs be used for secure remote access?

Securing access to specific applications is a another Internet-based remote access option. For example, there are many secure email programs that use a variety of application security measures, including PGP, S/MIME, SMTP-over-TLS, and APOP. Secure system administration can often be accomplished using Telnet over SSH or TLS. Secure teleworker access to corporate desktops can be accomplished with browser-based remote control services. Strictly speaking, these are not virtual private *networks* - they secure application streams rather than network connections. Don't get hung up on that detail: these can be efficient, secure methods for providing remote access to enterprise applications.



Where can I learn more about VPNs?

Websites that we recommend for more VPN information include:

  VPN Labs
  Hologuard VPN Learning Center
  VPN Consortium
  IETF IPsec Maintenance Working Group
  IETF L2 Working Group
  ICSA Certified IPsec Products
  Let us know about resources you think should be added to this list.