Cisco Group Encrypted Transport VPN

GDOI is defined as the Internet Security Association Key Management Protocol (ISAKMP) Domain of Interpretation (DOI) for group key management. In a group management model, the GDOI protocol operates between a group member and a group controller or key server (GCKS), which establishes SAs among authorized group members. The ISAKMP defines two phases of negotiation. GDOI is protected by a Phase 1 ISAKMP security association. The Phase 2 exchange is defined in IETF RFC 3547. The topology shown in the figure below and the corresponding explanation show how this protocol works.

The group member registers with the key server to get the IPsec SA or SAs that are necessary to communicate with the group. The group member provides the group ID to the key server to get the respective policy and keys for this group. These keys are refreshed periodically, and before the current IPsec SAs expire, so that there is no loss of traffic.

The output of the show crypto isakmp sa detail command will show the security association (SA) Authentication as "rsig" because the RSA signature is used for key encryption key (KEK) rekey authentication in GET VPN.

The responsibilities of the key server include maintaining the policy and creating and maintaining the keys for the group. When a group member registers, the key server downloads this policy and the keys to the group member. The key server also rekeys the group before existing keys expire.

The key server has two responsibilities: servicing registration requests and sending rekeys. A group member can register at any time and receive the most current policy and keys. When a group member registers with the key server, the key server verifies the group ID that the group member is attempting to join. If this ID is a valid group ID, the key server sends the SA policy to the group member. After the group member acknowledges that it can handle the downloaded policy, the key server downloads the respective keys.

There are two types of keys that the key server can download: the key encryption key (KEK) and the traffic encryption key (TEK). The TEK becomes the IPsec SA with which the group members within the same group communicate. The KEK encrypts the rekey message.

The GDOI server sends out rekey messages if an impending IPsec SA expiration occurs or if the policy has changed on the key server (using the command-line interface [CLI]). A rekey can also happen if the KEK timer has expired, and the key server sends out a KEK rekey. The rekey messages may also be retransmitted periodically to account for possible packet loss. Packet loss can occur because rekey messages are sent without the use of any reliable transport. If the rekey mechanism is multicast, there is no efficient feedback mechanism by which receivers can indicate that they did not receive a rekey message, so retransmission seeks to bring all receivers up to date. If the rekey mechanism is unicast, the receivers will send an acknowledgment message.

Figure 2

Protocol Flows That Are Necessary for Group Members to Participate in a Group

The topology shows the protocol flows that are necessary for group members to participate in a group, which are as follows:

1. Group members register with the key server. The key server authenticates and authorizes the group members and downloads the IPsec policy and keys that are necessary for them to encrypt and decrypt IP multicast packets.
2. As needed, the key server "pushes" a rekey message to the group members. The rekey message contains a new IPsec policy and keys to use when old IPsec SAs expire. Rekey messages are sent in advance of the SA expiration time to ensure that valid group keys are always available.
3. The group members are authenticated by the key server and communicate with other authenticated group members that are in the same group using the IPsec SAs that the group members have received from the key server.

Multicast Rekeying uses the GDOI protocol (IETF RFC 3547) to distribute the policy and keys for the group. The GDOI protocol is between a key server and a group member. The key server creates and maintains the policy and keys, and it downloads the policy and keys to the authenticated group members.

The GDOI protocol is protected by an ISAKMP Phase 1 exchange. The GDOI key server and the GDOI group member must have the same ISAKMP policy. This Phase 1 ISAKMP policy should be strong enough to protect the GDOI protocol that follows. The GDOI protocol is a four-message exchange that follows the Phase 1 ISAKMP policy. The Phase 1 ISAKMP exchange can occur in main mode or aggressive mode.

The figure below shows the ISAKMP Phase 1 exchange.

Figure 3

ISAKMP Phase 1 Exchange and GDOI Registration

The ISAKMP Phase 1 messages and the four GDOI protocol messages are referred to as the GDOI registration, and the entire exchange that is shown is a unicast exchange between the group member and the key server.

During the registration, if the rekey mechanism is multicast, the group member receives the address of the multicast group and registers with the multicast group that is required to receive the multicast rekeys.

The GDOI protocol uses User Datagram Protocol (UDP) port 848 (with Network Address Translation-Traversal (NAT-T), it floats to 4500).

