Cisco looks to ease VPN deployments

Simpler site-to-site VPNs, higher WAN performance and other features are on tap.

Cisco this week is expected to introduce VPN technology that could help businesses with fast-growing branch-office deployments more quickly set up and maintain secure WAN links.

The company plans to introduce, as part of a larger announcement, what it calls Group Encrypted Transport (GET) with a new version of its IOS router 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, experts say. (See our story on other new IOS features.)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 authorized to exchange encrypted traffic flows. A centralized 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 IETF RFC 3547.

Cisco's GET VPN topology

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. That 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 essentially are 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 setups, 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 endpoint where the other endpoints 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, the company 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.

VPN dynamics

Cisco and other vendors, such as Juniper and Check Point, have technologies that can make setting up IPSec VPN tunnels more dynamic and that 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 setup 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 buildout 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 adds.

What is there to GET?

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 only has 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 adds. "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. "For Cisco to be able to claim [GET] is better way to do VPNs, we'll need to see some proof points," Kerravala says.

Learn more about this topic

CiscoCisco blast: Rolls out simpler site-to-site VPNs, adds connectivity to routers, strengthens IOS


AT&T to use Cisco's new VPN offering

Q&A: Cisco's Volpi on 7600 router extensions

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2006 IDG Communications, Inc.

IT Salary Survey 2021: The results are in