Introduction
This document discuss about:
- What is Group Encrypted Transport VPN (GETVPN)
- How it Works
What is GETVPN?
GET (Group Encrypted Transport) VPN is a VPN technology which introduces the concept to eliminate point-to-point tunnels (site-to-site VPN) and associated overlay routing (DMVPN) since it relies on WAN routing. It enables any-to-any VPN connectivity using a group IPSec security paradigm.
In addition to IPSec, the following are the building blocks for GET VPN solution:
1. Group Domain Of Interpretation (GDOI)
GDOI is a group key management protocol used to provide a set of IPSec keys to a group of IOS devices called Group Members (GM) that wish to communicate securely i.e. GDOI is run between a GM and a Key Server (KS). These keys are periodically refreshed on all devices using a process called rekey.
GDOI is a "Phase 2" protocol which is protected by "Phase 1 Security Association (SA)". IKE Phase 1 remains the same as in traditional IPSec. All Group Members authenticate themselves using IKE to the device providing keys (called a Key Server) which is statically configured for all Group Members. All IKE authentication methods are supported - Pre-Shared Keys (PSK) or RSA-Signature (PKI) or RSA-Encryption.
GDOI introduces two different types of encryption keys- the Key Encryption Key (KEK) is used to secure GET VPN control plane, and the Traffic Encryption Key (TEK) which encrypts the data traffic.
RFC 3547 defines GDOI. GDOI runs on UDP port 848. There are six new payloads for GDOI:
- GDOI SA
- SA KEK which follows the SA payload
- SA TEK which follows the SA payload
- Key Download Array (KD)
- Sequence Number (SEQ)
- Proof of Possession (POP)
2. Key Server (KS)
A Key Server is a Cisco IOS device which is responsible for creating and maintaining GET VPN control plane. All IPSec policies like interesting traffic, IPSec security protocols, rekey timers, etc are manually defined on the Key Server, and are downloaded by Group Members using registration.Even if a Group Member owns a particular network or not, it downloads the interesting traffic defined on the Key Server (using ACL).
3. Co-operative Key Server (COOP KS)
GET VPN supports multiple KS if a KS fails or becomes unreachable. A Group Member can be configured to register with a list of KSs.
When COOP KSs boot, all KSs assume a "secondary" role and begin election process. A KS with highest priority wins the election (in case of a tie, the KS with highest IP Address wins) and becomes the "primary" KS. Other KSs remain in "secondary" state.A GM can register with either a Primary or Secondary KS. However, only Primary KS sends rekey messages. If a Secondary KS does not "hear" from the Primary KS for a period of time, the Secondary KS tries to contact Primary KS for updated information. If the Secondary KS still does not hear from Primary KS, re-election takes place and a Primary KS is elected.
4. Group Member (GM)
A GM is an IOS device responsible to handle GET VPN data plane. These are the actual devices who forms IPSec connections between them. A GM is statically configured with IKE Phase 1 parameters and Key Server information. The GMs download IPSec policies and keys from the KS during registration.
5. Rekeying
A KS performs rekey process (sending new keys when existing keys are about to expire) which includes refreshing keys and distributing to the GMs. GET VPN supports two types of rekey messages:
- Unicast rekey: In this process, the KS generates a rekey message and sends multiple copies of the message, one for each GM. The GM sends an ACK message upon receiving the rekey message.
- Multicast rekey: In this process, the KS generates a rekey message and sends a single copy of the message to the multicast address defined in the configuration. Each GM joins the multicast group at the time of registration and hence receives the rekey message. No ACK messages are sent by GM upon receiving the rekey message.
6. Time-based Anti-Replay (TBAR)
In traditional IPSec, anti-replay capability is available using counter-based sliding window. When the sender sends a packet with a sequence number, the receiver uses a sliding window to determine whether a packet is acceptable, or has arrived out-of-sequence.Due to group SA in GET VPN, counter-based sliding window is ineffective. In GET VPN, all GMs can communicate with each other using a common IPSec policy and a shared SA. Hence, there is no need to negotiate IPSec between GMs. GET VPN uses time-based anti-replay which is based on a pseudotime clock maintained on the KS.
GET VPN uses Tunnel mode of IPSec, but instead of using the tunnel endpoints in the new IP header, it reuses the original IP header as the new Tunnel header (much like IPSec Transport mode). This provides an advantage as the existing routing infrastructure can be used and no separate routing instance needs to be run for GET VPN.
How Group Domain Of Interpretation (GDOI)works?
RFC 3547 defines two new exchanges for GDOI:
1.) GROUPKEY-PULL Exchange
This exchange is also called Registration. This Phase 2 exchange downloads keys for a group's Re-key SA and Data-security SA. The Re-key SA includes Key Encryption Key (KEK) common to the group, and the Data-security SA includes Traffic Encryption Key (TEK) used to encrypt/decrypt data traffic.The Group Member (Initiator) initiates and contacts the Key Server. The GM is configured with the group identifier and acceptable Phase 1 policy. Once Phase 1 is complete, the initiator moves to GDOI protocol. The initiator builds a NONCE payload by choosing the Ni (Nonce value by initiator), builds an ID payload using the group identifier, and generates HASH(1). The first GDOI message is also called Request message.
Upon receipt of the GDOI message, the Key Server (Responder) processes the NONCE and ID payloads. It verifies that its database contains the group information for the group ID. It constructs the second GDOI message, chooses the Nr (Nonce value by responder) for NONCE payload, the policy for the group in the ID payload, followed by SA TEK payload for traffic SAs and SA KEK payload, and generates HASH(2). The second GDOI message is also called Push message.The GM receives the second GDOI message, validates the HASH(2) and process NONCE and SA payloads. If the group policy uses Certificates for authorization, the GM generates a hash with Ni and Nr, and signs it. This becomes the POP payload. The CERT payload holds the Public Key. The GM creates the third GDOI message using POP and CERT payloads, and generates HASH(3). The third GDOI messages is also called ACK message.
Upon receipt of the third GDOI message, the KS validates the hash. It constructs a fourth GDOI message including the SEQ payload containing the sequence number, the KD payload containing keys corresponding to policy previously sent in SA TEK and KEK, and POP and CERT payloads (if needed), and generates HASH(4). The fourth message is also called Key Download message.
The GM receives the fourth GDOI message and validates the hash. It then processes the SA TEK and KEK payloads.
2.) GROUPKEY-PUSH Exchange
The GROUPKEY-PUSH message replaces a Re-key SA &/or Data-security SA, and it can be pushed using unicast or multicast. It is only a single message generated by the KS. It includes new keys when the key-lifetime is about to finish.