IPsec is a well-known RFC that defines an architecture to provide various security services for traffic at the IP layer. The components and how they fit together with each other and into the IP environment are described in IETF RFC 2401.

Key servers and group members are the two components of the GET VPN architecture. The key server holds and supplies group authentication keys and IPsec SAs to the group members.

Group members provide encryption service to the interesting traffic (traffic that is worthy of being encrypted and secured by IPsec).

Communication among the key server and group members is encrypted and secured. GDOI supports the use of two keys: the TEK and the KEK. The TEK is downloaded by the key server to all the group members. The downloaded TEK is used by all the group members to communicate securely among each other. This key is essentially the group key that is shared by all the group members. The group policies and IPsec SAs are refreshed by the key server using periodic rekey messages to the group members. The KEK is also downloaded by the key server and is used by the group members to decrypt the incoming rekey messages from the key server.

The key server generates the group policy and IPsec SAs for the GDOI group. The information generated by the key server includes multiple TEK attributes, traffic encryption policy, lifetime, source and destination, a Security Parameter Index (SPI) ID that is associated with each TEK, and the rekey policy (one KEK).

The figure below illustrates the communication flow between group members and the key server. The key server, after receiving registration messages from a group member, generates the information that contains the group policy and new IPsec SAs. The new IPsec SA is then downloaded to the group member. The key server maintains a table that contains the IP address of each group member per group. When a group member registers, the key server adds its IP address in its associated group table, thus allowing the key server to monitor an active group member. A key server can support multiple groups. A group member can be part of multiple groups.

Figure 4

Communication Flow Between Group Members and the Key Server

IPsec and ISAKMP SAs are maintained by the following timers:

• TEK lifetime-Determines the lifetime of the IPsec SA. Before the end of the TEK lifetime, the key server sends a rekey message, which includes a new TEK encryption key and transforms as well as the existing KEK encryption keys and transforms. The TEK lifetime is configured only on the key server, and the lifetime is "pushed down" to the group members using the GDOI protocol. The TEK lifetime value depends on the security policy of the network. If the set security-association lifetime command is not configured, the default value of 86,400 seconds takes effect. To configure a TEK lifetime, see the "Configuring an IPsec Lifetime Timer" section.
• KEK lifetime-Determines the lifetime of the GET VPN rekey SAs. Before the end of the lifetime, the key server sends a rekey message, which includes a new KEK encryption key and transforms and new TEK encryption keys and transforms. The KEK lifetime is configured only on the key server, and the lifetime is pushed down to group members dynamically using the GDOI protocol. The KEK lifetime value should be greater than the TEK lifetime value (it is recommended that the KEK lifetime value be at least three times greater than the TEK lifetime value). If the rekey lifetime command is not configured, the default value of 86,400 seconds takes effect. To configure a KEK lifetime, see the "Configuring a Multicast Rekey" section.
• ISAKMP SA lifetime-Defines how long each ISAKMP SA should exist before it expires. The ISAKMP SA lifetime is configured on a group member and on the key server. If the group members and key servers do not have a cooperative key server, the ISAKMP SA is not used after the group member registration. In this case (no cooperative key server), the ISAKMP SA can have a short lifetime (a minimum of 60 seconds). If there is a cooperative key server, all key servers must have long lifetimes to keep the ISAKMP SA "up" for cooperative key server communications. If the lifetime command is not configured, the default value of 86,400 seconds takes effect. To configure an ISAKMP SA lifetime, see the "Configuring an ISAKMP Lifetime Timer" section.

The rekey sequence-number check between the key server and the group member is conducted as follows:

1. Antireplay in GROUPKEY-PUSH messages is restored as specified in RFC 3547.
   • The group member drops any rekey message that has a sequence number lower than or equal to that of the last received rekey message.
   • The group member accepts any rekey message that has a sequence number higher than that of the last received rekey message, no matter how large the difference.
2. The sequence number is reset to 1 at the first rekey message after the KEK rekey, not at the KEK rekey message itself.

Multicast rekeys are sent out using an efficient multicast rekey. Following a successful registration, the group member registers with a particular multicast group. All the group members that are registered to the group receives this multicast rekey. Multicast rekeys are sent out periodically on the basis of the configured lifetime on the key server. Multicast rekeys are also sent out if the IPsec or rekey policy is changed on the key server. Triggered by the configuration change, the rekey sends out the new updated policy to all the group members with an efficient multicast rekey.

