The Cisco TrustSec security architecture builds secure networks by establishing clouds of trusted network devices. Each device in a cloud is authenticated by its neighbors. Communication on the links between devices in the cloud is secured with a combination of encryption, message integrity checks, and data-path replay protection mechanisms. Cisco TrustSec uses the device and user identification information acquired during authentication for classifying, or coloring, the packets as they enter the network. This packet classification is maintained by tagging packets on ingress to the Cisco TrustSec network so that they can be properly identified for the purpose of applying security and other policy criteria along the data path. The tag, also called the security group tag (SGT), allows the network to enforce the access control policy by enabling the endpoint device to act upon the SGT to filter traffic.

Note	Ingress refers to entering the first Cisco TrustSec-capable device encountered by a packet on its path to the destination, and egress refers to leaving the last Cisco TrustSec-capable device on the path.

The Cisco TrustSec architecture consists of the following major components:

Authentication

Verifies the identity of each device before allowing it to join the Cisco TrustSec network

Authorization

Decides the level of access to the Cisco TrustSec network resources for a device based on its authenticated identity

Access Control

Applies access policies on a per-packet basis using the source tags on each packet

Secure communication

Provides encryption, integrity, and data-path replay protection for the packets that flow over each link in the Cisco TrustSec network

A Cisco TrustSec network has the following entities:

Supplicants

Devices that attempt to join a Cisco TrustSec network

Authenticators (AT)

Devices that are already part of a Cisco TrustSec network

Authorization Server

Servers that might provide authentication information, authorization information, or both

When the link between the supplicant and the AT comes up, the following sequence of events might occur:

Authentication (802.1X)

The authentication server authenticates the supplicant or the authentication is completed if you configure the devices to unconditionally authenticate each other.

Authorization

Each side of the link obtains policies, such as SGT and ACLs, that apply to the link. A supplicant might need to use the AT as a relay if it has no other Layer 3 route to the authentication server.

Security Association Protocol Negotiation

The EAPOL-Key exchange occurs between the supplicant and the AT to negotiate a cipher suite, exchange security parameter indexes (SPIs), and manage keys. Successful completion of all three tasks results in the establishment of a security association (SA).

The ports stay in the unauthorized state (blocking state) until the SA protocol negotiation is complete.

SA protocol negotiation can use any of the following modes of operation:

• Galois/Counter Mode (GCM) encryption

• GCM authentication (GMAC)

• No encapsulation (clear text)

• Encapsulation with no encryption or authentication

Based on the IEEE 802.1AE standard, Cisco TrustSec uses ESP-128 GCM and GMAC.

Cisco TrustSec authenticates a device before allowing it to join the network. Cisco TrustSec uses 802.1X authentication with Extensible Authentication Protocol Flexible Authentication through Secure Tunnel (EAP-FAST) as the Extensible Authentication Protocol (EAP) method to perform the authentication.

MACsec is an IEEE 802.1AE standards based Layer 2 hop-by-hop encryption that provides data confidentiality and integrity for media access independent protocols.

MACsec, provides MAC-layer encryption over wired networks by using out-of-band methods for encryption keying. The MACsec Key Agreement (MKA) Protocol provides the required session keys and manages the required encryption keys.

The 802.1AE encryption with MKA is supported on all types of links, that is, host facing links (links between network access devices and endpoint devices such as a PC or IP phone), or links connected to other switches or routers.

MACsec encrypts the entire data except for the Source and Destination MAC addresses of an Ethernet packet.

To provide MACsec services over the WAN or Metro Ethernet, service providers offer Layer 2 transparent services such as E-Line or E-LAN using various transport layer protocols such as Ethernet over Multiprotocol Label Switching (EoMPLS) and L2TPv3.

The packet body in an EAP-over-LAN (EAPOL) Protocol Data Unit (PDU) is referred to as a MACsec Key Agreement PDU (MKPDU). When no MKPDU is received from a participants after 3 hearbeats (each hearbeat is of 2 seconds), peers are deleted from the live peer list. For example, if a client disconnects, the participant on the switch continues to operate MKA until 3 heartbeats have elapsed after the last MKPDU is received from the client.

