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 6407.

   • 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.

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 reregisters.

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 reregister. 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

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 Figure 10 , 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.

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

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.

Before creating the GDOI group, you must first configure IKE and the IPsec transform set, and you must create an IPsec profile. For information about how to configure IKE and the IPsec transform set and to create an IPsec profile, see the “Related Documents” subsection of the “Additional References” section.

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.

To configure RSA keys that will be used to sign rekey messages, perform the following steps. Omit this subtask if rekey is not in use.

1.    enable


2.    configure terminal


3.    crypto key generate rsa general-keys label name-of-key

Router> enable

Router# configure terminal

Router(config)# crypto key generate rsa general-keys label mykeys

1.    enable


2.    configure terminal


3.    crypto gdoi group group-name


4.    Enter one of the following commands:

• identity number number
• identity address ipv4 address

5.    server local


6.    sa receive-only

Router> enable

Router# configure terminal

Router(config)# crypto gdoi group gdoigroupname 

Router(config-gdoi-group)# identity number 3333

Router(config-gdoi-group)# identity address ipv4 209.165.200.225

Router(config-gdoi-group)# server local

Router(config-local-server)# sa receive-only

This section includes the following optional tasks:

Rekey is used in the control plane by the key server to periodically refresh the policy and IPsec SAs of the group. On the group-member side, instead of fully re-registering when timers expire for any other reasons, refreshing the registration with a rekey is more efficient. The initial registration is always a unicast registration.

The key server can be configured to send rekeys in unicast or multicast mode. The rekey transport mode is determined by whether the key server can use IP multicast to distribute the rekeys. If multicast capability is not present within the network of the customer, the key server will have to be configured to send rekeys using unicast messages.

Additional options for rekey use the rekey authentication, rekey retransmit, and rekey address ipv4 commands. If unicast transport mode is configured, the source address command will have to be included to specify the source address of this unicast rekey message.

Multicast is the default transport type for rekey messages. The following bulleted items explain when to use rekey transport type multicast or unicast:

• If all members in a group are multicast capable, do not configure the rekey transport unicast command. The no rekey transport unicast command is not needed if the rekey transport type “unicast” was not configured previously under this group because multicast rekeys are on by default.

• If all members in a group are unicast, use the rekey transport unicast command.

• If you have mixed members in a group (that is, the majority are multicast, but a few are unicast), do not configure the rekey transport unicast command. The rekeys will be distributed using multicast to the majority of group members. The remainder of the group members that do not receive the multicast messages (unicast group members) will have to re-register to the key server when their policies expire. Mixed mode (that is, unicast and multicast rekey mode) is not supported.

If the no rekey transport unicast command is used, members in the GDOI group that are unable to receive the multicast rekey messages need to re-register with the key server to get the latest group policies. The re-registration forces the default transport type to multicast. If no transport type was configured previously, the multicast transport type will apply by default.

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.

Note

The recommended method to add or delete an entry in the Group Member ACL is to first create a copy of the existing Group Member ACL with a different name and then add or delete the entry in this new ACL, after which, you should replace the existing group member ACL under the GDOI crypto map with the newly created Group Member ACL.

To configure group member ACLs, perform this task (note that a group member access list can contain only deny statements).

1.    enable


2.    configure terminal


3.    access-list access-list-number deny ip host source host source


4.    access-list access-list-number permit ip source

Router> enable

Router# configure terminal

Router(config)# access-list 101 deny ip host 10.0.0.1 host 10.0.0.2

Router(config)# access-list 103 permit ip 209.165.200.225 0.255.255.255 10.20.0.0 0.255.255.255

1.    enable


2.    configure terminal


3.    crypto ipsec profile name


4.    set security-association lifetime seconds seconds

Router> enable

Router# configure terminal

Router(config)# crypto ipsec profile profile1

Router(ipsec-profile)# set security-association lifetime seconds 2700

1.    enable


2.    configure terminal


3.    crypto isakmp policy priority


4.    lifetime seconds

Router> enable

Router# configure terminal

Router(config)# crypto isakmp policy 1

Router(config-isakmp-policy)# lifetime 86400

If time-based antireplay is configured on the key server but the group member is not capable of supporting it, the GDOI-3-GM_NO_CRYPTO_ENGINE syslog message is logged to the group member. See the “Cisco Group Encrypted Transport VPN System Logging Messages” section for a list of system error messages.

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.

To configure the IPsec SA, perform the following steps.

1.    enable


2.    configure terminal


3.    crypto ipsec transform-set transform-set-name transform [transform2...transform4]


4.    crypto ipsec profile ipsec-profile-name


5.    set transform-set transform-set-name


6.    exit


7.    crypto gdoi group group-name


8.    Enter one of the following commands:

• identity number number
• identity address ipv4 address

9.    server local


10.    sa ipsec sequence-number


