Virtual Private Networks

Making a Public Network Private

Linda Boyer

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 definition of a VPN and explains the advantages and disadvantages of implementing a VPN. This article also discusses the types of VPN solutions available, focusing on today's only VPN solution that runs on IntranetWare and NetWare: Novell's BorderManager 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 a tunnel, 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 over the Internet. Depending on the solution, a VPN can also connect remote users to 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 applications on the corporate network without compromising security--just as these offices could if you leased dedicated lines to connect these offices to the corporate network.

Similarly, a LAN-to-client VPN provides most of the same benefits that you would get from installing a modem bank or a remote access server on the corporate network. That is, remote users on a LAN-to-client VPN can access files and applications on the corporate network without compromising security. However, remote users on a VPN gain that access by dialing a local telephone number to connect to the Internet rather than dialing a long-distance telephone 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 all of the same benefits as the traditional wide-area or remote access solutions. Because a VPN uses the public, relatively unreliable, and notoriously insecure Internet, some important distinctions exist between VPNs and other private solutions: 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, if you implement a VPN instead of a WAN, you do not need to lease costly private lines. 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 associated with 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 VPN itself are the only costs of implementing a VPN. And with a VPN that supports LAN-to-client connections, the only cost for remote access is the U.S. $20-per-month rate an Internet service provider (ISP) charges. By paying this monthly fee, remote users can establish a private connection with the corporate network by dialing the telephone number (usually a local one) for the ISP's nearest Internet access server.

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

Nevertheless, because low cost is the main advantage of VPNs, a few trade magazines and vendors have calculated savings based on hypothetical cases. For example, InfoWorld recently estimated that within three years you could save between U.S. $650,000 and U.S. $1,000,000 by using a VPN rather than private leased lines to connect 20 LANs. (See "Unhook Your Leased Lines," InfoWorld, Sept. 22, 1997, pp. 80­96. This particular reference is from the "VPNs Yield Big Savings Compared With Leased 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 costs associated with two remote access solutions. If a company had 75 remote users who dialed a long-distance telephone number to connect to the corporate network for 20 hours per month, the company would pay approximately U.S. $15,000 per month in long-distance telephone charges. However, if these remote users accessed an ISP's local Internet access server to connect to the corporate network over the Internet, the company would pay approximately U.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 companies Forrester Research interviewed use the Internet for remote access. Why so few? Not surprisingly, these companies are concerned about the security, reliability, and performance of the Internet. Because most VPNs are Internet based, 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 BorderManager group, asserts that a VPN is "actually more secure than a [private] leased line." With a private leased line, Natarajan explains, your company's data is unencrypted. As a result, if someone taps into this line (which is a possibility, contrary to popular belief), the data is there for 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 in a VPN and, arguably, not the most important one. According to Mal Radalgoda, director of Marketing at TimeStep, the encryption scheme a product uses is not proof of that product's security, despite what some companies might lead you to believe. The true test of a product's security, Radalgoda contends, "is the security protocol the product uses to guarantee that a VPN session is established securely."

The security protocol that TimeStep and many other vendors have chosen to support is IP Security (IPSec). Under development since 1989, IPSec is an industry standard for establishing tunnels over IP-based networks such as 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­1829. To read this draft, go to http://www.internic.net/ds/rfc-index.1800-1899.html, and access RFCs 1825­1829.)

Not as Fast as a WAN

If a VPN provides a low-cost, high-security alternative to WANs and remote access solutions, why doesn't every company rush out to buy a VPN solution? Most companies share justifiable concerns about the reliability and performance of VPNs. Since Internet-based VPNs are built on the Internet, they cannot offer 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 VPN industry matures, "it will start to look toward guaranteeing quality of service over the Internet." In the meantime, Kandah admits, some companies "will require private WAN connections because these connections can guarantee quality of service."

An Internet-based VPN is not only incapable of offering more than the Internet but can actually offer less. Encrypting and decrypting data are intensive functions that take their toll on a VPN's performance. The bottom line is that a VPN might be as secure as a private leased line, but a VPN isn'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, InfoWorld concluded that concerns about Internet reliability are often "blown out of proportion." In fact, InfoWorld "didn't experience any outages or unpredictable results."

InfoWorld also asserted that concerns about VPN performance are unfounded. The VPN solutions InfoWorld tested were no more than 15 percent slower than a 56 Kbit/s private leased line.

Not surprisingly, encrypted data is largely responsible for making VPNs slower than leased lines. However, encrypted data does not degrade performance as much as you might think. When comparing the performance of encrypted file transfers to unencrypted file transfers, InfoWorld found that encrypted 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 today are not interoperable. Although support for the IPSec standard goes a long way toward increasing the potential for interoperability, this support does not guarantee interoperability. For example, the IPSec standard includes a suite of protocols, and not all products that support this standard support the 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 products are theoretically compatible, using the same key management scheme doesn't guarantee that the products' configurations are. "You'll have to do some 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:

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 other VPN solutions. However, a firewall with a VPN component, such as BorderManager, FireWall-1 from Check Point Software Technologies Inc., or Gauntlet from Trusted Information Systems Inc., allows you to perform many tasks using one product.

Software-Based Solutions

Like firewall-based solutions, software-based solutions, such as VPN 2.5 from Aventail Corp. or Tunnel 97 from AltaVista Internet Software, are typically slower and less scalable than other VPN solutions (particularly hardware-based solutions). Most software-based solutions slow down when you reach 100 or more simultaneous connections. However, these solutions are generally easier to implement than other VPN solutions (again, particularly hardware-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 manage a VPN: You outsource these tasks to the ISP. However, ISP-based services cost more than implementing a VPN on your own, and few ISPs offer IP-based VPN services. Advanced Network Services Inc. is among the few ISPs that currently 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­45.)

In a typical configuration of the joint VPN solution from TimeStep and Ukiah Software, PERMIT Enterprise and NetRoad FireWALL are placed between the corporate network and a router to the Internet. This solution protects the 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 the border--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­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.)

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 standard and the SKIP key management protocol. As a result, a BorderManager VPN will be able to interoperate with other VPNs that also support the IPSec standard and the SKIP key management protocol. (A closed beta version of the next release of BorderManager should be available soon.) In addition, a future release of BorderManager will support the ISAKMP/Oakley key management protocol.

