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.

About me..

Dear readers,
My name is Dipti Ranjan Sahoo. I am a Network Test Engineer and  have worked for some of the best Internet device manufacturers in the industry. I have several years of QA experience and have worked on Routing, Switching and Security extensively.

As you know change in technology is like the flow of river, some times rapid, sometimes slow, but always incessant. As an engineer, I am very much a part of this change and observe it very closely - especially when the change relates to the networking technology.

The blogs that I plan on writing in this forum are my attempt to brief the interested audience about new networking technologies : new protocol stands or drafts,new features those are developed or being developed to solve tricky networking problems faced by network planners, designers, and administrators.

I thank you for being a part of the forum. You are more than welcome to leave comments and suggestions and I will do my best to answer them.

Thanks and regards

Dipti Ranjan Sahoo

Advantage of GVPN over traditional S2S IPSEC.

Please note that I have used the following acronyms in this blog:

GVPN  - Group VPN

VPN     - Virtual Private Network

S2S      - Site-to-Site

GC/KS - Group Controller / Key Server

GDOI   - Group Domain of Interpretation.

I have been working on Juniper's Group VPN solution for quite a some time; before that, I have worked on different VPN technologies such as Site-to-site IPSEC VPN , ADVPN, L2TP, GRE etc. In this blog I am going to focus on the advantages of GVPN technology over the rival Site-to-site IPSEC VPN. 

One major drawback of Site to site IPSEC VPN is that when more than 2 sites are interconnected using IPSEC, IPSEC configuration and maintenance of such configuration becomes a problem- especially in deployments of scale.

In case of S2S IPSEC VPNs, the inter site traffic is secured either by using a hub spoke design or a full mesh design. In case of hub-spoke design hub becomes a bottle neck for traffic and a single point of failure - unless hubs support HA(high availability), which is an advanced functionality and very may involve proprietary. In full-mesh topology the sheer size of configuration is an overhead. However, in both of these designs, the maintenance of the configuration for a larger scale - say 1000 or 2000 tunnels- becomes a huge challenge for administrators.

I feel that all of the above issues can be avoided if GVPN instead of the standard IPSEC VPN is configured. Some of the highlights on how this can be done is as follows:

Avoid Single point of failure: In GVPN deployment there are 2 entities, a GC/KS and a GM - refer to RFC 6407 for more details. GC/KS distributes the traffic SAs and policies that contain the traffic match criteria, encryption and authentication algorithms and keys. GMs are the entities that register to the GC/KS under any group and install these SAs after the GDOI exchanges are done. After GDOI SA is established, the inter GM traffic is transmitted using these GDOI SAs. At this point if GM's connectivity with GC/KS is broken, the inter GM traffic is not impacted as long as the SA life time has not expired. Mean while the GMs may regain connectivity with the GC/KS or try to reach other GC/KS. Yes, Juniper’s MX and SRX devices support this functionality.

Avoid traffic bottle necks: Since the inter GM traffic can follow any path and does not necessarily have to go through a GC/KS, GC/KS is not a point of failure for the traffic, as a Hub is in case of a Hub-spoke design of S2S IPSEC.

Easy configuration and maintenance of deployments for scale: In case of GVPN, the configuration required for thousands of tunnels for any to any VPN connectivity is relatively easy, for only GC/KS  contains the configuration of the SAs and traffic selectors. GMs need only to have sufficient configuration that enables them to register to the respective group in GC/KS. Unlike the IPSEC , the phase 2 GDOI is not a 2 way negotiation; in phase 2, GC/KS pushes all the SAs to the GMs. Hence, the GMs do not need any IPSEC proposal configuration.

I will keep adding more information to this blog. All questions, comments, suggestions and feedbacks are welcome.