Rocky road ahead?
By shelving XAUTH, the IETF intended to simplify remote access VPN implementation and deployment. Ironically, the decision may have the opposite effect in the short run.

When the IETF drafts expired, vendors implementing XAUTH were left without a common, readily-available specification. Some vendors that rejected XAUTH have already implemented another solution—for example, Microsoft deployed L2TP over IPsec for secure remote access in Windows 2000. Eventually, the IPSRA may standardize a very different solution. One proposal now being considered is based, in part, on digital certificates. Ultimately, this kind of divergence hampers multi-vendor interoperability and complicates migration.

What does this mean for ISPs?
Clearly, ISPs that want to offer IPsec remote access services with legacy user authentication can do so today. Many ISPs—including Genuity, UUNET, and Sprint—already do. Products incorporating XAUTH or Hybrid have been around for a while. Vendors have worked together, both publicly and privately, to address interoperability issues. To this end, the VPN Consortium (VPNC) recently created an XAUTH mailing list for implementor discussion. The VPNC also re-posted the XAUTH draft, giving vendors a common specification to implement against.

But ISPs entering this business should also realize that at least some change is likely in the long run. XAUTH won't evaporate while there's a market for it, but alternatives will appear. Several IPsec vendors have already added (or plan to add) L2TP over IPsec in order to interoperate with the native Windows 2000 IPsec client. We'll discuss L2TP and how it supports user-level authentication in next month's column.

One way to protect your investment today is to plan ahead for migration tomorrow. Keep XAUTH/Hybrid details hidden from customers by using generic provisioning interfaces and forms (a good practice anyway).

Even if you don't need multivendor interoperability right now, seek a vendor that considers it a priority. It's always good idea to avoid getting locked into a single source, and tight coupling between IPsec gateways and clients can limit your options. In an ideal world, you'd be able to offer your customers a choice of client-independent platforms. Is your vendor heading in this direction?

Some customers will prefer to run their own RADIUS or ACE servers; others will look to you to provide a managed authentication service. Be flexible in your remote access VPN offering, while tapping this opportunity deliver a set of complementary services.

Finally, if you haven't already done so, start gearing up for PKI now. Customers seeking IPsec remote access with strong authentication may opt for a managed PKI service. Look for a partner that can help you deliver managed PKI to your customers, or start planning to roll your own offering.

In future columns, we'll examine other challenges and opportunities associated with offering remote access VPN services.

—End

Back to page 1, page 2