Virtual Private Networks: Making a Public Network Private

Articles and Tips:

Linda Boyer

01 Feb 1998

During the past six months, trade magazines have published more than 150 articles about Internet-based virtual private networks (VPNs). Given the extensive coverage of VPNs, you probably know at least this much about them: VPNs save companies money. Unfortunately, you may not know why this statement is true because your understanding of VPNs is probably clouded by the ambiguous definition of a VPN and the many VPN-related acronyms. (See "VPN Glossary".)

To help you understand VPNs, this article narrows the broad definitionof a VPN and explains the advantages and disadvantages of implementing aVPN. This article also discusses the types of VPN solutions available, focusingon today's only VPN solution that runs on IntranetWare and NetWare: Novell'sBorderManager VPN component.

WHAT IS A VPN?

If you asked a dozen people what VPNs are, you would probably get a dozen different answers. The baseline definition of a VPN is ambiguous and has given rise to several interpretations. (See "Clearing Away Virtual Cobwebs.) However, the interpretation that is currently getting all of the attention--including the attention of this article--is that a VPN is a secure communications channel, called atunnel, across an existing network that has an IP infrastructure. Before sending data packets through this secure tunnel, the VPN devices that built the tunnel encrypt the data packets and then affix an unencrypted packet header. VPN devices can be hardware (such as gateways or routers), software (running on clients or servers), or a firewall (complete with a VPN component, of course).

The existing IP-based network might be a private intranet but, more commonly,is the public Internet. An Internet-based VPN connects multiple LANs overthe Internet. Depending on the solution, a VPN can also connect remote usersto the corporate network or, less commonly, remote users to each other.

A LAN-to-LAN VPN provides most of the same benefits as a private WAN.Branch offices connected by a LAN-to-LAN VPN can access files and applicationson the corporate network without compromising security--just as these officescould if you leased dedicated lines to connect these offices to the corporatenetwork.

Similarly, a LAN-to-client VPN provides most of the same benefits thatyou would get from installing a modem bank or a remote access server onthe corporate network. That is, remote users on a LAN-to-client VPN canaccess files and applications on the corporate network without compromisingsecurity. However, remote users on a VPN gain that access by dialing a localtelephone number to connect to the Internet rather than dialing a long-distancetelephone number to connect to the modem bank or the remote access server.

Whether LAN-to-LAN or LAN-to-client, a VPN provides most but not allof the same benefits as the traditional wide-area or remote access solutions.Because a VPN uses the public, relatively unreliable, and notoriously insecureInternet, some important distinctions exist between VPNs and other privatesolutions: cost, security, and performance.

Less Expensive Than a WAN

Although the precise definition of a VPN varies, one claim remains constant:VPNs save companies money. This claim isn't hard to prove. After all, ifyou implement a VPN instead of a WAN, you do not need to lease costly privatelines. And if you implement a VPN that supports LAN-to-client connections,you won't need to pay the toll-free or long-distance telephone fees associatedwith a modem bank or a remote access server.

With a VPN, you use your company's existing connection to the Internet.The cost of the connection coupled, of course, with the cost of the VPNitself are the only costs of implementing a VPN. And with a VPN that supportsLAN-to-client connections, the only cost for remote access is the U.S. $20-per-monthrate an Internet service provider (ISP) charges. By paying this monthlyfee, remote users can establish a private connection with the corporatenetwork by dialing the telephone number (usually a local one) for the ISP'snearest Internet access server.

But how much money will your company save?"A lot"is typicallythe closest thing you will get to an answer from vendors and ISPs. In theirdefense, it's nearly impossible to specify the exact amount of money yourcompany could save by implementing a VPN because so many variables exist.For example, this amount varies depending on several factors.

The VPN solution that your company chooses
The number of LANs and users your company wants to connect
The location of the LANs and users
The cost your company would have paid to implement a WAN or to install a modem bank or a remote access server

Nevertheless, because low cost is the main advantage of VPNs, a few trademagazines and vendors have calculated savings based on hypothetical cases.For example,InfoWorldrecently estimated that within three yearsyou could save between U.S. $650,000 and U.S. $1,000,000 by using a VPNrather than private leased lines to connect 20 LANs. (See"Unhook YourLeased Lines,"InfoWorld, Sept. 22, 1997, pp. 80[shy ]96. Thisparticular reference is from the"VPNs Yield Big Savings Compared WithLeased Lines"chart on p. 84.)

In addition, TimeStep Corp. estimates that the monthly costs for a frame-relay network connecting five LANs would be more than double the monthly costs for a five-LAN VPN built on PERMIT Enterprise, TimeStep's hardware-based solution. (The Business Case for VPNs, White Paper, TimeStep Corp., Sept. 1997, p. 6.) TimeStep points out that as you scale to 100 LANs the costs associated with private leased lines rise, whereas the costs associated with a VPN remain about the same.

TimeStep presents another hypothetical case that illustrates the costsassociated with two remote access solutions. If a company had 75 remoteusers who dialed a long-distance telephone number to connect to the corporatenetwork for 20 hours per month, the company would pay approximately U.S.$15,000 per month in long-distance telephone charges. However, if theseremote users accessed an ISP's local Internet access server to connect tothe corporate network over the Internet, the company would pay approximatelyU.S. $4,100 per month for Internet access, a T-1 line, and local loop charges.

As Secure as a WAN

Despite the unequivocal low cost of a VPN, some companies are reluctant to use one. A July 9, 1997 press release from Forrester Research sheds some light on the reasons behind this reluctance. (For more information, go to http://www.forrester.com.)

This press release notes that only 4 percent of the Fortune 1000 companiesForrester Research interviewed use the Internet for remote access. Why sofew? Not surprisingly, these companies are concerned about the security,reliability, and performance of the Internet. Because most VPNs are Internetbased, these concerns affect perceptions about the security, reliability,and performance of VPNs as well.

Concerns about the reliability and performance of VPNs are well-founded. (See the "Not as Fast as a WAN" section.) However, concerns about the security of VPNs are not. In terms of security, the difference between VPNs and other private solutions lies only in how VPNs create tunnels--not in the level of security these tunnels offer. VPNs are as safe to use as WANs that run entirely over private leased lines.

In fact, A. E. Natarajan, engineering manager for Novell's BorderManagergroup, asserts that a VPN is"actually more secure than a [private]leased line."With a private leased line, Natarajan explains, yourcompany's data is unencrypted. As a result, if someone taps into this line(which is a possibility, contrary to popular belief), the data is therefor the taking.

A VPN, on the other hand, uses any one of several cryptographic algorithms and keys of varying lengths to encrypt your company's data. (See "The Key to Security.) Even if someone managed to tap into the encrypted tunnel, he or she would be unable to read the data in this tunnel.

Encrypting data is only one of several security mechanisms at work ina VPN and, arguably, not the most important one. According to Mal Radalgoda,director of Marketing at TimeStep, the encryption scheme a product usesis not proof of that product's security, despite what some companies mightlead you to believe. The true test of a product's security, Radalgoda contends,"is the security protocol the product uses to guarantee that a VPNsession is established securely."

The security protocol that TimeStep and many other vendors have chosento support is IP Security (IPSec). Under development since 1989, IPSec isan industry standard for establishing tunnels over IP-based networks suchas the Internet.

The Internet Engineering Task Force (IETF) is currently reviewing a revision of the IPSec standard. Most vendors intend to support the revised version of the standard when it is finalized. (You can find the draft of the proposed standard in Requests for Comments (RFCs) 1825[shy ]1829. To read this draft, go to http://www.internic.net/ds/rfc-index.1800-1899.html, and access RFCs 1825[shy ]1829.)

Not as Fast as a WAN

If a VPN provides a low-cost, high-security alternative to WANs and remoteaccess solutions, why doesn't every company rush out to buy a VPN solution?Most companies share justifiable concerns about the reliability and performanceof VPNs. Since Internet-based VPNs are built on the Internet, they cannotoffer better reliability and performance than an Internet connection.

For example, an Internet-based VPN cannot guarantee quality of service.Simon Kandah, product manager for BorderManager, suggests that as the VPNindustry matures,"it will start to look toward guaranteeing qualityof service over the Internet."In the meantime, Kandah admits, somecompanies"will require private WAN connections because these connectionscan guarantee quality of service."

An Internet-based VPN is not only incapable of offering more than theInternet but can actually offer less. Encrypting and decrypting data areintensive functions that take their toll on a VPN's performance. The bottomline is that a VPN might be as secure as a private leased line, but a VPNisn't as fast.

On the other hand, Internet reliability and performance and, therefore,VPN reliability and performance might not be as bad as you think. For example,in a recent comparison of several VPN solutions,InfoWorldconcludedthat concerns about Internet reliability are often"blown out of proportion."In fact,InfoWorld"didn't experience any outages or unpredictableresults."

InfoWorldalso asserted that concerns about VPN performance areunfounded. The VPN solutionsInfoWorldtested were no more than 15percent slower than a 56 Kbit/s private leased line.

Not surprisingly, encrypted data is largely responsible for making VPNsslower than leased lines. However, encrypted data does not degrade performanceas much as you might think. When comparing the performance of encryptedfile transfers to unencrypted file transfers,InfoWorldfound thatencrypted data seldom degraded performance by more than 10 percent.

Not Quite Interoperable

If you want to implement a VPN, you should be aware that most VPNs todayare not interoperable. Although support for the IPSec standard goes a longway toward increasing the potential for interoperability, this support doesnot guarantee interoperability. For example, the IPSec standard includesa suite of protocols, and not all products that support this standard supportthe entire protocol suite.

Even products that support the entire IPSec protocol suite might not be interoperable. The IPSec standard also supports two key management schemes: Simple Key Management for Internet Protocol (SKIP) and Internet Security Association and Key Management Protocol/Oakley (ISAKMP/Oakley). (See "VPN Glossary.) Products that do not use the same key management scheme are not interoperable. Thus, a product that uses SKIP does not interoperate with a product that uses only ISAKMP/Oakley.

And while using the same key management scheme guarantees that productsare theoretically compatible, using the same key management scheme doesn'tguarantee that the products' configurations are."You'll have to dosome tweaking to ensure that the configurations are nice to each other,"Natarajan says with a laugh."Welcome to the world of VPNs."

THE WORLD OF VPNS

Today's VPN solutions fall into one of four categories:

Firewall-based solutions
Software-based solutions
Hardware-based solutions
ISP-based services

The VPN solutions in each category have unique advantages and disadvantages, as the next sections explain. (For a list of representative solutions from each category, see "VPN Solutions".)

Firewall-Based Solutions

Firewall-based solutions are usually slower and less scalable than otherVPN solutions. However, a firewall with a VPN component, such as BorderManager,FireWall-1 from Check Point Software Technologies Inc., or Gauntlet fromTrusted Information Systems Inc., allows you to perform many tasks usingone product.

Software-Based Solutions

Like firewall-based solutions, software-based solutions, such as VPN2.5 from Aventail Corp. or Tunnel 97 from AltaVista Internet Software, aretypically slower and less scalable than other VPN solutions (particularlyhardware-based solutions). Most software-based solutions slow down whenyou reach 100 or more simultaneous connections. However, these solutionsare generally easier to implement than other VPN solutions (again, particularlyhardware-based solutions).

Hardware-Based Solutions

Hardware-based solutions, such as TimeStep's PERMIT Enterprise, are faster and more scalable than other VPN solutions. Hardware-based solutions perform well, even when you have as many as 300 simultaneous connections. In addition, only these solutions can support the Federal Information Protection Standard (FIPS) 140, a standard for protecting encryption keys. (See "VPN Glossary".) On the other hand, hardware-based solutions can be more complicated to implement than other VPN solutions.

ISP-Based Services

With ISP-based services, you do not have to install, configure, and managea VPN: You outsource these tasks to the ISP. However, ISP-based servicescost more than implementing a VPN on your own, and few ISPs offer IP-basedVPN services. Advanced Network Services Inc. is among the few ISPs thatcurrently offer these services.

WHAT ABOUT IPX?

Although the vast majority of VPN solutions were not designed for IPX networks, most of these solutions make provisions to support IPX. For example, to ease the integration of PERMIT Enterprise with IPX networks, TimeStep recently formed a partnership with Ukiah Software Inc. Ukiah Software develops a software-based firewall for IPX networks called NetRoad FireWALL. (For more information about NetRoad FireWALL, see "Ukiah's NetRoad FireWALL: Multilevel Protection for Multiprotocol Networks,"NetWare Connection,July 1997, pp. 38[shy ]45.)

In a typical configuration of the joint VPN solution from TimeStep andUkiah Software, PERMIT Enterprise and NetRoad FireWALL are placed betweenthe corporate network and a router to the Internet. This solution protectsthe corporate network and encrypts data before sending it over the Internet.

BORDERMANAGER VPN--LIKE NO OTHER

Although most VPN solutions make provisions for supporting IPX, only one VPN solution was designed specifically for a heterogeneous IPX- and IP-based network and runs on an IntranetWare or NetWare server: the VPN component included with BorderManager. Recently a recipient of the Best Product of NetWorld+Interop award, BorderManager includes several components to help you manage, secure, and accelerate users' access to information at theborder--the point at which your company's network meets another network, such as the Internet. (For more information about BorderManager, see "Novell's Border Services,"NetWare Connection, May 1997, pp. 25[shy ]36.)

As a firewall-based solution, BorderManager's VPN component allows you to create secure tunnels--up to 256 tunnels per server. For example, you could create a tunnel across the Internet between your corporate network and branch offices or across your company's intranet between departments. (See Figure 1.)

Figure 1: BorderManager VPN establishes secure tunnels across the Internet between your corporate network and branch offices.

The next release of BorderManager will also include client software that enables LAN-to-client connections. With this client software, remote users will be able to initiate sessions with a BorderManager VPN server on your corporate network. This server, in turn, will work with the client software to create a secure tunnel across the Internet. (See "Feels Like Home.")

The next release of BorderManager will also support the IPSec standardand the SKIP key management protocol. As a result, a BorderManager VPN willbe able to interoperate with other VPNs that also support the IPSec standardand the SKIP key management protocol. (A closed beta version of the nextrelease of BorderManager should be available soon.) In addition, a futurerelease of BorderManager will support the ISAKMP/Oakley key management protocol.

Yes, Master

The BorderManager VPN uses a master-slave paradigm: One BorderManagerVPN server--generally a server on the corporate network--is the master server,and all other BorderManager VPN servers are slave servers. The master serverdictates the VPN's configuration parameters and is responsible for synchronizinginformation, such as routing information, on all BorderManager VPN servers.

The administrator of the master server handles most VPN management tasks,using Novell's NetWare Administrator (NWADMIN) utility to complete thesetasks. In fact, the NWADMIN utility is the single point of administrationfor all VPN management tasks (with the exception of configuration tasks,many of which must be completed at the server console using Novell's NIASCFGutility).

If you are the administrator of the master server, you can configurethe BorderManager VPN as either a mesh network or a star network. When youconfigure the BorderManager VPN as a mesh network, all slave servers cancommunicate securely with the master server and with each other. This configurationis ideal for connecting branch offices to the corporate network.

When you configure the BorderManager VPN as a star network, all slaveservers can communicate only with the master server; the slave servers cannotcommunicate with each other. This configuration is particularly useful forconnecting the networks of your company's partners and distributors to thecorporate network.

As the administrator of the master server, you can also configure theBorderManager VPN to automatically update routing information or to usestatic routing information. If you configure the BorderManager VPN to automaticallyupdate routing information, BorderManager updates the routing tables onall BorderManager VPN servers on your company's VPN whenever you or anotherVPN administrator makes a change. For example, if you added a subnetworkto your company's existing network, BorderManager would automatically addnew routing information to the routing tables on all of the BorderManagerVPN servers on your company's VPN.

No other VPN solution offers this type of automatic routing. Other VPNsolutions require you to manually configure static routes--a tedious taskthat is prone to human error. However, if you wanted to preserve bandwidthover the VPN tunnel by preventing routing information from travelling throughthis tunnel, you could choose to manually configure static routes for theBorderManager VPN.

Security Mechanisms

The BorderManager VPN uses several cryptographic algorithms to establisha tunnel across the Internet, including the Rivest, Shamir, Adleman (RSA)algorithm for authentication and the Diffie-Hellman algorithm for derivinga shared secret. (Shared secrets will be explained later in this article.)

To encrypt data, the BorderManager VPN uses the Rivest Code 2 (RC2) algorithmwith a 128-bit key for tunnels that remain within the borders of the UnitedStates and Canada. Due to U.S. government legislation on encryption, however,the BorderManager VPN uses only an RC2 40-bit key for tunnels that extendbeyond these borders.

Because RC2 is a symmetric algorithm, the same key is used to both encrypt and decrypt data.The RC2 128-bit key is extremely secure--theoretically possible but practically implausible to break. The RC2 40-bit key is also secure. Although this key can be broken, an intruder would need to invest a great deal of time, expense, and computing power to break it. (See "The Key to Security.")

BorderManager includes some additional security mechanisms to help putyour mind at ease if you must use the RC2 40-bit key. For example, as theadministrator of the master server, you could dictate a point at which theBorderManager VPN should change the key the BorderManager VPN servers areusing to encrypt data during a session. This point would be based on a particularnumber of packets. For example, you might specify that the BorderManagerVPN should change the key after every 100 packets.

To make this process less predictable and, therefore, even more secure,the BorderManager VPN uses a technique calledjittering. With jittering,the BorderManager VPN changes the RC2 key somewhere near the number of packetsyou specified but not always exactly at that number. For example, if youspecified that the BorderManager VPN should change the key after every 100packets, this VPN would actually change the key anywhere in the 75 to 100packet range.

It All Starts When . . .

So how does the BorderManager VPN create a tunnel across the Internet(or over your company's intranet)? The process begins when you decide whichBorderManager VPN server is the master server. Because the master serveris the focal point from which you must configure and manage the BorderManagerVPN, you should choose the BorderManager VPN server to which most of theVPN connections will be made. For example, suppose that the master serverwere located in San Jose, California and that Fred administered this server.Further suppose that only one slave server exists and is located in Ames,Iowa and administered by Ethel.

To configure the BorderManager VPN, Fred would run the NIASCFG utilityfrom the master server console and select the Master Server Configurationoption from the Virtual Private Network menu. Fred would then be promptedto specify, among other things, the master server's public IP address andits VPN tunnel IP address. The public IP address is the address by whichall Internet servers know the master server. The VPN tunnel IP address,on the other hand, is the address by which only slave servers know the masterserver.

To help the NIASCFG utility generate encryption information, Fred wouldalso enter aseed, which is a string of random numbers and letters--whateverFred felt like typing--that can include as many as 255 characters. The NIASCFGutility would then use this seed to generate the following encryption information:

The master server's RSA public and private keys, which the BorderManager VPN uses to authenticate BorderManager VPN servers
Diffie-Hellman parameters, which the BorderManager VPN uses to generate Diffie-Hellman public and private keys
The master server's Diffie-Hellman public and private keys, which the BorderManager VPN uses to securely exchange the RC2 keys that the BorderManager VPN servers must use to encrypt and decrypt data

After generating this encryption information, the NIASCFG utility wouldcompute amessage digest, which is a unique string of hexadecimalnumbers (totaling 16 bytes) that can be determined using only the masterserver's encryption information file and the MD5 message digest algorithm.The NIASCFG utility would store the message digest locally on the masterserver's hard drive.

Fred would then copy the master server's encryption information fileand would send this file to Ethel, the administrator of the slave serverin Ames. Fred could send the file either by surface mail or by e-mail. Thisfile would include the master server's public IP address, its VPN tunnelIP address, the Diffie-Hellman parameters, and its RSA public key.

When Ethel received the master server's encryption information file fromFred, she would save this file on a floppy diskette and launch the NIASCFGutility from the slave server console. Next, Ethel would select the SlaveServer Configuration option from the Virtual Private Network menu and, whenprompted, would insert the floppy diskette.

The NIASCFG utility would use the master server's encryption informationfile to compute a message digest, which should be identical to the messagedigest stored on the master server. To ensure that they are identical, Ethelwould call Fred and read aloud the slave server's message digest, whichFred would compare with the master server's message digest. If the messagedigests were identical, Fred and Ethel would know that the master server'sencryption information file Ethel received was authentic and unchanged.

Ethel would then continue to configure the slave server, completing stepssimilar to the steps Fred completed to configure the master server. AfterEthel completed these steps, the NIASCFG utility would compute a messagedigest based on the slave server's encryption information file and wouldstore the message digest locally.

Next, Ethel would save the slave server's encryption information fileand would send this file to Fred by surface mail or by e-mail. The filewould include the slave server's public IP address, its VPN tunnel IP address,its RSA public key, and its public Diffie-Hellman key.

After Fred received the slave server's encryption information file, hewould complete the same steps Ethel completed to verify that this file wasauthentic and unchanged. Fred would then launch the NWADMIN utility on hisworkstation. From the browser window, Fred would open the VPN Master Serverobject in the Novell Directory Services (NDS) tree and add the slave serverto this object's list of VPN members. (BorderManager extends the NDS schema,adding objects necessary for managing BorderManager services.)

Finally, Fred would click the Synchronize button. The master server would contact the slave server over a TCP/IP port and would send all of the configuration information the slave server needs to establish a tunnel, including the master server's public IP address and its public Diffie-Hellman key. (See Figure 1.)

Now the master server would have a copy of the slave server's public Diffie-Hellman key, and the slave server would have a copy of the master server's public Diffie-Hellman key. These servers would use each other's public Diffie-Hellman key and their own private Diffie-Hellman key to generate the same value, called ashared secret. The BorderManager VPN would use this shared secret to encrypt the RC2 128-bit key the servers must use to encrypt data. (For more information about shared secrets, see "Novell's Border Services,"NetWare Connection, May 1997.)

The master server and the slave server would then simultaneously generatecommands to create a tunnel. To create the tunnel, these servers would bindtheir TCP/IP and IPX protocol stacks to the BorderManager VPN'scryptodriver, which is a virtual driver between each server and the tunnel.To the protocol stacks, this crypto driver appears to be an ordinary WANdriver for an Ether-net board or Point-to-Point Protocol (PPP) board.

Having bound the protocol stacks to the crypto drivers, the servers would establish the VPN tunnel. Each server would then automatically send its routing information to the other server through the crypto driver, populating the routing tables on both ends of the BorderManager VPN. After the administrators of the master and slave servers completed the configuration process and the master and slave servers created a secure tunnel, the servers could begin exchanging encrypted packets. (For a summary of the steps outlined in this section, see "Configuring a BorderManager VPN.")

Encrypted Exchange

So what would happen to a packet that a client in Ames sent to the masterserver in San Jose? How would the slave server in Ames ensure the safe deliveryof that packet? And what would the master server do with this packet afterreceiving it?

Suppose that the client requested a file from the master server. Naturally,the request--in the form of a packet--would reach the slave server in Amesfirst. The slave server would look at the destination address of the packet,check its routing table to determine what to do with packets addressed tothe master server, and find that packets with this destination address shouldbe routed through the BorderManager VPN's crypto driver.

After the crypto driver received the packet from the slave server, this crypto driver would encrypt the packet using an RC2 128-bit key. (See "The Key to Security.") To decrypt the packet, the master server would need the same RC2 128-bit key the slave server used to encrypt the packet. However, sending this key across the wire would be dangerous if the key weren't encrypted. To protect the key, the slave server's crypto driver would use the shared secret to encrypt this key.

The slave server's crypto driver would then place a new IP header in front of the encrypted key, which is in front of the encrypted packet. (See Figure 2.) This header contains the encrypted packet's source address (the public IP address of the slave server) and its destination address (the public IP address of the master server).

Figure 2: BorderManager VPN encrypts a packet, encrypts the key used to encrypt the packet, places the encrypted key in front of this packet, places a new IP header in front of the entire packet, and then sends this packet through the tunnel.

After both a new IP header and an encrypted key were attached to theencrypted packet, the slave server would send this packet across the tunnel.All of the intermediate systems, such as routers, would know only that theencrypted packet originated from a server in Ames and was bound for a serverin San Jose.

When the master server received the encrypted packet, this server would forward the packet to its crypto driver. The master server's crypto driver would use the shared secret to decrypt the encrypted key and would then use this key to decrypt the encrypted packet, thus restoring the packet to its original form. Because the original packet contains the destination address of the master server, this server's crypto driver would forward the packet to the network layer, which would send the packet to the server's private network interface board. (For a summary of the steps outlined in this section, see "Exchanging Encrypted Packets.")

BARGAIN BORDERS

Creating a tunnel and exchanging encrypted packets across that tunnelmight sound complicated, but it isn't--not for you anyway. You need onlyconfigure your BorderManager servers (which is relatively simple), and theseservers do the rest.

If you want to use the BorderManager VPN, you can purchase BorderManagerthrough any Novell authorized reseller beginning at the suggested retailprice of U.S. $2,495 for a five-user license. If that sounds expensive,you're not thinking:

First, BorderManager is more than a VPN solution. BorderManager is alsoa firewall solution that includes a packet-filtering gateway, a circuit-levelgateway, and HTTP application proxies. In addition, BorderManager includesa proxy cache for accelerating users' access to the World-Wide Web.

Second, even if BorderManager were only a VPN solution, its cost wouldbe comparable to that of other VPN solutions. (For an idea of how much thesesolutions cost, see the sidebar on p. 34 of"Unhook Your Leased Lines,"InfoWorld,Sept. 22, 1997.) Also, because other VPN solutions don'tactually run on an IntranetWare or NetWare server, you might incur additionalhardware, software, and administrative costs to integrate another VPN solutionwith an IntranetWare or NetWare network.

Third, while the initial cost of a private leased line might be lessthan the initial cost of installing the BorderManager VPN (or another VPNsolution), the monthly costs of a private leased line are far greater thanthe monthly costs of using the BorderManager VPN--more than 50 percent greater.

Fourth, by implementing the BorderManager VPN (or another VPN solution),you are making the most out of what you probably already have: an Internetconnection. The BorderManager VPN allows you to use that connection to establishsecure communications channels to your company's partners, distributors,branch offices, and--very soon--remote users.

Linda Boyer works for Niche Associates, an agency that specializesin technical writing and editing. Niche Associates is located in Salt LakeCity, Utah.

VPN Glossary

AUTHENTICATION

Authentication is a method used to prove the identity of any device attempting to build or use a virtual private network (VPN).

ENCRYPTION

Encryption is the process of disguising information in such a way as to hide its substance. (The process of converting the encrypted information back to its original form is called decryption.)

FIPS 140

The Federal Information Protection Standard (FIPS 140) is a standard for key recovery that some hardware-based VPN solutions support. Financial institutions and the U.S. federal government use only VPN solutions that support FIPS 140, which makes it possible to recover an encryption key that has been lost or corrupted. No software-based VPN solutions, firewall-based VPN solutions, or Internet service provider (ISP) based services support FIPS 140.

IPSEC

IP Security (IPSec) is an International Engineering Task Force (IETF) standard for IP security. The IPSec standard defines a suite of security protocols that authenticate TCP/IP connections, add data confidentiality and integrity to TCP/IP packets, and are transparent to the application being used and to the underlying network infrastructure. The IETF is in the process of reviewing a revision of this standard, which is detailed in Requests for Comments (RFCs) 18251829. Many vendors support the current version and plan to support the revised version when it is finalized.

ISAKMP/OAKLEY

Internet Security Association and Key Management Protocol/Oakley (ISAKMP/Oakley) is one of two public-key management schemes that the IPSec standard supports. ISAKMP/Oakley is actually a hybrid protocol, integrating ISAKMP with the Oakley key exchange scheme. ISAKMP builds secure associations in multiprotocol environments and has very low overhead. (See also SKIP.)

L2F

Layer 2 Forwarding (L2F) is a tunneling protocol that Cisco Systems Inc. submitted to the IETF as a proposed standard. L2F transports link-layer frames such as Point-to-Point Protocol (PPP) and Serial Line Interface Protocol (SLIP). L2F, as the name implies, operates at the data-link layer, which is layer 2 in the Open Systems Interconnection (OSI) model defined by the International Standards Organization (ISO). L2F is targeted at the ISP market.

L2TP

Layer 2 Tunneling Protocol (L2TP) authenticates dial-up users and establishes a router-based connection to a server. L2TP is a combination of L2F and Point-to-Point Tunneling Protocol (PPTP). Specifically, L2TP is designed to tunnel PPP and SLIP sessions over the Internet, operating at the data-link layer of the OSI model. Like L2F, L2TP is targeted at the ISP market.

PPTP

Microsoft Corp. submitted Point-to-Point Tunneling Protocol (PPTP) to the IETF as a proposed standard, and several vendors, including 3Com Corp. and Ascend Communications Inc., have endorsed this proposed standard. PPTP, which encapsulates dial-up PPP traffic, is currently available for Windows NT servers and workstations and also for Windows 95 workstations through an upgrade.

SKIP

Simple Key Management for Internet Protocol (SKIP) is one of two public-key management schemes that the IPSec standard supports. SKIP is optimized for client connections to a remote network. (See also ISAKMP/Oakley.)

STEP

Compatible Systems developed Secure Tunnel Establishment Protocol (STEP) to rival L2TP for secure LAN-to-LAN connectivity. Unlike L2TP, which operates at layer 2 of the OSI model, STEP operates at layer 3. One advantage STEP has over L2TP is that STEP prevents PPP connections from monopolizing an Internet connection. In other words, if a STEP tunnel is in place, a second connection can be established concurrently.

TUNNELING

Tunneling is a method by which packets are encapsulated within a protocol that is understood at the entry and exit points of a network. L2F, L2TP, PPTP, and STEP are all tunneling protocols.

VPN

A VPN can be defined in several ways: The broad definition of a VPN is a private network that uses a public network's infrastructure. The definition used in this article, however, is a private network created by tunneling encrypted packets through an IP-based network, such as the Internet or an intranet. A VPN can also be defined as a carrier-based service that creates a private network by tunneling encrypted packets through a switched network, such as a frame-relay network or an asynchronous transfer mode (ATM) network. Although the switched network is privately owned by a telecommunications carrier or by an ISP, this network is considered public because it is used by all of the service's customers.

Clearing Away Virtual Cobwebs

If you are confused about virtual private networks (VPNs), join the club: This common confusion stems from multiple interpretations of a broad definition and frequent misuse of industry jargon.

TWO INTERPRETATIONS OF ONE DEFINITION

A VPN is broadly defined as a private network that uses a public network's infrastructure. This definition has given rise to multiple interpretations, two of which are extremely common. (See "VPN Glossary.")

The first interpretation defines a VPN as a private network that tunnels encrypted packets across an existing IP-based network, such as the Internet or an intranet. All of the VPN solutions discussed in this article are IP-based solutions.

The second interpretation specifies a VPN as a carrier-based service that tunnels encrypted packets through a switched network, such as a frame-relay network or an asynchronous transfer mode (ATM) network. This switched network is privately owned by a telecommunications carrier or an Internet service provider (ISP), but the network is shared by all of the service's customers.

AT&T is a leading provider of carrier-based VPN services, such as its WorldNet Intranet Connect Services (WICS), a global frame-relay network that connects IntranetWare and NetWare networks. CompuServe also offers carrier-based VPN services. CompuServe's primary service, NT Link, tunnels IP, IPX, and other network protocols through a global, high-speed network that includes frame relay, ATM, and packet connections.

JARGON USE AND ABUSE

The confusion about VPNs is also caused by frequent misuse of industry jargon. For example, some articles use the term extranet interchangeably with the term VPN. Although these terms are related, they do not denote the same thing. An extranet is a secure connection that companies use to conduct electronic commerce. You can use a VPN as an extranet solution, just as you can use a VPN as a LAN-to-LAN connectivity solution or as a remote access solution.

The often ambiguous use of the term tunnel also contributes to the confusion surrounding VPNs. When VPN devices exchange encryption keys and establish a confidential session over the Internet, that session is called a tunnel. Encrypted packets are then tunneled across the Internet; that is, these packets are wrapped within tunneling protocols, such as Layer 2 Tunneling Protocol (L2TP). (See "VPN Glossary.") Further confusing the VPN issue is that tunneling protocols are often mistakenly described as if they alone created a VPN. However, tunneling protocols only wrap packets; they don't encrypt the data these packets contain.

The Key to Security

All virtual private networks (VPNs) use an encryption scheme to render your data indecipherable to anyone but you. You have probably heard quite a lot about the cryptographic algorithms on which these encryption schemes are based. Rivest Code 2 (RC2), the Data Encryption Standard (DES), and Diffie-Hellman are only a few of the most commonly used algorithms.

You may be aware that these algorithms use keys to encrypt and decrypt data. However, you probably don't know that the algorithm a product uses isn't the key to the product's security, despite what some vendors would lead you to believe. Instead, the key to a product's security is its key or keys. Generally speaking, the longer the key, the safer your data.

According to cryptologist Bruce Schneier, "all of the security in [cryptographic] algorithms is based in the key (or keys); none is based in the details of the algorithm." (Applied Cryptography, Wiley, New York, 1994, pp. 34.) The algorithms can be published (and many have been) because it doesn't matter if an eavesdropper knows your algorithm--what matters is if he or she knows your decryption key. Without that key, an eavesdropper cannot read your data. If the eavesdropper could find your decryption key, however, he or she could read your data.

A key might be any one of a large number of possible values. The length of a key--its bit size--is directly related to how many possible values exist. For example, a 40-bit key has 2⁴⁰ possible values, and a 160-bit key has 2¹⁶⁰ possible values. The longer the key, the more possible values exist, and therefore, the harder it is to find the correct key.

Finding the correct key among these values is theoretically possible, regardless of key length. In practice, however, an enormous computing effort is required to crack even a relatively small key, such as a 40-bit key or a 56-bit key.

For example, in June 1997, a team of university students, programmers, and scientists solved a challenge issued by Rivest, Shamir, Adleman (RSA) to crack a message encrypted with a 56-bit DES key. Over a four-month period, tens of thousands of computers worked together to find the correct key out of 72 quadrillion possible values. Only 25 percent of the total number of possible values had been tested when the team discovered the correct key and decrypted the message: "Strong cryptography makes the world a safer place."

In October 1997, another team of users cracked a message encrypted with a 56-bit RC5 key in response to another RSA challenge. The 56-bit RC5 key also had 72 quadrillion possible values, 47 percent of which had been tested before the team discovered the correct key and decrypted yet another message: "It is time to move to a longer key length."

RSA issued these challenges to demonstrate the modest level of security in the encryption technology that the U.S. government allows to be exported. U.S. policy on encryption currently allows companies to use only 40-bit keys when exchanging information with users outside the United States and Canada. Financial institutions and companies with international branch offices can apply for a license that enables them to use keys of up to 56 bits.

VPN solutions operating within the United States and Canada offer key lengths ranging anywhere from 40 to 128 bits. VPN solutions that use 128-bit keys, such as Novell's BorderManager VPN component, are extremely secure. In fact, according to Schneier, breaking even an 80-bit key is "still beyond the realm of possibility." (Applied Cryptography, p. 153.) However, if you plan to establish a tunnel that extends beyond the borders of the United States and Canada, you will be limited to using a 40-bit key (or a 56-bit key if you qualify for a license), and therefore, your data will not be as secure.

If that prospect worries you, remember that although RSA has proven a 56-bit key can be broken, finding the correct key among 72 quadrillion possible values requires an enormous computing effort. You should also know that RSA gave the teams who participated in the challenge a major clue. RSA gave the teams a small piece of encrypted data along with the decrypted version of that data. Even armed with this clue, tens of thousands of computers running 24 hours a day, seven days a week took several months to solve RSA's challenge. Would your data attract that much attention?

VPN Solutions

Vendor	Contact Information	Solution
Advanced Network Services (a subsidiary of America Online)	1-800-456-8267, 1-703-758-7700 http://www.ans.com	Virtual Private Data Network (VPDN) Services (ISP-based service)
AltaVista Internet Software	1-978-506-2017 (fax) http://altavista.software.digital.com	Virtual Private Data Network (VPDN) Services (ISP-based service)
Aventail Corp.	1-888-762-5785, 1-206-215-1111 http://www.aventail.com	VPN 2.5 (software-based solution)
Check Point Software Technologies Inc.	1-800-429-4391, 1-650-562-0400 http://www.checkpoint.com	FireWall-1 (firewall-based solution)
FTP Software Inc.	1-800-282-4387, 1-978-685-4000 http://www.ftp.com	Secure Client 3.0 (software-based solution)
Novell Inc.	1-800-NETWARE, 1-801-861-5588 http://www.novell.com/catalog/qr/sne34150.html	BorderManager VPN (firewall- based solution)
Trusted Information Systems Inc.	1-888-FIREWALL, 1-301-527-9500 http://www.tis.com	Gauntlet (firewall-based solution)
TimeStep Corp.	1-800-383-8211, 1-613-599-3610 http://www.timestep.com	PERMIT Enterprise (hardware- based solution)

Feels Like Home

In the next release of BorderManager, the virtual private network (VPN) component will include new client software, which will enable remote users to initiate secure VPN tunnels to the corporate office. Remote users will first dial into the local Internet service provider's (ISP's) point-of-presence (POP) on the Internet, and will then authenticate and attach to the corporate network. At this point, the users will feel right at home, just as if they were using their own workstation at the corporate office.

The client software, which was being tested at the time this article was written, was designed with ease-of-installation in mind. Once the software is installed, users will need only to establish a dial-up Point-to-Point Protocol (PPP) connection with the lo-cal ISP POP. Once users have logged in to and connected to the ISP, the client VPN will launch a login executable. A dialog box will then appear, prompting the users to enter a username and password.

After users enter their username and password, the BorderManager VPN client software negotiates with the BorderManager server at the corporate network. During this negotiation, the client software and the BorderManager server will exchange Diffie-Hellman keys using the IP Security (IPSec) and Simple Key Management for Internet Protocol (SKIP) standards, create a shared secret, and establish a secure tunnel across the Internet.

At this time, the BorderManager server will also enable users to choose whether they want all packets encrypted or just packets bound to particular addresses. For example, a user could specify that he or she wanted only those packets going to the corporate intranet to be encrypted but that all other packets remain unencrypted.

Configuring a BorderManager VPN

To configure a BorderManager virtual private network (VPN), the administrator of the master server and the administrator of the slave server complete the following steps:

The administrator of the master server uses Novell's NIASCFG utility to generate encryption information for the master server.
The administrator of the master server sends the master server's encryption information to the administrator of the slave server.
The administrator of the slave server calls the administrator of the master server to verify that the master server's encryption information is authentic and unchanged.
The administrator of the slave server uses the master server's encryption information and the NIASCFG utility to generate encryption information for the slave server.
The administrator of the slave server sends the slave server's encryption information to the administrator of the master server.
The administrator of the master server calls the administrator of the slave server to verify that the slave server's encryption information is authentic and unchanged.
The administrator of the master server launches Novell's NetWare Administrator (NWADMIN) utility and opens the VPN Master Server object in the Novell Directory Services (NDS) tree.
The administrator of the master server adds the slave server to this object's list of VPN members and synchronizes the configuration information on all BorderManager VPN servers, which can then establish a tunnel.

Exchanging Encrypted Packets

Virtual private networks (VPNs) protect data by encrypting this data before sending it across the Internet. A master BorderManager VPN server and a slave BorderManager VPN server perform the following steps to exchange encrypted packets:

A packet being sent to the master server arrives at the slave server.
The slave server routes the packet through the BorderManager VPN crypto driver on this server.
The slave server's crypto driver encrypts the packet using a Rivest Code 2 (RC2) 128-bit key (or an RC2 40-bit key if the tunnel extends beyond the United States and Canada).
The slave server's crypto driver encrypts the key.
The slave server's crypto driver places a new IP header in front of the encrypted key, which is in front of the encrypted packet. (See Figure 2.)
The slave server's crypto driver sends the encrypted packet through the tunnel to the master server.
The master server receives the encrypted packet and forwards it to the crypto driver on this server.
The master server's crypto driver decrypts the key.
The master server's crypto driver uses the key to decrypt the packet.
The master server's crypto driver forwards the packet (now in its original, unencrypted form) to the private network interface board on this server.

* Originally published in Novell Connection Magazine

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.