Cisco looks to ease VPN deployment pain

New technology will make it simpler for remote sites to link securely with head office, says the networking giant

Cisco has introduced VPN technology that could help businesses with fast growing branch-office deployments set up and maintain secure WAN links quicker.

The networking equipment vendor has developed what it calls Group Encryption Transport (GET) with a new version of its IOS switch/routing software. GET will let customers work together in a site-to-site VPN more easily than with Cisco’s current site-to-site VPN technology, which is based on IPSec tunneling, say experts. AT&T also is expected to launch a GET-based enhancement to its MPLS-based IP VPN services, so that traffic on an IP VPN link could be encrypted as a further security measure, Cisco and AT&T say.

In a GET VPN, Cisco branch-office routers are configured as part of a group in which members are authorised to exchange encrypted traffic flows. A centralised key server — a specially configured router — distributes the encryption keys to each GET member via a protocol called Group Domain of Interpretation (GDOI), defined by the international engineering taskforce’s RFC 3547 standard.

GDOI coordinates group membership and creates a common encryption infrastructure using a method called multicast rekeying. This technique uses IP multicast to distribute IPSec security associations, keys and policies to group members. The process allows secure traffic connections over the internet. IPSec security associations in a GET VPN are timed to expire after a designated period. Periodically, the key server pushes new keys to the group-member routers via multicast — or multicast rekeying — before the security associations expire on the routers. Members of a GET group are essentially IP-multicast group members, but they exchange IPSec encryption key data, letting them communicate securely over an untrusted network.

In traditional site-to-site VPN tunnel set-ups, IPSec VPN tunnels are established and maintained among sites, creating a secure hub-and-spoke network laid on top of the public-routed internet. This makes large VPNs hard to set up and limits the traffic paths, because all devices and paths must be predefined, technology watchers say.

“In a large, fully meshed VPN, you have to tell each end-point where the other end-points are and build a lot of routes,” says Zeus Kerravala, an analyst with Yankee Group. “Then there is a whole routing table that gets built underneath. It’s not the simplest thing to manage. It’s not as easy as it should be.”

Cisco says a GET VPN lets customers use the basic, routed internet infrastructure without the VPN tunnel overlay. “We describe [GET VPN] as routing the way you know and love — just encrypted — but with all the efficiencies built into the routed network,” says Inbar Lasser-Raab, a product marketing director at Cisco. “If customers are using a hub-and-spoke, they will see an improvement in latency because they’re just using a routed network.”

Cisco is not saying how much the improvement is. Although it has collected data on latency and performance differences between its own IPSec tunnel and GET VPN technologies, it is not releasing the data. The IOS release that contains GET is Version 12.4(11)T, and will operate on Cisco’s 1800, 2800 and 3800 series, branch-office Integrated Services Routers, as well as on the Cisco 7200 and 7300 series WAN-aggregation routers.

Cisco and other vendors, such as Juniper and Check Point, have technologies that can make setting up IPSec VPN tunnels more dynamic and that also emulate fully meshed networks where nodes have direct links to each other. Cisco, for example, has Dynamic Multipoint VPN (DMVPN), an IOS feature that lets routers in hub-and-spoke IPSec VPNs set up tunnels between spokes dynamically.

“[DMVPN] helps bypass the hub-and-spoke [topology] and creates more of a mesh,” says Robert Whiteley, a senior analyst at Forrester Research. “It gives you a more automated set-up of tunnels, but it doesn’t bypass the overall problem. You still have to physically say, ‘here is the network topology’.”

Whiteley says a GET VPN would let users set up a very large VPN using just the basic routing infrastructure of the internet, and simply encrypt certain parts of the communications stream, “so you get the security aspects of a VPN without having to create this hardened tunnel”.

“If a company is consistently adding sites, plans to add sites or hasn’t gone through a VPN build-out yet, GET VPN is a no-brainer,” Whiteley says. The fact that it’s an IOS function that runs on routers could also simplify a deployment by eliminating the need for separate VPN gear on the network, he says.

Other industry observers are not as excited about GET. In particular, its method of using GDOI to distribute IPSec keys via multicast is “a fairly obscure aspect of VPNs that has only a very limited applicability”, says Joel Snyder, senior partner at Opus One network consulting firm and a member of the Network World Lab Alliance.

“For group communications using multicast, GDOI is a nice feature,” Snyder says. “But, honestly, that’s an unusual thing. Most folks are not trying to do site-to-site multicast traffic over an encrypted tunnel.”

Because running a GET VPN requires a certain Cisco IOS version — which implies an all-Cisco network — GET VPN shuts out any sites without Cisco, or even Cisco sites not enabled for GDOI. “If you don’t support [GDOI], you won’t be able to talk — so this is an interoperability issue,” Snyder says. He adds that site-to-site VPNs are not that hard to set up and manage with the right tools and products.

“If [Cisco] had a reasonable VPN management tool, and if they had good VPN concentrators, then they wouldn’t be as [troubled] about the whole efficiency issue” of meshed, site-to-site VPN management, Snyder says. “Solving the full-mesh VPN problem by dragging a new and incompatible technology into the picture and calling this better seems to me to be a really poor argument,” he says. “They could solve the full-mesh VPN problem by simply doing VPN right.”

Smaller sites with a few tunnels connecting locations probably won’t be interested in throwing out an established IPSec VPN for GET VPN, analysts say. Persuading larger sites with established VPN links and considerable investment in Cisco VPN gear, might also be a tough sell. “We’ll need to see some proof points,” Kerravala says.

Join the newsletter!

Error: Please check your email address.

Tags ciscovpnRemote

More about Check Point Software TechnologiesCiscoForrester ResearchJuniper NetworksOpus OneYankee Group

Show Comments
[]