Fragments

As good as it GETs?

February 17th, 2009 | by Jan Bervar |

By now, you probably have heard about the latest Cisco site-to-site VPN technology, Group Encrypted Transport VPN (GET VPN). GET VPN promises to solve most of the scalability and manageability issues of partially or fully meshed IPsec VPNs. However, before you jump into the fire, it’s important to understand that GET VPN has some not-so-obvious security-related drawbacks that may adversely affect your network:

• By default, GET VPN doesn’t hide endpoint identities and will allow traffic-snooping adversaries to perform traffic analysis. In other words, GET VPN will not hide who is communicating with whom-information that may be valuable to an attacker who could learn where the servers are, who exchanges the bulk of data, etc.
• GET VPN uses group session keys, as all routers share the same set of traffic-protecting cryptographic keys. Thus an attacker who compromises a single GET VPN member device can break crypto protection of other GET VPN traffic. This issue makes GET VPN less resilient to VPN member compromise as compared to classic peer-to-peer tunneling VPNs.
• GET VPN has somewhat weaker anti-replay packet protection, as it cannot synchronize anti-replay counters across group members. Unlike “classic” IPsec encapsulation, which has a very small anti-replay window using sequence numbers, GET VPN uses pseudo-timestamps and a longer time window (on average) to reject replayed packets.
• GET VPN puts a lot of stress on key servers. If you’re using RSA for peer authentication, you must plan for the worst-case scenario, in which every member wants to do a phase 1 IKE exchange with the key server at the same time. In this situation, the key servers’ tunnel setup rate becomes very important, as is the case with all hub-and-spoke IKE topologies.
• There is a tradeoff between geographical redundancy and the danger of network partitioning: the more resilient the network becomes (by distributing key servers to many geographical locations), the greater the danger of network splits and parts of the GET VPN using different keys, isolating themselves from other partitions.
• By default, the overall resilience of GET VPN is lower, as it depends on the availability of a small number of key servers. By contrast, the classic fully meshed distributed IPsec VPN can always function as long as members (peers) have mutual connectivity.

This is not to say that GET VPN should be avoided. On the contrary, it will be a preferred solution for many companies that seek a simple implementation of a fully meshed, cryptographically protected WAN over a private WAN or MPLS cloud, or even over the Internet when combined with GRE tunnels (and probably NHRP). Additionally, GET VPN does an excellent job providing scalable transmission security to multicast traffic. Just get all the facts straight and make acceptable compromises. Happy network engineering!

P.S. Give credit where credit is due. These are my afterthoughts from Frederic Detienne’s excellent GET VPN presentation at Networkers 2009. Good job, Fred!