4.2 Cisco TrustSec, Security Group Tags (SGT), SXP & MACsec

4.2 Cisco TrustSec, Security Group Tags (SGT) & SXP Protocol

Traditional enterprise security segmentation relies on IP-based Access Control Lists (ACLs) applied at router and firewall interfaces. However, in modern mobile and cloud-connected campus environments, IP-based filtering exhibits severe operational limitations: IP addresses change frequently as users roam, ACLs expand to thousands of unmanageable lines, and subnets become tightly coupled to physical topology.

Cisco TrustSec solves these scalability challenges by introducing Role-Based Access Control (RBAC). Rather than inspecting source and destination IP addresses, TrustSec assigns a cryptographic or logical Security Group Tag (SGT) to users and endpoints upon authentication, enforcing policy independently of underlying IP addressing and physical topology.

+-----------------------------------------------------------------------------------+
|                         CISCO TRUSTSEC 3-PILLAR LIFECYCLE                         |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  [1. CLASSIFICATION]              [2. TAGGING / TRANSPORT]    [3. ENFORCEMENT]    |
|  (Ingress Edge)                   (Network Fabric)            (Egress Edge)       |
|  - 802.1X / MAB via Cisco ISE     - Inline Tagging:           - Look up Dest SGT  |
|  - RADIUS Access-Accept with SGT    * VXLAN-GPO (16-bit ID)   - Read Src SGT Tag  |
|  - Static IP/Subnet/VLAN mapping    * CMD / 802.1AE EtherType - Evaluate Matrix   |
|  - Assigns Source SGT (e.g. SGT 4)- Control Plane:            - Apply SGACL       |
|                                     * SXP (TCP Port 64999)      in Hardware TCAM  |
+-----------------------------------------------------------------------------------+

---

1. Cisco TrustSec Architecture & Plane Separation

Cisco TrustSec organizes security enforcement into three discrete, decoupled phases:

Phase 1: Classification (Ingress)

Classification occurs at the edge of the network when an endpoint first connects. The ingress switch determines the identity and authorization of the device and assigns a Source Security Group Tag (SGT).

Phase 2: Tagging / Propagation (Transport)

Once assigned, the SGT must be communicated across the network infrastructure to the device responsible for policy enforcement. SGT transport occurs either:

• In-Band (Inline Tagging): Embedding the SGT into the packet header on every hop (e.g., VXLAN-GPO Group Policy ID or Cisco Meta Data [CMD] / 802.1AE).
• Out-of-Band (SXP): Propagating IP-to-SGT binding tables over a dedicated control protocol (SGT Exchange Protocol - SXP) when intermediate transit switches do not support inline tagging.

Phase 3: Enforcement (Egress)

Policy enforcement occurs at the egress network node immediately before the packet is delivered to the destination endpoint. The egress switch knows the destination host's SGT (from its local endpoint table) and extracts the source SGT from the incoming packet header. It then evaluates the Scalable Group ACL (SGACL) matrix in hardware TCAM to permit or deny the flow.

+-----------------------------------------------------------------------------------+
|              WHY ENFORCEMENT OCCURS AT EGRESS (SCALE ADVANTAGE)                   |
+-----------------------------------------------------------------------------------+
|  INGRESS ENFORCEMENT (Not Scalable):                                              |
|  - Ingress switch must know the SGT of EVERY destination host in the global enterprise|
|  - Requires massive TCAM tables on every access switch and high lookup latency.   |
|                                                                                   |
|  EGRESS ENFORCEMENT (TrustSec Architectural Model):                               |
|  - Ingress switch only needs to know the LOCAL source host's SGT (Classify & Tag).|
|  - Egress switch only needs the SGACL rules for LOCAL destination hosts attached  |
|    to its own ports. Massive reduction in TCAM memory consumption!                |
+-----------------------------------------------------------------------------------+

2. Security Group Tags (SGT) & Segmentation Hierarchy

The SGT Format

A Security Group Tag (SGT) is a 16-bit integer value ranging from 1 to 65,535:

• SGT 0: Reserved to denote an Unknown / Untagged endpoint.
• SGT 1: Default SGT for unclassified traffic.
• SGT 2: Reserved for TrustSec-capable network devices (Control Plane communication).
• SGTs 3–65,535: Dynamically or statically assigned to users, endpoints, servers, and IoT devices based on role.

Macro-Segmentation vs. Micro-Segmentation

TrustSec delivers layered, defense-in-depth segmentation:

