1520-9202/01/$10.00 © 2001 IEEE May ❘ June 2001 IT Pro 41

A Planning Framework for Implementing Virtual Private NetworksWilliam Yurcik and David Doss

A virtual private net-work (VPN) is sim-ply secure networkconnectivity over a

shared public network—basi-cally, a private network on apublic network infrastructure(the Internet). Figure 1 (nextpage) shows an example of anetwork layer VPN (adaptedfrom Paul Ferguson and GeoffHuston, “What is a VPN? PartI,”The Internet Protocol J., June1998,pp.2-19).Corporation X’ssubnetworks (which belong to a common administrative do-main) have established a VPN(depicted by dashed lines)across a portion of the Internet.This VPN is invisible to com-petitor corporation Y eventhough it is using common trans-mission and routing resources.

However, deploying a VPN isnot so simple; it requires exten-sive planning because of its largeup-front investment in hardwareand software, lengthy set-uptime, and ongoing maintenance.Here we present a planningframework for organizationsbased on an actual implementa-tion experience (Samuel Patton,Bryan Smith, and colleagues,“AVirtual Private Network De-ployment Framework,” Proc.IEEE Conf. Local ComputerNetworks, IEEE Press, Piscat-away, N.J., 2000, pp. 225-226).

Despite the common percep-tion that a VPN is not a cus-tomizable solution, a broadspectrum of VPN options isavailable. Network designersdo not anticipate any single

VPN solution to supplant oth-ers. Instead they forecast that a diversity of choices will con-tinue to emerge, increasing an advanced-planning frame-work’s value.

Until recently, corporationsrelied primarily on leasedtransmission capacity or con-tracted data services from com-

mon carriers to create theirown private wide area network(WAN).This model has drasti-cally changed because of

• decreasing costs for Internetconnectivity,

• increasingly higher band-width connections to theInternet, and

• mature encryption technol-ogy for secure Internet com-munications.

A VPN is virtual in that it hasno corresponding physical net-work but rather shares physicalcircuits with other traffic. AVPN is private in that it isolatesInternet traffic with routing andsecures it with encryption. Theuse of “private” and “Internetbased”to describe the same ser-vice appears to be an oxy-moron,but we explain later how

Because there isno single VPNsolution, it’s critical to have a planning frameworkto ensure successful deployment.

VPNs manage to be both.

MOTIVATIONCompanies have several

strong motivations for buildingVPNs; they provide

• a uniform corporate comput-ing environment that is trans-parent to users,

• secure communications, and • the cost efficiencies of using a

common public infrastruc-ture versus building andoperating a private WAN.

While many networking tech-nologies have not lived up totheir initial hype, this is not thecase for VPNs, which are beingwidely deployed and appear tobe earning the nickname “veryprofitable networks.”

A VPN not only drasticallydecreases cost but also increases

42 IT Pro May ❘ June 2001

P E R S P E C T I V E S

flexibility because corporations canestablish or release global Internetconnections on demand.They can alsoinitially pay for low bandwidth andincrease bandwidth as demand grows.

Internet connectivity is also aVPN’s major disadvantage: Guaran-teeing quality of service (QoS) overthe Internet is difficult because aggre-gate traffic flows can be unpre-dictable. Service-level agreements(SLAs) between Internet serviceproviders (ISPs) and corporations arean evolving contractual solutiondesigned to guarantee QoS based onthroughput, availability, and/or re-sponse time thresholds.

DEPLOYMENT DECISIONSMany choices will confront you in

considering how to deploy a VPN.Here we briefly describe the corechoices such as the different types ofVPNs, encryption, firewalls, and howto accommodate legacy systems.

Types of VPNsThe several types of VPNs corre-

spond to the various networking lay-ers: data link, network, transport, andapplication. The most common VPNin use provides secure dial-up (datalink) access. Here, we focus on net-work layer VPNs using IP routers;these VPNs commonly interconnect

LANs.The peerVPN model is one in which

paths are computed on a hop-by-hopbasis, where each node in the path is apeer with a next-hop node.The over-lay VPN model is one in which thenetwork-layer forwarding path is notcalculated on a hop-by-hop basis.Rather, routers use the intermediatelink layer as a “cut-through” toanother edge node on the other sideof a public network.

A subtype of the overlay VPNmodel is tunneling, which is the prac-tice of wrapping a packet with newheader information and allowing anintermediary network to deliver it.The most common tunneling mecha-nism is generic routing encapsulation(GRE) tunneling from source to des-tination router, router to router, orhost to host. Tunnels between source(ingress) and destination (egress)routers encapsulate source packetswith a new GRE header and forwardthem into a tunnel with the tunnel’sendpoint as a destination address.When the packet reaches the tunnelendpoint, the last router strips theouter GRE header away, unencapsu-lating the inner packet. The routerthen forwards this original packet toits original destination,which appearsin the inner packet header.

