As you learned in the previous blog that introduced the GET VPN solution, a major facet of this exciting technology is the Group Domain of Interpretation (GDOI) as outlined in RFC 3547. This technology is such a pivotal component of GET VPN because it serves as the mechanisms to provide the cryptographic keys to a group of VPN gateways.

GDOI relies on none other than Internet Key Exchange (IKE) Phase 1 to protect the distribution of the keys. Just as with "traditional" IPSec VPNs, you can utilize such methods as Pre-shared Keys (PSK) or the Public Key Infrastructure (PKI) for authentication with IKE Phase 1.

GDOI actually implements two different encryption keys. The Key Encryption Key (KEK) is used to secure the control plane, while the key used for data encryption is the Traffic Encryption Key (TEK).

Another critical element for the GET VPN is the Key Server (KS). This is the IOS device responsible for creating the GET VPN control plane. The KS is where you actually define the encryption policy (interesting traffic, encryption protocol, etc.) that is pushed to all group members.

Group members in GET VPN are the IOS routers responsible for the actual encryption and decryption of data traffic.

Another excellent aspect of GET VPN is the rekey process built into GDOI. GDOI periodically refreshes cryptographic keying information and distributes it to group members. GDIO has the ability to send rekey messages as unicast or multicast in the network infrastructure.

Obviously, if the Key Server fails, the GET VPN implementation is in big trouble. To help ensure availability of the solution, cooperative Key Servers (COOP KSs) provide redundancy. Under COOP, one of your KSs serves as the primary Key Server, while other KSs are the secondary devices. Messaging between the KSs ensure a failover election occurs if a downing of the primary device is detected through the lack of primary device messages.

Stay tuned to the blog for more information on the GET VPN, including basic configurations.