The IOS GETVPN is a tunnel-less (i.e. no overlay) VPN technology that provides end-to-end security for network traffic in a native mode and maintaining the fully meshed topology. It uses the core network’s ability to route and replicate the packets between various sites within the enterprise. Cisco IOS GETVPN preserves the original source and destination IP addresses information in the header of the encrypted packet for optimal routing. Hence, it is largely suited for an enterprise running over a private Multiprotocol Label Switching (MPLS)/ IP-based core network. It is also better suited to encrypt multicast traffic. Cisco IOS GET VPN uses Group Domain of Interpretation (GDOI) as the keying protocol and IPSec for encryption.
A GETVPN deployment has primarily three components, Key Server (KS), Group Member (GM), and Group Domain of Interpretation (GDOI) protocol. GMs do encrypt/ decrypt the traffic and KS distribute the encryption key to all the group members. The KS decides on one single data encryption key for a given life time. Since all GMs use the same key, any GM can decrypt the traffic encrypted by any other GM . GDOI protocol is used between the GM and KS for group key and group SA management. Minimum one KS is required for a GETVPN deployment. Unlike traditional IPSec encryption solutions, GET VPN uses the concept of group SA. All members in the GETVPN group can communicate with each other using a common encryption policy and a shared SA and therefore no need to negotiate IPSec between GMs on a peer to peer basis; thereby reducing the resource load on the GM routers.
The group member registers with the key server to get the IPSec SA that is necessary to encrypt data traffic within the group. The group member provides the group ID to the key server to get the respective policy and keys for this group. These keys are refreshed periodically by KS, and before the current IPSec SAs expire, so that there is no loss of traffic.
Key server is responsible for maintaining security policies, authenticating the GMs and providing the session key for encrypting traffic. KS authenticates the individual GMs at the time of registration. Only after successful registration the GMs can participate in group SA. A group member can register at any time and receive the most current policy and keys. When a GM registers with the key server, the key server verifies the group id number of the GM. If this id number is a valid and the GM has provided valid Internet Key Exchange (IKE) credentials, the key server sends the SA policy and the Keys to the group member.
There are two types of keys that the GM will receive from the KS:
● Key Encryption Key (KEK), for securing control plane
● Traffic Encryption Key (TEK), for securing data plane
The TEK becomes part of the IPSec SA with which the group members within the same group encrypt the data. KEK is used to secure rekey messages (i.e. control plane) between the key server and the group members.
The Key Server sends out rekey messages either because of an impending IPSec SA expiration or because the security policy has changed on the key server. Keys can be distributed during rekey using either multicast or unicast transport. Multicast method is more scalable as keys need not be transmitted to each group member individually. Unlike in unicast , KS will not receive acknowledgement from GM about the success of the rekey reception in multicast rekey method. In unicast rekey method, KS will delete a GM from its database if three consecutive rekeys are not acknowledged by that particular GM.
Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 4930-4934). . Kindle Edition.