Cisco Group Encrypted Transport VPN Configuration Guide, Cisco IOS XE Release 3S
GET VPN GM Removal and Policy Trigger
Downloads: This chapterpdf (PDF - 1.37MB) The complete bookPDF (PDF - 3.76MB) | The complete bookePub (ePub - 678.0KB) | Feedback

GET VPN GM Removal and Policy Trigger

Contents

GET VPN GM Removal and Policy Trigger

The GET VPN GM Removal and Policy Trigger feature lets you easily remove unwanted group members (GMs) from the group encrypted transport (GET) VPN network, provides a rekey triggering method to install new security associations (SAs) and remove obsolete SAs, and lets you check whether devices are running versions of GET VPN software that support these capabilities.

Finding Feature Information

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 at the end of this module.

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

Information About GM Removal and Policy Trigger

GET VPN Software Versioning

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 key server (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 Internet Key Exchange ( IKE) phase 1 negotiation (which is defined in RFC 2408, Internet Security Association and Key Management Protocol [ISAKMP]). KSs send the software version to other cooperative KSs in the version field of the cooperative KS announcement (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.

GM Removal

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 traffic encryption key (TEK) and key encryption key (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. The GET VPN GM Removal and Policy Trigger 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

You should use the GET VPN GM Removal and Policy Trigger feature only after all devices in the GET VPN network are upgraded to GET VPN software versions that support this feature. Otherwise, secondary KSs or GMs running older software will ignore the GM removal message and continue to encrypt and decrypt traffic using the old SAs. This behavior causes network traffic disruption.

This feature provides a command that you use on the KS (or primary KS) to check whether all devices in the network are running versions that support GM removal. When the primary KS tries to remove GMs in a network containing devices that do not support GM removal, a warning message appears. For more information, see the “Ensuring That GMs Are Running Software Versions That Support GM Removal” section.

GM Removal with Transient IPsec SAs

The GET VPN GM Removal and Policy Trigger feature provides a command that you use on the KS (or primary KS) to trigger GM removal with transient IPsec SAs. This behavior shortens key lifetimes for all GMs and causes them to re-register before keys expire. During GM removal, no network disruption is expected, because traffic continues to be encrypted and decrypted using the transient IPsec SA until its lifetime expires. For more information, see the “Removing GMs with Transient IPsec SAs” section.

GM Removal with Immediate IPsec SA Deletion

The GET VPN GM Removal and Policy Trigger feature provides an optional keyword that you can use on the KS (or primary KS) to force GMs to delete old TEKs and KEKs immediately (without using transient SAs) and re-register. However, this behavior can cause a disruption to the data plane, so you should use this method only for important security reasons. For more information, see the “Removing GMs and Deleting IPsec SAs Immediately” section.

Policy Replacement and Rekey Triggering

The GET VPN GM Removal and Policy Trigger 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

Without this feature, there are inconsistencies regarding which TEK and KEK policy changes will trigger rekeys:

  • Multiple rekeys could be sent during the course of security policy updates.
  • Some policy changes (for example, transform set, profile, lifetime, and anti-replay) will install new SAs on GMs; however, the SAs from the existing policies remain active until their lifetimes expire.
  • Some policy changes (for example, a TEK’s access control entry/access control list (ACE/ACL) changes) will install new SAs on GMs and take effect immediately. However, the obsolete SAs are kept in each GM’s database (and can be displayed using the show crypto ipsec sa command until their lifetimes expire).

For example, if the KS changes the policy from Data Encryption Standard (DES) to Advanced Encryption Standard (AES), when the GM receives this triggered rekey, it installs the new SAs (for example, for AES) and shortens the lifetimes of the old SAs (for example, for DES). The GM continues to encrypt and decrypt traffic using the old SAs until their shortened lifetimes expire.

Following is the formula to calculate the shortened lifetime:

TEK_SLT = MIN(TEK_RLT, MAX(90s, MIN(5%(TEK_CLT), 3600s)))

where

  • TEK_SLT is the TEK shortened lifetime
  • TEK_RLT is the TEK remaining lifetime
  • TEK_CLT is the TEK configured lifetime

The following table summarizes the inconsistencies regarding rekeys.

Table 1 Rekey Behavior After Security Policy Changes

Policy Changes

Rekey Sent?

Rekey Behavior After Policy Changes

TEK: SA lifetime

No

The old SA remains active until its lifetime expires. The new lifetime will be effective after the next scheduled rekey. Even if you enter the clear crypto sa command, it will re-register and download the old SA with the old lifetime again.

TEK: IPSEC transform set

Yes

The SA of the old transform set remains active until its lifetime expires.

TEK: IPSEC profile

Yes

The SA of the old profile remains active until its lifetime expires.

TEK: Matching ACL

Yes

Outbound packet classification immediately uses the ACL. But the old SAs remain in the SA database (you can view them by using the show crypto ipsec sa command).

TEK: Enable replay counter

Yes

But the old SA without counter replay remains active until its lifetime expires.

TEK: Change replay counter value

No

The SA with a new replay counter is sent out in the next scheduled rekey.

TEK: Disable replay counter

Yes

But the old SA with counter replay enabled remains active until its lifetime expires.

TEK: Enable TBAR

Yes

But the old SA with time-based anti-replay (TBAR) disabled remains active until its lifetime expires.

TEK: Change TBAR window

No

The SA with a new TBAR window will be sent out in the next scheduled rekey.

TEK: Disable TBAR

Yes

But the old SA with TBAR enabled remains active until its lifetime expires.

TEK: Enable receive-only

Yes

Receive-only mode is activated right after the rekey.

TEK: Disable receive-only

Yes

Receive-only mode is deactivated right after the rekey.

KEK: SA lifetime behavior

No

The change is applied with the next rekey.

KEK: Change authentication key

Yes

The change is applied immediately.

KEK: Change crypto algorithm

Yes

The change is applied immediately.

This feature solves these problems by ensuring consistency. With this feature, GET VPN policy changes alone will no longer trigger a rekey. When you change the policy (and exit from global configuration mode), a syslog message appears on the primary KS indicating that the policy has changed and a rekey is needed. This feature provides a new command that you then enter on the KS (or primary KS) to send a rekey (that is based on the latest security policy in the running configuration).

This feature also provides an extra keyword to the new command to force a GM receiving the rekey to remove the old TEKs and KEK immediately and install the new TEKs and KEK. Therefore, the new policy takes effect immediately without waiting for old policy SAs to expire. (However, using this keyword could cause a temporary traffic discontinuity, because all GMs might not receive the rekey message at the same time.)

Policy Replacement and Rekey Triggering Compatibility with Other GET VPN Software Versions

You should use rekey triggering only after all devices in the GET VPN network are upgraded to GET VPN software versions that support this feature. For GMs running older versions that do not yet support the crypto gdoi ks command, the primary KS uses the software versioning feature to detect those versions and only triggers a rekey without sending instruction for policy replacement. Therefore, when a GM receives the rekey, it installs the new SAs but does not shorten the lifetimes of the old SAs. (This behavior is the same as the prior rekey method and ensures backward compatibility for devices that cannot support policy replacement.)

This 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 policy replacement. For more information, see the “Ensuring That GMs Are Running Software Versions That Support Policy Replacement” section.

How to Configure GET VPN GM Removal and Policy Trigger

Ensuring That GMs Are Running Software Versions That Support GM Removal

You should use the GET VPN GM Removal and Policy Trigger feature only after all devices in the GET VPN network are upgraded to GET VPN software versions that support this feature. Otherwise, secondary KSs or GMs that are running older software will ignore the GM removal message and continue to encrypt and decrypt traffic using the old SAs. This behavior causes network traffic disruption.

Perform this task on the KS (or primary KS) to ensure that all devices in the network support GM removal.

SUMMARY STEPS

    1.    enable

    2.    show crypto gdoi feature gm-removal

    3.    show crypto gdoi feature gm-removal | include No


DETAILED STEPS
     Command or ActionPurpose
    Step 1 enable


    Example:
    Device> enable
     

    Enables privileged EXEC mode.

    • Enter your password if prompted.
     
    Step 2 show crypto gdoi feature gm-removal


    Example:
    Device# show crypto gdoi feature gm-removal
     

    Displays the version of the GET VPN software running on each KS and GM in the GET VPN network and displays whether that device supports GM removal.

     
    Step 3 show crypto gdoi feature gm-removal | include No


    Example:
    Device# show crypto gdoi feature gm-removal | include No
     

    (Optional) Displays only those devices that do not support GM removal.

     

    Removing GMs with Transient IPsec SAs

    Perform this task on the KS (or primary KS) to trigger removal of GMs with transient IPsec SAs.

    SUMMARY STEPS

      1.    enable

      2.    clear crypto gdoi [group group-name] ks members


    DETAILED STEPS
       Command or ActionPurpose
      Step 1 enable


      Example:
      Device> enable
       

      Enables privileged EXEC mode.

      • Enter your password if prompted.
       
      Step 2 clear crypto gdoi [group group-name] ks members


      Example:
      Device# clear crypto gdoi ks members
       

      Creates a new set of TEK and KEK keys. This command also sends out GM removal messages to all GMs to clean up their old TEK and KEK databases.

       

      Examples

      A message appears on the KS as follows:

      Device# clear crypto gdoi ks members
      
      % This GM-Removal message will shorten all GMs' key lifetimes and cause them to 
      re-register before keys expiry.
      Are you sure you want to proceed? ? [yes/no]: yes
      Sending GM-Removal message to group GET...	

      After each GM receives the GM removal message, the following syslog message appears on each GM:

      *Jan 28 08:37:03.103: %GDOI-4-GM_RECV_DELETE: GM received delete-msg from KS in group GET. 
      TEKs lifetime are reduced and re-registration will start before SA expiry

      Each GM removes the KEK immediately and shortens the lifetimes of the old TEKs as follows:

      TEK_SLT = MIN(TEK_RLT, MAX(90s, MIN(5%(TEK_CLT), 3600s)))
      TEK_SLT: TEK shortened lifetime
      TEK_RLT: TEK Remaining LIfeTime
      TEK_CLT: TEK Configured LIfeTime

      Also, the GMs start re-registering to the KS to obtain the new TEKs and KEK according to the conventional re-registration timer and with jitter (random delay) applied. Jitter prevents all GMs from reregistering at the same time and overloading the key server CPU. Only GMs that pass the authentication based on the new credential installed on the KS will receive the new TEKs and KEK.

      GM removal should not cause a network disruption, because traffic continues to be encrypted and decrypted using the transient IPsec SA until its lifetime expires.

      If you try to use this command on the secondary KS, it is rejected as follows:

      Device# clear crypto gdoi ks members
      
      ERROR for group GET: can only execute this command on Primary KS

      Removing GMs and Deleting IPsec SAs Immediately

      Perform this task on the KS (or primary KS) to force GMs to delete old TEKs and KEKs immediately and re-register.

      SUMMARY STEPS

        1.    enable

        2.    clear crypto gdoi [group group-name] ks members now


      DETAILED STEPS
         Command or ActionPurpose
        Step 1 enable


        Example:
        Device> enable
         

        Enables privileged EXEC mode.

        • Enter your password if prompted.
         
        Step 2 clear crypto gdoi [group group-name] ks members now


        Example:
        Device# clear crypto gdoi ks members now
         

        Creates a new set of TEK and KEK keys. This command also sends out GM removal messages to all GMs to clean up their old TEK and KEK databases.

        Note   

        Using the now keyword can cause a network disruption to the data plane. Proceed with the GM removal only if a security concern is more important than a disruption.

         

        Examples

        A message appears on the KS as follows:

        Device# clear crypto gdoi ks members now
        
        % This GM-Removal immediate message will cleanup all GMs downloaded policies
        % This will cause all GMs to re-register.
        Are you sure you want to proceed? ? [yes/no]: yes
        Sending GM-Removal message to group GET...

        After you enter the above command, the KS sends a “remove now” message to each GM to trigger the following actions on each GM:

        1. Immediately cleans up its downloaded TEKs and KEK and its policy and returns to fail-open mode (unless fail-close mode is explicitly configured).
        2. Sets up a timer with a randomly chosen period within 2 percent of the configured TEK lifetime.
        3. When the timer in Step 2 expires, the GM starts re-registering to the KS to download the new TEKs and KEK.

        On each GM, the following syslog message is displayed to indicate that the GM will re-register in a random time period:

        *Jan 28 08:27:05.627: %GDOI-4-GM_RECV_DELETE_IMMEDIATE: GM receive REMOVAL-NOW in group 
        GET to cleanup downloaded policy now. Re-registration will start in a randomly chosen 
        period of 34 sec	

        If you try to remove GMs in a network containing devices that do not support GM removal, a warning message appears:

        Device# clear crypto gdoi ks members now
        
        % This GM-Removal immediate message will cleanup all GMs downloaded policies
        % This will cause all GMs to re-register.
        Are you sure you want to proceed? ? [yes/no]: yes
        WARNING for group GET: some devices cannot support GM-REMOVAL and can cause network 
        disruption. Please check 'show crypto gdoi feature'.
        Are you sure you want to proceed ? [yes/no]: no

        Ensuring that GMs Are Running Software Versions That Support Policy Replacement

        Perform this task on the KS (or primary KS) to check whether all devices in the network support policy replacement.

        SUMMARY STEPS

          1.    enable

          2.    show crypto gdoi feature policy-replace

          3.    show crypto gdoi feature policy-replace | include No


        DETAILED STEPS
           Command or ActionPurpose
          Step 1 enable


          Example:
          Device> enable
           

          Enables privileged EXEC mode.

          • Enter your password if prompted.
           
          Step 2 show crypto gdoi feature policy-replace


          Example:
          Device# show crypto gdoi feature policy-replace
           

          Displays the version of the GET VPN software running on each KS and GM in the GET VPN network and displays whether that device supports policy replacement.

           
          Step 3 show crypto gdoi feature policy-replace | include No


          Example:
          Device# show crypto gdoi feature policy-replace | include No
           

          (Optional) Finds only those devices that do not support policy replacement. For these devices, the primary KS sends only the triggered rekey without instructions for policy replacement. Therefore, when a GM receives the rekey, it installs the new SAs but does not shorten the lifetimes of the old SAs. This behavior is the same as the existing rekey method and ensures backward compatibility.

           

          Triggering a Rekey

          If you change the security policy (for example, from DES to AES) on the KS (or primary KS) and exit from global configuration mode, a syslog message appears on the KS indicating that the policy has changed and a rekey is needed. You enter the rekey triggering command as described below to send a rekey based on the latest policy in the running configuration.

          Perform this task on the KS (or primary KS) to trigger a rekey.

          SUMMARY STEPS

            1.    enable

            2.    crypto gdoi ks [group group-name] rekey [replace-now]


          DETAILED STEPS
             Command or ActionPurpose
            Step 1 enable


            Example:
            Device> enable
             

            Enables privileged EXEC mode.

            • Enter your password if prompted.
             
            Step 2 crypto gdoi ks [group group-name] rekey [replace-now]


            Example:
            Device# crypto gdoi ks group mygroup rekey
             

            Triggers a rekey on all GMs.

            The optional replace-now keyword immediately replaces the old TEKs and KEK on each GM to enable the new policy before the SAs expire.

            Note   

            Using the replace-now keyword could cause a temporary traffic discontinuity.

             

            Examples

            A message appears on the KS as follows:

            Device# crypto gdoi ks rekey
            Device#
            *Jan 28 09:17:44.363: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey with 
            policy-replace for group GET from address 10.0.8.1 with seq # 2

            After the policy change, when each GM receives this triggered rekey, it installs the new SAs (for example, for AES) and shortens the lifetimes of the old SAs (for example, for DES). Each GM continues to encrypt and decrypt traffic using the old SA until its shortened lifetime expires.

            If you try to trigger a rekey on the secondary KS, it rejects the command as shown below:

            Device# crypto gdoi ks rekey
            ERROR for group GET: This command must be executed on Pri-KS

            Configuration Examples for GET VPN GM Removal and Policy Trigger

            Example: Removing GMs from the GET VPN Network

            Ensuring That GMs Are Running Software Versions That Support GM Removal

            The following example shows how to use the GET VPN software versioning command on the KS (or primary KS) to check whether all the devices in the network support the GM removal feature:

            Device# show crypto gdoi feature gm-removal
            
            Group Name: GET                     
            	Key Server ID       Version   Feature Supported
            	   10.0.8.1         1.0.2          Yes
            	   10.0.9.1         1.0.2          Yes
            	   10.0.10.1        1.0.2          Yes
            	   10.0.11.1        1.0.2          Yes
            	Group Member ID     Version   Feature Supported
            	   10.0.0.2         1.0.2          Yes
            	   10.0.0.3         1.0.1          No
                  

            The following example shows how to find only those devices that do not support GM removal:

            Device# show crypto gdoi feature gm-removal | include No
            
            	      10.0.0.3          1.0.1          No
                  

            The above example shows that the GM with IP address 10.0.0.3 is running older software version 1.0.1 (which does not support GM removal) and should be upgraded.

            Removing GMs with Transient IPsec SAs

            The following example shows how to trigger GM removal with transient IPsec SAs. You use this command on the KS (or primary KS).

            Device# clear crypto gdoi ks members
            
            % This GM-Removal message will shorten all GMs' key lifetimes and cause them to 
            re-register before keys expiry.
            Are you sure you want to proceed? ? [yes/no]: yes
            Sending GM-Removal message to group GET...		 
                  

            Removing GMs and Deleting IPsec SAs Immediately

            The following example shows how to force GMs to delete old TEKs and KEKs immediately and re-register. You use this command on the KS (or primary KS).

            Device# clear crypto gdoi ks members now
            
            % This GM-Removal immediate message will cleanup all GMs downloaded policies
            % This will cause all GMs to re-register.
            Are you sure you want to proceed? ? [yes/no]: yes
            Sending GM-Removal message to group GET...
                  

            Example: Triggering Rekeys on Group Members

            Ensuring That GMs Are Running Software Versions That Support Rekey Triggering

            The following example shows how to use the GET VPN software versioning command on the KS (or primary KS) to display the version of software on devices in the GET VPN network and display whether they support rekey triggering after a policy change:

            Device# show crypto gdoi feature policy-replace
            	
            Key Server ID       Version  Feature Supported
            		10.0.8.1         1.0.2          Yes
            		10.0.9.1         1.0.2          Yes
            		10.0.10.1        1.0.2          Yes
            		10.0.11.1        1.0.2          Yes
            	Group Member ID     Version  Feature Supported
            		5.0.0.2          1.0.2          Yes
            		9.0.0.2          1.0.1          No
                  

            The following example shows how to find only those devices that do not support rekey triggering after policy replacement:

            Device# show crypto gdoi feature policy-replace  | include No
            
            	      9.0.0.2          1.0.1          No
                  

            For these devices, the primary KS sends only the triggered rekey without instructions for policy replacement. Therefore, when a GM receives the rekey, it installs the new SAs but does not shorten the lifetimes of the old SAs.

            Triggering a Rekey

            The following example shows how to trigger a rekey after you have performed a policy change. In this example, an IPsec policy change (for example, DES to AES) occurs with the profile gdoi-p2 command:

            Device# configure terminal
            Device(config)# crypto gdoi group GET
            Device(config-gdoi-group)# server local
            Device(gdoi-local-server)# sa ipsec 1
            Device(gdoi-sa-ipsec)# no profile gdoi-p
            Device(gdoi-sa-ipsec)# profile gdoi-p2
            Device(gdoi-sa-ipsec)# end
            Device#
            
            *Jan 28 09:15:15.527: %SYS-5-CONFIG_I: Configured from console by console
            *Jan 28 09:15:15.527: %GDOI-5-POLICY_CHANGE: GDOI group GET policy has changed. Use 
            'crypto gdoi ks rekey' to send a rekey, or the changes will be send in the next scheduled 
            rekey
            Device# crypto gdoi ks rekey
            Device#
            *Jan 28 09:17:44.363: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey with 
            policy-replace for group GET from address 10.0.8.1 with seq # 2
                  

            The following example shows the error message that appears if you try to trigger a rekey on the secondary KS:

            Device# crypto gdoi ks rekey
            
            ERROR for group GET: This command must be executed on Pri-KS

            Additional References for GET VPN GM Removal and Policy Trigger

            Related Documents

            Related Topic

            Document Title

            Cisco IOS commands

            Cisco IOS Master Command List, All Releases

            Cisco IOS security commands

            Cisco IOS Security Command References

            Technical Assistance

            Description

            Link

            The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

            http:/​/​www.cisco.com/​cisco/​web/​support/​index.html

            Feature Information for GET VPN GM Removal and Policy Trigger

            The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

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

            Table 2 Feature Information for GET VPN GM Removal and Policy Trigger

            Feature Name

            Releases

            Feature Information

            GET VPN GM Removal and Policy Trigger

            Cisco IOS XE Release 3.8S

            This feature provides a command that lets you efficiently eliminate unwanted GMs from the GET VPN network, provides a rekey triggering command to install new SAs and remove obsolete SAs, and provides commands that display whether devices on the network are running versions of GET VPN software that support these features.

            The following commands were introduced or modified: clear crypto gdoi, crypto gdoi ks, show crypto gdoi.