★ wanayoo — archive 1999 http://data.com/roundups/hardware.htmlNouvelle recherche | Portail wanayoo
CMP's TechWeb Click Here to Vist CMPNET


Data Communications
Search Data Communications

 Browse By...
 Technology/Topic
 Vendor
 Issue

 Visitors Center

 FAQs
 Contact the Editors
 Registration
 Subscriptions

 Content
 VIEWPOINT
 TECH TUTORIALS
 ATM
 Carrier-Class Gear
 Internet/Intranets
 IP Tools/Issues
 Network Software
 Net Management/SLAs
 QOS
 Remote Access
 Routers/Switches
 Security
 Servers/Peripherals
 Services/Outsourcing
 Workgroup Networks

 NEW PUBLIC NETWORK

 LAB TEST CENTER

 GLOBAL NETWORKS

 PRODUCT LEADERS

 OPINIONS/COLUMN
 Lippis on Internetworking
 Sound Byte

 Marketing Services
 T99 Media Services
 Industry Front & Center
 Reader Service

 Custom Publishing
 Vendor Strategies
 Sponsorships

Click Here to Vist CMPNET

TechWeb Sites
 Byte.com
 CMPmetrics
 Data Communications
 File Mine
 InformationWeek
 InternetWeek
 Network Computing
 Planet IT
 TechShopper
 TechWeb News
 Tele.com
 WebTools
 Winmag.com


April 21, 1998


By Andrew Cray

VPN Hardware

VPN Hardware: Armed Compounds

New VPN boxes combine higher speeds and tighter security


MORE INFO
VPNs: Taking Sides



The hard way is the right way. Router vendors know it. Switch makers know it. Now vendors of VPN gear are finding out for themselves: Running processing-intensive routines in hardware pumps up performance. a Better yet, firming up on encryption and authentication makes new VPN boxes harder to hack than software equivalents—and that's what net managers tunneling sensitive corporate data through the Internet really need from VPN gear.

And now they can choose from among at least 17 vendors whose products combine revved-up rates with forbidding fronts. But making the most of the hardware mix means taking a long, hard look at this new breed of box. Start with the performance claims: While VPN hardware is indeed faster, vendors like to inflate the numbers—so don't take them at face value. Then decide whether a standalone unit will suffice or whether routing and firewall functions will be needed as well. And since security is what VPNs (virtual private networks) are all about, get straight on encryption algorithm s and authentication schemes. Also check installation procedures and learn how encryption keys are managed, since those are sure tip-offs on how easy (or hard) the device is to use. There's one more thing to weigh: interoperability. After all, products need to speak the same language if encrypted sessions are to be set up among trading partners. The good news on this front is that at least six vendors say their products can work together (at a basic level, at least), thanks to a spec now being developed by the IPSec (IP security) group of the IETF.

Strength and speed are only two of the payoffs of choosing the right box. Ask James Collum, associate director of information services at Cell Genesys (Foster City, Calif.), a biotech company. Instead of paying for three 128-kbit/s leased lines to link corporate HQ to a development facility 40 miles away, he's moving data via the T3 (45-Mbit/s) Internet access link already in place—and encrypting it with VPN access devices from Redcreek Communications Inc. (Newark, Calif.). "Right now, we're saving $3,000 a month," Collum says. He expects to save even more when he replaces his international leased lines with a VPN.

Hard Facts


BUILD YOUR OWN CUSTOM TABLE
Vendors of VPN Hardware
But corporate networkers who want to see the speed, security, and savings should get set on the VPN players first. And that might be easier said than done. The market is hot, as proven by the recent string of buyouts and licensing deals. In the last few months, for example, Bay Networks Inc. (Santa Clara, Calif.) acquired New Oak Communications Inc. (Acton, Mass.); Shiva Corp. (Bedford, Mass.) acquired Isolation Systems Ltd. (Toronto) in order to integrate VPN functionality into its remote products; and Cisco Sy stems Inc. (San Jose, Calif.) reached an agreement with Redcreek to integrate that vendor's VPN technology into its Pix firewall. Other players in the hardware VPN arena include Cylink Corp. (Sunnyvale, Calif.), Information Resource Engineering Inc. (IRE, Baltimore), Radguard Ltd. (Tel Aviv, Israel), Timestep Corp. (Kanata, Ontario), and VPNet Technologies Inc. (San Jose) (see Table 1 ).

