Group VPN - the new pizza in old box :

Group VPN - the new pizza in old box :
Dear reader,
Are you a network admin or an architect who is bogged down by the network configuration overhead, created because of the need for creating and monitoring  hundreds of Ipsec tunnels between all those secured sites, not to mention the manual effort required to create the  physical infrastructure for full mesh style network, or the careful consideration on scale and performance of the hub?

How would you react if you are told that new and improved Group VPN  is designed in such a way as to offer the advantages of both the full mesh site-to-site vpn and the hub-and-spoke vpn without the limitation of either. Exciting isn’t it? GVPN provides tunnel-less encryption for any to any connectivity eliminating both the need of a hub- hence the bottle neck- ,and the need for thousands of interconnecting tunnels.

If you are new to Group VPN, then I understand your reservations: Ipsec VPN has been around for years; it is one of the most widely used L3 VPN technology to secure traffic between sites ; it is a stable solution with many advanced features such as NATT, IKEV2, and tunnel mode/ transport mode encryptions ; and has different style of configuration - policy based VPN or route based VPN. Regardless of all these advanced features and configuration designs, the above described problems of scale still remain.  There has been solutions that attempt to address the problem but most of such solutions are stop gap in nature.

If you have had a tryst with the the GVPN technology in some distant past- the Cisco GET VPN or the Juniper GVPN1.0 for instance- you may have some reservations about this technology, mostly because it was not an industry standard and was a proprietary solution that left you dependent on the vendor for enhancements or bug fixes. But the good news is the technology has since then matured; it has been re-engineered. There has been drafts and RFCs standardizing the Group VPN solution, and major network device makers such as Juniper Networks and Cisco have been working tirelessly to bring this technology to you . So the problem that you faced with the proprietary implementation of the GVPN technology is largely gone.

Now that I have picked your interest, you may be wanting to know more about the GVPN, the tunnel less encryption, and how how does it do what it says it does. In order to understand the concept behind tunnel-less encryption, we have to understand the mechanism of GVPN.

Here is a short introduction to the GVPN technology :

In GVPN deployment there are 2 entities, a GC/KS-read Group Controller/ Key Server- and a GM-read Group Member.GC/KS distributes the traffic SAs and policies that contain the traffic match criteria, encryption, and authentication algorithms and corresponding keys. GMs register to the GC/KS under any group and install these SAs and Keys, we call those SATs, and TEKs respectively. After GDOI SA is established, the inter GM traffic is encrypted using these downloaded SATs. This is where the key concept of tunnel-less encryption of GVPN lies: unlike the Ipsec VPN, GVPN does not negotiate a secured channel with another GM. Both the GMs use the same SA, downloaded from GC/KS, to encrypt and decrypt the traffic as long as the inter GM traffic stream matches the policy downloaded as part of SATs. 

I understand that the brief description above may have left you with more questions. If so, please write your questions in the comments section. However, if you ware willing to wait, then please note that I am going to discuss GVPN in greater details in my next blog.