The key server pushes the rekey time back as follows:

1. If the TEK timeout is 300 seconds:

tek_rekey_offset = 90 (because 300 < 900)

If retransmissions are configured, the rekey timer is moved back more.

For three retransmissions every 10 seconds: 3 x 10

So the rekey will actually happen at (300 - 90 - 30) = 180 seconds

2. If the TEK timeout is 3600 seconds:

tek_rekey_offset = 3600 x 10 percent = 360 seconds

If retransmissions are configured, the rekey timer is moved back more.

For three retransmissions every 10 seconds: 3 x 10

So the rekey will actually happen at (3600 - 360 - 30) = 3210 seconds

When a KEK expires and when the transport mode is multicast, a multicast KEK rekey is sent. When a multicast KEK rekey is sent, the group member replaces the old KEK with the new KEK. Because it is a multicast rekey, and the retransmissions are sent, the old KEK continues to be used for encryption. This situation occurs because the group member does not receive the new KEK rekey. Hence the group member that received the multicast KEK rekey does not have the old KEK, and hence it drops these retransmissions.

The group member that did not initially receive the KEK key now receives the KEK retransmission and replaces the old KEK with the new KEK and will drop the retransmissions that will follow. For example, if five retransmissions are configured and a multicast KEK rekey with sequence number 1 is received at group member 1, all the other retransmissions with sequence numbers 2 3 4 5 6 will be dropped at the group member because the group member does not have the old KEK.

If group member 2 does not get the KEK rekey with sequence number 1 and it receives the retransmission with sequence number 2, it will drop the other retransmissions 3, 4, 5, 6.

• Configuration Requirements for Multicast Rekeying

In a large unicast group, to alleviate latency issues, the key server generates rekey messages for only a small number of group members at a time. The key server is ensured that all group members receive the same rekey messages for the new SA before the expiration of the old SA. Also, in a unicast group, after receiving the rekey message from the key server, a group member sends an encrypted acknowledge (ACK) message to the key server using the keys that were received as part of the rekey message. When the key server receives this ACK message, it notes this receipt in its associated group table, which accomplishes the following:

• The key server keeps a current list of active group members.
• The key server sends rekey messages only to active members.

In addition, in a unicast group, the key server removes the group member from its active list and stops sending the rekey messages to that particular group member if the key server does not receive an ACK message for three consecutive rekeys. If no ACK message is received for three consecutive rekeys, the group member has to fully re-register with the key server after its current SA expires if the group member is still interested in receiving the rekey messages. The ejection of a nonresponsive group member is accomplished only when the key server is operating in the unicast rekey mode. The key server does not eject group members in the multicast rekey mode because group members cannot send ACK messages in that mode.

As in multicast rekeying, if retransmission is configured, each rekey will be retransmitted the configured number of times.

Rekey transport modes and authentication can be configured under a GDOI group.

If unicast rekey transport mode is not defined, multicast is applied by default.

If the TEK rekey is not received, the group member re-registers with the key server 60 seconds before the current IPsec SA expires. The key server has to send out the rekey before the group member re-registration occurs. If no retransmission is configured, the key server sends the rekey tek_rekey_offset before the SA expires. The tek_rekey_offset is calculated based on the configured rekey lifetime. If the TEK rekey lifetime is less than 900 seconds, the tek_rekey_offset is set to 90 seconds. If the TEK rekey lifetime is configured as more than 900 seconds, the tek_rekey_offset = (configured TEK rekey lifetime)/10. If retransmission is configured, the rekey occurs earlier than the tek_rekey_offset to let the last retransmission be sent 90 seconds before the SA expires.

The key server uses the formula in the following example to calculate when to start sending the rekey to all unicast group members. The unicast rekey process on the key server sends rekeys to unicast group members in groups of 50 within a loop. The time spent within this loop is estimated to be 5 seconds.

A key server rekeys group members in groups of 50, which equals two loops. For example, for 100 group members:

Number of rekey loops = (100 group members)/50 = 2 loops:

• Time required to rekey one loop (estimation) = 5 seconds
• Time to rekey 100 group members in two loops of 50: 2 x 5 seconds = 10 seconds