After taking a look at the vendors, bone up on the basics. There are two types of VPN hardware: standalone units and routers with built-in VPN functions. Standalones sit on the LAN and ship encrypted data out via routers, while router-based products send data out to the Internet via their own WAN interfaces.

And there are three ways VPN devices can be deployed. First, they can be situated at the edge of the private network to encrypt and authenticate links between corporate sites. Second, they can be used for securing communications among trading partn ers on an extranet. Third, they can be used for securing remote access to the corporate net; telecommuters run special software that establishes an air-tight link with the VPN device every time they dial in over the 'Net.

Most vendors say their products can be used for all three applications. The exceptions are Cisco, with its Encryption Service Adapter, Netscreen Technologies Inc. (Santa Clara, Calif.), with its Netscreen-100, and Teltrend Inc. (St.Charles, Ill.), with its Network IQ Family—since those products don't permit remote access.

But what really makes today's VPN devices different is the hardware: These boxes typically boast a powerful central processor, an operating system specifically tooled to handle security, and the ability to offload encryption and authentication processes onto dedicated ASICs. Bay, with its BNES products, and Fortress Technologies Inc. (Tampa, Fla.), with its Netfortress VPN, are among the few vendors that depart slightly from this design, using multiple Pentium (or other general-purpose) processors. But they nevertheless feature their own operating systems for maximum performance.

Compare that to software-based VPN products, which are typically loaded onto a generic PC with one CPU running the Windows NT or Unix general-purpose operating systems. Collum did—and he came to a quick conclusion. "We couldn't get the throughput we needed from software manufacturers," he says, noting that his Redcreek box moves Cell Genesys' medical imaging files onto the Internet at 7 Mbit/s—with no noticeable delay.

But if VPN products are primarily about security, then why all the fuss over performance? Simple: Actually securing those connections involves a lot of processing activity. Just think of all the encrypted sessions that have to be set up. Then consider the labor at the network layer: The box pulls apart IP packets one by one, encrypts (and authenticates) the contents, and then reassembles them. Finally, the session has to be torn down. And al l of it has to be done at line speed to keep bottlenecks from building up. "Software is always going to be slower than an ASIC. That's guaranteed," says Tony Davis, network administrator at Hartnell Community College (Salinas, Calif.), who is looking at using VPNs to connect a remote campus to his main site. What's more, results from a Data Comm lab test indicate that hardware beats software down the line as a general rule of thumb (see "VPNs: Security With an Uncommon Touch," September 21, 1997; http://www.data.com/lab_tests/vpn.html ).

Another problem with VPN software? It often pulls triple duty—acting as a firewall and management terminal in addition to VPN access device. "If you don't have dedicated resources then by definition it's going to be slower," says Bruce Hartley, chief technology officer at security consultancy DMW Worldwide LLC (Colorado Springs, Calif.).

Rate Realities

So hardware beats software in the throughp ut stakes. But exactly how speedy are today's VPN boxes? It's hard to tell. "The vendors don't run the same tests, so you don't have an apples-to-apples comparison," Hartley says. It's hardly surprising, then, that vendors claim throughput rates of anything from 22 Mbit/s to 60 Mbit/s—and higher. "We can get up to 100 Mbit/s," boasts Elad Shaviv at Radguard.

Maybe. But it's a lot more likely net managers will see nowhere near that kind of performance. Ask Collum, who remembers Redcreek's promise of 10-Mbit/s rates. "I would fall off my chair if I saw that throughput," he says.

