GET VPN Support of IPsec Inline Tagging for Cisco TrustSec

The Cisco TrustSec (CTS) architecture secures networks by establishing domains of trusted network devices. Once a network device authenticates with the network, the communication on the links between devices in the cloud is secured with a combination of encryption, message integrity checks, and replay protection mechanisms.

CTS uses the user and device identification information acquired during the authentication phase to classify packets as they enter the network. CTS maintains classification of each packet or frame by tagging it with a security group tag (SGT) on ingress to the network so that it can be identified for applying security and other policy criteria along the data path. The tags allow network intermediaries such as switches and firewalls to enforce access control policy based on the classification.

The GET VPN Support of IPsec Inline Tagging for Cisco TrustSec feature uses GET VPN inline tagging to carry the SGT information across the private WAN.

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.

Prerequisites for GET VPN Support of IPsec Inline Tagging for Cisco TrustSec

All key servers (KSs) and group members (GMs) on which you want to enable this feature must be running GET VPN software version 1.0.5 or higher. You should use this feature only after all devices in the GET VPN network are upgraded to GET VPN software versions that support it.

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 IPsec inline tagging for Cisco TrustSec. For more information, see the "Ensuring That GMs Are Running Software Versions That Support IPsec Inline Tagging for Cisco TrustSec" section.

Restrictions for GET VPN Support of IPsec Inline Tagging for Cisco TrustSec

This feature does not support IPv6 traffic.

This feature does not support transport mode on the Cisco ASR 1000 Series Aggregation Services Routers or on the Cisco VPN Internal Service Module for Cisco Integrated Services Routers Generation 2 (ISR G2).

Information About GET VPN Support of IPsec Inline Tagging for Cisco TrustSec

Group Member Registration of Security Group Tagging Capability

When a KS receives a security association (SA) registration request from a group member (GM) or receives a connection establishment request from a cooperative KS, it checks whether any group SA has SGT inline tagging enabled. If so, all GMs and cooperative KSs must register using GET VPN software version 1.0.5 or higher to be accepted. Otherwise, the registration request or establishment request is rejected, and the KS generates a syslog message to notify the network administrator.

Creation of SAs with Security Group Tagging Enabled

After you enable GET VPN support of IPsec inline tagging (using the tag cts sgt command) in a group SA and then trigger a rekey (using the crypto gdoi ks rekey command), the KS checks for GMs and cooperative KSs in the group not using a compatible software version. If found, a warning message appears:

Packet Overhead and Fragmentation When Using Security Group Tagging

If a packet is fragmented before GDOI encryption, each fragment is inline tagged with SGT information accordingly. If packet is fragmented after GDOI encryption, only the first fragment is inline tagged with SGT information.

You can use two methods to handle
fragmentation. The first method is to use the ip mtu command on
the interface that is handling encryption to accommodate the extra bytes used to carry the SGT information via Cisco metadata. The second method is
to use the ip tcp adjst-mss 1352 command on the GM's LAN
interface. This command ensures that the resulting IP packet on the
LAN segment is less than 1392 bytes, thereby providing 108 bytes for
any overhead plus the Cisco metadata to carry the SGTs.

After enabling IPsec inline tagging, you must trigger a rekey. For more information, see the "Triggering a Rekey" section.

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.cryptogdoiks [group
group-name]
rekey [replace-now]

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2

cryptogdoiks [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.

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

Verifying and Troubleshooting GET VPN Support of IPsec Inline Tagging for Cisco TrustSec

To view the configuration that is running on a GM, use the
show running-config command.

To display the number of packets that are tagged with SGTs, enter the following command.

The following example shows how to configure two groups: A group with GMs that are upgraded to GET VPN version 1.0.5 or higher (and therefore supports CTS SGT inline tagging) and a group with GMs that are not yet upgraded. The upgraded GMs will register to group number 1111 (a lower crypto map sequence number) and with group number 2222 (a higher crypto-map sequence number). Non-upgraded GMs will register only to group number 2222.

This example configures SGT tagging for traffic between two sites. The permit ip commands add access control entries (ACEs) to the access control list (ACL) that permit communication between the two sites:

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:

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:

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

Note

If time-based antireplay (TBAR) is set, the key server periodically
sends a rekey to the group members every 2 hours (7200 sec). In the following
example, even though the lifetime is set to 8 hours (28800 sec), the rekey
timer is set to 2 hours.

Standards and RFCs

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.

Feature Information for GET VPN Support of IPsec Inline Tagging for Cisco TrustSec

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 3 Feature Information for GET VPN Support of IPsec Inline Tagging for Cisco TrustSec

Feature Name

Releases

Feature Information

GET VPN Support of IPsec Inline Tagging for Cisco TrustSec

Cisco IOS XE Release 3.9S

The Cisco TrustSec (CTS) architecture secures networks by establishing domains of trusted network devices. Once a network device authenticates with the network, the communication on the links between devices in the cloud is secured with a combination of encryption, message integrity checks, and replay protection mechanisms.

CTS uses the user and device identification information acquired during the authentication phase to classify packets as they enter the network. CTS maintains classification of each packet or frame by tagging it with a security group tag (SGT) on ingress to the network so that it can be identified for applying security and other policy criteria along the data path. The tags allow network intermediaries such as switches and firewalls to enforce access control policy based on the classification.

The GET VPN Support of IPsec Inline Tagging for Cisco TrustSec feature uses GET VPN inline tagging to carry the SGT information across the private WAN.

The following commands were introduced or modified: show crypto gdoi, show crypto ipsec sa, tag cts sgt.