Featured image

Table of Contents Link to heading

TrustSec: Group-Based Policy with Security Group Tags Link to heading

Info
Cisco TrustSec (CTS) is a next-generation network access control framework that enforces policy based on the identity of a user or device rather than its IP address or physical location. Policy is expressed between Security Group Tags (SGTs) — 16-bit values assigned to authenticated entities — rather than between IP subnets.

TrustSec operates in three sequential phases: classification (assign an SGT), propagation (carry the SGT across the network), and enforcement (apply policy based on SGTs at the egress point).

Why SGT-Based Policy Scales Better Than IP ACLs Link to heading

Traditional IP ACL-based access control requires ACL entries for every source/destination IP pair that needs a policy. As the number of endpoints grows, ACL maintenance becomes untenable — adding a new server means updating ACLs on potentially dozens of switches.

SGT-based policy defines access between groups:

Traditional IP ACL approach TrustSec SGT approach
permit tcp 10.1.0.0/24 10.2.0.0/24 eq 443 per device Define: Finance SGT → Finance-Server SGT: permit HTTPS
Must update every switch ACL when IPs change Policy follows identity — no updates when IPs change
Does not survive endpoint moves User carries their SGT regardless of physical location
1000 users × 100 servers = complex ACL matrix Policy matrix = number of distinct groups, not endpoints

Phase 1: Ingress Classification — Assigning SGTs Link to heading

SGTs are assigned when an endpoint authenticates to the network. The method depends on the endpoint type and environment:

Dynamic assignment (preferred for user-facing environments):

  • 802.1X authentication — ISE assigns an SGT based on the user/device identity attributes returned by the RADIUS access-accept
  • MAC Authentication Bypass (MAB) — for devices that cannot perform 802.1X
  • Web Authentication (WebAuth) — for guest or BYOD portals

Static assignment (for server environments and infrastructure):

  • IP-to-SGT mapping: a specific IP is always tagged with a specific SGT
  • Subnet-to-SGT: all IPs in a subnet receive the same SGT
  • VLAN-to-SGT: all endpoints on a VLAN receive the SGT associated with that VLAN
  • Interface-to-SGT: all traffic entering a specific port receives a fixed SGT
  • Port profile-to-SGT: tag by switch port profile
! Static IP-to-SGT mapping on a switch
cts role-based sgt-map 10.1.1.100 sgt 100

! Static VLAN-to-SGT mapping
cts role-based sgt-map vlan-list 10 sgt 20

Phase 2: Propagation — Carrying SGTs Across the Network Link to heading

Once classified, the SGT must travel with the packet as it traverses the network so enforcement points can read it.

Inline tagging (preferred — hardware-based, Layer 2):

The switch inserts a 16-bit SGT value into a Cisco MetaData (CMD) field added to the Ethernet frame. This is called native tagging and requires TrustSec-capable ASICs on all devices in the path.

Ethernet Frame with TrustSec inline tag:
| Dst MAC | Src MAC | EtherType (0x8909) | SGT (16-bit) | Original EtherType | Payload |
Note
Inline tagging is supported only on Cisco hardware with TrustSec ASIC support (Catalyst 3850, 9000, Nexus). When traffic traverses a device without inline tag support, the tag is stripped. Use SXP for those segments.

SGT Exchange Protocol (SXP) — software-based, Layer 3:

SXP is a TCP-based control-plane protocol that propagates IP-to-SGT bindings between devices that cannot perform inline tagging. Instead of tagging frames, SXP distributes a mapping table (IP → SGT) so enforcement devices can look up the SGT of a packet’s source IP address.

! Enable SXP on a switch
cts sxp enable

! Define SXP peer connection
cts sxp connection peer 10.1.1.1 password default mode local speaker

SXP creates a speaker/listener relationship:

  • Speaker: Device with SGT knowledge (e.g., access switch that authenticated the endpoint) — pushes IP-to-SGT mappings
  • Listener: Device that needs SGT information to enforce policy (e.g., firewall, core switch) — receives the mappings

Phase 3: Egress Enforcement — Applying Policy at the Destination Link to heading

At the egress point (the switch port facing the destination server, or a firewall), the SGT of the source and the SGT of the destination are compared against an SGACL (Security Group ACL) policy matrix.

Security Group ACL (SGACL) on routers and switches:

! Define SGACL — deny Finance access to HR servers, permit HTTPS to Finance servers
ip access-list role-based FINANCE-TO-HR
 deny ip

ip access-list role-based FINANCE-TO-FINANCE-SERVERS
 permit tcp dst eq 443
 deny ip

