How MACsec Works: Layer 2 Ethernet Encryption with 802.1AE

MACsec (Media Access Control Security) is a Layer 2 encryption protocol defined by IEEE 802.1AE that provides hop-by-hop confidentiality, integrity, and replay protection for Ethernet frames. Unlike IPsec or TLS, which operate at Layer 3 and above, MACsec encrypts everything between two directly connected network devices -- switches, routers, or hosts -- at the data link layer. Every frame on the wire is encrypted, including the Layer 3 headers, ARP traffic, control plane protocols, and even LLDP and STP frames that would normally be invisible to higher-layer encryption.

MACsec was standardized in 2006 (IEEE 802.1AE-2006, revised in 2018) and has become increasingly important as organizations recognize that encryption at Layer 3 and above leaves a significant gap: any traffic within a Layer 2 domain -- between switches in a data center, between a host and its top-of-rack switch, or across a campus backbone -- travels in the clear. An attacker with physical access to a network cable or a compromised switch can passively capture or actively modify all traffic on the segment. MACsec closes this gap by encrypting every frame at wire speed using hardware offload in the NIC or switch ASIC.

This article covers the MACsec frame format, the SecTAG header, GCM-AES encryption, MACsec Key Agreement (MKA), deployment models, and how MACsec compares to other encryption approaches.

Why Layer 2 Encryption Matters

Consider a typical data center network. Servers in the same rack communicate through a top-of-rack (ToR) switch over Ethernet. Traffic between racks traverses aggregation switches and spine switches. All of this is Layer 2 or bridged Layer 3 traffic. Without MACsec, an attacker who gains access to any switch in the path -- through physical access, a supply chain compromise, or exploitation of a switch management vulnerability -- can:

• Passively sniff all traffic on the segment, including credentials, API tokens, database queries, and inter-service communication that may not use TLS.
• Inject frames to conduct ARP spoofing, VLAN hopping, or man-in-the-middle attacks.
• Modify frames in transit to alter data, inject malicious payloads, or redirect traffic.
• Replay captured frames to re-execute transactions or bypass authentication.

TLS protects application data in transit, but many protocols that traverse local networks are not encrypted: ARP, DHCP, NTP, SNMP, routing protocol adjacencies, storage traffic (iSCSI, NFS), and east-west microservice traffic that uses plaintext HTTP or gRPC internally. MACsec encrypts all of it, regardless of the upper-layer protocol.

The MACsec Frame Format

A MACsec-protected frame wraps a standard Ethernet frame with two additional components: the SecTAG (Security Tag) header, inserted between the source MAC address and the EtherType/payload, and the ICV (Integrity Check Value), appended after the encrypted payload. The original EtherType and payload are encrypted; the Ethernet header (destination and source MAC addresses) remains in the clear so that switches can still forward the frame.

The SecTAG Header

The Security Tag (SecTAG) is the critical addition that MACsec makes to the Ethernet frame. It is identified by EtherType 0x88E5 and contains:

• TCI (Tag Control Information) -- a 6-bit field containing flags:
  • V (version) -- always 0 for the current standard
  • ES (End Station) -- set if the sender is an endpoint (not a bridge)
  • SC (Secure Channel) -- if set, the optional SCI field is present
  • SCB (Single Copy Broadcast) -- used for bridge operation
  • E (Encryption) -- if set, the payload is encrypted; if clear, only integrity-protected
  • C (Changed text) -- indicates the original frame's EtherType was moved into the encrypted payload
• AN (Association Number) -- 2 bits identifying which of four possible security associations (keys) is in use. This allows hitless key rotation: the new key can be installed as a different AN while the old key is still active.
• SL (Short Length) -- 8 bits indicating the payload length for short frames (less than 48 bytes of user data).
• PN (Packet Number) -- 32 bits (or 64 bits in 802.1AEbw XPN mode) providing replay protection. Each frame gets a monotonically increasing sequence number. The receiver tracks the highest seen PN and drops frames with a PN below the replay window.
• SCI (Secure Channel Identifier) -- an optional 8-byte field (6-byte MAC address + 2-byte port identifier) that identifies the transmitting secure channel. This is required in multi-peer topologies where the receiver needs to identify which peer sent the frame.

Integrity Check Value (ICV)

