VPN devices show strength on security

VPN devices and software employ multitier encryption, authentication and access control
to establish secure Internet tunnels between remote sites, field offices and headquarters
LANs.

VPNs reduce network support and hardware requirements, eliminate expensive dedicated
lines and cut telecommuting costs. A single VPN hardware server attached to the office
network removes the need for maintaining modem banks and remote-access servers.

Remote users simply load preconfigured VPN tunneling software onto their PCs and
connect to their Internet providers instead of dialing up the office network.

National Software Testing Laboratories Inc. of Conshohocken, Pa., recently tested six
leading hardware VPN devices and found each to have top-notch security. Each device could
fend off more than 200 types of attack, and remote management was easy in most cases.

Despite the good security and usability, however, performance was difficult over links
at T1 or faster rates.

In worst-case stress testing, the devices dropped anywhere from 50 percent to 85
percent of offered loads. For intranet applications that send lots of short packets, this
results in lots of retransmissions.

Although the loss of packets negated bandwidth savings, a couple of products stood out
for their features and security. The clPro VPN from Radguard Inc. had tamperproof security
and enterprise-ready management features.

The VSU-1010 from VPNet Technologies Inc. also offered great security and management.
Both earned Reviewer’s Choice designations, but VPNet’s product performed best
overall.

NSTL tested all devices for security, ease of management and performance. The test bed
modeled a LAN-to-LAN connection over the Internet using a matched pair of VPN boxes, one
at each site. For performance measurements, the test bed had 10-Mbps Ethernet connections
instead of the more common 1.5-Mbps or 56-Kbps links. But in all other respects it
represented a typical office-to-office VPN connection.

Vendors had to comply with several requirements to ensure a fair comparison. NSTL
accepted only hardware-based VPN de-vices, because encryption performed in software is
generally too slow for 1.5-Mbps or faster links.

NSTL asked vendors to disable data compression so that encryption performance could be
measured. NSTL also required that devices support triple Data Encryption Standard
encryption, Encapsulating Security Payload tunneling, and message authentication using
either Message Digest 5 or Secure Hashing Algorithm 1.

For government agencies, security is unquestionably the most crucial VPN attribute, so
the first order of business was to evaluate vulnerability.

Rather than try to break encryption schemes, NSTL used SafeSuite 5.0 from Internet
Security Systems Inc. of Atlanta to launch more than 200 common and not-so-common attacks.
They ranged from attempting to gain super-user access to simply tying up the device with
so much traffic it could not handle legitimate requests—the so-called
denial-of-service attack.

SafeSuite found vulnerabilities in only two products, and one was a false positive.
SafeSuite reported that the Fort Knox Policy Router from Internet Devices Inc. responded
to the Unix rwho (remote who) command, showing which users were logged on. But Internet
Devices said the product does not run this service, and it’s possible that SafeSuite
mistook the vendor’s key management daemon for rwho.

The LANRover VPN Gateway from Shiva Corp. was the only product to show a true
vulnerability. Attackers could guess its Transmission Control Protocol sequence numbers, a
weakness that could be exploited to make traffic appear to have come from a trusted
machine. Shiva was unaware of this vulnerability before the NSTL tests, and it promised a
patch would be ready before the end of this month.

Although the other products came out clean, NSTL does not certify them as safe. Its
tests required the world’s top authorities on securing these VPN devices—the
makers themselves—setting them up to withstand known attacks.

In the real world, configuration errors and new attacks are common. Buyers should
consider security an ongoing issue and run frequent checks with scanning devices and
intrusion-detection systems.

Next came the management test. Considering the functional differences between products,
NSTL decided not to attempt head-to-head comparisons of configuration and monitoring
capabilities.

Instead, working with input from VPN users and vendors, we developed real-world
scenarios focusing on two essential functions: key management and device administration.
Remote configuration was a special concern, because VPNs inherently involve remote
locations. For both scenarios, NSTL defined several tasks and rated them on how easily the
VPN devices worked.

In the first scenario, a hypothetical network manager received a call at home saying
that an encryption key had been compromised. The manager had to perform three tasks,
preferably without going to the office: Immediately revoke the compromised key, verify
that the VPN device had dropped all active sessions and disable the external interface.
The latter task would prevent an attacker from using the key until logs could be reviewed
next morning.