So the key server pushes the rekey time back as follows:

• If the TEK timeout is 300: 300 - 10 = 290

But the start has to be earlier than the TEK expiry (as in the multicast case):

• Because 300 < 900, tek_rekey_offset = 90
• So 90 seconds is subtracted from the actual TEK time: 290 - tek_rekey_offset = 200 seconds

If retransmissions are configured, the rekey timer is moved back more:

• For three retransmissions every 10 seconds: 200 - (3 x 10) = 170
• If the TEK timeout is 3600 seconds: 3600 - 10 = 3590

But the start has to be earlier than the TEK expiry (as in the multicast case):

• Because 3600 > 900, tek_rekey_offset = 3600 x 10 percent = 360
• So 360 seconds is subtracted from the actual TEK time: 3590 - tek_rekey_offset = 3230 seconds

If retransmissions are configured, the rekey timer is moved back more:

• For three retransmissions every 10 seconds: 3230 - (3 x 10) = 3200 seconds

The tek_rekey_offset formula applies to unicast and multicast rekeying.

The table below provides a list of rekey behavior based on the security policy changes.

Enter the following commands for the policy changes to take effect immediately:

• Use the clear crypto gdoi [group] command on the key server.
• Use the clear crypto gdoi [group] command on all the group members.

Note	The key server sends rekeys for policy updates after the administrator exits configuration mode, ensuring that the rekeys are sent when appropriate.

Note

Passive-mode behavior before changing to bidirectional mode on a group member is as follows: If an you change the SA mode on the key server to "no sa receive-only," and exits configuration mode, the rekey is sent to the group member, and you can see the state on the group member changing from "inbound only" to "inbound optional;" the state will change to "both" after an interval set by a built-in timer; about five minutes. The key server shows this state as "both" immediately; this is done by design because all group members might be in the process of being updated.

When a rekey is received and processed on a group member, the new IPsec SA (the SPI) is installed. There is a period of time when the old and the new IPsec SAs are used. After a certain specified interval, the old IPsec SA is deleted. This overlap ensures that all group members receive the current rekey and insert the new IPsec SAs. This behavior is independent of the transport method (multicast or unicast rekey transport) for the rekeys from the key server.

Approximately 30 seconds before the old SA expires, the group member starts to use the new SA in the outbound direction to encrypt the packet. Approximately 60 seconds before the old SA expires, if no new SA is received on the group member side via a rekey from the key server, the group member re-registers.

In the figure below, time T2 is when the old SA expires. T1 is 30 seconds before T2, which is when the group member (GM) starts to use the new SA in the outbound direction. T0 is another 30 seconds before T2. If no new SA is received at T0, the group member has to re-register. T is another 30 seconds from T0. The key server should send a rekey at T.

Figure 8

IPsec SA Usage on a Group Member

Note	Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

Configuration changes on a key server can trigger a rekey by the key server. Please refer to the following sample configuration as you read through the changes that will or will not cause a rekey that are described following the example.

crypto ipsec transform-set gdoi-p esp-aes esp-sha-hmac
! 
crypto ipsec profile gdoi-p
 set security-association lifetime seconds 900
set transform-set gdoi-p 
!
crypto gdoi group diffint
 identity number 3333
 server local
  rekey algorithm aes 128
  rekey address ipv4 121
  rekey lifetime seconds 3600
  no rekey retransmit
  rekey authentication mypubkey rsa mykeys
  sa ipsec 1
   profile gdoi-p
   match address ipv4 120
   replay counter window-size 3

The following configuration changes on the key server will trigger a rekey from the key server:

• Any change in the TEK configuration ("sa ipsec 1" in the example):
  • If the ACL ("match address ipv4 120" in the above example) is changed. Any addition, deletion, or change in the ACL causes a rekey.
  • If TEK replay is enabled or disabled on the key server, rekey is sent.
  • Removal or addition of the IPsec profile in the TEK ("profile gdoi-p" in the example).
  • Changing from multicast to unicast transport.
  • Changing from unicast to multicast transport.

The following configuration changes on the key server will not trigger a rekey from the key server:

