GVPN introduction continued…

Let us look at the GVPN little more in-depth. 

GVPN is based on the GDOI protocol. The protocol is specified in RFC 6407 and defines an ISAKMP Domain of Interpretation (DOI) to manage Security Associations and keys for participants known as group members - GMs. By virtue of such a participation, all GMs share identical information to encrypt and decrypt traffic among each other. The creation, management and distribution of GDOI SAs and the associated group-keys- TEKs and KEKs -are handled by a key server - GC/KS.

The protocol exchange has two type of exchanges. In the first type of exchange the GMs register to the GC/KS and download the SAs to encrypt both inter GM traffic and further communications with GC/KS. These SAs are known as SATs and SAKs respectively- we will talk about these SAs a bit later. The exchange is called GROUPKEY-PULL exchange and is initiated by the GM. In the second type of exchange GC/KS is the initiator and the exchange is called GROUPKEY-PUSH. In this exchange the GC/KS informs GMs to install the new SATs/SAKs and expire the old SATs/SAKs. As you may have noticed this exchange poses striking resemblance to the Site-to-site IPSEC VPN, with one crucial difference - the centralized GC/KS. More interestingly, the GROUPKEY-PULL has two phases like that of normal Site-to-site IPSEC, and it uses ISAKMP to achieve this, yet again with one crucial difference - the phase 2 of ISAKMP uses UDP port 848 as opposed to port 500 in site-to-site IPSEC.

There are two different types of Group Security Associations. The first is called “Security Association Transport Encryption Key” (SAT) that protects the traffic between the GMs. This one is comparable with a normal IPSec SA. The associated cryptographic key is named “Transport Encryption Key” (TEK). The second G-VPN Security Association is called “Security Association Key Encryption Key” (SAK) and protects rekey-messages send from the KS to the GMs. The associated cryptographic key is named “Key Encryption Key” (KEK). Beside the algorithms used for encryption, the KS also provides the policy which specifies what traffic needs to be secured by the GMs. These traffic-selectors are part of the SAT. 

The Group Members use ESP protocol in tunnel-mode to secure the traffic. However, in G- VPN the tunnel-mode is modified. Because there is no direct association between the GMs, it is not necessary to use special IP-Addresses in the outer IP-Header (i.e. IP-Addresses of IPSec-Gateways). Every GM can decrypt the traffic of every other GM, as long both are members of the same GDOI group. Thus the inner IP-Header is copied to the outer IP- Header and the underlying routing- and QoS-infrastructure can be used anymore. This feature is called Header Preservation.

Now that we have understood several elements of the GVPN solution, let us look in to the GROUPKEY-PULL and GROUPKEY-PUSH protocol exchanges.

To get the GDOI SAs and keys and group-keys, the GM registers with the KS for a specific group. Before the registration process can start the GM and KS have to setup a secure connection using IKEv1 protocol in either Main Mode or aggressive mode. As a result of the exchange the IKESA needed to secure the registration process is established. This part of the exchange is called the phase 1 exchange. After the phase 1 exchange is complete, phase 2 exchange start. The IKESA established during phase 1 exchange is used to secure the messages in phase 2 exchange. In phase 2 exchange a GM tells the KS to which GDOI group he wants to register and after successful authentication the GM gets all GDOI SAs and keys (SATs, TEKs, SAKs, and KEKs). After the registration the GM has all information to communicate with the other GMs by using SAT, as well as the information to successfully decrypt the rekeying-messages by using SAK. Upon the soft lifetime expiry of the SAT and SAK, the KS initiates GROUPKEY-PUSH exchange encrypted using the KEK. This message is fairly straight forward and the exchange is concluded as soon as the GM acknowledges the receipt of the message. Thus the GVPN leverages the framework of ISAKMP and avoids the disadvantages of Site-to-site IPSEC by using centralized key server model. 

I will be writing about some practical deployment scenarios showcasing the use of GVPN in my next post. Stay tuned ...

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.