Frames, scope and replay protection

Find the protection boundary

R1 sends traffic through R2 to R3. Only the R1–R2 link has MACsec enabled in this example. R2 is a trusted termination point: it validates received frames and exposes their contents to its normal forwarding functions. R3 does not inherit protection from R1.

A switch can similarly terminate a protected link and forward on another protected link with different keys. A transparent carrier service can instead carry frames between distant MACsec endpoints, if it supports the required frame types, size and control traffic. A normal routed IP path does not transparently transport Ethernet MKA messages.

Read the frame fields

For the common GCM-AES profile, a protected frame retains destination and source MAC addresses, followed by the MACsec EtherType 0x88E5, SecTAG, secure data and ICV, with an Ethernet FCS on the wire. The normal client's EtherType is carried within the secure data. An included SCI identifies the sending secure channel using a system identifier and port identifier; the association number selects a secure association within that channel.

The SecTAG occupies 8 bytes without an explicit SCI or 16 bytes with it, including the MACsec EtherType. The usual 16-byte ICV makes the added overhead 24 or 32 bytes before considering extra outer VLAN tags or other encapsulation. Budget actual wire size rather than subtracting a universal value from every interface MTU.

Offset zero encrypts the complete secure data. A nonzero confidentiality offset deliberately leaves initial data bytes visible while retaining integrity protection. Integrity-only operation, VLAN clear-tag options and newer privacy features must be checked against the actual cipher and platform; they are not implied by the word “MACsec”.

Follow the packet number

Integrity detects modification but does not by itself prove freshness. A previously valid frame still has a valid ICV. Replay enforcement uses packet numbers and receive state for the secure association. A non-XPN packet number is 32 bits; key replacement must occur before exhaustion or reuse. XPN extends the numbering space on compatible peers.

These numbers describe one receiving association, not a sequence shared by both directions. A nonzero replay window tolerates bounded reordering by accepting some older numbers. Do not assume an IPsec-style duplicate bitmap: on the documented MACsec implementation, frames still inside the permitted window are not replay protected. A larger window therefore changes both availability and replay exposure.

Choose and verify a receive policy

The following fragment applies to the already protected direct R1–R2 link from the introduction. It retains strict reception order. Apply the intended receive policy at both ends.

configure terminal
interface TenGigabitEthernet1/0/1
 macsec replay-protection window-size 0
end

R2# show macsec interface TenGigabitEthernet1/0/1
MACsec is enabled
 Replay protect : enabled
 Replay window : 0
 Cipher : GCM-AES-128
 Confidentiality Offset : 0
 Receive Secure Channels
  SA Statistics
   Valid pkts 1200
   Late pkts 4

The configuration is strict and four received frames were late relative to the active receive boundary. This does not identify an attack: legitimate reordering can produce the same symptom. Compare counter changes during an isolated test and inspect the transport before changing the policy. The failure lesson separates reordering from key and reachability problems.