The ICV is the authentication tag produced by the GCM-AES cipher. It is appended after the encrypted payload and is either 8 or 16 bytes long (16 bytes is standard and recommended for full security). The ICV covers both the encrypted payload and the SecTAG (which is transmitted in the clear), ensuring that an attacker cannot modify the SecTAG without detection.

GCM-AES Encryption

MACsec uses AES in Galois/Counter Mode (GCM-AES) as its mandatory cipher suite. GCM provides authenticated encryption -- it simultaneously encrypts the data and produces an authentication tag (the ICV), combining confidentiality and integrity in a single operation.

Two cipher suites are defined:

• GCM-AES-128 -- AES with 128-bit keys. The default cipher suite, mandatory to implement.
• GCM-AES-256 -- AES with 256-bit keys. Provides a larger security margin and is increasingly required by government and financial sector standards.
• GCM-AES-XPN-128/256 -- Extended Packet Numbering variants (802.1AEbw) that use 64-bit packet numbers instead of 32-bit, enabling longer-lived security associations at high speeds (at 100 Gbps, a 32-bit PN space can be exhausted in about 0.3 seconds with minimum-size frames).

The GCM mode works by combining a counter mode for encryption with a polynomial hash (GHASH) for authentication:

1. A 128-bit initialization vector (IV) is constructed from the SCI and the packet number. The SCI provides uniqueness per channel, and the PN provides uniqueness per frame.
2. The AES cipher in counter mode generates a keystream that is XORed with the plaintext payload to produce ciphertext.
3. The GHASH function computes an authentication tag over the ciphertext and the additional authenticated data (AAD), which includes the SecTAG and the Ethernet header.
4. The authentication tag (ICV) is appended to the frame.

GCM-AES is designed for hardware acceleration. Modern network ASICs and NICs include dedicated AES-GCM engines that encrypt and decrypt at line rate -- 100 Gbps and above -- with no measurable impact on latency or throughput. This hardware offload is what makes MACsec practical: software encryption at Layer 2 would be far too slow for high-speed network links.

MKA: MACsec Key Agreement Protocol

MACsec defines the frame format and encryption but does not specify how peers negotiate and distribute keys. That job belongs to MKA (MACsec Key Agreement), defined in IEEE 802.1X-2010 (clause 11). MKA is an extension of 802.1X that runs within EAPoL (Extensible Authentication Protocol over LAN) frames and handles the entire key lifecycle.

MKA Key Hierarchy

MKA uses a hierarchical key structure:

• CAK (Connectivity Association Key) -- the master key shared between MKA peers. This is either pre-shared (configured on both devices) or derived from an 802.1X EAP authentication exchange. The CAK is never used directly for encryption.
• CKN (Connectivity Association Key Name) -- a name identifying the CAK. Peers must agree on both the CAK and CKN to establish an MKA session.
• ICK (ICV Key) -- derived from the CAK, used to compute the ICV (integrity check) for MKA protocol messages (MKPDUs).
• KEK (Key Encrypting Key) -- derived from the CAK, used to encrypt the SAK when distributing it to peers.
• SAK (Secure Association Key) -- the key actually used by MACsec to encrypt and authenticate data frames. The SAK is generated by the key server (the MKA peer with the highest priority) and distributed to all peers in the connectivity association, encrypted with the KEK.

MKA Session Establishment

When two MKA-enabled peers connect, the session establishment proceeds as follows:

1. CAK distribution -- either both peers have a pre-shared CAK/CKN pair (configured by the administrator), or the CAK is derived from an 802.1X EAP authentication exchange (e.g., EAP-TLS). Pre-shared keys are simpler but do not scale; 802.1X-derived keys provide per-session uniqueness and are preferred in enterprise deployments.
2. MKPDU exchange -- both peers send MKA Protocol Data Units (MKPDUs) in EAPoL frames. MKPDUs contain the peer's Member Identifier (MI), Message Number (MN), key server priority, and supported cipher suites. MKPDUs are integrity-protected using the ICK derived from the CAK.
3. Key server election -- the peer with the lowest key server priority (or lowest SCI as tiebreaker) becomes the key server. The key server is responsible for generating the SAK.
4. SAK distribution -- the key server generates a random SAK, encrypts it with the KEK, and distributes it to all peers in the next MKPDU. The SAK is wrapped using AES Key Wrap (RFC 3394).
5. SAK installation -- all peers install the SAK and begin encrypting and decrypting data frames. The key server assigns an Association Number (AN) to the SAK.
6. Keepalive -- MKPDUs continue to be exchanged periodically (default every 2 seconds) as keepalives. If a peer misses three consecutive MKPDUs (6 seconds), the MKA session is torn down and the security association is deleted.

