Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to https://cfnng.cisco.com/. An account on Cisco.com is not required.

Cisco Group Encrypted Transport Virtual Private Network (GETVPN) architecture is based on the Group Domain of Interpretation (GDOI) protocol. GETVPN uses Internet Security Exchange and Key Management Protocol (ISAKMP) to authenticate new group members, download cryptographic policy, and distribute traffic encryption key (TEK) and key encryption key (KEK) to group members. However, Internet Key Exchange Version 2 (IKEv2) has replaced. IKEv2 reduces network latency, reduces complexity in message exchanges, improves interoperability and reliability, and fixes cryptographic issue in HASH authentication. GET VPN combines IKEv2 protocol with IPsec to provide an efficient method to secure IP multicast traffic or unicast traffic through the GETVPN G-IKEv2 feature. This feature provides a complete IKEv2 solution across all of Cisco’s VPN technologies.

The G-IKEv2 protocol provides a mechanism for a group member (GM) to download policy and keys from a key server (KS). These policy and keys are used to secure communication among GMs in a group. G-IKEv2 is a new model to secure group communication between remote locations in an enterprise private WAN. The following figure depicts the basic system architecture of GETVPN using G-IKEv2 to register GM's with a KS and download keys and policy to GM's from a KS.

Internet Key Exchange Version 2 (IKEv2), a next-generation key management protocol based on RFC 4306, is an enhancement of the IKE Protocol. IKEv2 is used for performing mutual authentication and establishing and maintaining security associations (SAs). For more information on IKEv2, see FlexVPN and Internet Key Exchange Version 2 Configuration Guide.

The following table compares the tunnel performance between IKE and IKEv2.

The benefits of IKEv2 are as follows:

The message exchanges between GM and KS conforms to the Internet Engineering Task Force (IETF) Group Key Management using IKEv2 Standards draft.

1. Group member initiates a registration request to key server by sending preferred cryptographic algorithms (in SAi payload), Diffie–Hellman public number, in initiator’s key exchange (KE) phase 1 payload, and nonce, which is a random number for guaranteeing liveness in Initiator’s nonce payload.

2. Key server responds with the negotiated cryptographic algorithm (in responder’s SA phase 1 payload), Diffie–Hellman public number (in responder’s KE payload), nonce (in responder’s nonce payload). Optionally, if key server is configured to use Rivest, Shamir, and Adleman (RSA) digital signature as an authentication method, key server also sends a certificate request.

3. On receiving key server’s response to the registration request, the group member uses the cryptographic algorithm in the SAr1 payload and Diffie–Hellman value to create keys and to encrypt the message sent to the key server. The encrypted message includes the initiator’s ID and, optionally, certificate and certificate request, if RSA digital signature is used as authentication method. In case of Suite B implementations, a notify payload is sent for requesting sender IDs used with Galois/Counter Mode (GCM)–Advanced Encryption Standard (AES) or Galois Message Authentication Code (GMAC)–Advanced Encryption Standard (AES) transforms.

   Note

   Group member requests a set of sender IDs applicable for interfaces for a lifetime of one day. After receiving the lifetime in a registration (for Long SA Lifetime) or a rekey (for Short SA Lifetime) message, group member stores the lifetime for calculating the number of sender IDs for future registrations.

4. After authenticating group manager, key server authorizes group member before registering group manager. After registration, key server sends the group’s policy (in the GSA payload) and the group’s keying material (in the KD payload) to group manager. The SEQ payload is optional and is sent when the key server wants to inform group manager of the current sequence number of the rekey message. These payloads are included in the GSA_AUTH response message.

Key Server Rekey

Key server distributes new group keys to group members using the G-IKEv2 group maintenance channel via unicast or multicast communication. Rekey is optional in G-IKEv2. When rekey is used, the KS sends a rekey message to group member. This message could be unicast or multicast depending on the key server configuration. Key server uses the KEK that is sent to the group member during registration to encrypt the rekey message. On receiving a rekey message, group member must ensure that the SEQ number in the rekey message is larger than the last received SEQ number. Group member could have received the SEQ number either via a registration message or a rekey message, whichever is later. If key server group is configured as both GDOI (IKEv1) and G-IKEv2 group, two rekey messages are sent—one over GDOI and another over G-IKEv2—for multicast rekey. In case of unicast rekey, key server only sends a GDOI or G-IKEv2 rekey depending on the group member’s mode or type.

Note	If the rekey is unicast, the group member must send an acknowledgment to key server.

The GETVPN G-IKEv2 feature supports the existing GETVPN features, which are as follows:

• Rekey and retransmission

• GM access control list (ACL)

• Fail-close mode

• Receive-only mode

• Anti-replay

• Authentication policy for group member registration

• GDOI MIBS

• VRF-Aware group member

• Group member removal and policy replacement

• Cooperative key server

• GETVPN IPv6 dataplane

• IPsec inline tagging support

• GETVPN resiliency phase 1 and phase 2

• Cooperative announcement message optimization

The GETVPN G-IKEv2 feature is supported in GKM version 1.0.12 and later releases. The supported GKM versions for a key server is 1.0.13 and a group member is 1.0.12. The difference between versions on a key server and a group member is because the IP D3P support on GETVPN Key Server and Internet-Draft ACK for Cisco GETVPN Key Server features are available on the key server from 1.0.13 only.

Over a period of time, you may want to upgrade and migrate your key servers and group members to G-IKEv2. Migration from GDOI to G-IKEv2 for an entire GETVPN group requires careful planning. You cannot migrate all your group members at the same time. The migration entails allowing GDOI group members and G-IKEv2 group members to communicate using the same traffic encryption key (TEK) while using different control plane protocols—GDOI and G-IKEv2. A GDOI to G-IKEv2 migration sequence includes the following:

