IPSec punchfest, 12/27/99

Error 404--Not Found

Error 404--Not Found

From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.

Error 404--Not Found

Error 404--Not Found

From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.

IPSec punchfest

You need look no further than the IP Security (IPSec) effort if you want to see a perfect example of a power struggle in the network industry. Power swirls around this Internet Engineering Task Force protocol like a twister surrounding Dorothy.

chart

Contributing to the maelstrom are arch rivals that intermittently work together over IPSec interoperability and duke it out over how to write the next portion of the specification; at least four independent - and often opposing - testing organizations; and a handful of spokespeople for users, who remain sorely under-represented.

While the core of the IPSec specification, including machine-to-machine tunneling and encryption methods, is now an official standard, bickering continues over how to improve the standard. Likewise, vendors and testing organizations are engaged in power battles over how to validate implementations of the agreed-upon IPSec standard. And the already slow democratic process of the IETF grinds to a crawl.

"The IPSec Working Group has been working for about seven years. Usually the IETF likes a working group to finish in 12 to 18 months," says Ron Cully, lead product manager for Windows Networking for Microsoft.

To be fair, the working group has valid reasons for a lengthy tenure. A security standard for IP - originally intended to be part of IPv6 - is a complex matter. And the target keeps moving.

"It's taken them so long largely because the technology changed out from under them," explains Andrew Newman, senior systems analyst for Yale University IT Services, an IPSec user and co-author of "Implementing IPSec." "The early IPSec standard . . . was developed for a time when there wasn't a broad need for security."

Not so today. The average enterprise uses IP to create LANs, provide remote access, connect far-flung offices and conduct electronic business. In addition, the enterprise has sewn itself up with remote access servers (RAS), public-key infrastructures and network address translators. Smoothing a standardized IP-based security blanket over the top is no easy task.

Still, the same argument could be applied to any widespread standard conceived to ensure multivendor interoperability. Yet Secure Sockets Layer has managed to grow from seed to flowering plant in roughly the same time frame. And XML shows that the industry can cooperate in fast-forward mode when it wants to.

So what's the holdup on widespread IPSec interoperability? Why, after years of bake-offs and Interops, does interoperability remain iffy at best?

The answer has three parts: Philosophical disagreements in the working group tend to come from companies that have a vested interest in a particular technology; testing organizations work for the vendors; and users don't have much input.

The philosophy of security

Vendor marketing makes it sound as if the industry is a lot closer to IPSec interoperability than it actually is. It's true that interoperability exists today, but only if you need to tunnel between gateways with permanent IP addresses and you can exchange keys offline. If vendors claim interoperability - or display a stamp from the International Computer Security Association (ICSA) - this is typically the IPSec compliance they're espousing.

"The basic stuff is done and has been done for some time," says Bob Moskowitz, IPSec Working Group co-chair and senior technical director in charge of the ICSA's IPSec testing lab. "But there are a number of problems we face from here, such as Internet Key Exchange (IKE) with a preshared key - it needs a static IP address. That eliminates dial-up."

IKE is IPSec's handshake and determines which cryptographic algorithm will be used for the session. Obviously, static addresses and preshared keys won't cut it for all users - particularly dial-up users with their dynamic IP addresses and extranet partners with whom a preshared key may not be practical.

"Interoperability for virtual private networks (VPN) has been an issue with us. Within our own company we find that as soon as you start running multivendor products, you're in trouble," says Ken Ng, systems architect for American Protective Services, a 15,000-employee, 100-office physical security firm based in Oakland, Calif. "We want the VPN to reduce the cost of our dial-up RAS."

And so the battle lines have been continuously drawn over how to modify the IPSec standard for remote access. For example, an IETF Working Group called IP Secure Remote Access has been formed to solve these issues - and this is reportedly the third time that vendors have tried to create an IPSec remote access working group.

There are three camps in the dispute. One wants to use Layer 2 Tunneling Protocol (L2TP) with IPSec; another wants to modify IKE so it can support legacy remote access authentication over the Internet (within this group are several alternatives); and a third group wants IKE modified to support Dynamic Host Configuration Protocol (DHCP).

You need only look at a vendor's background to see which stance it is taking. Microsoft, which helped develop L2TP with Cisco, is leading the push for the L2TP/IPSec method. (L2TP is a derivative of Microsoft's Point-to-Point Tunneling Protocol and Cisco's Layer 2 Forwarding.)

