What is MACsec? (IEEE 802.1AE)
MACsec (Media Access Control Security) is a Layer 2 encryption standard defined in IEEE 802.1AE. It provides confidentiality, integrity, and authenticity for Ethernet frames on a hop-by-hop basis — encrypting everything that travels over a wired Ethernet link.
If TLS encrypts your web traffic and IPsec encrypts your IP packets, MACsec encrypts the Ethernet frames themselves — before they even reach the IP layer.
Why MACsec Exists
Ethernet was originally designed for trusted, local environments. There's no built-in encryption or authentication — anyone who can plug into a switch port (or tap a cable) can see all traffic on that VLAN in plaintext.
Higher-layer encryption (TLS, IPsec) helps, but leaves gaps:
- ARP, DHCP, and other Layer 2 protocols aren't protected by TLS or IPsec
- Metadata (which MAC is talking to which MAC, frame sizes, timing) is visible
- VLAN tags and control plane traffic can be manipulated
- Physical layer attacks (cable taps between switches) bypass all higher-layer encryption
MACsec closes these gaps by encrypting everything at Layer 2.
How MACsec Works
The MACsec Frame Format
MACsec wraps standard Ethernet frames with a security header (SecTAG) and an Integrity Check Value (ICV):
Standard Ethernet Frame:
┌──────────┬──────────┬──────────┬─────────┐
│ Dst MAC │ Src MAC │ EtherType│ Payload │
└──────────┴──────────┴──────────┴─────────┘
MACsec Frame:
┌──────────┬──────────┬────────┬──────────┬─────────────────┬─────┐
│ Dst MAC │ Src MAC │ SecTAG │ EtherType│ Encrypted Data │ ICV │
└──────────┴──────────┴────────┴──────────┴─────────────────┴─────┘
↑ ↑
Security Tag Integrity Check
(EtherType 0x88E5) (8 or 16 bytes)
Key points:
- The source and destination MAC addresses are NOT encrypted — switches still need them to forward frames
- Everything after the SecTAG is encrypted (including the original EtherType, VLAN tags, and payload)
- The ICV provides integrity verification — any tampered frame is detected and dropped
- MACsec uses AES-GCM-128 or AES-GCM-256 for encryption and authentication
Encryption Modes
MACsec supports two modes:
- Encrypt + Authenticate (GCM): The default. Encrypts the payload AND verifies integrity. An eavesdropper can't read or modify the traffic.
- Authenticate only (GMAC): Does NOT encrypt — the payload is plaintext. But integrity is still checked, so tampering is detected. Useful when you need to support inline monitoring tools that need to inspect traffic.
MKA — Key Management
MACsec itself only defines the frame encryption. Key management is handled by MKA (MACsec Key Agreement), defined in IEEE 802.1X-2010 (clause 9+).
MKA handles:
- Key derivation: Generating the Secure Association Key (SAK) used for encryption
- Key distribution: Securely sharing keys between MACsec peers
- Key rotation: Periodically changing keys (rekeying) without disrupting traffic
- Peer discovery: Identifying which devices on a link support MACsec
Key Hierarchy
CAK (Connectivity Association Key)
└─ derived from pre-shared key OR 802.1X authentication
│
├─ CKN (CAK Name) — identifies the key pair
│
└─ SAK (Secure Association Key)
└─ actual encryption key, rotated automatically by MKA
└─ derived by the Key Server (elected among peers)
Two Ways to Establish Keys
| Pre-Shared Key (PSK) | 802.1X (EAP-TLS) | |
|---|---|---|
| How | Manually configure same CAK/CKN on both ends | RADIUS server distributes keys after EAP authentication |
| Scale | Link-by-link (OK for small deployments) | Centralized, scales to thousands of ports |
| Use Case | Switch-to-switch uplinks, point-to-point links | Host-to-switch (enterprise access ports) |
| Key Rotation | Manual (or timed via MKA) | Automatic on reauthentication |
Deployment Scenarios
1. Switch-to-Switch (Infrastructure)
Encrypt inter-switch links to protect against physical cable taps. Critical in environments where cables run through untrusted areas (between buildings, through shared conduit, across campus).
[Switch A] ──── MACsec encrypted ──── [Switch B]
PSK mode, AES-256-GCM
2. Host-to-Switch (Access Layer)
Encrypt the link from an endpoint (laptop, server) to the access switch. Combined with 802.1X authentication, this provides both identity verification and traffic encryption.
[Laptop] ── 802.1X auth ──→ [Switch]
←── MACsec tunnel ──→
(EAP-TLS derives CAK automatically)
3. Data Center (Server-to-Switch)
Protect east-west traffic between servers and ToR (Top-of-Rack) switches. Increasingly important in multi-tenant environments and compliance-driven data centers.
4. WAN/Dark Fiber
MACsec can encrypt traffic over dark fiber or Metro Ethernet services. Some vendors support MACsec over longer distances with line-rate encryption at 100Gbps+.
MACsec vs Other Encryption
| MACsec | IPsec | TLS | |
|---|---|---|---|
| Layer | 2 (Data Link) | 3 (Network) | 4-7 (Transport+) |
| Scope | Single hop (link) | End-to-end or site-to-site | End-to-end (application) |
| Protects | All Ethernet traffic including L2 protocols | IP traffic only | Application data only |
| Performance | Hardware line-rate (ASIC) | Software or dedicated hardware | Software (CPU) |
| Overhead | ~32 bytes per frame | ~50-70 bytes per packet | ~20-40 bytes per record |
| Best For | LAN/campus encryption | VPN/WAN tunnels | Web/API security |
Configuration Example: Cisco IOS-XE (PSK Mode)
# Define the MACsec key chain
key chain MACSEC-KEYS macsec
key 01
cryptographic-algorithm aes-256-cmac
key-string 0 <your-hex-CAK-here>
# Apply MKA policy
mka policy MKA-POLICY
macsec-cipher-suite gcm-aes-256
key-server priority 0
# Apply to interface
interface GigabitEthernet1/0/1
mka policy MKA-POLICY
mka pre-shared-key key-chain MACSEC-KEYS
macsec
Configuration Example: Linux (wpa_supplicant)
# /etc/wpa_supplicant/wired.conf
ctrl_interface=/var/run/wpa_supplicant
eapol_version=3
ap_scan=0
network={
key_mgmt=IEEE8021X
eap=TLS
identity="host.example.com"
ca_cert="/etc/ssl/certs/ca.pem"
client_cert="/etc/ssl/certs/host.pem"
private_key="/etc/ssl/private/host.key"
eapol_flags=0
macsec_policy=1
macsec_integ_only=0 # 0=encrypt+auth, 1=auth-only
mka_cak=<hex-CAK>
mka_ckn=<hex-CKN>
}
Performance Considerations
- Hardware offload is essential. Modern enterprise switches (Cisco Catalyst, Juniper EX/QFX, Arista 7000 series) handle MACsec in ASICs at full line rate — 1G, 10G, 25G, 100G, even 400G with no throughput penalty.
- Software MACsec is slow. Linux supports MACsec via the kernel, but encryption happens in CPU. Fine for management links; not suitable for high-throughput data paths.
- MTU overhead: MACsec adds ~32 bytes (SecTAG + ICV). On standard 1500-byte MTU links, this means your effective payload drops slightly. On jumbo frame networks, this is negligible.
- Latency: Hardware MACsec adds nanoseconds of latency — imperceptible. Software MACsec adds microseconds.
Limitations
- Hop-by-hop only: Each switch decrypts and re-encrypts. If a switch is compromised, traffic on that switch is exposed. (This is by design — switches need to read headers to forward frames.)
- No Wi-Fi support: MACsec is for wired Ethernet only. Wi-Fi has its own encryption (WPA3).
- Requires hardware support: Both ends of a link must support MACsec. You can't enable it unilaterally.
- Breaks passive monitoring: Network TAPs and SPAN ports won't see plaintext. Plan for decryption points if you need monitoring.
- MAC addresses are still visible: MACsec encrypts the payload but not the Ethernet header. Source and destination MACs are in the clear.
When to Use MACsec
MACsec is especially valuable when:
- Cables pass through physically insecure areas
- You're in a regulated industry (finance, healthcare, government) requiring encryption at rest and in transit
- You need to protect against insider threats with physical access
- You want zero-trust at Layer 2 — verify and encrypt every link, not just the perimeter