Introduction to MACsec

What does MACsec protect?

IEEE 802.1AE MAC Security (MACsec) protects Ethernet communication between participating devices. It provides data-origin authenticity and integrity, with optional confidentiality. Encryption protects the carried payload; visible Ethernet addressing still permits delivery. MACsec does not hide link usage or stop an attacker from cutting or saturating the link.

On a typical routed or switched network, protection is hop by hop. R2 validates and decrypts frames received from R1. Traffic leaving R2 on another interface needs a separate protected association. This does not provide application-to-application encryption through every transit device; TLS or an appropriately designed IPsec connection serves a different scope.

Inside a protected frame

A MACsec frame includes a security tag (SecTAG), protected data and an integrity check value (ICV). The tag carries information such as the association number and packet number, and can include a Secure Channel Identifier (SCI). Receivers validate integrity and enforce replay policy before delivering accepted traffic. A replay window controls tolerance for reordering; accepting an old authenticated frame is a different problem from detecting a modified frame.

With confidentiality enabled and offset zero, the protected payload is encrypted. Do not assume every control frame or every VLAN tag is hidden: EAPOL key-management traffic must reach the peer, and tag placement and control-protocol handling depend on the implementation.

MKA establishes the keys

IEEE 802.1X defines MACsec Key Agreement (MKA). MACsec is the frame-protection mechanism; MKA discovers live participants, elects a key server and coordinates the keys used by the data plane. MKA messages travel in EAPOL, independently of IP routing.

1. Establish trust. Peers obtain a Connectivity Association Key (CAK) and its name, the CKN. This lesson uses a pre-shared CAK. An authenticated EAP method such as EAP-TLS can instead supply key material in a suitable deployment.
2. Authenticate participation. MKA derives an integrity key and a key-encryption key from the CAK. The former authenticates MKA messages; the latter wraps distributed key material. The CKN identifies the CAK and is not a password.
3. Install traffic keys. The elected key server generates and distributes a Secure Association Key (SAK). The SAK protects data frames; the CAK is not simply used as the Ethernet traffic key.
4. Maintain protection. MKA tracks peer liveness and coordinates SAK replacement. A secure channel represents one sender; successive secure associations allow key changes. Packet numbers must not be reused with the same key. Extended packet numbering (XPN) addresses high-rate packet-number consumption when supported.

A PSK deployment does not require a RADIUS server merely to exchange MKA messages. It does require secure provisioning and rotation of shared secrets. Key-server status is a key-management role, not a forwarding master or a routing preference.

Two devices, one protected link

Before applying the example, establish ordinary Ethernet connectivity and matching access/trunk settings on the direct link. Keep those existing Layer 2 settings; IP addresses are not required for MKA. Use test endpoints on the two sides if you want to generate user traffic. Have console or separate management access because enforcing protection can interrupt the link.

• Both ends need compatible MACsec hardware/software, a common cipher suite, matching CAK and CKN, and a currently valid key lifetime.
• Allow the added SecTAG and ICV overhead in the frame-size budget. Check MTU and VLAN handling along the actual path.
• For a carrier Ethernet service, confirm transparent transport of required EAPOL and MACsec frames. The direct link here does not validate such a service.
• Do not assume a virtual image implements MACsec because it supports other commands. A conceptual topology is sufficient for this lesson if suitable devices are unavailable.

Configure the same association at both ends

Apply this block to each device's participating port after the underlying link is prepared. The published CAK is an example only: replace it on both ends with the same randomly generated secret before a real deployment. The key identifier 01 supplies the CKN in this example; local key-chain names need not match, but key material and identifiers must.

configure terminal
dot1x system-auth-control
key chain LINK-KEY macsec
 key 01
  cryptographic-algorithm aes-128-cmac
  key-string 8c40a71d25f6913b70e2c94a56d809be
 exit
exit
mka policy LINK-MKA
 macsec-cipher-suite gcm-aes-128
 confidentiality-offset 0
exit
interface TenGigabitEthernet1/0/1
 macsec access-control must-secure
 mka policy LINK-MKA
 mka pre-shared-key key-chain LINK-KEY
 macsec replay-protection window-size 0
 macsec network-link
end

The MKA policy explicitly selects GCM-AES-128 with full payload confidentiality. AES-128-CMAC is the key-chain authentication algorithm, a different setting from the data cipher. The example uses the key's default unbounded lifetime; schedule and coordinate finite lifetimes and rollover for operational deployments.

must-secure blocks ordinary unprotected data if key establishment fails. A permissive policy can allow cleartext fallback; that is unsuitable when the requirement is mandatory encryption. A zero replay window is appropriate for this ordered direct-link example; assess reordering before choosing a window on a different transport.

Verify control and data protection

Run the checks on both devices. The excerpts below are constructed examples with unrelated fields omitted; they are not recorded device results.

R1# show mka sessions
Total MKA Sessions....... 1
      Secured Sessions... 1
      Pending Sessions... 0

One secured session indicates successful MKA establishment. Check its detailed view to confirm the expected peer and that the current SAK is installed for receive and transmit; an interface-up state alone proves neither.

R1# show macsec interface TenGigabitEthernet1/0/1
MACsec is enabled
 Replay protect : enabled
 Replay window : 0
 Cipher : GCM-AES-128
 Confidentiality Offset : 0
 Access control : must secure

These fields confirm the intended policy, but configuration state alone does not prove that traffic is being encrypted. Generate known test traffic and compare the same command's secure-channel and secure-association counters on both ends: protected/encrypted transmit and validated/decrypted receive counters should advance. Check invalid, late and not-valid counters for drops; counter labels vary by hardware.

If the link does not secure

R1# show mka sessions
Total MKA Sessions....... 1
      Secured Sessions... 0
      Pending Sessions... 1

A pending session can result from missing EAPOL reachability, incompatible policy, or a CAK/CKN mismatch; this summary does not identify which. Check the physical link, peer configuration, active key lifetime and cipher compatibility. For an independently confirmed CAK mismatch, securely correct the differing key on the affected device to match its peer, then repeat the checks.

R1# show mka sessions
Total MKA Sessions....... 1
      Secured Sessions... 1
      Pending Sessions... 0

Confirm protected traffic counters advance on both ends after restoration. Do not “fix” mandatory encryption by allowing cleartext fallback. A successful ping demonstrates reachability, not encryption. If inspecting a packet capture, capture on the physical wire side of the protection boundary; a host capture before encryption or after decryption may correctly show plaintext.