Getting a real read on rates means taking several factors into account, like the encryption algorithm being used, whether authentication functions and key exchange are being run, and the size of packets. The figures quoted by the vendors above, for example, assume packet sizes of 1,450 bytes. Apply smaller packets (such as those used on most corporate nets) and throughput takes a tumble.

To cut through the c onfusion, Data Comm asked vendors to stick to four parameters when giving performance numbers. First, use 56-bit DES (Data Encryption Standard) (since all vendors offer it); second, switch on message authentication; third, assume 64-byte packets (the smallest size possible; on most networks, average packet size is slightly over 100 bytes); and finally, switch off compression. Plug those numbers in and performance begins to look a lot different. IRE turns in a 1.8-Mbit/s figure, and Radguard's number comes down to 8 Mbit/s—slightly lower than the 100-Mbit/s claim.

Even then, net managers will have to make allowances. If they're using triple DES, for example, they should divide the throughput rate by 2.5—since stronger algorithms usually take a greater toll on encryption processors. (It's worth noting that VPNet claims the ASICs on its VSU-1000 and VSU-1010 process both DES and triple DES at around the same speed.)

Networkers also should remember that tunneling adds overhead, since a p acket's header and payload have to be encapsulated in an entirely new header. How much overhead? About 35 percent, estimates Tom Bleier, vice president of sales and marketing at Internet Devices. The throughput figures given here don't reflect the effect of overhead.

Finally, weigh in the cost of session establishment. "Everyone takes a performance hit when they're calculating keys," says Michael Feinstein, director of product management at Bay. The problem here is the heavy processing burden of public-key cryptography, which is used in everything from digital certificates to authentication to key exchange. Unfortunately, there's no easy way to figure out exactly how big the hit will be. "We're just doing that testing now," says Bleier.

Vendors do admit that more sessions add up to lower performance. Bay, Shiva, and Timestep, for instance, claim their products can handle 1,000 to 2,000 simultaneous sessions—but that doesn't mean they can set them up all at once. "We can initiate new tunne ls at about 100 per second," Feinstein says.

But even doing that would leave no processing power for regular encryption. This is something most likely to affect companies with lots of remote users dialing in frequently to pull down mail. "Site-to-site connections are more stable," notes Bleier, pointing out that two VPN devices exchanging data between sites are likely to keep a session up all day. To guard against public-key slowdowns, some products—including Radguard's Cipro—offload the mathematical computations involved in public-key cryptography onto a dedicated RSA chip.

There's another possible way to address the slowdown: Let two VPN devices share the encryption load. Packets pass through both, but one handles one set of IP addresses while the other handles a second set.

Tighten Up

In addition to speed, vendors of VPN hardware also promise tighter security. They base their pledge on two factors.

First, VPN hardware is better at blocking physical access to encryption keys, since it typically wipes the memory of all chips in the box if someone attempts to open it up by force. Second, say vendors, proprietary operating systems don't allow hackers in. "Windows NT and Unix are designed to allow remote logins," notes Radguard's Shaviv. "So obviously they're less secure."

Still, not everyone is convinced that software is too soft on hackers. "I can tell you how to tighten down a Unix system," says Hartley, arguing that the "hardened" operating systems shipped by software vendors can be just as tough to crack. What's more, he notes, even VPN hardware needs to be configured and set up, either via a local EIA-232 port or remotely from the central office—giving cybercrooks enough of a hole to worm through.

About Routing

All right, so once net managers have assessed all those angles it's time to get down to particulars. The first thing to check is whether the VPN device comes with built-in routing. Right now, 11 vendors—including Ba y, Cisco, Redcreek, Shiva, Teltrend, and VPNet—offer VPN hardware with routing capabilities.

