Group Domain of Interpretation (GDOI) is a group key protocol whereby all group members register with a key server. The concept is to use a group (common) key among a group of routers for encryption and decryption. The key server and a few group members have the ability to form a group; the key server authenticates the group member and distributes group keys and policies to the group members. The traffic encrypted by a group member can be decrypted by any other group member registered with the same key server. No additional security negotiation is needed between any two group members when they want to encrypt traffic between them. More details are given in the following sections.
Dynamic Multipoint VPN (DMVPN) provides spoke-to-hub and spoke-to-spoke connectivity solutions using multipoint generic routing encapsulation (mGRE) and Next Hop Resolution Protocol (NHRP). If spoke-to-spoke direct connectivity is enabled in the network, the spoke maintains a permanent IP Security (IPsec) tunnel to the hub, but the spoke-to-spoke IPsec tunnel is dynamic (on demand). Whenever spoke-to-spoke connectivity is desired, the originating spoke will send an NHRP resolution request to the hub, and the destination spoke and the hub will respond with an nonbroadcast, multiaccess (NBMA) address mapped to the destination's NHRP address.
Once the mapping is received, the spoke will initiate a dynamic IPsec tunnel with the destination spoke using the same mGRE interface. Traffic will start passing through this dynamic tunnel. Until this dynamic tunnel is built, traffic continues to pass through the hub. To get any response from the destination spoke, the same procedure is initiated by the destination spoke toward the originating spoke. Creation of a dynamic tunnel prevents the hub from being bombarded with spoke-to-spoke traffic but introduces some delay in setting up the tunnel. Though this delay exists for any direct communication between spokes, certain real-time applications, such as voice, might still look to avoid it. By using GDOI technology, the delay caused by IPsec negotiation is eliminated, which is the major contributor to the overall delay. GDOI is not a replacement for DMVPN.
DOCUMENT SCOPE
This document describes the topology setup of the configuration of GDOI in the deployment of an Enterprise-Class Teleworker(ECT) solution. It provides a step-by-step explanation and discusses the specific hardware and software required to set up this network. This document does not go into detail explaining DMVPN and its deployment on specific platforms. The reader is expected to be familiar with DMVPN concepts.
GDOI IN DMVPN NETWORK DEPLOYMENT
To understand this deployment, a brief introduction is given regarding GDOI followed by the high-level packet flow in this implementation.
Note: Cisco Systems® implements the GDOI protocol using the Cisco IOS® Software Secure Multicast feature, which was introduced in Cisco IOS Software Release 12.4(6)T.
GDOI describes a protocol for a group of systems to download encryption keys and security policy from a key server. The key server is a router that distributes encryption keys to a group of systems (group members). Group members that setup Internet Key Exchange (IKE) sessions with the key server download encryption keys and policies required for encryption. Both group members and key servers use identity strings to represent a group. The basic goal behind a GDOI implementation is to overcome the limitations of regular IPsec-like pairwise keys, point-to-point tunnel, no multicast support, etc. With GDOI, all group members within a group can send and receive encrypted traffic between them using the same group key obtained from the key server. Any encrypted traffic within the same group can be decrypted by any group member. There is no need to build point-to-point IPsec sessions between various group members, avoiding the use of pairwise keys. Unlike plain IPsec, GDOI maintains a single IPsec session between the group member and key server, and no other IPsec sessions exist between group members.
The security policies and access lists are defined on the key server. The access list can also include multicast entries. To support multicast encryption, all the group members should have multicast capability between them. Since policies are defined only on the key server, the same set of policies is downloaded to all group members within a group. The key server pushes new group keys (also known as a rekey) whenever needed, like IPsec security associations (SAs) lifetime expiration, clearing the GDOI session. Key servers can use either unicast or multicast key distribution for rekeying. To support multicast rekeying, all group members should have multicast capability.
GDOI requires a group member registered with the key server; GDOI registration occurs in two phases.
1. IKE phase 1 (the same used in plain IPsec)
2. GDOI registration protocol (similar to quick mode in IPsec)
GDOI uses User Datagram Protocol (UDP) 848 to establish its IKE sessions between the key server and the group members. Upon receiving a registration request, the key server authenticates the router, performs an optional authorization check, and downloads the policy and keys to the group member. The group member is ready to use these encryption keys. The key server pushes new keys to the group (also known as rekeying the group) whenever needed, similar to SA expiration. The key server can host multiple groups and each group will have a different group key.
Figure 1. GDOI Registration
How does GDOI help in a DMVPN network?
In an ECT solution, DMVPN is implemented using tunnel protection enabled in the tunnel interfaces of both hub and spokes. Tunnel protection uses IPsec profiles, which install policies dynamically during tunnel negotiation between them. From the deployment perspective, each spoke maintains a permanent IPsec tunnel with the hub, and any spoke-to-spoke connectivity requires the spoke to send out a NHRP resolution request to the hub. Upon receiving an NHRP resolution reply, the spoke will dynamically create another IPsec tunnel directly with the destination spoke. A new set of pairwise keys is negotiated between spokes directly, and a point-to-point tunnel is created. As mentioned previously, this introduces a delay in setting up direct tunnels. By integrating GDOI within the DMVPN, delay can be reduced by eliminating this creation of direct tunnels between spokes.
With GDOI, the spokes and hubs are group members and group keys can be distributed to the hub and all spokes, eliminating the need for point-to-point IPsec sessions between them. Any group member can talk to any other group member using the same key. This means the spoke changes the destination address to forward traffic directly to other spokes once NHRP resolution is completed. This reduces the delay between spoke-to-spoke connections by eliminating creation of dynamic IPsec tunnels between them. With this integration, each spoke maintains a GDOI session only with the key server and there is no permanent tunnel between the hub and spoke. The spoke maintains NHRP entries for the hub; the spoke still needs to contact the hub first whenever spoke-to-spoke connectivity is required. The key server can push "gre any any" to all group members to achieve the same result as DMVPN using tunnel protection. This requires no other change in the key server as new spokes are added. Also, GDOI does not support IPsec profiles, so tunnel protection is removed from tunnel interfaces and GDOI is tied to the physical interface.
Following is the summary of packet flow in the DMVPN network using GDOI.
1. The hub and all spokes, configured as group members, register with the GDOI key server.
2. The key server distributes group key and IPsec policy to all group members; IPsec policy defines the traffic selectors. For DMVPN, "gre any any" could secure all tunnel traffic.
3. A spoke-to-hub tunnel is established using NHRP. All packets traveling via the DMVPN tunnel are now encrypted using the group key.
4. The spoke sends an NHRP resolution request to the hub for any spoke-to-spoke communication.
5. Upon receiving an NHRP resolution reply from the hub, the spoke sends traffic directly to other spokes with group key encryption. Until the NHRP resolution reply is received, spoke-to-spoke traffic continues via the hub with group key encryption.
Note: Multicast traffic will be forwarded to the hub for any spoke-to-spoke communication, even with this deployment.
Figure 2. Packet Flow
Note: Points 4 and 5 are not shown in the diagram; they are exchanged between the hub and the spokes over the tunnel formed in step 3.
NETWORK ARCHITECTURE
TOPOLOGY
The following topology shows deploying GDOI in an existing ECT solution. The detailed packet flow using GDOI has been explained in the previous section.
Figure 3. GDOI in the Original ECT Solution
RECOMMENDED PLATFORMS AND IMAGES
Images based on Cisco IOS Software Release 12.4(9)T are required to enable GDOI. The following platforms are suggested for various roles of this deployment.
• Key server: Cisco 1700 Series Modular Access Router and above
• Group member configured for DMVPN hub: Cisco 3800 Integrated Service Router and above
• Group member configured for DMVPN spoke: Cisco 871 Ethernet Broadband Router and above
DEPLOYMENT
GDOI is deployed in our ECT solution setup and both data and voice are tested in this network. The delay created when initiating voice calls does not exist. From the ECT perspective, GDOI is tied to the physical interface; it does not support IPsec profiles, and tunnel protection is removed from the tunnel interfaces. GDOI can coexist with plain IPsec tunnels used for manageability.
INITIAL SETUP
Both hub and spoke are configured as GDOI group members and a separate router is configured for the GDOI key server. The following configuration is required to enable GDOI in a DMVPN setup.
Key Server Configuration
!!!! The following configuration enables keyserver in a router. Each group defined in keyserver has an identity which is shared among the members within the group. Here identity is set to 1234 for group `dmvpn'. Key server also defines the policies using access-list 105 to be distributed to group members upon registration. !!!!
!
crypto gdoi group dmvpn
identity number 1234
server local
rekey lifetime seconds 300
sa ipsec 1
profile dmvpn-gdoi
match address ipv4 105
!
!!!! ISAKMP and IPsec profile configuration are defined below. As the setup is using PKI certificates, configurations involving PKI are not shown here. !!!!
!!!! The following configuration shows that there is no crypto map associated with any physical interface. !!!!
!
interface Loopback0
description interface used for tunnel setup
ip address 192.168.1.1 255.255.255.255
!
interface FastEthernet0/0
description to ISP
ip address 10.1.1.1 255.255.255.240
duplex auto
speed auto
!
!!!! The following acl defines the policies to be pushed to group members. `gre any any' is used here to encrypt all traffic seen in dmvpn tunnel interface, just to achieve the same as dmvpn with tunnel protection. !!!!
!
access-list 105 permit gre any any
Note: One advantage with this acl 105 is that there is no additional configuration required in key server for newly added spokes within the same group/dmvpn. Only respective spokes need to be configured for GDOI.
Group Member Configuration on DMVPN Hub
!!!! IPsec transform-sets and profile configurations are not required as they are part of negotiation with key server when establishing GDOI session. Only ISAKMP configurations are required to be defined. !!!!
!
crypto isakmp policy 1
encr 3des
!
crypto isakmp keepalive 10
!
!!!! Group member is defined with same identity and location of key server. !!!!
!
crypto gdoi group dmvpn
identity number 1234
server address ipv4 192.168.1.1
!
!!!! Crypto map has a new type `gdoi' and is tied to group member created above. !!!!
!
crypto map gdoi 1 gdoi
set group dmvpn
!
!!!! Tunnel protection is removed from tunnel interface. !!!!
!
interface Tunnel100
description DMVPN - EIGRP network
bandwidth 2000
ip address 1.1.1.1 255.255.255.0
no ip redirects
ip mtu 1400
no ip next-hop-self eigrp 7
ip pim nbma-mode
ip pim sparse-dense-mode
ip multicast rate-limit out 768
ip nhrp map multicast dynamic
ip nhrp network-id 1000
ip nhrp holdtime 600
ip nhrp server-only
ip tcp adjust-mss 1360
no ip split-horizon eigrp 7
no ip mroute-cache
delay 1500
tunnel source Loopback0
tunnel mode gre multipoint
tunnel key 10000
!
interface Loopback0
ip address 192.1.1.2 255.255.255.0
no ip redirects
!
!!!! GDOI is enabled by applying crypto map to physical interface. !!!!
!
interface GigabitEthernet0/0
ip address 10.1.1.2 255.255.255.240
crypto map gdoi
!
Group Member Configuration on DMVPN Spoke
!!!! IPsec transform-sets and profile configurations are not required as they are part of negotiation with key server when establishing GDOI session. Only ISAKMP configurations are required to be defined. !!!!
!
crypto isakmp policy 1
encr 3des
crypto isakmp keepalive 10
!
!!!! Group member is defined with same identity and location of key server. !!!!
!
crypto gdoi group dmvpn
identity number 1234
server address ipv4 192.168.1.1
!
!!!! Crypto map with type gdoi is defined along with management tunnel. From the spoke's perspective, it may be necessary to keep management tunnel active along with GDOI session (as part of ECT solution) for the following reasons. Management tunnel is point-to-point and mostly used for management purpose as well as to access PKI/AAA servers in a secure mode. !!!!
!
crypto map mgmt-gdoi 1 ipsec-isakmp
description Management Tunnel
set peer 192.168.1.10
set transform-set mgmt-ipsec
match address mgmt_acl
crypto map mgmt-gdoi 2 gdoi
set group dmvpn
!
!!!! Tunnel protection is removed from tunnel interface. !!!!
!
interface Tunnel10
bandwidth 2000
ip address 1.1.1.11 255.255.254.0
no ip redirects
ip mtu 1400
ip nhrp map multicast 192.1.1.2
ip nhrp map 1.1.1.1 192.1.1.2
ip nhrp network-id 1000
ip nhrp holdtime 300
ip nhrp nhs 1.1.1.1
ip nhrp registration no-unique
ip pim sparse-dense-mode
ip multicast rate-limit out 128
ip tcp adjust-mss 1360
no ip mroute-cache
load-interval 30
delay 2000
qos pre-classify
tunnel source FastEthernet4
tunnel mode gre multipoint
tunnel key 10000
!
!!!! GDOI is enabled by applying crypto map to physical interface. !!!!
!
interface FastEthernet4
description outside interface
ip address dhcp client-id FastEthernet4
ip access-group fw_acl in
crypto map mgmt-gdoi
!
!!!! The following line is added to firewall acl to permit GDOI packets (udp 848). !!!!
!
ip access-list extended fw_acl
permit udp any any eq 848
!
BENEFITS
• The hub and all spokes use group key for encryption and decryption.
• No separate IPsec spoke-to-spoke tunnel is required.
• There is minimal or no delay in setting up voice calls between spokes.
• Hub and spokes will have a single GDOI session with the key server.
• If rekey is enabled, spokes don't need to re-register with the key server.
• It is easy to migrate from DMVPN with tunnel protection to GDOI-based DMVPN.
CAVEATS / FINAL NOTES
• An additional device is needed to function as the GDOI key server.
• There is no redundancy support for key servers.
• If rekey fails for any GM, GM must re-register with the key server after SA lifetime expiration; this may cause temporary disconnect in the network.
• Tunnel protection needs to be removed from the mGRE interface; though no issues are observed for spoke-to-spoke, this may cause packet loss in between, due to the separation of NHRP and crypto functions.
• The GDOI crypto map must be applied in the physical interface for the hub and all spokes.
• The image must be upgraded to Cisco IOS Software Release 12.4(9)T in the hub and all spokes.
• There is no support for mixed GDOI based DMVPN spokes and DMVPN spokes with tunnel protection.
• GDOI based DMVPN spokes behind Network Address Translation (NAT) are NOT supported for spoke to hub or spoke to spoke tunnel. The support may be available in later GDOI_DMVPN phases.
• For rekey to work, an exclusive Internet Group Management Protocol (IGMP) join is needed in the mGRE interface.
• If GM has to be removed from a group, the changes may take as long as traffic encryption keys lifetime remains.
• If direct spoke to spoke traffic is blocked, it would cause traffic blackhole as NHRP and crypto functions are separated. There may be improvements in later GDOI_DMVPN phases.
• Provisioning and Management support for GDOI_DMVPN solution in Cisco Security Manager 3.0 through flexconfig (templates)