11.    profile ipsec-profile-name


12.    match address ipv4 {access-list-number | access-list-name}


13.    end

Router> enable

Router# configure terminal

Router(config)# crypto ipsec transform-set gdoi-trans esp-aes esp-sha-hmac

Router(config)# crypto ipsec profile profile1

Router(ipsec-profile)# set transform-set transformset1

Router(ipsec-profile)# exit

Router(config)# crypto gdoi group gdoigroupname 

Router(config-gdoi-group)# identity number 3333

Router(config-gdoi-group)# identity address ipv4 209.165.200.225

Router(config-gdoi-group)# server local

Router(gdoi-local-server)# sa ipsec 1

Router(gdoi-sa-ipsec)# profile gdoi-p

Router(gdoi-sa-ipsec)# match address ipv4 102

Router(gdoi-sa-ipsec)# end

1.    enable


2.    configure terminal


3.    crypto gdoi group group-name


4.    identity number policy-name


5.    server local


6.    address ip-address


7.    sa ipsec sequence-number


8.    profile ipsec-profile-name


9.    match address {ipv4 access-list-number | access-list-name}


10.    replay counter window-size seconds


11.    replay time window-size seconds

Router> enable

Router# configure terminal

Router(config)# crypto gdoi group gdoigroup1 

Router(config-gdoi-group)# identity number 1234

Router(config-gdoi-group)# server local

Router(config-server-local)# address 209.165.200.225

Router(config-server-local)# sa ipsec 1

Router(gdoi-sa-ipsec)# profile test1

Router(gdoi-sa-ipsec)# match address ipv4 101

Router(gdoi-sa-ipsec)# replay counter window-size 512

Router(gdoi-sa-ipsec)# replay time window-size 1

1.    enable


2.    configure terminal


3.    crypto gdoi group group-name


4.    identity name


5.    passive


6.    server address ipv4 {address | hostname}

Router> enable

Router# configure terminal

Router(config)# crypto gdoi group group1

Router(config-gdoi-group)# identity 2345

Router(config-gdoi-group)# passive

Router(config-gdoi-group)# server address ipv4 209.165.200.225

1.    enable


2.    clear crypto gdoi ks coop role

Router> enable

Router# clear crypto gdoi ks coop role

1.    enable


2.    configure terminal


3.    crypto gdoi group group-name


4.    Do one of the following:

• identity number number
• identity address ipv4 address

5.    server address ipv4 address

Router> enable

Router# configure terminal

Router(config)# crypto gdoi group gdoigroupone

Router(config-gdoi-group)# identity number 3333

Router(config-gdoi-group)# identity address ipv4 209.165.200.225

Router(config-gdoi-group)# server address ipv4 209.165.200.225

1.    enable


2.    configure terminal


3.    crypto map map-name seq-num gdoi


4.    set group group-name

Router> enable

Router# configure terminal

Router(config)# crypto map mymap 10 gdoi

Router(config-crypto-map)# set group group1

1.    enable


2.    configure terminal


3.    interface type slot / port


4.    crypto map map-name redundancy standby-group-name stateful

Router> enable

Router# configure terminal

Router(config)# interface gigabitethernet 0/0

Router(config-if)# crypto map map1

1.    enable


2.    configure terminal


3.    crypto map map-name gdoi fail-close


4.    match address {access-list-number | access-list-name}


5.    activate

Router> enable

Router# configure terminal

Router(config)# crypto map map1 gdoi fail-close

Router(crypto-map-fail-close)# match address 133

Router(crypto-map-fail-close)# activate

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.

To configure the ciphers and hash algorithms for KEK to be allowed by the GM, perform the following steps.

1.    enable


2.    configure terminal


3.    crypto gdoi group group-name


4.    Enter one of the following commands:

• identity number number
• identity address ipv4 address

5.    server address ipv4 address


6.    client rekey encryption cipher [... [cipher]]


7.    client rekey hash hash


8.    end

Router> enable

Router# configure terminal

Router(config)# crypto gdoi group gdoigroupone

Router(config-gdoi-group)# identity number 3333

Router(config-gdoi-group)# identity address ipv4 10.2.2.2

Router(config-gdoi-group)# server address ipv4 10.0.5.2

Router(config-gdoi-group)# client rekey encryption aes 128 aes 192 aes 256

Router(config-gdoi-group)# client rekey hash sha

Router(config-gdoi-group)# end

1.    enable


2.    configure terminal


3.    crypto ipsec transform-set transform-set-name transform [transform2...transform4]


4.    exit


5.    crypto gdoi group group-name


6.    client transform-sets transform-set-name1 [... [transform-set-name6]]


7.    end

Router> enable

Router# configure terminal

Router(config)# crypto ipsec transform-set g1 esp-aes 192 esp-sha-hmac