You can thus create a VPN from a

Y

Y

Y

X

Y

Y

X

X

Routers

Shared publiclinks

Figure 1. A VPN connects corporation X with geographically remote subnetworks.

collection of tunnels between sitesbecause routing is isolated.This isola-tion is possible because the tunnelegress addresses are within a VPNsite’s address space, and the packetswithin the tunnel use a separate VPNaddress space. Tunneling can alsoencapsulate other protocols in a for-mat that preserves their functionality.

You should consider other optionswhen deciding what type of VPN touse:

• Consider using provisioned VPNs,which offer multisite connectivityacross a single ISP backbone.Usinga single ISP backbone enhancesperformance and security.

• Think about combining all VPNfunctions into a single hardenedbox with added redundancy fea-tures, such as multi-homed connec-tions—two or more independentconnections—to multiple ISPs andfail-over backup. Such a configura-tion can be more robust than chain-ing together separate devices, eachof which could fail separately.

• Look for network equipment with abandwidth from 10 Mbps to 100Mbps and the ability to handlemore than 1,000 simultaneous VPNtunnels per device.

EncryptionTunneling does not ensure privacy

because networks typically transmiteven encapsulated IP packets in plaintext.This is clearly a problem if a cor-poration wants to use the Internet totransmit important business informa-tion. The evolving standard for net-work-layer encryption is IP Security(IPSec).

IPSec supports two types of encap-sulation, which are used in combina-tion: an authentication header (AH)protocol and an encapsulating secu-rity payload (ESP). AH providessecure source identification and dataintegrity verification using a headerfield, but does not provide confiden-tiality—fields are left in plain text.ESP supports payload encryption for

May ❘ June 2001 IT Pro 43

practical to establish large VPNs.Widespread use of CAs will dependon the continuing deployment of pub-lic-key infrastructure (PKI), whichincludes directory services and keymanagement, among other services.

After you determine where youwant to implement encryption, youmust choose an algorithm type andkey length appropriate to protectagainst expected threats. With thisinformation you can estimate the pro-cessing resources that encryption willrequire. On average, it takes about 40times more computing effort to routeencrypted data than plain text. Forthis reason, it is essential to determinethe processing level needed at peaktimes to effectively handle a givennumber of secure connections. Con-sider a coprocessor-based encryptionengine for greater throughput.

Knowing that no system is hackerproof, you must also have a plan forrecovery if a hacker compromisesyour encryption algorithm.

FirewallsTunnels and encryption do not

obviate the need for firewalls to filternetwork route advertisements suchthat only specific networks receiveroutes that are within the VPN com-munity of interest. Conversely, non-VPN routes are not forwarded withinthe VPN. This inability of VPN hosts

to respond to packets with sourceaddresses from outside the VPN com-munity of interest provides egresssecurity. Ingress filters prevent out-siders from injecting external packetsinto the VPN.

It’s also important to determinefirewall performance based on VPNtraffic loads. Firewall filtering options(static, dynamic, and stateful) havedifferent performance levels, whichyou must weigh against perceivedrisks. For example, dynamic firewallscan modify their access lists based onday and time restrictions or suspiciousevents (unlike static firewalls), andslower stateful firewalls can be morepowerful since they attempt to iden-tify individual packets as part of validTCP (Transmission Control Protocol)interactions.

Also consider the use of a Webproxy. In addition to preventing directIP connections to user machines,proxies can provide a stronger filter-ing capability. They can be built tomonitor specific protocols and canenforce customized security options,such as the ability to filter out poten-tially malicious ActiveX or Javascriptmobile code.

Accommodating legacy systems

Because VPNs replace existing net-work services, a major concern is how

confidentiality and has two modes:tunnel mode for WAN traffic (theentire packet, including source anddestination addresses, is encrypted toprevent traffic analysis) and trans-port mode (only the payload isencrypted) for LAN traf-fic.

Although mostVPN vendors aremoving to supportIPSec, not all VPNproducts are interoper-able. IPSec-based VPNtraffic can also encounter layer-vio-lating devices—that is, networkdevices that modify packets at thenetwork layer or higher; networkaddress translation devices are themost prevalent example. Such layer-violating devices do not supportIPSec.

In general and independent ofIPSec, end-to-end encryption to indi-vidual end systems provides confi-dentiality with the highest level ofauthentication. However, such con-nections are open to traffic analysisbecause they must leave headers inplain text for intermediate networkdevices. For traffic between networkswhere interoperability may be a prob-lem, the application layer must supplyend-to-end encryption, which resultsin scalability problems for key distri-bution and client uniformity.