+-----------------------------------------------------------------------------------+
|                    MACRO-SEGMENTATION VS. MICRO-SEGMENTATION                      |
+-----------------------------------------------------------------------------------+
|  MACRO-SEGMENTATION (Virtual Networks / VRFs)                                     |
|  +-----------------------------------------------------------------------------+  |
|  |  CORP VRF (VNI 4099)                     |  GUEST VRF (VNI 4100)            |  |
|  |  +-------------------------------------+ |  +-----------------------------+ |  |
|  |  | MICRO-SEGMENTATION (SGTs & SGACLs)  | |  | Micro-Segmentation:         | |  |
|  |  | - Employees   (SGT 4)               | |  | - Guest Users (SGT 99)      | |  |
|  |  | - Contractors (SGT 5)               | |  |                             | |  |
|  |  | - HR Servers  (SGT 10)              | |  |                             | |  |
|  |  | [SGACL: SGT 5 -> SGT 10: DENY]      | |  |                             | |  |
|  |  +-------------------------------------+ |  +-----------------------------+ |  |
|  +-----------------------------------------------------------------------------+  |
|  * Inter-VRF traffic is completely blocked unless routed via an external Firewall |  |
+-----------------------------------------------------------------------------------+

SGT Classification Methods

Endpoints can be classified and mapped to SGTs using dynamic or static mechanisms:

1. Dynamic SGT Classification (Recommended):

   • 802.1X / MAB / WebAuth: When an endpoint authenticates through Cisco ISE, ISE evaluates authorization policies (user group, device OS, posture compliance, location) and returns a RADIUS Access-Accept message with the Cisco vendor-specific attribute (Cisco AV-Pair):

     cisco-av-pair = cts:security-group-tag=0004-00
     

   • The switch assigns SGT 4 to the ingress physical port or authenticated MAC session dynamically.

2. Static SGT Classification:

   • IP-to-SGT Mapping: Statically binds a single host IP address to an SGT (cts role-based ip-to-sgt 10.2.2.100 tag 10). Typically used for legacy data center servers.
   • Subnet-to-SGT Mapping: Binds an entire IP subnet CIDR block to an SGT (cts role-based ip-to-sgt 10.5.0.0/16 tag 20).
   • VLAN-to-SGT Mapping: Assigns an SGT to all unauthenticated packets arriving on a specific VLAN (cts role-based vlan-to-sgt 100 tag 30). Useful during brownfield migrations.
   • Port/Interface-to-SGT Mapping: Statically assigns an SGT to all traffic entering a physical switch port (cts role-based sgt 50). Ideal for dedicated server or WAN uplinks.

3. Scalable Group ACLs (SGACLs) & The Policy Matrix

Traditional ACLs evaluate standard 5-tuple packet headers (Source IP, Destination IP, Protocol, Source Port, Destination Port). A policy matrix between $M$ source subnets and $N$ destination subnets requires $M \times N$ separate ACL lines, causing rule explosion.

In contrast, Scalable Group ACLs (SGACLs) evaluate access permissions based on Source SGT and Destination SGT.

The TrustSec Policy Matrix

The security matrix is a 2-dimensional grid where rows represent Source SGTs (Initiators) and columns represent Destination SGTs (Targets). Each cell at the intersection contains an SGACL policy rule.

+-----------------------------------------------------------------------------------+
|                         TRUSTSEC SECURITY POLICY MATRIX                           |
+-----------------------+--------------------+------------------+-------------------+
| Source SGT \ Dest SGT | SGT 4 (Employees)  | SGT 5 (Contract) | SGT 10 (HR Serv)  |
+-----------------------+--------------------+------------------+-------------------+
| SGT 4 (Employees)     | PERMIT ALL         | PERMIT (Web/ICMP)| PERMIT (HTTPS/SSH)|
| SGT 5 (Contractors)   | DENY ALL           | PERMIT ALL       | DENY ALL          |
| SGT 10 (HR Servers)   | PERMIT (Return)    | DENY ALL         | PERMIT ALL        |
+-----------------------+--------------------+------------------+-------------------+

SGACL Rule Definition Example

! Define an SGACL permitting HTTPS (TCP 443) and SSH (TCP 22) while denying all other IP traffic
Switch(config)# ip access-list role-based SGACL_HR_ACCESS
Switch(config-ext-nacl)# permit tcp dst eq 443
Switch(config-ext-nacl)# permit tcp dst eq 22
Switch(config-ext-nacl)# deny ip