SAK Rotation and Rekeying

The SAK must be rotated periodically to limit the impact of a key compromise and to avoid exhaustion of the 32-bit packet number space. With standard (non-XPN) MACsec, the packet number wraps at 2^32 frames, after which the SAK must be rotated. At 100 Gbps with minimum-size (64-byte) frames, this occurs approximately every 0.3 seconds, making XPN (64-bit packet numbers) essential for high-speed links.

MKA supports hitless key rotation using the Association Number (AN). The key server generates a new SAK with a different AN (cycling through 0-3), distributes it via MKPDU, and both peers install the new SAK before the old one expires. For a brief overlap period, the receiver can decrypt frames using either the old or new SAK based on the AN in the SecTAG.

Deployment Models

Point-to-Point MACsec

The simplest and most common deployment is point-to-point MACsec between two directly connected devices: switch-to-switch, switch-to-router, or host-to-switch. Each link has its own independent MKA session and SAK. The frame is encrypted by the sending device, transmitted over the wire, and decrypted by the receiving device. At each hop, the frame is decrypted, the plaintext is processed (routing decisions, ACL checks, QoS marking), and then re-encrypted with the next hop's SAK for transmission.

This hop-by-hop model means that every switch in the path must support MACsec. The frame is in plaintext inside each switch's forwarding pipeline, which is acceptable because the switches are trusted devices. The encryption protects the wire between devices, not the devices themselves.

Host-to-Switch (Downlink) MACsec

MACsec between a host and its access switch (sometimes called "downlink MACsec" or "client MACsec") protects the first hop -- the cable from the server's NIC to the switch port. This is typically authenticated via 802.1X (EAP-TLS with certificates), making it suitable for environments where devices are dynamically connected (laptops, phones, IoT devices) rather than statically cabled infrastructure.

Many enterprise NIC drivers (Intel, Mellanox, Broadcom) support MACsec in hardware, enabling 10-25 Gbps encryption without CPU overhead. Linux kernel support for MACsec has been available since kernel 4.6 via the macsec module, configurable through ip link commands or wpa_supplicant for 802.1X-authenticated sessions.

# Linux: create a MACsec interface
ip link add link eth0 macsec0 type macsec port 1 encrypt on
ip macsec add macsec0 tx sa 0 pn 1 on key 00 \
  dbbf48a8b6f93a4f30f1eab37ba39af1a07a5789e52f35aa3a69b2158bc7af48
ip macsec add macsec0 rx address 00:11:22:33:44:55 port 1
ip macsec add macsec0 rx address 00:11:22:33:44:55 port 1 sa 0 pn 1 on key 01 \
  ab83fea4e3a7f3eab37ba39af1a07a5789e52f35aa3a69b21dbbf48a8b6f9358
ip link set macsec0 up

Switch-to-Switch (Uplink) MACsec

MACsec between switches (uplink MACsec) protects the links between infrastructure devices -- the data center fabric, campus backbone, or WAN interconnects. These links are typically configured with pre-shared keys (PSK) because the switches are statically connected and managed by the same operations team.

Key considerations for switch-to-switch MACsec:

• Line-rate encryption -- switch ASICs must encrypt/decrypt at the full port speed (10G, 25G, 40G, 100G, 400G). Modern ASICs from Broadcom (Memory Access Packet Processor, Memory Access Packet Processor 3), Intel/Barefoot (Tofino 2), and Cisco (Silicon One) include MACsec offload engines.
• MTU overhead -- MACsec adds 32 bytes of overhead (SecTAG + ICV), which may cause MTU issues if the path MTU is already at the Ethernet maximum. Infrastructure links often run with jumbo frames (9000+ byte MTU) to accommodate this.
• Performance monitoring -- MACsec encrypts everything including monitoring traffic. Tools that rely on packet sniffing (SPAN ports, TAPs) will see only encrypted frames unless they are placed before the MACsec encryption point or have access to the SAK.

Multi-Point MACsec

Standard MACsec is point-to-point: one SAK per pair of devices. In a multi-access topology (e.g., a shared Ethernet segment or a switch with multiple ports in the same connectivity association), multi-point MACsec extends the model. All devices in the connectivity association share the same SAK, and the SCI field in the SecTAG identifies the sender. The key server distributes the SAK to all members.