Router(cfg-crypto-trans)# exit

Router(config)# crypto gdoi group gdoigroupone

Router(config-gdoi-group)# client transform-sets g1

Router(config-gdoi-group)# end

event manager applet test1
 event snmp oid <new GDOI MIB object> .....
 action 2.0 track set 99 state up
 
track 99 stub-object
 delay up 60

1.    enable


2.    configure terminal


3.    crypto gdoi group group-name


4.    client status active-sa track tracking-number


5.    exit

Device> enable

Device# configure terminal

Device(config)# crypto gdoi group gdoigroupone

Device(config-gdoi-group)# client status active-sa track 99

Device(config-gdoi-group)# exit

1.    enable


2.    configure terminal


3.    crypto gdoi group group-name


4.    server local


5.    authorization address ipv4 { access-list-name | access-list-number }


6.    exit


7.    exit


8.    access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [time-range time-range-name] [fragments] [log [word] | log-input [word]]


9.    exit

Router> enable

Router# configure terminal

Router(config)# crypto gdoi group getvpn

Router(config-gdoi-group)# server local

Router(gdoi-local-server)# authorization address ipv4 50

Router(gdoi-local-server)# exit

Router(config-gdoi-group)# exit

Router(config)# access-list 50 permit ip 209.165.200.225 0.0.0.0 209.165.200.254 0.0.0.0

Router(config)# exit

1.    enable


2.    configure terminal


3.    crypto isakmp identity {address | dn | hostname}


4.    crypto pki trustpoint name


5.    subject-name [x.500-name]


6.    exit


7.    crypto gdoi group group-name


8.    server local


9.    authorization identity name


10.    exit


11.    exit


12.    crypto identity name


13.    dn name=string [, name=string]


14.    exit


15.    crypto isakmp identity {address | dn | hostname }


16.    crypto pki trustpoint name


17.    subject-name [x.500-name]


18.    end

Router> enable

Router# configure terminal

Router(config)# crypto isakmp identity dn

Router(config)# crypto pki trustpoint GETVPN

Router(ca-trustpoint)# subject-name OU=GETVPN

Router(ca-trustpoint)# exit

Router(config)# crypto gdoi group getvpn

Router(config-gdoi-group)# server local

Router(gdoi-local-server)# authorization identity GETVPN_FILTER

Router(gdoi-local-server)# exit

Router(config-gdoi-group)# exit

Router(config)# crypto identity GETVPN_FILTER

Router(config-crypto-identity)# dn ou=GETVPN

Router(config-crypto-identity)# exit

Router(config)# crypto isakmp identity dn

Router(config)# crypto pki trustpoint GETVPN

Router(ca-trustpoint)# subject-name ou=getvpn

Router(ca-trustpoint)# exit

1.    enable


2.    show crypto gdoi ks members

Router> enable

Router# show crypto gdoi ks members

1.    enable


2.    show crypto gdoi ks rekey


3.    show crypto gdoi [gm]

Device> enable

Device# show crypto gdoi ks rekey

For group diffint (handle: 2147483650) server 10.0.8.1 (handle: 2147483650):

# of teks : 1 Seq num : 0
KEK POLICY (transport type : Unicast)
spi : 0xA8110DE7CC8B0FB201F2A8BFAA0F2D90
management alg : disabled encrypt alg : 3DES 
crypto iv length : 8 key size : 24 
orig life(sec): 300 remaining life(sec): 296 <------- ticking down
sig hash algorithm : enabled sig key length : 94 
sig size : 64 
sig key name : mykeys

Device# show crypto gdoi 
GROUP INFORMATION

Group Name : diffint
Group Identity : 3333
Rekeys received : 0
IPSec SA Direction : Both

Group Server list : 10.0.8.1

Group member : 10.0.3.1 vrf: None
Version : 1.0.2 
Registration status : Registered
Registered with : 10.0.8.1
Re-registers in : 93 sec <-----------re-registration time for TEK or KEK
Succeeded registration: 1
Attempted registration: 1
Last rekey from : 0.0.0.0
Last rekey seq num : 0
Unicast rekey received: 0
Rekey ACKs sent : 0
Rekey Received : never
allowable rekey cipher: any
allowable rekey hash : any
allowable transformtag: any ESP

Rekeys cumulative
Total received : 0
After latest register : 0
Rekey Acks sents : 0

ACL Downloaded From KS 10.0.8.1:
access-list permit ip host 10.0.1.1 host 239.0.1.1
access-list permit ip host 10.0.100.2 host 238.0.1.1

KEK POLICY:
Rekey Transport Type : Unicast
Lifetime (secs) : 255	<-----------lifetime ticking
Encrypt Algorithm : 3DES
Key Size : 192 
Sig Hash Algorithm : HMAC_AUTH_SHA
Sig Key Length (bits) : 512