! Apply the SGACL to the matrix cell: Source SGT 4 (Employees) -> Destination SGT 10 (HR Servers)
Switch(config)# cts role-based permissions from 4 to 10 SGACL_HR_ACCESS

Matrix Enforcement Actions

• Permit: All traffic between the SGT pair is allowed.
• Deny: All traffic between the SGT pair is dropped at the egress switch ASIC.
• SGACL Filter: Traffic is evaluated against specific Layer 4 protocol and port rules.
• Default Action: If no specific cell rule is provisioned, the switch falls back to the globally configured TrustSec default action (typically Default Permit during initial rollout, transitioning to Default Deny in mature zero-trust environments).

4. SGT Transport: Inline Tagging vs. SGT Exchange Protocol (SXP)

To enforce SGACLs at the egress edge, the egress switch must know the Source SGT of every arriving packet. There are two primary mechanisms to convey SGT information across the network:

+-----------------------------------------------------------------------------------+
|                     INLINE SGT TAGGING VS. SXP PROTOCOL                           |
+-----------------------+----------------------------------+------------------------+
| Feature               | Inline SGT Tagging               | SXP (IETF Draft)       |
+-----------------------+----------------------------------+------------------------+
| Transport Mode        | In-Band (Inside Packet Header)   | Out-of-Band (TCP 64999)|
| Protocol / Framing    | VXLAN-GPO (SD-Access) or CMD/MACsec| TCP Control Session  |
| Hardware Dependency   | Requires TrustSec/ASIC support   | Works over ANY IP net  |
| Intermediate Switches | Must support & preserve tags     | Completely unaware     |
| Scalability           | Infinite (Line-rate in ASICs)    | Bound by TCP/BGP table |
| Primary Deployment    | Greenfield SD-Access / Catalyst  | Brownfield & Firewalls |
+-----------------------+----------------------------------+------------------------+

1. Inline SGT Tagging

• SD-Access Fabrics: The 16-bit SGT is embedded directly inside the Group Policy ID field of the VXLAN-GPO header (UDP 4789).
• Classical Ethernet Campuses: SGT is carried in the Cisco Meta Data (CMD) field inserted into the Layer 2 Ethernet frame (EtherType 0x8909 or IEEE 802.1AE MACsec WAN tag). Every intermediate switch along the path must support TrustSec hardware tagging to retain and forward the CMD header.

2. SGT Exchange Protocol (SXP - draft-smith-kandula-sxp)

When intermediate routers, firewalls, MPLS WAN providers, or legacy switches do not support inline TrustSec hardware tagging, CMD headers are stripped or dropped.

SXP bridges this gap by creating an out-of-band control connection over TCP port 64999. SXP propagates IP-to-SGT binding tables from authentication points (such as Cisco ISE or access switches) directly to egress enforcement devices (such as data center firewalls or core switches).

5. SGT Exchange Protocol (SXP) Deep Dive

SXP is a Cisco-originated control protocol, documented in the IETF Internet-Draft draft-smith-kandula-sxp ("Scalable-Group Tag eXchange Protocol"), specifically engineered to transport IP-to-SGT mappings across non-TrustSec networks. Note that SXP has never been published as an RFC — it remains an expired informational draft, and the authoritative specification for production behaviour is the Cisco TrustSec configuration guide for your platform. Treat any exam-prep source that cites an RFC number for SXP as unreliable.

+-----------------------------------------------------------------------------------+
|                         SXP PEERING ROLES & ARCHITECTURE                          |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  +------------------------+      SXP over TCP 64999     +----------------------+  |
|  |       SXP SPEAKER      |============================>|     SXP LISTENER     |  |
|  | - Learns IP-SGT binding|   (MD5 Auth Protected)      | - Receives bindings  |  |
|  |   via 802.1X / ISE     |                             | - Programs TCAM      |  |
|  | - Advertises bindings  |                             | - Enforces SGACLs    |  |
|  +------------------------+                             +----------------------+  |
|         (Access Switch)                                    (Data Center Firewall) |
+-----------------------------------------------------------------------------------+

SXP Peering Roles

1. SXP Speaker: The device that learns IP-to-SGT bindings (e.g., via local 802.1X authentications, Cisco ISE pxGrid, or static configurations) and transmits them across the SXP connection to its configured peer.
2. SXP Listener: The device that receives IP-to-SGT binding updates from an SXP speaker and installs them into its local IP-to-SGT database and hardware forwarding tables for SGACL enforcement.
3. Both (Bi-directional): A device configured to act simultaneously as both an SXP Speaker and an SXP Listener with its peer, exchanging local bindings in both directions.