TimeStep, which has always positioned itself as an IP-based VPN provider, has developed an Internet draft, dubbed IKE-XAUTH, that spells out the IKE/ Remote Authentication Dial-In User Service (RADIUS) method. XAUTH stands for extended authorization. In fact, TimeStep has already released a product based on IKE-XAUTH, Permit Enterprise Version 2.0.

Other extensions to IKE include Hybrid Mode from CheckPoint Software (which uses XAUTH) and Crack from Network Alchemy.

RedCreek Communications is leading the DHCP push. Engineers at RedCreek say their method - which spans two drafts - configures and authenticates remote access users' systems using existing protocols and requiring no IKE modifications. RedCreek was one of the first vendors to support IKE in its earlier form, ISAKMP.

To complicate matters, some of the L2TP crowd has joined RedCreek. Intel, Microsoft and Sun contributed to the first DHCP draft, and Microsoft also contributed to the second draft. But clearly Microsoft is putting its might behind the L2TP pitch. For Microsoft, it's not much of a risk. The L2TP draft uses DHCP anyway, says William Dixon, program manager for IP Security at Microsoft and an active participant in the IETF working group.

The advantage of L2TP over IPSec is that it marries the exceptional encapsulating ability of L2TP with the superior security of IPSec, supporters argue. Both are well-established protocols that have been proven to work together. And this method places the burden of complexity on vendors, proponents say.

Opponents disagree, claiming that L2TP over IPSec burdens users because two protocols are inherently harder to support than one. Also, they say this draft is inefficient because it doesn't authenticate the user before establishing the connection. If the user isn't authorized for the services granted, it shuts down the connection.

A third common complaint is that L2TP over IPSec increases system overhead, a notion that Microsoft's Dixon downplays: "L2TP has the ability to use header compression. With that, the header content gets down to a single byte of overhead."Backing the viability of L2TP with IPSec are some analysts - independent of the IETF working group - who note that L2TP is used to encapsulate other types of packets in IP and is already common in enterprise nets.

"Most enterprises don't have just IP. They have IPX and SNA. L2TP isn't aimed at [Open Systems Interconnection] Layer 2 tunnels, [as is IPSec]. There's no reason why you wouldn't use both in a network," says Eric Zines, senior market analyst for TeleChoice and presenter for Network World's VPN technical seminars.

Those in favor of modifying IKE for stronger authorization point to elegance - especially for users who aren't supporting L2TP already. "They argue if you're going to do IKE [for authorization], add the code and do it right," IPSec Working Group's Moskowitz says. By improving IKE, IPSec can support legacy security systems such as RADIUS.

But others are against the idea, calling that approach "imprudent" in their drafts. The catch, they point out, is network address translation (NAT).

NAT is a work-around for the address shortage in IPv4. It lets companies use their own, unregistered IP addresses for devices when communicating internally and to share fewer registered addresses when sending packets externally. NAT devices are good for making do with fewer registered addresses, and they add security. If hackers can't find the IP address, they can't access the device from the outside. But "IKE is NAT-hostile," Moskowitz says. "It places the IP address inside an encrypted packet."

At best, this means that the internal address must become public - negating NAT's security benefits. At worst, it places that IP address inside an encrypted packet, leading to routing problems.

Certificates, too, remain a sticky issue for user authentication. While one request for comment (RFC) describes how to exchange certificates, it does not specify how those certificates are verified, Microsoft's Dixon says. So, of course, vendors are filling in the blanks themselves. "Interoperability tends to get derailed by other vendors. You have to implement pieces that are essentially vendor extensions," Yale's Newman says.

No objectivity

Which technical choice should users push for? That's hard to say because there are no objective sources of information, other than the trade press. Vendors are basing their drafts on technologies that give them the fastest time to market, not necessarily the best standard.

"RedCreek and TimeStep are two relatively small companies very active in standards work and shipping products," Dixon says. Of course, Microsoft, too, has implemented IPSec over L2TP in Windows 2000.

The best source of information would be other users, but they aren't involved enough. "Although the IETF is pretty open, users don't get much of a voice. The people spending most of the their time in working groups are the vendors, Dixon says."

Adds Moskowitz, "these issues are so heavily laden with technology that most users won't be able to enter the debate effectively unless they go the route I've gone and really get into the middle."

