Version 4.1 - 2.0 GDOI
I've been looking forward to discussing this topic. I've actually set up GETVPN in production and know this one pretty well. It's interesting how your knowledge leads to experience, which leads to more knowledge. GDOI is the Group Domain of Interpretation. You will see this in GETVPN - Group Encrypted Transport Virtual Private Network.
In my previous post, I spoke about the three IKE RFCs that were replaced by RFC 4306. Well the first of those was RFC 2407 [DOI] - Domain of Interpretation. "Security protocols sharing a DOI choose security protocol and cryptographic transforms from a common namespace and share key exchange protocol identifiers. They also share a common interpretation of DOI-specific payload data content, including the Security Association and Identification payloads." So think of a group of routers (such as a Corporate hub with Branch spokes) that connect over an insecure medium (DMVPN over the Internet) which need to protect the networks behind them. With GETVPN, you are setting up a group of routers that are all speaking the same encrypted language and can communicate securely between any two of them. This is much easier than setting up separate site-to-site IPsec tunnels with each of the members. GETVPN is actually covered in topic 6.6, so I'm going to curb my enthusiasm about it and speak specifically about GDOI in this post. Most of the study material available will speak about GDOI and GETVPN with respect to IKEv1. However, you can also use GETVPN G-IKEv2 to implement IKEv2. [Just FYI.]
An important concept is the idea of a keyserver. The group members (routers) connect to a keyserver (another router specifically configured) to download the encryption keys and security policy. This connection is on UDP 848. There are two types of keys -> KEK (Key Encryption Key) and TEK (Traffic Encryption Key). If you know what these acronyms stand for, you can remember what they do. Only the TEK encrypts the traffic between members. And the member routers only have an IPsec connection to the key server. The member must register with the key server and be authenticated (and optionally authorized) - and then the policy and keys are downloaded to the member.
Note that the member is downloading the policy from the keyserver. The keyserver is where you define what traffic is to be encrypted (where you find the ACLs). If you've never done this before, you may want to read Cisco's Whitepaper on Implementing GDOI in a Dynamic Multipoint VPN. Another important concept is the identity number. This tells the (keyserver) router to which group the member is trying to register. The same keyserver can service multiple groups.
And, of course, there is RFC 6407 which specifically covers the GDOI protocol. If you're not familiar with the protocol itself, it's worth taking the time to read. The GDOI includes two new Phase 2 ISAKMP exchanges. The GROUPKEY-PULL registration - which is when the member registers and pulls down the policy and keys. The GROUPKEY-PUSH rekey protocol exchange - which is when the keyserver sends out policy updates and rekey material. These messages are protected by the KEK.
The Security Considerations section of the RFC is interesting. "GDOI assumes that the group members and GCKS are secure even though the network is insecure." But what if one of the Group Members is compromised? This is probably not on the exam, but IRL - it's really important that you secure your Group Members and keyserver. Normally, the keyserver is on the internal network. But the Group Members (by their nature) are at the edges of an insecure medium. Just something to consider when implementing this.