SXP Protocol Versions

SXP Connection Mechanics & Timers

• Transport: TCP Port 64999.
• Authentication: Protected via TCP MD5 shared secret passwords configured on both peers.
• Keepalive & Hold Timers:
  • Hold Time: Default 120 seconds (negotiated during connection setup; defines how long a listener waits before tearing down bindings if keepalives cease).
  • Keepalive Time: Default 30 seconds (or $1/3$ of the negotiated hold time).

6. Cisco IOS-XE CLI Configuration & Verification for TrustSec and SXP

1. Configuring TrustSec SXP Peering

! Enable SXP globally on the switch
Switch(config)# cts sxp enable

! Configure switch source IP for SXP connections
Switch(config)# cts sxp default source-ip 192.168.100.1

! Configure an SXP connection to Data Center Firewall (Listener) with MD5 password
Switch(config)# cts sxp connection peer 192.168.200.10 password CiscoPass123 mode speaker

2. Configuring Static IP-to-SGT Mappings

! Map a specific server IP to SGT 10 (Finance-Servers)
Switch(config)# cts role-based ip-to-sgt 10.2.2.100 tag 10

! Map an entire subnet to SGT 20 (Engineering)
Switch(config)# cts role-based ip-to-sgt 10.5.0.0/16 tag 20

3. Verifying SXP Connections and Binding Tables

! Verify SXP peering connection status
Switch# show cts sxp connections
Peer IP          Source IP        Mode     Version  Status    HoldTime (sec)
----------------------------------------------------------------------------
192.168.200.10   192.168.100.1    Speaker  4        ON        120

! Verify learned IP-to-SGT binding database
Switch# show cts sxp sgt-map
IPv4 SGT-to-IP Binding Table
============================
IP Address           SGT      Source    Instance ID
----------------------------------------------------
10.1.1.50/32         4        LOCAL     CORP
10.2.2.100/32        10       SXP       CORP
10.5.0.0/16          20       CONFIG    CORP

! Verify TrustSec Role-Based Permissions (SGACL Matrix)
Switch# show cts role-based permissions
IPv4 Role-based permissions from group 4:Employees to group 10:Finance-Servers:
    SGACL_HR_ACCESS (Configured / Active)

! Verify hardware TCAM enforcement counters for SGACL drops and permits
Switch# show cts role-based counters
Role-based IPv4 counters
From    To      Permit-Packets  Deny-Packets
--------------------------------------------
4       10      42890           142
5       10      0               5912
*       *       1204890         0

7. IEEE 802.1AE MACsec: Link-Layer Encryption for TrustSec

ENCOR v1.2 topic 5.4.d names "TrustSec and MACsec" together as one component of network security design. They are complementary, not alternatives: TrustSec answers who may talk to whom, MACsec answers can anyone read it on the wire.

7.1 What MACsec Actually Is

MACsec is IEEE 802.1AE, a Layer 2 encryption standard that protects an Ethernet frame hop by hop. Each device decrypts the frame on ingress, processes it normally, and re-encrypts it on egress toward the next MACsec peer. That single property drives every design decision:

Because each hop decrypts, the switch in the middle can still read the CMD header (EtherType 0x8909) that carries the SGT and can therefore enforce an SGACL. An IPsec tunnel would hide that tag from every transit device. This is exactly why Cisco pairs MACsec with TrustSec rather than substituting one for the other.

7.2 The MACsec Frame Format

+---------+---------+-----------------+---------+-----------------+-------+-----+
|  DMAC   |  SMAC   |  SecTAG         | 802.1Q  | CMD (SGT)       | ICV   | CRC |
|         |         |  EtherType      |   +     |   +             | 16 B  |     |
|         |         |  0x88E5         | Payload |  Payload        |       |     |
+---------+---------+-----------------+---------+-----------------+-------+-----+
                    |<-- 8 or 16 B -->|<---- encrypted region --->|
                    |<--------- integrity-protected ------------->|

• SecTAG — 8 bytes, or 16 bytes when the optional 8-byte Secure Channel Identifier (SCI) is carried. It holds MACsec EtherType 0x88E5, the TCI/AN flags, the Short Length field, and the Packet Number (PN) used for replay protection.
• ICV — a 16-byte Integrity Check Value appended to every frame.
• Total overhead — Cisco's guidance is to budget 32 bytes and raise the interface MTU accordingly. The encryption itself happens below the IP layer so the endpoints are unaffected, but an intermediate service provider router will drop the enlarged frame if its MTU was not adjusted. This is the classic "MACsec came up and large transfers broke" symptom, and it is the same PMTU failure mode covered in Section 14.1.