Conversely, tunnel mode encryptiontransparently protects traffic betweenVPN subnetworks. It lets participatingend systems remain undetected anddisguises traffic patterns. VPN end-point routers encrypt packets, how-ever, traffic between end systems andthe first-hop VPN router is in plaintext. Any corruption of operation ortraffic interception at tunnel endpointswill compromise the entire VPN.

Hackers foiled in attempts to cracknetwork traffic may instead targetclient machines. Alleviating theseproblems requires a certificate author-ity (CA) to issue and manage digitalcertificates exchanged by VPN devicesand users. CAs solve the authentica-tion scalability problems and make it

The idea of using a public network to create the illusion of a pri-vate data or voice network—one devoted exclusively to spe-

cific subscribers—is not new. The first packet-based VPNemerged in 1975 when BBN delivered the first PrivateLine Interface (PLI) packet encryption devices to pro-tect classified data for transmission over the Arpanet.Another example is Centrex service, which local tele-phone companies have offered for many years as a cen-

tral-office switch service for providing private data andvoice networks. In 1985, AT&T began offering software-

defined networks (SDNs) for private voice networks based on dedicatedand (later) switched connections; telephone companies billed users dif-ferently for on- and off-net calls.

VPNs: An Historical Context

44 IT Pro May ❘ June 2001

VPNs will effect existing operationsand applications.You must consider amigration path for existing networkinfrastructure and existing applica-tions when creating a VPN. No singlevendor or service provider has all theapplication interoperability answersfor a VPN,and legacy applications willremain.

Issues related to legacy systemsinclude the following:

• In a heterogeneous, multiprotocolenvironment, a VPN must supportlegacy protocols.

• Encryption may block legacy net-work management functions.

• As VPNs become larger, networkmanagement tasks grow exponen-tially, making outsourcing attrac-tive; managed VPN services is agrowth industry.

• You should identify legacy net-worked applications and determinethe effect of potential addressingchanges. Examples include DNSand e-mail applications.

• From a security perspective, thepotential for undetected misconfig-uration of general-purpose legacyoperating systems makes them apoor VPN foundation.

A detailed plan to deploy a VPNshould include a pilot network withnoncritical traffic. After successful

completion of a pilot network, theplan should slowly migrate networkpartitions one at a time into the newVPN. You should simultaneouslymaintain the legacy production net-works during the entire process—thisoverlay capability is one of the mainflexibility features of a VPN. It isadvisable to start with a minimal setof VPN features, gradually turn onnew capabilities, and let the networkstabilize. You should turn off thelegacy production network only afterthe operations and user communitiesgain confidence in the new VPN.

M any people use the term“VPN” generically as if itwere a single specific solu-

tion. In the end,however,each distinctVPN solution has its own strengths,weaknesses, and price tag; IT profes-sionals must weigh these characteris-tics against business requirements.Future VPN research directionsinclude taking advantage of the QoScapabilities of multiprotocol labelswitching (MPLS).MPLS is a methodof assigning labels that tell routerswhere to send a packet and what pri-ority that packet should receive,potentially combining the use of net-work-layer routing and per-packetswitching with link-layer circuits andper-flow switching. �

William Yurcik is an assistant profes-sor of applied computer science at Illi-nois State University. Contact him atwjyurci@ilstu.edu.

David Doss is an associate professorand graduate program coordinator inthe Department of Applied ComputerScience at Illinois State University.Contact him at dldoss@ilstu.edu.

P E R S P E C T I V E S

We recommend these sources for further background on network-layervirtual private networks.

➤ “A Framework for IP Based Virtual Private Networks,” BryanGleeson and colleagues, Internet Engineering Task Force RFC 2764,Feb. 2000; http://www.ietf.org/rfc/rfc2764.txt.

➤ Virtual Private Networks, 2nd edition, Charlie Scott, Paul Wolfe, andMike Erwin, O’Reilly, Cambridge, Mass., 1999.

➤ Virtual Private Networks: Technologies and Solutions, Ruixi Yuanand W. Timothy Strayer, Addison-Wesley, Reading, Mass., 2001.

➤ Virtual Private Networking: A View from the Trenches, BrucePerlmutter with Jonathon Zarkower, Prentice Hall, Upper SaddleRiver, N.J., 2000.

Resources

ED I TOR IA LCA L ENDARED I TOR IA LCA L ENDAR

JULY/AUGUSTFault Tolerance

SEPTEMBER/OCTOBERSoftware OrganizationalBenchmarking

NOVEMBER/DECEMBERUbiquitous Computing