! Assign to the SGT policy matrix
cts role-based permissions from 10 to 20 FINANCE-TO-HR
cts role-based permissions from 10 to 30 FINANCE-TO-FINANCE-SERVERS

Security Group Firewall (SGFW) on Cisco Secure Firewalls:

Cisco FTD/ASA can read SGTs from inline-tagged packets or SXP bindings and apply identity-based firewall rules without referencing IP addresses:

access-rule: permit Finance-SGT to Finance-Server-SGT https
access-rule: deny Finance-SGT to HR-Server-SGT any

MACsec: IEEE 802.1AE Layer 2 Hop-by-Hop Encryption Link to heading

Info
MACsec (IEEE 802.1AE) provides Layer 2 encryption between directly connected devices on a single hop. Unlike IPsec (Layer 3, end-to-end), MACsec encrypts every frame on the wire between two adjacent devices, with frames decrypted and re-encrypted at each hop.

How MACsec Works Link to heading

MACsec adds two fields to the Ethernet frame:

  • SecTAG (802.1AE Security Tag): 8–16 bytes, contains the Association Number (AN) and Packet Number (PN) for replay protection
  • ICV (Integrity Check Value): 16 bytes, a GMAC/GCM authentication tag that verifies frame integrity and authenticity

The frame payload is encrypted using AES-GCM-128 or AES-GCM-256 (Galois/Counter Mode — provides both encryption and authentication in a single pass).

MACsec provides:

  • Confidentiality: Frame payload encrypted — unreadable on the wire
  • Integrity: Any bit flip in the frame is detected by the ICV check
  • Replay protection: Packet Number (PN) prevents replayed frames from being accepted
  • Origin authentication: Verifies the frame came from an authenticated MACsec peer
Note
MACsec encrypts only the frame between two directly connected MACsec peers. The frame is decrypted at the receiving switch, processed internally in cleartext, then re-encrypted before transmission on the next hop. It is a hop-by-hop mechanism, not end-to-end encryption.

Downlink MACsec secures the link between an endpoint (PC, IP phone, server) and the access switch.

Key exchange is performed by MACsec Key Agreement (MKA) protocol (IEEE 802.1X-2010):

  1. Endpoint authenticates to the network via 802.1X using EAP (EAP-TLS is most common)
  2. The RADIUS server (ISE) derives and distributes a Master Session Key (MSK) to both the endpoint and the switch
  3. MKA uses the MSK to negotiate the Secure Association Key (SAK) — the actual encryption key for the MACsec session
  4. MACsec session is established; all frames on the link are now encrypted

Requirements:

  • MACsec-capable switch (Catalyst 9000, 3850, Nexus)
  • MACsec-capable endpoint supplicant (Cisco Secure Client, or native OS MACsec support)
! Configure MACsec on an access port (Catalyst 9000)
interface GigabitEthernet1/0/1
 authentication port-control auto
 mka policy MKA-POLICY
 macsec

mka policy MKA-POLICY
 macsec-cipher-suite gcm-aes-256

Uplink MACsec encrypts the inter-switch links (trunk ports, uplinks to distribution/core).

By default, uplink MACsec uses Security Association Protocol (SAP), a Cisco proprietary keying protocol. SAP is negotiated automatically between TrustSec-capable switches on a per-link basis.

! Enable TrustSec and SAP MACsec on an uplink
interface GigabitEthernet1/0/24
 cts manual
  policy static sgt 2 trusted
  sap pmk <key> mode-list gcm-encrypt gmac no-encap

SAP supports four protection modes (in order of preference):

  • gcm-encrypt: AES-GCM-128 encryption + authentication (full MACsec)
  • gmac: Authentication only, no encryption
  • no-encap: No protection (negotiated as fallback when peer doesn’t support MACsec)

TrustSec vs MACsec: Complementary, Not Competing Link to heading

TrustSec and MACsec address different security requirements and are deployed together in high-security environments:

Aspect TrustSec (CTS) MACsec (802.1AE)
What it does Enforces access control between groups Encrypts frames on the wire
Security layer Policy/identity (who can talk to whom) Physical link encryption (confidentiality)
Scope Network-wide group policy Single hop between adjacent devices
Key technology SGT, SGACL, SXP MKA, SAP, AES-GCM
Requires PKI? Recommended for 802.1X-based SGT assignment Yes, for downlink MACsec with EAP-TLS
Inline with each other Yes — SGT tags ride inside MACsec-encrypted frames Yes — MACsec encrypts the frame that carries the SGT

In a fully deployed TrustSec + MACsec environment: endpoints authenticate via 802.1X, receive an SGT, and their traffic is encrypted by MACsec on the wire to the switch. The switch decrypts the frame, reads the SGT, and applies group-based policy before forwarding.