• Replay counter window size is changed under the TEK ("sa ipsec 1" in the example).
• Configuring or removing rekey retransmit.
• Removing or configuring the rekey ACL.
• Changing the TEK lifetime ("set security-association lifetime seconds 300" in the example) or changing the KEK lifetime ("rekey lifetime seconds 500" in the example).
• Adding, deleting, or changing the rekey algorithm ("rekey algorithm aes 128" in the example).

The table below is a comprehensive list of GET VPN command changes, and it shows which commands will or will not trigger a rekey. Commands are broken out based on the configuration mode in which they are entered. The table also shows when the commands take effect, regardless of whether they trigger a rekey.

When a timeout is caused by a pseudotime synchronization, the key server checks if either the KEK or the TEK timer is scheduled to expire in next 60 seconds, and if so, combines that timeout with the pseudotime synchronization timeout. That is, the rekey acts as both a TEK or KEK rekey and a pseudotime synchronization timeout rekey. See the "Time-Based Antireplay" section for more information on pseudotime synchronization.

Multicast rekeys are retransmitted by default. For unicast rekeys, if the key server does not receive the ACK, it retransmits the rekey. In either case, before retransmitting a rekey, the key server checks if there is a TEK or KEK rekey scheduled in the next 120 seconds. If so, it stops the current retransmission and waits for the scheduled rekey to happen.

The behavior of a group member changes when ACL changes or any other policy changes are made in the key server. The effect of different policy changes on the behavior of the group members is explained in the following three scenarios.

ip access-list extended get-acl
permit ip host A host B
permit ip host B host A

ip access-list extended get-acl
permit ip host C host D
permit ip host D host C

When you are configuring a crypto map to work in fail-close mode, you must be careful. If the fail-close ACL is defined improperly, you may lock yourself out of the router. For example, if you use Secure Shell (SSH) to log in to the router through the interface with the crypto map applied, you have to include the deny tcp any eq port host address command line under the fail-close ACL. You may also need to include the routing protocol that the router is using (such as deny ospf any any) to find the path to the key server. It is suggested that you configure fail-close and its ACL first, and then verify the fail-close ACL using the show crypto map gdoi fail-close map-name command. After you have checked your fail-close ACL and are confident that it is correct, you can make the crypto map work in the fail-close mode by configuring the activate command. Fail-close is not activated until you have configured the activate command.

The fail-close ACL is configured from the group-member perspective. The fail-close ACL is configured on group member as follows:

access-list 125 deny ip host host1-ip-addr host2-ip-addr

In fail-close mode, all IP traffic from host1 to host2 will be sent out by group member 1 in clear text. In addition, the inbound mirrored traffic (that is, IP traffic from host2 to host1) is also accepted by GM1 in clear text.

Note	All IP traffic matching deny entries are sent out by the group member in clear text.

The inbound traffic is matched to the mirrored access list.

The fail-close access list follows the same rules as the group member access list. For more information, see the "Group Member Access Control List" section.

You need not configure the deny udp any eq 848 any eq 848 command to make the GDOI registration go through. The code itself checks whether it is a GDOI packet for a particular group member from the key server to which it is configured. If it is a GDOI packet for this group member, the packet is processed. But for a scenario in which the key server is behind group member 1, if group member 1 cannot register successfully with the key server, other group members also will not be able to register unless an explicit deny udp any eq 848 any eq 848 command line is configured for group member 1. However, if the Fail-Close feature is properly configured, even if a group member fails to register with a key server, you will be able to ensure that no unwanted traffic can go out "in the clear." But you can allow specified traffic to go out in the clear, in which case registration packets from other group members will be able to reach the key server through group member 1 even if it fails to get registered.

For information on configuring fail-close mode, see the "Activating Fail-Close Mode" section.

To verify whether fail-close mode is activated, use the show crypto map gdoi fail-close command.

Clocks of the group members can slip and lose synchronization with the key server. To keep the clocks synchronized, a rekey message (multicast or unicast, as appropriate), including the current pseudotime value of the key server, is sent periodically, either in a rekey message or at a minimum of every 30 minutes to the group member. If a packet fails this antireplay check, the pseudotime of both the sender and receiver is printed, an error message is generated, and a count is increased.

To display antireplay statistics, use the show crypto gdoi group group-name gm replay command on both the sender and receiver devices. If the configuration is changed by the administrator to affect the replay method of the size configuration, the key server initiates a rekey message.

