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.