All the VPN devices allowed remote revocation of keys. All products except Permit/Gate
4520 from TimeStep Corp. dropped all active sessions automatically when a key was revoked.
Permit/Gate can drop sessions remotely, but it requires giving a separate command.

The two-step process raises the possibility that the manager might forget. VSU-1010
scored high because it made this task particularly easy.

Every device had simple routines for remotely denying access by disabling an interface.
The leaders were Radguard’s clPro and the products from Shiva and VPNet.

For the device management scenario, the net manager was supposed to enable Web access
remotely on VPN devices that had formerly allowed only File Transfer Protocol traffic.
NSTL wanted to verify that remote commands were encrypted, find out whether enabling new
rules would force active sessions to be dropped, and verify that rule changes did not
require a reboot.

Net managers appear to be in safe hands when it comes to sending commands from a remote
location. All the products used strong encryption to safeguard configuration sessions.
Those from Internet Devices and VPNet use 128-bit Secure Sockets Layer encryption.
Radguard and Shiva use 112- or 168-bit triple DES. Ravlin from RedCreek Communications
Inc. and TimeStep’s VPN product both rely on Hashed Message Authentication Code
encryption algorithms.

NSTL also verified that rule changes could be invoked without dropping active sessions.
Products from Internet Devices and TimeStep were the only ones to cut off active sessions.
Though not a major drawback, this could pose a problem for sites with large numbers of
users.

In ease of invoking rule changes, the standout was Shiva’s LANRover. The device
can schedule new rules to go into effect at a future time, which comes in handy for making
changes when the manager is unavailable.

As for changing rules without having to reboot, TimeStep’s Permit/Gate 4520 was
the only device that required a restart. Net managers don’t often make changes to
access rules, but taking all VPN users offline might be unacceptable for high-availability
applications. TimeStep officials said the next release will not require a reboot.

In reviewing overall ease of management, NSTL gave special consideration to products
that make it easy to configure and monitor large numbers of VPN devices. The standout was
Radguard’s clPro, which gets all its configuration parameters from a button-sized,
plug-in token. An administrator could simply ship out the tokens to field locations.

TimeStep’s Permit/Gate sets all configuration parameters just once—at the
certificate authority—for devices to download as they come online. Close behind were
the tools from Shiva and VPNet, which have simple, no-nonsense configuration menus.
Internet Devices’ Fort Knox Policy Router has a slightly more complex management
interface, but is accessible with any Web browser.

Although security is of prime importance, performance clearly matters. NSTL devised a
stress test involving worst-case traffic loads and security tasks. VPN devices have custom
silicon to speed encryption, but data scrambling still inflicts a major performance hit.

The reviewers requested that devices have the fastest interface type supported by all
products (half-duplex 10-Mbps Ethernet); that they authenticate each packet using MD-5 or
SHA-1 algorithms; that they use triple DES encryption; and that they disable compression.
As it turned out, only the Shiva and VPNet products supported compression.

In the test bed configuration, one virtual office sent a stream of packets to the other
over a virtual Internet, represented by an external router. The VPN products acted as
bridges rather than routers in all cases.

NSTL sent unidirectional traffic so that it could be offered at wire rate, without
collisions caused by multiple generators, between a pair of VPN devices on an encrypted
link. A protocol analyzer measured the traffic rate on the sending and receiving sides.
The testers ran the tests twice, once with authentication only and again with
authentication plus encryption.

For each set of tests, traffic ranged from 64-byte packets, the smallest Ethernet
allows, up to packet sizes of 512, 1,024 and 1,280 bytes—all offered at wire speed.

The testers began with encryption disabled to see whether performance suffered from
authentication and bridging. Most products did indeed slow things down. Even without
encryption, only two products forwarded all clear-text traffic without dropping packets:
RedCreek’s Ravlin 10 and VPNet’s VSU-1010. The others forwarded 60 percent or
less of the offered load. TimeStep’s Permit/Gate 4520 forwarded just 23 percent of
short packets.

With encryption enabled, things got worse. No product came close to wire-speed
performance. In fact, all dropped at least 50 percent of the offered load. The top
performer was VPNet’s VSU-1010, which managed to move 46 percent of traffic, or
nearly 6,700 packets per second.