A tick is the interval duration of the SAR clock. Packets sent in this duration have the same pseudoTimeStamp. The tick is also downloaded to group members, along with the pseudotime from the key server. For example, as shown in the figure below, packets sent between T0 and T1 would have the same pseudoTimeStamp T0. SAR provides loose antireplay protection. The replayed packets are accepted if they are replayed during the window. The default window size is 100 seconds. It is recommended that you keep the window size small to minimize packet replay.

Figure 10

SAR Clock Interval Duration

The Antireplay feature can be enabled under IPsec SA on a key server by using the following commands:

• replay time window-size--Enables the replay time option, which supports the nonsequential, or time-based, mode. The window size is in seconds. Use this mode only if you have more than two group members in a group.
• replay counter window-size--Enables sequential mode. This mode is useful if only two group members are in a group.
• no replay counter window-size--Disables antireplay.

Announcement messages are secured by IKE Phase 1 and are sent as IKE notify messages. Authentication and confidentiality that are provided by IKE is used to secure the messaging between the key servers. Antireplay protection is provided by the sequence numbers in the announcement messages. Announcement messages are periodically sent from primary to secondary key servers.

Announcement messages include the components, described in the following sections that help maintain the current state.

Remove the sa receive-only command under the group. Removing the sa receive-only command creates new IPsec SAs for this group and causes a rekey. On receipt, group members reinstall the SA in both directions and begin to use it in passive mode. Because the SA cannot remain in passive mode forever, the group members change those SAs to receive or send mode if there is no rekey in 5 minutes. The conversion from passive mode to bidirectional encryption mode is automatic and does not require the administrator to do anything.

The same crypto map is applied to multiple subinterfaces, and each subinterface is in a different VRF context or the same VRF context, and the key server is accessible through a different VRF or global VRF table. This is addressed by separating out the control traffic.

There is one group member registration for all the crypto maps applied to different subinterfaces. After successful registration, policies are downloaded to where the crypto maps are.

Different groups are applied to different interfaces, and each of these interfaces is in a different VRF context or the same VRF context. All these groups are accessing the same key server, and this key server is accessible through a different VRF or global VRF table. This is addressed by having individual group members registering for each group.

So for every group, there is one registration and also one unicast rekey received. All these group members would be using the same IKE SA, which is established between the CE and the key server.

Different groups are applied to different interfaces, and each of these interfaces is in a different VRF context or the same VRF context. All these groups are accessing different key servers, and these key servers are accessible through a different VRF or the global VRF table. This is addressed by having a group member registering for each group. So for every group, there is one registration and also one unicase rekey received. Because every registration is with a different key server, a different IKE SA is established for every registration.

GET VPN GM authorization can be done using preshared keys or PKI. It is a best practice to turn on GET VPN authorization. When a key server serves multiple GDOI groups, key server authorization is required to prevent a GM in one group from requesting keys and policies from another group. The ISAKMP authorization confirms that the GM is allowed to request GDOI attributes from the key server while the GDOI authorization confirms that the GM is allowed to request GDOI attributes from a specific group configured in the key server.

GDOI authorization is based on the ISAKMP identity sent by a GM. If a GM sends an IP address as an identity, then only an authorization address is used for authorization. If a GM sends a distinguished name (DN) or hostname, then an authorization identity is used. Using an IP address as an identity will bypass authorization matching a DN or hostname and vice versa. To ensure that only GMs with a specific DN can connect (and no GMs using another identity can connect), you must specify deny any in the authorization address.

%GDOI-1-UNAUTHORIZED_IPADDR: Group getvpn received registration from
unauthorized ip address: 10.1.1.9

%GDOI-1-UNAUTHORIZED_IDENTITY: Group getvpn received registration from
unauthorized identity: Dist.name: hostname=GroupMember-1, ou=TEST

GET VPN software versions are of the form

major-version.minor-version.mini-version

where

• major-version defines compatibility for all GET VPN devices.
• minor-version defines compatibility for KS-to-KS (cooperative key server) associations and for GM-to-GM interoperability.
• mini-version tracks feature changes that have no compatibility impact.

For example, the base version (for all prior GET VPN features) is 1.0.1. Also, for example, the version that contains the GM removal feature and the policy replacement feature is 1.0.2, which means that these features are fully backward compatible with the base version (despite the introduction of behavior in these features for triggered rekeys).