7.3 Key Agreement: MKA vs. Cisco SAP

Encryption is worthless without a way to agree on keys. There are two mechanisms, and confusing them is a reliable exam trap.

Under MKA one participant is elected Key Server (lowest key-server priority wins) and it generates and distributes the Secure Association Key (SAK) to its peers, rekeying periodically.

Downlink vs. uplink MACsec: downlink MACsec protects the switch-to-host link and is normally keyed by MKA using the MSK produced by an 802.1X EAP-TLS session (Section 16.5). Uplink MACsec protects switch-to-switch links and is keyed either by MKA with a pre-shared CAK/CKN or by SAP under TrustSec NDAC.

7.4 Cipher Suites and Extended Packet Numbering

The default cipher in an MKA policy is always GCM-AES-128. On Catalyst 9000 platforms, GCM-AES-256 and both XPN suites require a Network Advantage license.

XPN stands for Extended Packet Numbering and exists for one reason: the standard 32-bit Packet Number space is exhausted quickly on 40G and 100G links, forcing frequent SAK rekeys. XPN widens the packet number to 64 bits so a high-speed link can run far longer between rekeys. Two documented restrictions matter:

• XPN cipher suites do not support a confidentiality offset — the two features cannot be combined.
• XPN cipher suites are not supported on switch-to-host MACsec connections.

7.5 Confidentiality Offset

confidentiality-offset accepts 0, 30, or 50 bytes. A non-zero offset leaves the first N bytes of the frame authenticated but not encrypted, so an intermediate device that is not a MACsec peer can still read the IP and Layer 4 headers for load-balancing or flow analysis. Offset 30 typically exposes the IPv4 header; offset 50 typically exposes the IPv6 header. The 50-byte offset is not supported with XPN cipher suites, and Cisco recommends offset 0 when AnyConnect is in use on the client.

7.6 should-secure vs. must-secure

macsec access-control controls what happens to unencrypted frames arriving on a MACsec-enabled interface:

• must-secure — the default. Unencrypted frames are dropped. This is the correct production posture.
• should-secure — unencrypted frames are permitted to pass in the clear. Cisco explicitly recommends configuring should-secure while first enabling MACsec or migrating a link, then removing it once the session establishes, because otherwise a one-sided configuration silently black-holes the link.

This is the highest-value operational fact in the topic. Enabling MACsec on one end of a production uplink with the default must-secure takes the link down instantly.

7.7 Configuration and Verification

! ---- Switch-to-switch uplink MACsec using MKA with a pre-shared CAK/CKN ----
key chain MACSEC-UPLINK-KC macsec
 key 01
  cryptographic-algorithm aes-256-cmac
  key-string 7 <encrypted-hex-CAK>
!
mka policy UPLINK-MKA
 key-server priority 10
 macsec-cipher-suite gcm-aes-256
 confidentiality-offset 0
!
interface TenGigabitEthernet1/0/1
 description MACsec uplink to Distribution-1
 mtu 1532                                  ! 1500 + 32 bytes MACsec overhead
 mka policy UPLINK-MKA
 mka pre-shared-key key-chain MACSEC-UPLINK-KC
 macsec network-link
 macsec access-control should-secure       ! REMOVE once the session is Secured
!
! ---- Verification ----
Switch# show mka sessions interface TenGigabitEthernet1/0/1 detail
 Status ................ Secured - Secured MKA Session with MACsec
 Local Tx-SCI .......... 00a3.8e1c.4401/0001
 Peer Tx-SCI ........... 00a3.8e1c.9c01/0001
 MKA Policy Name ....... UPLINK-MKA
 Key Server Priority ... 10
 Latest SAK Status ..... Rx & Tx
 Latest SAK KI .........  ...  AN 0
!
Switch# show macsec interface TenGigabitEthernet1/0/1
 MACsec is enabled
  Replay protect : enabled      Replay window : 0
  Cipher : GCM-AES-256          Confidentiality Offset : 0
 Transmit Secure Channels: encrypt pkts 88214093, protected pkts 0
 Receive  Secure Channels: decrypt pkts 91043221, invalid pkts 0, not valid 0

Reading that output: Status: Secured is the only healthy state — Pending or Init means the peers never agreed on a key, almost always a CKN/CAK mismatch or a cipher-suite mismatch. A rising not valid counter on the receive channel indicates ICV failures, which point at a key mismatch or corruption rather than a configuration error.