 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 Familysince 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 didand 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/swith 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
dutyacting 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/sand
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/sslightly 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.5since 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 sessionsbut 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
productsincluding Radguard's Ciprooffload 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 officegiving
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
vendorsincluding Ba
y, Cisco, Redcreek, Shiva, Teltrend, and
VPNetoffer 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 cardswhere availableto
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
vendorsincluding Shiva and VPNetsay 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
productsincluding 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 vendorsShiva, Timestep, and VPNet Technologiesnow 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
levelbut more work needs to be done to finalize a spec. "The drafts
have been changing on a fairly frequent basis," says Lombardwhich
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 awaymaybe 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 testingwhich 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 highstarting at
$5,000. Sure, the box will probably cover security for an entire
siteencrypting and authenticating all traffic flowing from one end of
a corporate network to the otherbut 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.
|