Cisco Group Encrypted Transport Virtual Private Network (GET VPN)

Cisco GET VPN - a new technology from Cisco, designed to ensure the safety of tunnels through provider connections, with a number of useful features. This article is devoted to its description, features and settings.

We begin by tradition with the formulation of the problem. The classical topology consists of several branches connected via a provider network.

It is required to connect networks behind branches. The most common solution is IPSec and in particular DMVPN. Which, among other things, is a tunnel technology and allows the use of public Internet channels. The disadvantage of this solution is that the network is built on the hub-n-spoke principle, and the spoke-to-spoke tunnels are installed as needed, which is not very convenient.

Another common option is MPLS VPN, which, although it allows you to build a highly scalable network, does not provide the confidentiality required in some cases. Cisco GET VPN is designed more specifically for MPLS VPN networks, allowing you to provide encryption of the transmitted data without sacrificing the scalability and reachability of spoke-to-spoke.

In addition, the GET VPN itself does not perform tunneling, i.e. replacing the header, which virtually negates its applicability for data transmission over the Internet, since the vast majority of hosts on internal networks use private IP addresses. In the case of MPLS VPN, such problems do not arise due to the use of the extension by the VPNv4 provider.
')
General concepts.
In the future, I assume that the reader is familiar with the technology and terminology of IPSec.

A new feature of GET VPN is the introduction of the concept of a " trusted group ", all members of which share the same IPSec SA (security association). This allows any member of a group ( GM , group member) to decrypt traffic encrypted by any other GM. In addition, since every GM can decipher our message, we can send multicasts.

The same encryption keys are defined for all GMs. This is implemented using the GDOI protocol (Group Domain of Interpretation). Two different keys are used: one to encrypt data, the other to encrypt control messages. The packet to be transmitted is encapsulated with ESP using the received shared key.

The figure shows that the original header is not replaced by anything, hence the restriction on the use of the Internet.

Key servers ( KS , key servers) are responsible for synchronizing and updating keys. All encryption policies, protocols used, “interesting” traffic, timers, etc. tuned to KS and distributed across all GM . GM is first authenticated to IKE Phase 1, and then receive the necessary data from KS during registration. In other words, only parameters IKE Phase 1 and KS are configured on GM. The rest he gets automatically.

In addition, since KS actually becomes a point of failure for the entire network, it is possible to create several KS, called COOP KS (cooperative KS), with the ability to pick up functions in cold standby mode.

Moving from terminology to actually setting up GET VPN on Cisco IOS.

Customization .

So, let us have the aforementioned topology, in which the branches are connected using MPLS VPN, i.e. we assume that the connection between them is established and we are not afraid to send there packets with private source and / or destination addresses.

The configuration of GET VPN can be divided into several stages:

1. PKI configuration (optional)
2. IKE Phase 1 Configuration
3. GDOI Group Configuration
4. Configuration of IPSec profile on KS and crypto map on GM
5. COOP KS configuration (optional)

Stage 1. Common for KS and GM.
We configure routers to receive certificates from CA. This is a topic for a separate small article, so in the future I will assume that we have received certificates. The only note is the need to make the keys on KS as exportable, since they must be the same for all COOP KS.

Stage 2 . In a familiar way, we configure crypto isakmp policy. I will describe the policy using PKI, for pre-shared everything is the same.

crypto isakmp policy 10
encr aes
lifetime 1200
group 2

A few comments.
1) Cisco recommends using AES as the best in terms of cryptographic strength / processor resources. Let me remind you that by default, for isakmp policy rsa-sig authentication, so the line with it does not appear in the config.
2) The recommended value for rekey is 1200 s. Cisco recommends doing it in the range of 15-30 minutes, with a default of 20.

Stage 3 . The most serious part.
3.1. KS Setup
Create a gdoi group.
crypto gdoi group getvpn

Next, set the group ID. Must be the same for all KS and GM
identity number 1234

We identify our router as KS
server local

We configure the change of IPSec keys (namely them, not ISAKMP) once a day
rekey lifetime seconds 86400

We set the retransmission scheme when changing keys (there are two types: two times with an interval of 60s or three times with an interval of 40s)
rekey retransmit 40 number 3

Configure authentication.
rekey authentication mypubkey rsa getvpn-export-general
Here getvpn-export-general is our keys received from CA.

Next, ask how to update the keys, unicast or multicast.
rekey transport unicast

Next, set up the group IPSec SA:
sa ipsec 1