Multi-point MACsec is less common in practice because modern networks are predominantly point-to-point switched topologies. It is mainly relevant for shared media segments or specific bridged topologies.

MACsec vs IPsec vs TLS

Each encryption technology operates at a different layer and solves a different problem:

These layers are complementary, not competing. In a defense-in-depth architecture, MACsec encrypts the physical wire, IPsec encrypts routed traffic between sites, and TLS provides end-to-end application-layer encryption. A packet traversing a data center might be simultaneously protected by all three: TLS encrypts the application data inside an IPsec tunnel that crosses a MACsec-encrypted fabric link.

MACsec on WAN Links

Traditionally, MACsec was limited to LAN segments because it operates at Layer 2 and requires direct Ethernet adjacency. However, MACsec over WAN has become increasingly important for encrypting data center interconnects (DCI) and metro Ethernet links. Two approaches exist:

• Native MACsec over dark fiber or wavelength services -- if the WAN link is a raw Ethernet service (Layer 2 transport without routed hops), MACsec works natively. The frames traverse the provider's optical transport network encrypted. The provider cannot read the traffic, which is a significant advantage for compliance-sensitive data.
• MACsec over MPLS/IP WAN -- for routed WAN links, MACsec frames must be tunneled. Approaches include GRE or VXLAN encapsulation of MACsec frames, or using vendor-specific WAN MACsec implementations that separate the encryption from the Ethernet framing.

The XPN (Extended Packet Numbering) extension (IEEE 802.1AEbw) is critical for WAN MACsec because long-haul links carrying high-speed traffic would exhaust the 32-bit PN space too quickly, requiring constant rekeying that could cause traffic drops.

Security Considerations

• Pre-shared key management -- PSK-based MKA requires the same key on both endpoints. Key distribution and rotation must be handled out-of-band (configuration management, secure API). In large networks with hundreds of links, PSK management can become operationally challenging.
• 802.1X dependency -- EAP-derived MACsec keys depend on the RADIUS/802.1X infrastructure. If the RADIUS server is unreachable, new MACsec sessions cannot be established. Backup RADIUS servers and local fallback policies are essential.
• Visibility trade-offs -- MACsec encrypts everything on the wire, which means network monitoring tools (packet captures, intrusion detection systems, NetFlow/sFlow collectors) that tap the physical link will see only encrypted frames. Monitoring must happen at points where the traffic is decrypted -- typically inside the switch forwarding pipeline or at host endpoints.
• Side-channel considerations -- while MACsec encrypts the payload, the frame size and timing are still visible. Traffic analysis can reveal patterns (e.g., the cadence of a VoIP call or the burst pattern of a database query) even without decrypting the content.

Vendor Support and Real-World Deployment

MACsec is widely supported in modern network infrastructure:

• Cisco -- Catalyst 9000, Nexus 9000 (with -FX3/-GX2 ASICs), ASR 1000. Supports 256-bit AES and XPN on newer hardware.
• Arista -- 7050X, 7060X, 7260X, 7800R series with MACsec-capable port modules.
• Juniper -- MX, QFX, EX series with MACsec line cards.
• Nokia -- SR Linux, 7750 SR with MACsec support on select interfaces.
• Linux -- kernel 4.6+ with macsec module, configurable via ip link or wpa_supplicant.
• NIC vendors -- Intel E810 (100G), NVIDIA ConnectX-6 Dx (100G), Broadcom BCM57508 (200G).

See It in Action

MACsec protects the physical links that carry BGP sessions, Ethernet frames, and all inter-switch traffic within data center fabrics. While MACsec itself is invisible to the routing layer, the networks of major switch vendors and data center operators that deploy MACsec are visible in the global routing table. Use the god.ad BGP Looking Glass to explore them:

• AS16509 -- Amazon Web Services, where MACsec protects Direct Connect links
• AS396982 -- Google Cloud, offering MACsec on Cloud Interconnect
• AS8075 -- Microsoft Azure, with MACsec on ExpressRoute Direct
• AS109 -- Cisco Systems, a leading MACsec hardware vendor
• AS11164 -- Arista Networks, known for data center switches with MACsec

Every hop between your device and this page traversed physical links -- copper cables, fiber optics, switch backplanes. MACsec ensures that even if someone taps those wires, all they see is encrypted noise. Look up any IP address or AS number to trace the path your traffic takes and consider which links along the way are MACsec-protected.