Standard needed so VPN failures can be detected

The Internet Engineering Task Force is working to plug a gap in the IP Security virtual private network standard that lets VPN gear continue to send packets even after the equipment receiving the data has failed.

Because IPSec is the authentication and encryption standard that most VPN vendors are adopting, the standard should spell out how VPN tunnel servers can quickly discover that the peer or client it was talking to has died, industry experts say.

Otherwise vendors will keep using proprietary methods that inhibit full interoperability among multivendor gear. Such interoperability is key to an important potential use of VPNs: granting business partners secure access, says Eric Zines, a consultant with TeleChoice, a telecom consulting group in Boston.

Interoperability should let your business partner's gear talk to yours, no matter what company makes it, as long as they both meet the IPSec standard. And that should include a keep-alive feature that would cure the problem, Zines says.

The IETF has received several keep-alive proposals, according to Robert Mos-kowitz, co-chair of the IETF's IPSec Workgroup, but none were discussed at the group's last meeting. Other issues, such as proper configuration of IPSec clients and network address translation, took precedence, he says.

Moskowitz also says there is no consensus within the group. "The answer is that we don't know the best way to do it."

Some vendors have built proprietary technologies to meet the need for a keep-alive feature. Intel gets around the problem by shipping its VPN gateways with IPSec software and Shiva Smart Tunnel software, products Intel acquired when it bought Shiva. Smart Tunnel includes keep-alive, according to Bob Lonadier, an Intel VPN product manager.

Nortel's Contivity gear uses information gathered via routing information protocol (RIP) to update which other Contivity boxes are still active. Compatible Systems' IntraPort devices ping each other.

Other vendors, such as TimeStep and 3Com, are waiting for a standard before incorporating a keep-alive feature.

Without the feature, different vendors' boxes can still establish encrypted sessions over an IP backbone and transfer data. But if one box goes down and loses track of established tunnels, it is cumbersome to establish new ones.

"That was one of the biggest problems we had in our interoperability tests," says Joel Snyder, a senior partner at Opus One, a Tucson, Ariz., consulting group. Snyder helped run VPN interoperability tests in May at NetWorld+Interop '99 in Las Vegas.

If there is no other mechanism, the sending equipment would eventually find out the receiving device had failed, but that could take hours. At a preset interval, IPSec gear switches the key it uses to encrypt data. When no key exchange information is forthcoming from the box at the other end, the sending box would know the gear was no longer up and running (see diagram).

The failed tunnel server might have come back up in the meantime, in which case a new tunnel would be set up. But data that was sent after the first tunnel failed would be lost and have to be resent.

Such potentially long outages are of particular concern to VPN service providers, according to TimeStep's Roy Pereira, a senior product manager. Without quick notification of a failure, service providers will have trouble maintaining network quality they have promised to customers in service-level agreements.

"They really need to know if something is up or down. They are religious about reliability," Pereira says.