GMs send the GET VPN software version to the KS in the vendor-ID payload during IKE phase 1 negotiation (which is defined in RFC 2408). KSs send the software version to other cooperative KSs in the version field of the ANN messages. Cooperative KSs also synchronize their lists of versions that each GM is using.

The GM removal feature and the policy replacement feature each provide a command that you run on the KS (or primary KS) to find devices in the group that do not support that feature.

Without the GM removal and policy replacement features, you would need to complete the following steps to remove unwanted GMs from a group:

1. Revoke the phase 1 credential (for example, the preshared key or one or more PKI certificates).
2. Clear the TEK and KEK database on the KS.
3. Clear the TEK and KEK database on each GM individually and force each GM to re-register.

The third step is time-consuming when a GET VPN group serves thousands of GMs. Also, clearing the entire group in a production network might cause a network disruption. This feature automates this process by introducing a command that you enter on the KS (or primary KS) to create a new set of TEK and KEK keys and propagate them to the GMs.

• GM Removal Compatibility with Other GET VPN Software Versions
• GM Removal with Transient IPsec SAs
• GM Removal with Immediate IPsec SA Deletion

This feature provides a new rekey triggering method to remove obsolete SAs and install new SAs.

• Inconsistencies Regarding Which TEK and KEK Policy Changes Will Trigger Rekeys
• Policy Replacement and Rekey Triggering Compatibility with Other GET VPN Software Versions

The GDOI MIB Support for GET VPN feature provides a command that you use on the KS (or primary KS) to check whether all the devices in the network are running versions that support the GDOI MIB. For more information, see the "Ensuring that GMs Are Running Software Versions That Support the GDOI MIB" section.

The GDOI MIB objects are organized into the following GDOI MIB tables. Following is the relationship (hierarchy) among the tables:

Figure 12

GDOI MIB Table Hierarchy

Following is a list of the MIB table objects (listed per group).

Group table objects:

• Group ID type--Specifies whether the group ID is an IP address, group number, hostname, and so on.

• Group ID length--Number of octets in the group ID value.

• Group ID value--Group number, IP address, or hostname.

• Group name--String value.

KS table objects:

• KS ID type

• KS ID length

• KS ID value

• Active KEK--SPI of the KEK that is currently used by the KS to encrypt the rekey message.

• Last rekey sequence number--Last rekey number that was sent by the KS to the group.

GM table:

• GM ID type

• GM ID length

• GM ID value

• Registered KS ID type--ID type of the KS to which the GM is registered.

• Registered KS ID length

• Registered KS ID value

• Active KEK--SPI of the KEK currently used by the GM to decrypt rekey messages.

• Last rekey seq number--Last rekey number received by the GM.

KS KEK table:

• KEK index

• KEK SPI

• KEK source ID information--Source ID type, ID length, and ID value.

• KEK source ID port--Port associated with the source ID.

• KEK destination ID information--Destination ID type, ID length, and ID value.

• KEK destination ID port--Port associated with the destination ID.

• IP protocol ID--UDP or TCP.

• Key management algorithm (unused).

• Encryption algorithm and key length (bits)

• SIG payload hash algorithm, SIG payload signature algorithm, and SIG payload key length (bits).

• Hash algorithm (will be reused from the IPsec MIB)

• Diffie-Hellman group

• KEK original lifetime (seconds)--Maximum time for which a KEK is valid.

• KEK remaining lifetime (seconds)

KS TEK selector table (corresponds to the ACLs that are configured as part of the IPsec SA in the GDOI group configuration on the KS):

• Tek selector index--An integer index.

• TEK source ID information--Source ID type, ID length, and ID value.

• TEK source ID port--Port associated with the source ID.

• TEK destination ID information--Destination ID type, ID length, and ID value.

• TEK destination ID port--Port associated with the destination ID.

• TEK Security protocol--GDOI_PROTO_IPSEC_ESP protocol ID value in the SA TEK payload (see RFC 3547).

KS TEK policy table:

• TEK policy index--An integer index.

• TEK SPI--Four octets

• Encapsulation mode--Tunnel or transport.

• Encryption algorithm and key length (bits)

• Integrity and authentication algorithm and key length (bits)

• TBAR window size (seconds)