Even Moskowitz, users' former top representative, now represents a vendor of sorts. Although Moskowitz is still the working group's chair, he was working for Chrysler when he began with IPSec.

Currently he runs the IPSec interoperability test lab at the for-profit ICSA. While it's certainly good to have a former user as testing watchdog, the ICSA makes big bucks from the chronic lack of interoperability, reportedly charging as much as $25,000 per box for testing.

Consequently, some working group insiders have accused Moskowitz of having a conflict of interest. As long as interoperability problems remain high, business will boom at the ICSA, they say.

Moreover, the ICSA tests only shipping products for IPSec conformance - and only a subset of the RFCs at that - along with testing other aspects of security. And although the ICSA doesn't publish this statistic, boxes routinely fail. This has frustrated many vendors that want the ICSA to help them achieve compliance for the current standard and emerging versions.

Vendors are so angry that they've established a second forum, the Virtual Private Network Consortium (VPNC). Paul Hoffman, known for his work with the Internet Mail Consortium, runs this group.

"All of my members are extremely unhappy with the ICSA. The ICSA is absolutely failing them," Hoffman says. However, he adds that if the ICSA would agree to assist with interoperability development more, "there would be no reason for the VPNC to exist."

Moskowitz says this is a case of the good guy vs. the bad guy. "Paul plays the role of getting things going, and the ICSA is the bad guy at this point. We hand the box back to the vendor and say 'fix your product.' We don't want the ICSA to be the good guy, or we can't be an effective bad guy. We want two organizations."

Still, Hoffman recognizes that the market is so wrought with power struggles that vendors have created their own interoperability bottleneck.

"It's not the standards process that's going so slowly. It's the vendors," he says. "Vendors won't get on the phone with one another. . . . A lot of them do want to cooperate, but only to get interoperability on whatever feature is hot today."

For that kind of short-term cooperation, vendors can turn to the IPSec Developers Forum. Formed by Radguard, the forum introduces vendors to one another for one-on-one tests, says Avi Rembaum, director of marketing for Radguard in Tel Aviv, Israel, and the forum's manager. Developers can use the forum for free.

Likewise, the National Institute for Standards and Testing (NIST) has a test site on the Web that allows vendors to test their IPSec products against a reference IPSec implementation over a live Internet connection. For example, it allows vendors to test "a single IKE negotiation," says Sheila Frankel, a computer scientist for NIST's Computer Security Division in Gaithersburg, Md.

Yet for all this testing, none of the results are available to users. The rationale is that if the public knew about failed tests, vendors wouldn't want to work on interoperability.

However, one exception exists. ICSA publishes lab notes for products that receive the ICSA stamp. These document exactly how interoperability was achieved. Long notes embarrass the vendor into improving its IPSec implementation, Moskowitz says.

Still, the VPNC, the IPSec Developers Forum and NIST sites are helpful user sources because they offer other ways to glean information about IPSec interoperability. The VPNC is readying a chart that documents which vendors have tested successfully with each other, and the Forum and NIST are available to users for IPSec interoperability tests. Plus, NIST lets you download its IPSec reference specification - which is valuable for network engineers who need to learn about IPSec.

At this point, the process sorely needs more user input. Your future remote-access network is being decided now, and for the most part, without you.

Related links

Contact Senior Editor Julie Bort

IETF IPSec working group

IPSec secures overhauled aeronautic net
Network World Fusion Focus on Security, 06/02/99.

IP Security: Keeping your business private
Network World, 3/15/99.

IBM presses for new IP Security implemention
Network World, 1/11/99.

Elron Software ships IPSec-based firewall with command-line filtering
Network World Fusion, 12/14/99.

Securing the last mile
Testing shows a level playing field for user-to-site VPNs.
Network World, 12/13/99.

Sign up for our Fusion Focus on Security newsletter
Keeps you up-to-date on the latest products and services.

Send this article to a colleague

Interactive power-o-meter

Profiles in Power

Profiles in Power

Power Struggles

Power Sign-off

The Signature Series

Home
Contact us
Site Map
Today's news
This week in NW
Research

Free newsletters
Forums
Opinions
Careers
Terms of Service
Network World, Inc.

Seminars & Events
Advertiser Index
Product Showcase
Vendor white papers
NW Subscriptions

Copyright, 1995-2001 Network World, Inc. All rights reserved.