• Backward compatibility—The new Cisco IOS software image containing the GETVPN G-IKEv2 feature must support existing GDOI features and must be consistent with for earlier releases of GDOI features for Cisco IOS software.

• Service upgrade—The recommended sequence for changing the Cisco IOS software image is secondary key server, primary key server, and group member.

• Service downgrade—The recommended sequence for changing the Cisco IOS software image is group member, secondary key server, and primary key server.

Service Upgrade Procedure

1. Save the existing key server and group member GDOI configurations. For more information, see the “Configuration Replace and Configuration Rollback” feature module in the Managing Configuration Files Configuration Guide.

2. Configure a key encryption key (KEK) and a traffic encryption key (TEK) lifetime on all key servers to avoid network split and merge during the migration of the key servers. Use the crypto gdoi ks rekey command to configure the new lifetimes.

3. Upgrade key server to the new Cisco IOS software images. Follow the sequence mentioned above—start with the secondary key server followed by the primary key server. All existing configurations that use the keyword gdoi will be converted to the keyword gkm . For example, the global configuration command crypto gdoi group will be converted to crypto gkm group command. However, the groups continue to use GDOI for registration and rekey.

4. On key server, execute the gikev2 command in the server local command for groups that support GDOI and G-IKEv2 group members.

5. Upgrade group members to the new Cisco IOS software image. All existing configurations that use the keyword "gdoi " will be converted to the keyword gkm . For example, the global configuration commands crypto gdoi group and crypto map gdoi will be converted to "crypto gkm group " and crypto map gkm respectively. These groups continue to use GDOI for registration and rekey and include the client protocol gdoi command.

6. Configure the client protocol gikev2 command to use G-IKEv2 on group member.

7. Configure the no gdoi command in the server local command, to stop servicing GDOI group members.

For a group member to use GDOI after upgrading to G-IKEv2, configure the client protocol gdoi command in the group member group configuration. Group member registers again with key server using GDOI instead of G-IKEv2.

Note	Before you convert group member, ensure that key server to which group member is registered is configured with the gdoi command in GDOI local server configuration mode.

crypto gdoi group g1
 identity 1111
 server local
  .
  .
  .
  sa ipsec 1
   profile getvpn_profile
   match address getvpn_acl
   .
   .
   .
   redundancy
   .
   .
   .

crypto gkm group g1
 identity 1111
 server local
  gdoi
  no gikev2
  gikev2 ikev2_profile1
  .
  .
  .  
  sa ipsec 1
   profile getvpn_profile
   match address getvpn_acl
   .
   .
   .
   redundancy
   .
   .
   .

crypto gdoi group g1
 identity 1111
 server address ipv4 ks1
 server address ipv4 ks2

crypto map GETVPN_CM 10 gdoi
 set group g1

interface g0/0/0
 crypto map GETVPN_CM

crypto gkm group g1
 identity 1111
 server address ipv4 ks1
 server address ipv4 ks2
 client protocol gdoi 
 client protocol gikev2 ikev2_profile1 ] – Configure this to start using G-IKEv2

crypto map GETVPN_CM 10 gdoi
 set group g1

interface g0/0/0
 crypto map GETVPN_CM

All GETVPN commands—EXEC and global configuration commands—include the keyword gdoi. G-IKEv2 does not include the Domain of Interpretation, therefore, a generic abbreviation gkm referring to Group Key Management is used for a group that can use either GDOI or G-IKEv2 protocols for registration and rekey. As of now, both commands crypto gdoi and crypto gkm are available. However, the GDOI keyword will be deprecated and replaced by the gkm keyword in future. For example, to configure a key server group, the GDOI command is crypto gdoi group group-name , whereas the GKM command would be crypto gkm group group-name .

In a G-IKEv2-enabled network, a Key Server (KS) authorizes a Group Member (GM) on the GM’s identity. The identities currently supported by KS are IP address, fully qualified domain name (FQDN) and distinguished name (DN). The identity of a GM used for authorization is same as the identity used in IKEv2 protocol. In addition to the above listed identities, IKEv2 also supports email and key-id. When a GM registers to a KS using G-IKEv2, the registration fails when GM uses email or key-id as identities. Secondly, the KS is authorized twice for a GM—by IKEv2 and group key management (GKM) respectively.

The G-IKEv2 Enhancement for GETVPN feature leverages IKEv2 supported identities thereby enabling IKEv2 profile-based authorization on G-IKEv2 networks. The GM identity is used by IKEv2 and GKM on KS to authenticate the GM. IKEv2 uses its identity to bring up a session and GKM uses identity for GM registration.

On G-IKEv2 networks, there are no additional commands required to configure IKEv2 profile-based authorization. The authorization is taken care when configuring the IKEv2 profile. You must only attach the IKEv2 profile to a GKM group (as a part of Get VPN G-IKEv2 feature) to the KS and the GM. G-IKEv2 registration fails if the same IKEv2 profile is not attached to both KS and GM. The G-IKEv2 Enhancement for GETVPN feature allows you to use the additional identities supported by IKEv2 on G-IKEv2 networks.

In case of GDOI-based networks, the authorization must be configured via the authorization command.

Note	Although, GDOI and G-IKEV2 support access control list configuration in a authorization list, IKEv2 does not support ACL in identity configuration. Therefore ACL is not supported on G-IKEv2 networks but is supported and applicable for GDOI networks.