The SAP GCM cipher suite that is available in the releases earlier than Cisco Nexus Release 7.3(0)DX(1), supports 128-bit AES key generation, which is used to encrypt and decrypt data. M3 line card, support for which is introduced in Cisco Nexus Release 7.3(0)DX(1), has the capability to encrypt or decrypt data with 256-bit AES key with 64-bit sequence number.

CTS MACsec GCM 256-bit feature, which is an extension of the SAP GCM cipher suite, is introduced in the Cisco Nexus Release 7.3(0)DX(1) leverages the 256-bit AES key capability of the hardware.

Note	CTS MACsec GCM 256-bit feature is supported only in M3 line card. The GCM 256-bit encryption mode is supported in Cisco Nexus Release 7.3(0)DX(1) and later releases.

The M3 line card has the capability to support the 64-bit sequence number, which is the Extended Packet Sequence Number (XPN). The CTS Manager makes the driver to program the XPN bit in the hardware when GCM-256 encryption mode is enabled. As per XPN standard, the encryption input vector requires the following two fields:

• 32-bit Short Secure Channel Identifier (SSCI)

• 96-bit salt

These fields are constant values for the SAP protocol and are sent by the CTS manager to the driver to enable them to be programmed in the hardware.

Note	While performing ISSU from earlier releases to Cisco Nexus Release 7.3(0)DX(1) to restore the SAP session structure from the persistent storage service (PSS), the CTS manager ensures that the existing 128-bit AES key enabled interfaces are not affected.

Note

The newly introduced GCM encryption mode is not supported in the releases earlier to Cisco Nexus Release 7.3(0)DX(1). So, when the user migrates from Cisco Nexus Release 7.3(0)DX(1) to any releases earlier to it with the saved configuration, using copy running-config startup-config command where gcm-encrypt-256 keyword is saved in Cisco Nexus Release 7.3(0)DX(1), the unsaved configuration has to be prompted to be removed before migrating to the earlier releases.

This section provides information about the configuration tasks for Cisco TrustSec authentication, authorization, and data path security.

The following are the configuration models:

• Cisco TrustSec configuration on port-channel interfaces:

  Any Cisco TrustSec configuration performed on a port-channel interface is inherited by all its member interfaces.

• Cisco TrustSec configuration on port-channel member interfaces:

  Port-channel compatibility parameters are not allowed to be configured on port-channel member interfaces.

  Other Cisco TrustSec configurations, such as MACSec configuration, which would not result in incompatibility, are allowed on port-channel member interfaces.

• Adding new members to a port-channel:

  • Using the channel-group command:

    Addition of new members is accepted, if the configuration on the port-channel and that on all members are compatible; if not, the addition is rejected.

    Note	If Cisco TrustSec is not configured on the port-channel and the Cisco TrustSec configuration on the members being added is compatible, the addition is accepted and the port-channel inherits the compatibility parameters from the member interfaces.

  • Using the channel-group force command:

    If the interfaces being added are capable of supporting the port-channel configuration, they inherit the compatibility parameters from the port-channel and the addition is accepted. However, if some interfaces being added are not capable of supporting the port-channel configuration, the addition is rejected.

The following are the updates to the user interfaces after Cisco NX-OS Release 7.2(0)D1(1):

• When the channel group or channel-group force command is issued, if there is any incompatibility in the Cisco TrustSec configuration, an error message is displayed to the user pointing to the incompatible configuration.

• The show run and show start command displays the Cisco TrustSec configuration on port-channel interfaces as well along with that on physical ethernet interfaces.

• The show cts role-based sgt-map command displays the port-sgt learnt mappings that was learnt on the port-channel interface, if applicable.

When In-Service Software Upgrades (ISSU) is performed from a lower version that does not support this feature, as soon as the ISSU is completed, all port-channels inherit the compatibility parameters from their first configured member interface. A warning level syslog is generated for port-channels on which the configuration incompatibility is detected.