This document describes the MACsec feaure, its uses cases, and how to troubleshoot the feature on Catalyst 9000 switches. Scope of this document is MACsec on LAN, between two switches/routers. It does not cover other use cases.
There are no specific requirements for this document.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Note: Consult the appropriate configuration guide for the commands that are used in order to enable these features on other Cisco platforms.
Clear text data communication is susceptible to security threats. Security breaches can occur at any layer of the OSI model. Some of the common breaches at Layer 2 are sniffing, packet eavesdropping, tampering, injection, MAC address spoofing, ARP spoofing, Denial of Service (DoS) attacks against a DHCP server, and VLAN hopping.
MacSec is an L2 encryption technology described in IEEE 802.1AE standard. MACsec secures the data on physical media, and makes it impossible for data to be compromised at higher layers. As a result, MACsec encryption takes priority over any other encryption method for higher layers, such as IPsec and SSL.
Advantages of MacSec
Client-Oriented Mode: MACsec is used in setups where two switches that are peering with each other can alternate as a key server or a key client prior to exchanging keys. The key server generates and maintains the CAK between the two peers.
Data Integrity Check: MACsec uses MKA to generate an Integrity Check Value (ICV) for the frame that arrives on the port. If the generated ICV is the same as the ICV in the frame, then the frame is accepted; otherwise it is dropped.
Data Encryption: MACsec provides port-level encryption on tthe interfaces of switches. This means that the frames sent out of the configured port are encrypted and frames received on the port are decrypted. MACsec also provides a mechanism where you can configure whether only encrypted frames or all
frames (encrypted and plain) are accepted on the interface.
Replay Protection: When frames are transmitted through the network, there is a possibility that frames get out of the ordered sequence. MACsec provides a configurable window that accepts a specified number of out-of-sequence frames.
MACsec and MTU
The MACsec header adds up to 32 bytes of header overhead. Consider a larger system/interface MTU on switches in the path to account for the additional overhead added by the MACsec header. If MTU is too low, you might see unexpected packet loss/delay for applications that need to use higher MTU.
Note: If there is an issue related to MACSEC, please ensure the GBIC at both ends are supported per the Compatibility Matrix .
Where MACsec is Used
Campus Use Cases
Between Sites or Buildings
Between Floors in a Multi-tenancy
Data Center Use Cases
Data Center Interconnect
WAN Use Cases
Data Center Interconnect
MACsec Key Agreement
defined in IEEE 802.1X REV-2010 as a key agreement protocol for discovering MACsec peers and negotiating keys
Connectivity Association Key
long-lived master key used to generate all other keys used for MACsec. LAN implemntations derive this from MSK (generated during EAP exchange)
Pairwise Master Key
One of the components used to derive the session keys that are used to encrypt traffic. Manually confgured, or derived from 802.1X
CAK key name
used to configure the key value or CAK. Only even number of HEX characters up to 64 characters allowed.
Secure Association Key
derived by the elected Key Server from the CAK and is the key used by the router/end devices to encrypt traffic for a given session.
Integrity Check Value key
derived from CAK and is tagged in every data/control frame to prove the frame is from an authorzied peer. 8-16 bytes depending cipher suite
Key Encrypting Key
derived from CAK (the preshared key) and used to protect the MacSec Keys
Secure Channel Identifier
Each virtual port receives a unique secure channel identifier (SCI) based on the MAC address of the physical interface concatenated with a 16-bit port ID
Scenario 1: MACsec Switch to Switch link security with SAP in Pre-Shared Key (PSK) mode
Step 1. Validate the configuration on both sides of the link
9300_stack#show run interface gig 1/0/1 interface GigabitEthernet1/0/1 description MACSEC_manual_3850-2-gi1/0/1 switchport access vlan 10 switchport mode trunk cts manual no propagate sgt sap pmk AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA mode-list gcm-encrypt <-- use full packet encrypt mode
3850#show run interface gig1/0/1 interface GigabitEthernet1/0/1 description 9300-1gi1/0/1 MACSEC manual switchport access vlan 10 switchport mode trunk cts manual no propagate sgt sap pmk AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA mode-list gcm-encrypt
NOTE: cts manual <-- Supplies local configuration for Cisco TrustSec parameters no propagate sgt <-- disable SGT tagging on a manually-configured TrustSec-capable interface, if you do not need to propage the SGT tags.
sap pmk AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA mode-list gcm-encrypt <-- Use the sap command to manually specify the Pairwise Master Key (PMK) and the Security Association Protocol (SAP) authentication and encryption modes to negotiate MACsec link encryption between two interfaces. The default encryption is sap modelist gcm-encrypt null
9300_stack#(config-if-cts-manual)#sap pmk fa mode-list ? gcm-encrypt GCM authentication, GCM encryption gmac GCM authentication, no encryption no-encap No encapsulation null Encapsulation present, no authentication, no encryption
Use "gcm-encrypt" for full GCM-AES-128 encryption.
These protection levels are supported when you configure SAP pairwise master key (sap pmk): SAP is not configured— no protection. sap mode-list gcm-encrypt gmac no-encap—protection desirable but not mandatory. sap mode-list gcm-encrypt gmac—confidentiality preferred and integrity required. The protection is selected by the supplicant according to supplicant preference. sap mode-list gmac —integrity only. sap mode-list gcm-encrypt —confidentiality required. sap mode-list gmac gcm-encrypt —integrity required and preferred, confidentiality optional.
Step 2. Verify MACsec state, and the parameters/counters are correct
### Ping issued between endpoints to demonstrate counters ### Host-1#ping 10.10.10.12 <-- sourced from Host-1 IP 10.10.10.11 !!!!!!!!!!!!!!!!!!!!!
9300_stack#sh macsec summary Interface Transmit SC Receive SC <-- Secure Channel (SC) flag is set for transmit and receive GigabitEthernet1/0/11 1
9300_stack#sh macsec interface gigabitEthernet 1/0/1 MACsec is enabled Replay protect : enabled Replay window : 0 Include SCI : yes Use ES Enable : no Use SCB Enable : no Admin Pt2Pt MAC : forceTrue(1) Pt2Pt MAC Operational : no Cipher : GCM-AES-128 Confidentiality Offset : 0 ! Capabilities ICV length : 16 Data length change supported: yes Max. Rx SA : 16 Max. Tx SA : 16 Max. Rx SC : 8 Max. Tx SC : 8 Validate Frames : strict PN threshold notification support : Yes Ciphers supported : GCM-AES-128 GCM-AES-256 GCM-AES-XPN-128 GCM-AES-XPN-256 ! Transmit Secure Channels SCI : 682C7B9A4D010000 SC state : notInUse(2) Elapsed time : 03:17:50 Start time : 7w0d Current AN: 0 Previous AN: 1 Next PN: 185 SA State: notInUse(2) Confidentiality : yes SAK Unchanged : no SA Create time : 03:58:39 SA Start time : 7w0d SC Statistics Auth-only Pkts : 0 Auth-only Bytes : 0 Encrypt Pkts : 2077 Encrypt Bytes : 0 ! SA Statistics Auth-only Pkts : 0 Encrypt Pkts : 184<-- packets are being encrypted and transmitted on this link ! Port Statistics Egress untag pkts 0 Egress long pkts 0 ! Receive Secure Channels SCI : D0C78970C3810000 SC state : notInUse(2) Elapsed time : 03:17:50 Start time : 7w0d Current AN: 0 Previous AN: 1 Next PN: 2503 RX SA Count: 0 SA State: notInUse(2) SAK Unchanged : no SA Create time : 03:58:39 SA Start time : 7w0d SC Statistics Notvalid pkts 0 Invalid pkts 0 Valid pkts 28312 Valid bytes 0 Late pkts 0 Uncheck pkts 0 Delay pkts 0 UnusedSA pkts 0 NousingSA pkts 0 Decrypt bytes 0 ! SA Statistics Notvalid pkts 0 Invalid pkts 0 Valid pkts 2502<-- number of valid packets received on this link UnusedSA pkts 0 NousingSA pkts 0 ! Port Statistics Ingress untag pkts 0 Ingress notag pkts 36 Ingress badtag pkts 0 Ingress unknownSCI pkts 0 Ingress noSCI pkts 0 Ingress overrun pkts 0 !
9300_stack#sh cts interface summary Global Dot1x feature is Disabled CTS Layer2 Interfaces --------------------- Interface Mode IFC-state dot1x-role peer-id IFC-cache Critical-Authentication ------------------------------------------------------------------------------------ Gi1/0/1 MANUAL OPEN unknown unknown invalid Invalid
Port QoS Subblock Trust Type .................... [0x2] Default Value .................  Ingress Table Map ............. [0x0] Egress Table Map .............. [0x0] Queue Map ..................... [0x0] Port Netflow Subblock Port Policy Subblock List of Ingress Policies attached to an interface List of Egress Policies attached to an interface
Physical Port Macsec Subblock <-- You will not see this block when MACSEC is not enabled Macsec Enable .... [Yes] Macsec port handle.... [0x4e00004c] <-- Same as PORT_LE Macsec Virtual port handles.... ..........[0x11000005] Macsec Rx start index....  Macsec Rx end index....  Macsec Tx start index....  Macsec Tx end index.... 
**snip** LEAD_PORT_ALLOW_CTS value 0 Pass LEAD_PORT_ALLOW_NON_CTS value 0 Pass LEAD_PORT_CTS_ENABLED value 1 Pass <-- Flag = 1 (CTS enabled) LEAD_PORT_MACSEC_ENCRYPTED value 1 Pass <-- Flag = 1 (MACsec encrypt enabled) LEAD_PORT_PHY_MAC_SEC_SUB_PORT_ENABLED value 0 Pass LEAD_PORT_SGT_ALLOWED value 0 Pass LEAD_PORT_EGRESS_MAC_SEC_ENABLE_WITH_SCI value 1 Pass <-- Flag = 1 (MACsec with SCI enabled) LEAD_PORT_EGRESS_MAC_SEC_ENABLE_WITHOUT_SCI value 0 Pass LEAD_PORT_EGRESS_MAC_SEC_SUB_PORT value 0 Pass LEAD_PORT_EGRESS_MACSEC_ENCRYPTED value 0 Pass **snip**
Scenario 2: MACsec Switch-to-Switch Link Security with MKA in Pre-Shared Key (PSK) mode
Step 1. Validate the configuration on both sides of the link
C9500#sh run | sec key chain
key chain KEY macsec key 01 cryptographic-algorithm aes-256-cmac key-string 7 101C0B1A0343475954532E2E767B3233214105150555030A0004500B514B175F5B05515153005E0E5E505C52564007025859040C27181B5141521317595F052C28 lifetime local 00:00:00 Aug 21 2019 infinite <-- use NTP to sync the time for key chains
C9500#sh macsec interface fortyGigabitEthernet 1/0/1 MACsec is enabled Replay protect : enabled Replay window : 0 Include SCI : yes Use ES Enable : no Use SCB Enable : no Admin Pt2Pt MAC : forceTrue(1) Pt2Pt MAC Operational : no Cipher : GCM-AES-256 Confidentiality Offset : 0
SCI : 0CD0F8DCDC010008 SC state : notInUse(2) Elapsed time : 00:24:38 Start time : 7w0d Current AN: 0 Previous AN: - Next PN: 2514 SA State: notInUse(2) Confidentiality : yes SAK Unchanged : yes SA Create time : 1d01h SA Start time : 7w0d
SA Statistics Auth-only Pkts : 0 Encrypt Pkts : 402 <-- should increment with Tx traffic
Port Statistics Egress untag pkts 0 Egress long pkts 0
Receive Secure Channels SCI : A0F8490EA91F0026 SC state : notInUse(2) Elapsed time : 00:24:38 Start time : 7w0d Current AN: 0 Previous AN: - Next PN: 94 RX SA Count: 0 SA State: notInUse(2) SAK Unchanged : yes SA Create time : 1d01h SA Start time : 7w0d
C9500#sh mka sessions interface fortyGigabitEthernet 1/0/1 Summary of All Currently Active MKA Sessions on Interface FortyGigabitEthernet1/0/1... ==================================================================================================== Interface Local-TxSCI Policy-Name Inherited Key-Server Port-ID Peer-RxSCI MACsec-Peers Status CKN ==================================================================================================== Fo1/0/1 0cd0.f8dc.dc01/0008MKA NO YES 8 a0f8.490e.a91f/0026 1 Secured01 <--- CKN number must match on both sides
0cd0.f8dc.dc01 <--MAC of local interface a0f8.490e.a91f <--MAC of remote neighbor 8 <-- indicates IIF_ID of respective local port (here IF_ID is 8 for local port fo1/0/1)
C9500#sh platform pm interface-numbers | in iif|1/0/1 interface iif-id gid slot unit slun HWIDB-Ptr status status2 state snmp-if-index Fo1/0/18 1 1 1 1 0x7EFF3F442778 0x10040 0x20001B 0x4 8
C9500#sh mka sessions interface fortyGigabitEthernet 1/0/1 detail MKA Detailed Status for MKA Session =================================== Status: SECURED - Secured MKA Session with MACsec Local Tx-SCI............. 0cd0.f8dc.dc01/0008 Interface MAC Address.... 0cd0.f8dc.dc01 MKA Port Identifier...... 8 Interface Name........... FortyGigabitEthernet1/0/1 Audit Session ID......... CAK Name (CKN)........... 01 Member Identifier (MI)... DFDC62E026E0712F0F096392 Message Number (MN)...... 536 <-- should increment as message numbers increment EAP Role................. NA Key Server............... YES MKA Cipher Suite......... AES-256-CMAC
Latest SAK Status........ Rx & Tx Latest SAK AN............ 0 Latest SAK KI (KN)....... DFDC62E026E0712F0F09639200000001 (1) Old SAK Status........... FIRST-SAK Old SAK AN............... 0 Old SAK KI (KN).......... FIRST-SAK (0)
SAK Transmit Wait Time... 0s (Not waiting for any peers to respond) SAK Retire Time.......... 0s (No Old SAK to retire) SAK Rekey Time........... 0s (SAK Rekey interval not applicable)
MKA Policy Name.......... MKA Key Server Priority...... 200 Delay Protection......... NO Delay Protection Timer.......... 0s (Not enabled)
Follow the same instructions mentioned in Scenario 1
Warning: For interoperability purposes. Please be aware that some platforms do padding and some platforms do not do, so this can lead to key issues where the mka session will remain in "Init" state. You can verify this with "show mka sessions"
Padding Issue Example
This use case shows a Catalyst 9500 and a Nexus 7k in NX-OS 8.2(2) but can also happen with Catalyst devices like C3560CX.
If you follow the configuration presented in Scenario 2, MKA won't establish the tunnel due to a key mismatch.
You must manually complete the key with 0's on the 9500 side since this device does not do padding.
conf t key chain macsec1 macsec key 0100000000000000000000000000000000000000000000000000000000000000 --> device does not do padding automatically key-string 12345678901234567890123456789012 end
conf t key chain macsec1 macsec key 01 --> Device does automatic padding. key-octet-string 12345678901234567890123456789012 end
Other Configuration Options
MACsec Switch-to-Switch Link Security with MKA on Bundled/Port-Channel interface
L3 and L2 Port-channels (LACP, PAgP and Mode ON)
Encryption Types (AES-128 and AES-256 (AES-256 is applicable for Advantage License)
Key Exchange MKA PSK only
Catalyst 9200 (AES-128 only)
Catalyst 9500 and Catalyst 9500H
Sample Switch to Switch Etherchannel Configuration
Key chain and MKA policy configuration remains same as shown earlier in MKA configuration section.
interface <> <-- This is the physical member link. MACsec encrypts on the individual links macsec network-link mka policy <policy-name> mka pre-shared-key key-chain <key-chain name> macsec replay-protection window-size frame number channel-group <number> mode active <-- Adding physical member to the port-channel
MACsec Switch-to-Switch Link Security across L2 intermediate switches, PSK mode
This section covers some of those supported WAN MACsec scenarios where Cat9K needs to transparently pass encrypted packets.
There are cases when routers are not directly connected but they have L2 intermediate switches, and the L2 switches should bypass the encrypted packets without any processing of the encryption.
Catalyst 9000 switches forward transparently packets with Clear Tag starting in 16.10(1)
Pass through is supported for MKA/SAP
Supported on L2 access, trunk or Etherchannels
Supported by default (no config CLIs to enable/disable)
Ensure routers send EAPOL frames with non-default (0x888E) ether-type
EoMPLS / VPLS Topology
Supported Platforms Cat 9300/9400,9500/9500H as “PE” or “P” Devices
Supported by default (no config CLIs to enable/disable)
Double encryption is not supported. End to End MACsec with Clear tag require the Hop by Hop switches to not enable on the L2 directly connected Links
ClearTag + EoMPLS with intermediate Layer 2 only switches, MACsec cannot enable on CE-PE link
ClearTag + L3VPN with intermediate switches not supported
There is no support for "Should Secure" in PSK Mode, "Must Secure" is the default mode
Must Secure policy will not encrypt only EAPoL to negotiate the MACsec settings
MACsec Operational Information
Sequence of Operation
When the link and both end devices come up, they exchange MKA frames (ethertype = 0x888E, same as EAPOL with packet type as MKA). Its a multi point to multipoint negotiation protocol. The CAK key value (normally static preshared), key name (CKN) must match and ICV must be valid for peers to be discovered and accepted.
The device with lowest Key Server priority (default = 0) is elected as the Key Server. The Key server generates the SAK and distributes through MKA messages. Incase of tie highest value of SCI (secure Channel Identifier) wins.
Subsequently, all MacSec secured frames are encrypted with the SAK (Symmetric cryptography). There are seperate TX and RX Secure Channels created. But same Key SAK is used for both encrypt and decrypt.
When a new device is detected in a multi access LAN (through EAPOL-MKA messages) the key server generates a new key to be used by all the devices. The new key comes into use after it is acknowledged by all devices (refer section 9.17.2 of IEEE Std 802.1X-2010).
Control frame (EAPOL-MKA)
EAPOL destination MAC = 01:80:C2:00:00:03 to multicast the packets to multiple destinations
EAPOL ether type = 0x888E
L2 payload in the Control frame format
MACSec inserts two aditional tags on data frames with maximum overhead of 32bytes (min 16 byte).
SecTag = 8 to 16 bytes (8 byte SCI is optional)
ICV = 8 to 16 bytes based on the cipher suit (AES128/256)