January 4, 2000 Web posted at: 10:47 a.m. EST (1547 GMT) by Julie Bort

From...

(IDG) -- 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.

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.

	MESSAGE BOARD
Encryption

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.

MORE COMPUTING INTELLIGENCE

IDG.net home page

IP Security: Keeping your business private

Securing the last mile

What are the hot security issues for 2000?

IDG.net's network operating systems page

Reviews & in-depth info at IDG.net

E-BusinessWorld

Year 2000 World

Questions about computers? Let IDG.net's editors help you

Subscribe to IDG.net's free daily newsletter for network experts

Search IDG.net in 12 languages

News Radio

Fusion audio primers

Computerworld Minute

"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.

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.

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.