RedCreek’s Ravlin 10 was close behind, forwarding more than 6,000 packets per
second, but every few seconds, the pair of Ravlin devices would stop transmitting for
about five seconds, then begin again.

Stop-start behavior is anathema to delay-sensitive applications such as voice and
video. Even some data apps could run into trouble. RedCreek attributed this behavior to a
watchdog process that monitors for security problems. The vendor offered a customized fix
but acknowledged that stock production units would perform the same as those NSTL tested.

Even so, the Ravlin’s encrypted forwarding rate was higher than that of other
devices. The Internet Devices product forwarded only 36 percent of encrypted traffic
without loss. TimeStep’s Permit/Gate forwarded 23 percent, and devices from Radguard
and Shiva less than 20 percent.

Performance was far better with longer packets, even when operating under triple DES
encryption. For 512- and 1,024-byte packets, only two did not forward at wire speed:
RedCreek’s Ravlin and TimeStep’s Permit/Gate. Ravlin hit wire speed with
1,280-byte packets, but with the pauses described above.

NSTL tried to send 1,518-byte packets, the longest Ethernet allows. But VPNs don’t
actually forward 1,518-byte packets intact, because the ESP header would make them
illegally long. The TCP/IP stack instead breaks the packets in two, transmits the
fragments and reassembles them on the receiving end. Each of the devices transmitted all
the fragments at wire speed.

These performance ills might give pause to network architects designing intranets or
apps that use a lot of short packets. One of the biggest VPN benefits is saving money on
leased lines, but if VPN devices chew up bandwidth by dropping traffic, savings could
prove elusive.

It always helps to put results in perspective. First, security is more important to
government network managers than performance.

Second, applications that mainly involve large packetlike batch file transfers or
server mirroring will do just fine with any of these devices. Testing suggests they can
handle links up to 10 Mbps with no degradation of long packets.

Third, performance will not be much of a concern to the many agency offices that have
links operating at T1 or slower rates.

Fourth, few production networks ever see maximum packet rates over long periods.
Nevertheless, bursts of wire-speed traffic are common, and VPN devices can drop packets
and force retransmissions.

Last year, most VPN devices could handle only encryption and authentication.
They’ve come a long way since then. Five of the six devices NSTL tested are also IP
routers, three serve as firewalls and three can be certificate authorities. The Fort Knox
Policy Router even does bandwidth management. All the products can handle dial-up and
LAN-to-LAN connections.

The products have in common IP Security protocol compliance—as far as it goes.

The emerging TCP/IP security specifications from the Internet Engineering Task Force
remain in flux. That leaves vendors a lot of wiggle room and does little to ease fears
that products won’t work together.

IPSec defines two types of key management: an umbrella standard called Internet Key
Exchange, formerly known as ISAKMP/Oakley, and a key exchange method called Simple Key
Exchange Internet Protocol, developed by Sun Microsystems Inc. All vendors back IKE, but
not all use the same version.

IPSec doesn’t specify an encryption algorithm, largely because export restrictions
make standardization almost impossible. For this test, NSTL relied on the IETF’s
Request for Comments 1851, which specifies how to perform triple DES when using
IPSec’s encapsulating header format.

Fortunately, IPSec is clearer about secure transmission. The Encapsulating Security
Payload defines a method of tunneling, or encrypting an entire packet and placing it
inside a larger packet for transport. The Authentication Header defines a way of
authenticating traffic without encrypting it. Although tunneling means more overhead,
encryption makes it a much safer way to move traffic.

Aside from adherence to IPSec, there’s another way these products are similar.
They all fall short in the interfaces available. The highest common denominator among the
products tested was 10-Mbps half-duplex Ethernet, although products from Internet Devices,
Radguard and Shiva also supported 100-Mbps Fast Ethernet. VPNet’s VSU-1010
didn’t allow full-duplex Ethernet connections, and no product had interfaces for an
asynchronous transfer mode, a Fiber Distributed Data Interface or a token-ring.

The vendors need to add software for more types of dial-up clients, which are generally
for Microsoft Windows 95 and Windows NT only. TimeStep has an Apple Macintosh client, and
RedCreek has a Windows for Workgroups 3.11 client, but none of the products offers
software for MS-DOS or Unix.  

Helen Holzbaur is a network project manager at National Software Testing
Laboratories Inc. of Conshohocken, Pa.