Bind IPSec profile
profile GETVPN_PROFILE

Determine what to encrypt
match address ipv4 199

Here I will allow myself to stop in more detail. The fact is that for traditional p2p IPSec tunnels, it is common to describe interesting traffic in the most specific way. for example, for a tunnel between R1 and R2 we would write on R1:
access-list 199 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255

Since there are a lot of tunnel ends in GET VPN, there will be a lot of such records. Therefore, Cisco recommends that you maximize Summarize ACE. For example, in our case, it is best to write ACL 199 like this:
access-list 199 permit ip 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255
This will lead to a significant reduction in the number of SAs.

Next, set up a TBAR (time-based anti-replay protection)
replay time window-size 5
And set the address from which we will manage the change of keys.
address ipv4 192.168.1.1

3.2. GM setup.
Everything is much simpler here, in fact, we need to specify which group we belong to (using the identity number) and KS of this group.
crypto gdoi group getvpn
identity number 1234
server address ipv4 192.168.1.1


Stage 4.
4.1. KS setup.
On KS, you need to create settings that will be lowered by GM.
crypto ipsec transform-set GETVPN_SET esp-aes esp-sha-hmac
crypto ipsec profile GETVPN_PROFILE
set security-association lifetime seconds 7200
set transform-set GETVPN_SET

4.2 GM Settings
You need to bind a GET VPN group to a crypto map.
crypto map getvpn-map 10 gdoi
set group getvpn


Stage 5 . Let's leave it for another article, if the topic is interesting :) Once interested, let's consider. As already mentioned, we can configure several KS, one of which will be the main one, and the others will pick up its functions when it falls.
So, to set up COOP KS you need the following:

1. You need to configure the RSA keys on the primary KS and export both keys (private and public) to all COOP KSs.
2. You must configure redundancy itself.

With the keys , I think everyone is familiar.
We generate exportable keys:
Primary_KS(config)#crypto key generate rsa general-keys label getvpn-keys modulus 1024 exportable

Export them:
Primary_KS(config)#crypto key export rsa getvpn-keys pem terminal 3des Ci$co

And import on all COOP KS:
COOP_KS(config)# crypto key import rsa getvpn-keys pem exportable terminal Ci$co

Next setting KS .

Be sure to turn on the ISAKMP keepalive so that they can detect the death of each other.
rypto isakmp keepalive 15 periodic

We go to our group
crypto gdoi group getvpn
server local

We include redundancy:
redundancy

We assign a priority (the server with the highest priority will be primary, if the priorities are equal, the primary will be KS with the highest IP address)
local priority 100

And we point out to him all the other KS
peer address ipv4 192.168.2.1
peer address ipv4 192.168.3.1

And configure the timers:
protocol timeout refresh 20
protocol timeout periodic 30
protocol retransmit 2

Timeout refresh - the interval at which the primary KS sends messages to the rest. Default is 20s
Timeout periodic - if during this time the secondary KS does not receive a refresh message, it informs all other KS about problems with the primary.
Retransmit - the number of messages from the secondary KS to all other KS when not receiving the message from the primary. By default, 2 messages are sent, after which KS redefines their roles.

According to tradition, a few comments.

1. COOP KS send their messages to UDP port 848, while the messages contain information about all GMs and policies. The message grows with the increase in the number of GM and will require fragmentation. In order for KS to properly handle such messages, you may have to increase the system buffer:
   buffers huge size 65535
2. COOP KS must have the same GET VPN configuration. This does not happen automatically.
3. COOP KS can be registered on each other also as GM.

In conclusion, it remains only to hang our crypto map on the interface and take into account the additional costs of the header:
ip tcp adjust-mss 1360

Thus, summing up :

1. We have a new technology that allows you to encrypt connections between offices.
2. The main area of ​​application is MPLS VPN privacy enhancement.
3. Advantages - native support for spoke-to-spoke connections, high scalability and multicast support.
4. Disadvantages - a direct consequence of the lack of tunnels - to the extent impossible to work through the public Internet.
5. A special feature is the presence of shared IPSec keys that allow all members of the group to decrypt messages sent by other members of this group.

Again, I do not pretend to be complete. Behind the scenes were the COOP KS setting, supported models of routers and a lot more. If the topic is of interest, let us consider it more deeply, but for now, allow me to bow out of it :)

More detail, you can read here: GET VPN Design and Implementation Guide

UPD 1. Thanks for the valuable quickshooter and Fedia comments.

Podkopaev Ilya, instructor