5.2 MACsec Link Security and Key Agreement
Key Takeaways
MACsec is IEEE 802.1AE protection for an Ethernet link; every protected hop needs its own supported configuration.
A connectivity association describes the trusted peers; MKA manages secure association keys in CAK modes.
Static CAK configuration needs matching CKN/CAK values and an interface association; creating the association alone does not protect traffic.
Validate key agreement, protected traffic counters and MTU support on both endpoints before declaring a link secured.
Why MACsec Is a Separate Layer 2 Security Skill
A VLAN separates broadcast domains, but it does not encrypt traffic on the wire. DHCP snooping checks selected control messages, and a MAC limit restricts learned source addresses. Neither prevents someone with access to the physical link from reading unencrypted Ethernet payloads. Media Access Control Security (MACsec), standardized in IEEE 802.1AE, provides Ethernet-frame integrity and data-origin protection, with confidentiality when encryption is enabled. Replay protection helps reject old protected frames presented again.
The protection applies between MACsec peers on a supported Ethernet link. Suppose Access A connects through Distribution B to Core C. Protecting A–B does not automatically protect B–C. Each link has its own association and security state. A routed IPsec VPN instead protects traffic between IPsec endpoints across a routed network. Select the technology from the required protection boundary rather than from the fact that both can encrypt data.
Associations, Channels and Keys
A connectivity association (CA) identifies the cooperating security relationship. A secure channel is a unidirectional flow of protected frames from one participant; a secure association (SA) identifies a particular key/state used on that channel. Key rollover can replace an SA without redefining the VLAN or changing the host’s IP subnet.
In connectivity association key modes, MACsec Key Agreement (MKA) establishes and maintains the working security relationship. The CAK supplies the association’s keying basis, while the CKN identifies that keying context. The elected key server distributes a working secure association key (SAK). These names are not interchangeable: the manually provisioned CAK is not simply a fixed frame-encryption key copied unchanged into every packet. Working SAKs can be refreshed during operation.
| Mode or component | Operational meaning |
|---|---|
| Static CAK | Administrators provision compatible association credentials on the switch/router peers; MKA manages working SAKs |
| Dynamic CAK | Authentication supplies association keying material; Juniper’s switch-to-host design uses 802.1X/EAP-TLS and certificate infrastructure |
| Static SAK, where supported | Administrators directly manage secure associations and their keys; it has a different configuration model |
| Interface association | Binds the security relationship to the actual Ethernet link carrying traffic |
Do not assume a mode supported on one Juniper platform exists on every EX, QFX, MX or SRX interface. Port, optic, speed, licensing and release restrictions can determine whether the design is possible. The exam’s concept is the protection mechanism and its dependencies; production configuration must follow the actual hardware support matrix.
Reading a Junos Configuration
For an applicable static-CAK switch-to-switch link, the high-level work is to create a named connectivity association, choose security-mode static-cak, configure its CKN and CAK on both endpoints, and attach it under security macsec interfaces. The following shows the attachment and mode only; it intentionally omits key material and is not a complete deployable configuration:
[edit]
set security macsec connectivity-association CAMPUS security-mode static-cak
set security macsec interfaces ge-0/0/0 connectivity-association CAMPUS
Creating CAMPUS without the final interface reference does not enable MACsec on ge-0/0/0. Conversely, matching local association names alone proves nothing about the remote peer’s credentials. Confirm the actual key context, mode and selected interface. Keep real secrets out of tickets and shared examples; an invented sample key is not evidence that a live link negotiated successfully.
Operational Verification and Failure Scenarios
Use the supported show security macsec statistics, connection and interface views to check agreement and protected traffic in both directions. First establish that the physical interface is up. Then check MKA/association state and the installed transmit/receive SAs. Finally, send controlled traffic and verify that protected frame counters rise on both peers. A link-up LED establishes physical carrier, not encryption.
If physical carrier is present but agreement fails, compare static CAK/CKN values, security mode and the interface attachment. If agreement succeeds but traffic fails, inspect MTU, validation/replay counters and platform-specific behavior. MACsec adds framing overhead; Juniper’s configuration guide requires allowing space for the documented overhead between media and protocol MTUs. A design passing small pings can still lose larger frames if the wire-size budget is wrong.
A replay/validation error counter should lead to a specific investigation: peer state, key rollover, ordering, cabling path or incompatible settings. Disabling validation just to make counters stop would defeat the security requirement. Likewise, MACsec does not replace access authentication or routing policy. An authorized compromised endpoint can originate harmful traffic inside a valid protected channel; the cryptographic protection confirms the link relationship, not that every application request is appropriate.
Before accepting a scenario as “secure,” identify both MACsec endpoints, the key agreement mechanism, the protected direction and actual counters. This reasoning separates an incomplete configuration from a key mismatch and from a packet-size fault.
Official references checked 2026-10-18: MACsec configuration, security modes, and interface association.
A switch has a complete static-CAK connectivity association but no interface references it. What remains necessary to protect the intended Ethernet link?
Add a BGP export policy for the CAK
Bind the connectivity association to the supported MACsec interface
Set the access VLAN ID equal to the key server priority
Change OSPF to a stub area
Access A–Distribution B uses MACsec. B–Core C is an ordinary unprotected Ethernet link. What protection boundary has been established?
End-to-end encryption from A through C
Encryption for every VLAN using B as a gateway
Protection on A–B; B–C needs its own protection if required
Authentication of every application on hosts connected to A
Sections you finish are checked off in the contents.