Network Computingwww.networkcomputing.com

Client-side interoperability poses additional problems because of the nature of remote access. IPSec peers are identified by their addresses during IKE negotiation and by their protected subnets during IPSec negotiation. However, remote users' IP addresses are indeterminate a priori, and can't be relied upon as ID. In single-vendor remote-access environments, clients are identified by some proprietary mechanism, such as a certificate or a user name/password pair. The client is then assigned an IP address local to the VPN gateway and the VPN is formed.

We used TimeStep's Permit/Client and IRE Safenet/SoftPK for interoperability testing. We also used TimeStep's Permit/Gate 7520 and VPNet's VSU-1100 as gateways. In both cases, we ran into similar issues with forming host VPNs--getting the subnet and identity naming correct in both the client and the gateway. Although manual configuration will get VPNs up and running, there are obvious issues: It's not scalable and requires some expertise on the end user's part to configure or modify the configuration in the field. Neither option works in the general user population.

A number of drafts in the IEFT IPSec working group use different approaches to configuring remote hosts. One method is to exchange configuration information during Phase 1 of the IKE exchange, commonly called Mode Config. The exchange is initiated in either direction by a two-step handshake. The advantage to Mode Config is that it occurs at the initial stages, though it does complicate the exchange. The other option uses a DHCP security association at the start of the VPN session. While DHCP is well understood and can be extended by the vendor, it also adds a step to VPN construction.