But is built-in routing better? That depends on the network. Net managers already using gear from a variety of vendors might prefer a standalone box; on the other hand, adding VPN cards—where available—to routers already in place could be the more economic move. And when making the decision, bear in mind that VPN devices are currently interoperable at only a basic level. What's more, some vendors—including Shiva and VPNet—say their boxes offer only limited routing and may not run protocols like IPX; they say their units should be deployed in conjunction with routers already in place.

Another feature to look into is firewall capability. Some products—including those from Bay, Internet Devices, IRE, Radguard, and Timestep— can filter out packets from unauthorized external sources. Still, the truly security-conscious tend to avoid using one box for all their protection n eeds. "We recommend our device be placed in parallel with an existing firewall," says John Burnham, director of product marketing for extranet access at Bay.

Puzzle It Out

As for how VPN hardware actually secures the network, all products rely on a combination of encryption and authentication. On the encryption side, devices establish a secure tunnel between two sites (or between one site and a client PC). Both the payload and the header of each IP packet traveling between the two locations are encrypted, and a new, unscrambled header is added at the top of the packet (so that it can still be routed). Encrypting the payload prevents eavesdroppers from listening in; scrambling the IP header stops hackers from figuring out who in the internal network is talking to whom.

Corporate networkers evaluating VPN hardware have a choice of three main encryption algorithms: DES (data encryption standard), triple DES, and IDEA (international data encryption algorithm). All VPN hardware vendors ba ck DES, and most also support triple DES. Fortress is the only vendor surveyed that offers IDEA.

Since the algorithm defines how easily the encryption can be solved, it's important to choose carefully. DES, with only a 56-bit key, is probably near the end of its road: It keeps getting cracked, most recently by a team of programmers from an online organization called distributed.net, who did it in only 39 days by using thousands of computers to run through all possible key combinations. No wonder Stuart Lombard, vice president of VPN marketing at Shiva, calls the market demand for DES "nonexistent." Triple DES (which has a 112-bit key) and IDEA (with a 128-bit key) will keep the hackers at bay for now. Trouble is, the U.S. government restricts key export, so companies building international networks may be out of luck. Before building a VPN overseas, figure out what type of encryption is available.

Dealing In Keys