• TEK original lifetime (seconds)--Maximum time for which a TEK is valid.

• TEK remaining lifetime (seconds)

• TEK Status--Inbound, outbound, or not in use.

GM KEK table:

• KEK index--An integer index.

• KEK SPI

• KEK source ID information--Source ID type, ID length , and ID value.

• KEK source ID port--Port associated with the source ID.

• KEK destination ID information--Destination ID type, ID length, and ID value.

• KEK destination ID port--Port associated with the destination ID.

• IP protocol ID--UDP or TCP.

• Key management algorithm (unused)

• Encryption algorithm and key length (bits)

• SIG payload hash algorithm, SIG payload signature algorithm, and SIG payload key length (bits)

• Hash algorithm

• Diffie-Hellman group

• KEK original lifetime (seconds)--Maximum time for which a KEK is valid.

• KEK remaining lifetime (seconds)

GM TEK selector table (corresponds to the ACLs that are downloaded to the GM as part of the TEK policy from the KS):

• TEK selector index--An integer index.

• TEK source ID information--Source ID type, ID length, and ID value.

• TEK source ID port--Port associated with the source ID.

• TEK destination ID information--Destination ID type, ID length , and ID value.

• TEK destination ID port--Port associated with the destination ID.

• TEK Security protocol--GDOI_PROTO_IPSEC_ESP protocol ID value in the SA TEK payload (see RFC 3547).

GM TEK policy table:

• TEK policy index--An integer index.

• TEK SPI --Four octets.

• Encapsulation mode--Tunnel or transport.

• Encryption algorithm and key length (bits)

• Integrity and authentication algorithm and key length (bits)

• TBAR window size (seconds)

• TEK original lifetime (seconds)--Maximum time for which a TEK is valid.

• TEK remaining lifetime (seconds)

• TEK Status--Inbound, outbound, or not in use.

The GDOI MIB supports the SNMP notifications in the following table. The GDOI MIB contains two kinds of notifications--those generated by the KS and those generated by each GM. You can enable any combination of notifications (or all notifications).

For more information, see the "Enabling GDOI MIB Notifications" section.

The GDOI MIB contains only objects that are listed in RFC 3547 and does not contain objects for functionality specific to the Cisco implementation of GDOI. This functionality includes:

• Cooperative key servers

• GM ACLs

• Receive-only SAs

• Fail-close/fail-open

• Crypto map objects

• Other Cisco GET VPN-specific features

Configure the group ID, server type, and SA type. (See the "Configuring the Group ID Server Type and SA Type" section.)

Remove the receive-only configuration on the key server so that the group members are now operating in bidirectional receive and send mode.

Before configuring the rekey authentication command, you must have configured the router to have an RSA key generated using the crypto key generate rsa command and general-keys and label keywords (for example, "crypto key generate rsa general-key label my keys").

1.    enable

2.    configure terminal

3.    crypto gdoi group [ipv6] group-name

4.   Enter one of the following commands:

5.    server local

6.    rekey transport unicast

7.    rekey lifetime seconds number-of-seconds

8.    rekey retransmit number-of-seconds number number-of-retransmissions

9.    rekey authentication mypubkey rsa key-name

10.    address ipv4 ipv4-address

1.    enable

2.    configure terminal

3.    crypto gdoi group [ipv6] group-name

4.   Enter one of the following commands:

5.    server local

6.    rekey address ipv4 {access-list-name | access-list-number}

7.    rekey lifetime seconds number-of-seconds

8.    rekey retransmit number-of-seconds number number-of-retransmissions

9.    rekey authentication {mypubkey | pubkey} rsa key-name

10.    exit

11.    exit

12.    access-list access-list-number {deny | permit} udp host source [operator[port]] host source [operator[port]]

13.    interface type slot/ port

14.   ip igmp join-group group-address [source source-address]

The access list defined in Step 4 is the same one that should be used to configure the SA. See the "Configuring the IPsec SA" section.

Configure the IPsec SA. See the "Configuring IPsec SA" section.

Replay should be configured. If replay is not configured, the default is counter mode.

Configure a crypto map. See the "Creating a Crypto Map Entry" section.

Apply the crypto map to an interface to which the traffic has to be encrypted. See the "Applying the Crypto Map to an Interface to Which the Traffic Must Be Encrypted" section.