Configuring Cisco TrustSec

Information about Cisco TrustSec

Cisco TrustSec provides security improvements to Cisco network devices based on the capability to strongly identify users, hosts, and network devices within a network. TrustSec provides topology-independent and scalable access controls by uniquely classifying data traffic for a particular role. TrustSec ensures data confidentiality and integrity by establishing trust among authenticated peers and encrypting links with those peers.

The key component of Cisco TrustSec is the Cisco Identity Services Engine (ISE). Cisco ISE can provision switches with TrustSec Identities and Security Group ACLs (SGACLs), though these may be configured manually on the switch.

Cisco TrustSec Features

The table below lists the Cisco TrustSec features to be eventually implemented on TrustSec-enabled Cisco switches. Successive general availability releases of Cisco TrustSec will expand the number of switches supported and the number of Cisco TrustSec features supported per switch.

Cisco TrustSec Feature Description
802.1AE Tagging (MACsec)

Protocol for IEEE 802.1AE-based wire-rate hop-to-hop Layer 2 encryption.

Between MACsec-capable devices, packets are encrypted on egress from the transmitting device, decrypted on ingress to the receiving device, and in the clear within the devices.

This feature is only available between TrustSec hardware-capable devices.

Endpoint Admission Control (EAC)

EAC is an authentication process for an endpoint user or a device connecting to the TrustSec domain. Usually EAC takes place at the access level switch. Successful authentication and authorization in the EAC process results in Security Group Tag assignment for the user or device. Currently EAC can be 802.1X, MAC Authentication Bypass (MAB), and Web Authentication Proxy (WebAuth).

Network Device Admission Control (NDAC)

NDAC is an authentication process where each network device in the TrustSec domain can verify the credentials and trustworthiness of its peer device. NDAC utilizes an authentication framework based on IEEE 802.1X port-based authentication and uses EAP-FAST as its EAP method. Successful authentication and authorization in NDAC process results in Security Association Protocol negotiation for IEEE 802.1AE encryption.

Security Group Access Control List (SGACL)

A Security Group Access Control List (SGACL) associates a Security Group Tag with a policy. The policy is enforced upon SGT-tagged traffic egressing the Cisco TrustSec domain.

In Cisco IOS XE Fuji 16.8.1, IPv6 support was enabled for SGACL enforcement and logging of VRF name was enabled in SGACL logs.

Cisco TrustSec SGACL High Availability

Cisco TrustSec Security Group access control lists (SGACLs) support the high availability functionality on switches that support the Cisco StackWise technology. Cisco StackWise technology provides stateful redundancy and allows the switch stack to enforce and process access control entries.

There is no Cisco TrustSec-specific configuration to enable this functionality.

Security Association Protocol (SAP)

After NDAC authentication, the Security Association Protocol (SAP) automatically negotiates keys and the cipher suite for subsequent MACSec link encryption between Cisco TrustSec peers. SAP is defined in IEEE 802.11i.

Security Group Tag (SGT)

An SGT is a 16-bit single label indicating the security classification of a source in the Cisco TrustSec domain. It is appended to an Ethernet frame or an IP packet.

In Cisco IOS XE Fuji 16.8.1, Layer 2 Inline Tagging is supported for IPv6 multicast traffic with unicast source IPv6 addresses.

SGT Exchange Protocol (SXP)

Security Group Tag Exchange Protocol (SXP). With SXP, devices that are not Cisco TrustSec-hardware-capable can receive SGT attributes for authenticated users and devices from the Cisco Identity Services Engine (ISE) or the Cisco Secure Access Control System (ACS). The devices can then forward a source IP-to-SGT binding to a Cisco TrustSec-hardware-capable device will tag the source traffic for SGACL enforcement.

When both ends of a link support 802.1AE MACsec, SAP negotiation occurs. An EAPOL-key exchange occurs between the supplicant and the authenticator to negotiate a cipher suite, exchange security parameters, and manage keys. Successful completion of these tasks results in the establishment of a security association (SA).

Depending on your software version and licensing and link hardware support, SAP negotiation can use one of these modes of operation:

  • Galois Counter Mode (GCM)—authentication and encryption

  • GCM authentication (GMAC)— GCM authentication, no encryption

  • No Encapsulation—no encapsulation (clear text)

  • Null—encapsulation, no authentication or encryption

Feature Information 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 1. Feature Information for Cisco TrustSec

Feature Name

Releases

Feature Information

Cisco TrustSec

Cisco IOS XE Everest 16.6.1

Cisco TrustSec provides security improvements to Cisco network devices based on the capability to strongly identify users, hosts, and network devices within a network. CiscoTrustSec provides topology-independent and scalable access controls by uniquely classifying data traffic for a particular role. Cisco TrustSec ensures data confidentiality and integrity by establishing trust among authenticated peers and encrypting links with those peers.

This feature was implemented on the following platforms

  • Cisco Catalyst 9500 Series Switches

Information about Cisco TrustSec SGT Caching


Note
This feature is not supported on the C9500-12Q, C9500-16X, C9500-24Q, C9500-40X models of the Cisco Catalyst 9500 Series Switches.

Security Group Tagging (SGT) caching feature creates a cache containing source IP address, VRF and SGT bindings when the switch receives new IP packets with a valid SGT. These IP-SGT bindings are used to add the CMD header back to the outgoing packet after DPI processing.

Deep Packet Inspection (DPI) services are required in data center deployments. In a network with non-Cisco products co-existing with Cisco products, it is possible that service layer is unaware of Cisco proprietary SGT. In such cases, SGT from the packet is stripped off and packets are forwarded to service layer for regular DPI processing. After DPI services are applied, SGT information needs to be added back to the packet so that to prevent loss of SGT information.

SGT caching is applicable in the following two scenarios:

  1. One arm services

    One-arm services - In this scenario, SGT is stripped off from incoming packets before sending them to services. When packets come back to the switch after the service is applied, SGT caching allows the switch to use SGT from the cache to re-apply the SGT tag. This allows applying SGACL enforcement locally to packets or to forward the packets to other CTS capable devices.

  2. Bump in the wire services

    In this scenario, packets go through the service and they do not come back to the redirecting switch. The SXP uses the cache created by SGT caching feature to export the learned bindings to the next hop switch. The post service switch or next hop switch re-applies the SGT on the packets.


Note

  • This feature works only on license, Network-Advantage with DNA-Advantage add on.

  • SGT caching feature is supported only in ingress direction and only on CTS trusted L3 physical ports. Also, it is supported only for IPv4 packets and not IPv6.

  • Packets sent to the CPU are rate limited and the ones denied by egress ACL/SGACL are not cached.

  • SGT-Caching entries can be scaled up to 64K(65,536).

Configure SGT Caching

  • Use this command to enable SGT caching on all interfaces in ingress direction. If SGT caching is already configured on any interface, this command is rejected.

    CLI1 – Config# [no] cts role-based sgt-caching

  • Use this command to enable SGT caching on an interface in ingress direction. SGT caching does not support interface level configuration in egress direction. If SGT caching is already configured globally, this command will have no effect.

    CLI2 – Config-if# [no] cts role-based sgt-caching ingress

View SGT Caching Bindings

You can use show cts role-based sgt-map all command to display the SGT caching bindings learnt by IOSd from different sources like cli, sxp, internal, caching etc.

Clearing Cached Entries

The cached entries can be cleared by:

  • Removing SGT caching configuration.

  • Interface shutdown (Ingress port where caching is enabled).

  • Default Timeout (not configurable) - a cached entry inactive for 300 seconds gets cleared.