Yes, Master

The BorderManager VPN uses a master-slave paradigm: One BorderManager VPN server--generally a server on the corporate network--is the master server, and all other BorderManager VPN servers are slave servers. The master server dictates the VPN's configuration parameters and is responsible for synchronizing information, 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 these tasks. In fact, the NWADMIN utility is the single point of administration for all VPN management tasks (with the exception of configuration tasks, many of which must be completed at the server console using Novell's NIASCFG utility).

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

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

As the administrator of the master server, you can also configure the BorderManager VPN to automatically update routing information or to use static routing information. If you configure the BorderManager VPN to automatically update routing information, BorderManager updates the routing tables on all BorderManager VPN servers on your company's VPN whenever you or another VPN administrator makes a change. For example, if you added a subnetwork to your company's existing network, BorderManager would automatically add new routing information to the routing tables on all of the BorderManager VPN servers on your company's VPN.

No other VPN solution offers this type of automatic routing. Other VPN solutions require you to manually configure static routes--a tedious task that is prone to human error. However, if you wanted to preserve bandwidth over the VPN tunnel by preventing routing information from travelling through this tunnel, you could choose to manually configure static routes for the BorderManager VPN.

Security Mechanisms

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

To encrypt data, the BorderManager VPN uses the Rivest Code 2 (RC2) algorithm with a 128-bit key for tunnels that remain within the borders of the United States and Canada. Due to U.S. government legislation on encryption, however, the BorderManager VPN uses only an RC2 40-bit key for tunnels that extend beyond 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 put your mind at ease if you must use the RC2 40-bit key. For example, as the administrator of the master server, you could dictate a point at which the BorderManager VPN should change the key the BorderManager VPN servers are using to encrypt data during a session. This point would be based on a particular number of packets. For example, you might specify that the BorderManager VPN 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 called jittering. With jittering, the BorderManager VPN changes the RC2 key somewhere near the number of packets you specified but not always exactly at that number. For example, if you specified that the BorderManager VPN should change the key after every 100 packets, this VPN would actually change the key anywhere in the 75 to 100 packet 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 which BorderManager VPN server is the master server. Because the master server is the focal point from which you must configure and manage the BorderManager VPN, you should choose the BorderManager VPN server to which most of the VPN connections will be made. For example, suppose that the master server were 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 utility from the master server console and select the Master Server Configuration option from the Virtual Private Network menu. Fred would then be prompted to specify, among other things, the master server's public IP address and its VPN tunnel IP address. The public IP address is the address by which all 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 master server.

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

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

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

When Ethel received the master server's encryption information file from Fred, she would save this file on a floppy diskette and launch the NIASCFG utility from the slave server console. Next, Ethel would select the Slave Server Configuration option from the Virtual Private Network menu and, when prompted, would insert the floppy diskette.

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

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

Next, Ethel would save the slave server's encryption information file and would send this file to Fred by surface mail or by e-mail. The file would 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, he would complete the same steps Ethel completed to verify that this file was authentic and unchanged. Fred would then launch the NWADMIN utility on his workstation. From the browser window, Fred would open the VPN Master Server object in the Novell Directory Services (NDS) tree and add the slave server to 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 a shared 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 generate commands to create a tunnel. To create the tunnel, these servers would bind their TCP/IP and IPX protocol stacks to the BorderManager VPN's crypto driver, which is a virtual driver between each server and the tunnel. To the protocol stacks, this crypto driver appears to be an ordinary WAN driver 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 master server in San Jose? How would the slave server in Ames ensure the safe delivery of that packet? And what would the master server do with this packet after receiving 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 Ames first. The slave server would look at the destination address of the packet, check its routing table to determine what to do with packets addressed to the master server, and find that packets with this destination address should be 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).

After both a new IP header and an encrypted key were attached to the encrypted packet, the slave server would send this packet across the tunnel. All of the intermediate systems, such as routers, would know only that the encrypted packet originated from a server in Ames and was bound for a server in 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 tunnel might sound complicated, but it isn't--not for you anyway. You need only configure your BorderManager servers (which is relatively simple), and these servers do the rest.

If you want to use the BorderManager VPN, you can purchase BorderManager through any Novell authorized reseller beginning at the suggested retail price 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 also a firewall solution that includes a packet-filtering gateway, a circuit-level gateway, and HTTP application proxies. In addition, BorderManager includes a proxy cache for accelerating users' access to the World-Wide Web.

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

Third, while the initial cost of a private leased line might be less than the initial cost of installing the BorderManager VPN (or another VPN solution), the monthly costs of a private leased line are far greater than the 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 Internet connection. The BorderManager VPN allows you to use that connection to establish secure communications channels to your company's partners, distributors, branch offices, and--very soon--remote users.

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

NetWare Connection, February 1998, pp. 6-21