But even before a secure tunnel can be established, VPN devices have to agree on a key. Most products rely on a two-tier scheme for handling encryption keys (see "Internet Security: How Much Is Enough?" April 1996; http://www.data.com/Roundups/How_Much_is_Enough.html ). There's a session key, which is used for the actual encryption, and a public/private key pair, which is used for exchanging the session key.

How are the public and private keys managed? The private key is almost always generated on the VPN and stored in memory, but the public key has to be made available to other boxes in the network. Vendors typically do this via a centralized directory of public keys, or by distributing the keys to every device in the VPN.

Many vendors also use X.509 digital certificates for key management. Because each certificate contains the public key of the VPN, devices merely need to exchange certificates to communicate. The big advantage of certificates is interoperability: The X.509 spec has been incorpora ted as part of the IPSec standard for secure VPNs. In fact, some vendors—Shiva, Timestep, and VPNet Technologies—now rely solely on digital certificates for their key management (see "Certificate Authorities: Who Do You Trust?" March 21, 1998; http://www.data.com/roundups/certificate.html ).

Who Goes There?

Authentication is the next feature to check. VPN access devices perform this in three ways. Message authentication checks the identity of each packet, proving that it hasn't been altered in transit. Client authentication guarantees that other devices in the network are legitimate VPN sites. User authentication relies on passwords, tokens, or smartcards to check the identity of remote users trying to gain access to the network.

VPN devices perform message authentication along with encryption as part of the tunneling process. Each IP packet is stamped with a unique checksum known as the authentication header (AH), which proves the packet's authenticity and guarantees it hasn't been altered in transit. Vendors typically support two algorithms for message authentication: MD-5 and SHA-1, both of which are included in the IPSec standard. While one suffices, having both improves the chances of interoperability.

For effective client authentication, net managers should look for a product that boasts X.509 digital certificates. When one box requests a secure session with another, it asks for a copy of that unit's certificate. If the document checks out, the device knows it's talking to a legitimate VPN site.

As for user authentication, almost every vendor now offers remote user software that sets up a secure tunnel between a laptop and VPN access device. In fact, some (Bay and Shiva among them) work under the assumption that their products will be used primarily for remote access. Most vendors offer smart cards or tokens for user authentication as a safer alternative to passwords (although vendors that do suppo rt cards and tokens optionally allow the use of passwords too).

Time to Talk?

There's another thing networkers should consider: Interoperability. For the last few years, vendors have been working on two fronts to get their products to talk to one another. First, they've been working with the IETF on IPSec, which lets devices set up tunnels, perform authentication, and exchange keys. Right now, most products support both IPSec and ISA/KMP (Internet Security Association/Key Management Protocol) Oakley, the standard for key exchange within IPSec. And those vendors that don't say they'll be offering compliant products within the next few months.

Second, vendors are running tests to ensure that their products do in fact communicate. But standards compliance and actual interoperability are two different things. "It's dragging on a bit," admits Shiva's Lombard. For years, vendors have been attending demonstrations hosted by the Automotive Network Exchange (ANX), a group of U.S. automakers a ttempting to build an extranet for ordering parts from suppliers. Interoperability has been achieved at a basic level—but more work needs to be done to finalize a spec. "The drafts have been changing on a fairly frequent basis," says Lombard—which means the testing process has to be repeated.

Fortunately, there is a guideline that network managers can work toward. In March, the ANX announced field trials with six vendors that it said had best met interoperability requirements: Cisco, Checkpoint, Radguard, Raptor Systems Inc. (Waltham, Mass.), Timestep, and Trusted Information Systems Inc. (TIS, Glenwood, Md.). Other VPN boxes were tested, but they didn't exhibit an acceptable level of interoperability.

Lombard says full interoperability among all products probably isn't that far away—maybe four or six months. But the actual date depends on how quickly vendors get approved by the International Computer Security Association (ICSA, Carlisle, Pa.)—the group that handles firewa ll testing—which has assumed responsibility for certifying vendors for IPSec compliance. And because ICSA issued a detailed spec before it invited vendors to come into its labs, products approved by the organization should in theory work together.

Add It Up

Now it's bottom-line time. Yes, net managers know that VPNs can save them money over costly leased lines. But they also have to weigh in the cost of the VPN access devices themselves.

And thanks to all that hardware, prices tend to be high—starting at $5,000. Sure, the box will probably cover security for an entire site—encrypting and authenticating all traffic flowing from one end of a corporate network to the other—but there could be other expenses as well. Remote client software, for instance, costs from $25 (Redcreek) to $99 (Fortress, Timestep, and VPNet) per user (discounts are available for multiple licenses).

And don't forget the management server, the unit that looks after the keys and allows a dministrators to revoke them. Not every product requires one, but for those that do expect to pay another $10,000. Certificate authority servers also cost extra; Radguard's, for example, comes in at $6,500.


CONTACT AUTHOR
acray@data.com

If there's any place software beats hardware, it's here. But net managers will have to decide if paying several thousand dollars less is worth the performance penalty. One software option is the F-Secure VPN encryptor from Data Fellows Inc. (San Jose, Calif.), which costs just $2,495 ($3,500, with the machine it runs on).

But sometimes software isn't cheaper. Take the Aventail VPN from Aventail Corp. (Seattle). It comes in at $7,995—not including the server. Still, net managers also get a built-in firewall and access control functions, plus software f or 50 remote users.


Andrew Cray is WAN equipment editor for Data Comm. He can be reached via e-mail at acray@data.com .


Home Contact Editors Lab Tests Registration Tech Tutorials
Buyer's Guide Global Networks Opinion / Columns FAQs Subscriptions

CMPnet Click Here to Vist CMPNET