Group Encrypted Transport VPN (GETVPN)

GETVPN (Group Encrypted Transport VPN) is a tunnel-less VPN technology meant for private networks like MPLS VPN where we use a single SA (Security Association) for all routers in a group.

Traditional IPSec has some scalability issues because it’s point-to-point. Take a look at the following picture:

Each line represents an IPSec point-to-point tunnel. For each IPSec tunnel, the router has an IPSec SA. For example, R1 has four tunnels so that’s four IPsec SAs. With only a couple of routers this is no problem, but if you have a large topology and you need a full mesh of IPSec tunnels, things can get hairy. There is a limit to the number of IPSec SAs each router can have.

When you run IPSec on top of a hub and spoke topology like DMVPN then the hub has an IPSec SA with each and every spoke router. This limits the number of spoke routers you can have.  DMVPN supports direct spoke-to-spoke traffic but when a spoke wants to send traffic to another spoke, it first has to create a new IPSec SA which takes time, causing delay.

Another issue with traditional IPSec is that you can’t encapsulate multicast traffic unless you encapsulate it first with GRE.

GETVPN solves the scalability issue by using a single IPSec SA for all routers in a group. It also supports multicast traffic without GRE. In this lesson, I’ll explain how GETVPN works and I’ll show you how to configure it.

GETVPN Components

GETVPN has four main components:

• GM (Group Member)
• KS (Key Server)
• GDOI (Group Domain of Interpretation)
• IPSec

Let’s take a closer look at each component:

Group Member

The GM (Group Member) is a VPN router that is a member of the group and encrypts traffic with other GMs. All GMs have the same IPSec SA so any GM can encrypt traffic with any other GM right away.

Key Server

The KS (Key Server) is the “caretaker” of our group. They KS takes care of group registration and authentication of GMs. Each GM that wants to join the group registers with the KS and when authentication is successful, the KS sends the encryption keys and the policy that we use for the group.

When a GM tries to register with the KS, the KS checks a group ID and IKE credentials. When this checks out, the KS sends the following items to the GM:

• The security policy that we use for the group.
• Two keys:
  • KEK (Key Encryption Key): this is used to encrypt rekey messages. GMs use this key to decrypt rekey messages from the KS.
  • TEK (Traffic Encryption Key): this becomes the IPSec SA that all GMs use to encrypt traffic between each other.

The KS sends rekey messages when the current IPSec SA is about to expire or when the security policy is changed. Rekeying can be done through unicast or multicast. With unicast, each GM sends an acknowledgment to the KS when it receives the new key. When the KS doesn’t receive an acknowledgment after 3 transmissions, it deletes the GM. Multicast is a more scalable method for rekeying but it doesn’t support acknowledgments.

GDOI

GDOI is the protocol we use between the KS and GMs. It is protected with ISAKMP phase 1, the same ISAKMP we use for regular IPSec. You can use all ISAKMP authentication options like a pre-shared key or certificates. In phase 2, the KS sends the two keys (KEK and TEK) and the security policy. The KS keeps track of the SA lifetime and rekeys a new SA when it is about to expire. The rekey messages are signed with a private key of the KS since anyone could pretend to be the KS.

IPSec

GETVPN uses ESP (Encapsulating Security Payload), the same as traditional IPSec VPNs. It only supports tunnel mode which encapsulates the entire IP packet which adds a new IP header. There is a twist however, GETVPN uses tunnel mode with address preservation. This means it copies the inner IP header to the outer IP header, without any changes. Here’s an example:

With traditional IPSec ESP tunnel mode, the outer header always has the IP addresses of the VPN routers. Here’s an example:

The internal IP header shows traffic from different hosts on the network but the outside IP header always shows the IP addresses of the VPN routers. Using tunnels like this is known as overlay routing and one of the disadvantages is that these packets probably always get routed the same way throughout our network since the IP addresses never change.

Using tunnel mode with address preservation, the outer IP header has the IP addresses of the inner IP header:

The advantage of copying the inner IP header to the outer IP header is that the network can route packets based on the actual destination and find the best path to each destination. One disadvantage, however, is that you can’t use address preservation on the Internet since private IP addresses are unroutable. It’s incompatible with NAT since NAT makes changes to the outer IP header.

GETVPN is meant for private networks, like MPLS VPN where you have full reachability between all sites.

Configuration

You now know the basics of GETVPN so let’s see if we can configure this. Here is the topology I’ll use:

We have one key server and four group members. The cloud in the middle represents a private WAN. OSPF is configured on the GM routers to advertise the loopback interfaces.

Key Server

Let’s start with the KS, that’s where we need to configure most things. There are a couple of items we need:

• IKE phase 1 policy: this is how the GMs authenticate with the KS.
• RSA key: used for rekeying to secure the re-key messages.
• IPSec policy: the policy that defines how we encrypt traffic.
• Access-list: the traffic that we want to encrypt.

Let’s start with an IKE phase 1 policy. This is exactly the same as traditional IPSec:

R1(config)#crypto isakmp policy 10
R1(config-isakmp)#encryption aes
R1(config-isakmp)#hash sha
R1(config-isakmp)#authentication pre-share 
R1(config-isakmp)#group 5

We will keep it simple and use a pre-shared key. You can configure a different pre-shared key for each GM but I will use the same pre-shared key for all GMs:

R1(config)#crypto isakmp key MY_KEY address 0.0.0.0

GETVPN uses IPSec ESP so we need a transform-set for this:

R1(config)#crypto ipsec transform-set TRANSFORM_SET esp-aes esp-sha-hmac

In the transform-set, you don’t have to configure mode tunnel since that’s the default option.

We don’t use a crypto map but an IPSec profile and we add the transform-set to it:

R1(config)#crypto ipsec profile IPSEC_PROFILE
R1(ipsec-profile)#set transform-set TRANSFORM_SET

The last part we need to configure is the GDOI group but before we can do this, I need an RSA key pair. The KS uses the private key of the RSA key pair to sign the rekey messages. Let’s create a new RSA key pair and add a label called “RSA_KEYS” to it:

R1(config)#crypto key generate rsa modulus 1024 label RSA_KEYS

I also need an access-list that tells the GMs what traffic to encrypt. Let’s create an access-list that matches ICMP traffic:

R1(config)#ip access-list extended ICMP
R1(config-ext-nacl)#permit icmp any any

Now we can configure the GDOI group:

R1(config)#crypto gdoi group GDOI_GROUP
R1(config-gkm-group)#identity number 123

The KS and all GMs need to use the same group identity number. I use identity 123. The next command tells the router that this is the KS:

R1(config-gkm-group)#server local

We also have to add our own KS IP address:

R1(gkm-local-server)#address ipv4 192.168.1.254

Next is the rekey configuration. We tell the router to use the RSA key-pair to protect the rekey messages and to send them with unicast:

R1(gkm-local-server)#rekey authentication mypubkey rsa RSA_KEYS
R1(gkm-local-server)#rekey transport unicast

The last thing to do is to configure the IPSec policy. This is where we add the IPSec profile and our access-list: