MACsec and secure transport
Requirement / business driver
Encrypt data in transit on links/paths you don't fully trust (campus uplinks, DCI, WAN, leased fibre) - choosing the right layer to encrypt at.
MACsec vs IPsec
| MACsec (802.1AE) | IPsec | |
|---|---|---|
| Layer | L2, hop-by-hop | L3, across routed paths |
| Encrypts | Ethernet frames on a link | IP packets end-to-end / tunnel |
| Typical use | Switch-to-switch, campus uplinks, DCI / WAN MACsec | Site-to-site / remote access over untrusted L3 |
| Performance | Line-rate in ASIC | Depends (crypto offload helps) |
| Scope | Per link (re-encrypt each hop) | Across the routed network |
Overlay VPN security: "VPN" is not "IPsec"
A common misconception is that VPN means IPsec. VPN is the overlay (MPLS L3VPN/L2VPN, SSL VPN, DMVPN, GRE, GETVPN, client remote-access); IPsec is the network-layer cryptography you apply to secure it. Two protection models matter: peer-to-peer (IPsec / DMVPN / VTI - a security association per pair) and group (GETVPN, RFC 3547 - one group SA, tunnel-less, preserving native routing and multicast over a private core), see Tunneling technology selection. A recurring decision is whether to extend the VPN across the enterprise WAN at all - driven by the business/compliance requirement, not adopted by default.
GETVPN anatomy - keys, key servers, and the migration path
The group model has moving parts worth naming. Members register over GDOI (RFC 3547, an IKE-based exchange) with a key server, which authenticates them and hands back the group policy plus two keys: the KEK (key-encryption key) protecting subsequent rekey messages, and the TEK (traffic-encryption key) every member shares for the data plane. The KS pushes replacement keys before the current ones expire, so steady state never pauses; and because the KS sits outside the data path, a KS failure does not stop traffic - it stops rekeys and new registrations - which is why key servers deploy as a cooperative (COOP) pair that elects a primary and synchronises policy and keys. Two design rules follow. The encryption policy must exclude what keeps the WAN alive: PE-CE routing, GDOI itself, and management access are explicitly denied from encryption, or the underlay eats its own control plane. And migration is a KS-controlled switch: deploy members with receive-only SAs (forward cleartext, accept ciphertext) while coverage and rekeying are proven, then flip the KS to full SAs for a network-wide encryption cutover from one point - the staged path from cleartext to an encrypted WAN without per-site flag days (Reference models and migration considerations).
High-speed realities - XPN, the 32-byte tax, replay windows, fail posture
The original MACsec ciphers carry a 32-bit packet number per SAK; at 100 Gbps that space exhausts in seconds-to-minutes, forcing constant SAK rekeys that disrupt the flow - which is why XPN (802.1AEbw) ciphers with a 64-bit packet number are effectively mandatory at 100G+. Three more parameters are design decisions, not defaults: MACsec adds ~32 bytes per frame, so the usable IP MTU shrinks by that much unless the link runs jumbo - budget it like any encapsulation (MTU, fragmentation, and PMTUD); the replay-protection window must match what the transport can reorder (a provider Ethernet service that load-shares can reorder legitimately - a too-tight window drops good traffic, a huge one weakens the protection); and the fail posture - should-secure (forward in clear if key agreement fails) versus must-secure (fail closed) - is the availability-vs-confidentiality call: bring-up and troubleshooting favour should-secure, steady state on a compliance-driven link demands must-secure.
Cloud private links - where does enterprise-controlled encryption end?
The major clouds offer MACsec on dedicated private-link ports (10/100G), giving line-rate encryption from the customer edge in the colocation facility to the provider's edge with keys the enterprise controls. The design question is the encryption-domain boundary, and compliance - not technology - answers it. Trusted-provider verdict: MACsec to the cloud edge satisfies policy, and the provider's own encryption covers the rest -> simplest, full line rate. Untrusted-provider verdict: enterprise-controlled crypto must reach deeper, so an IPsec/GRE overlay (or the SD-WAN fabric, SD-WAN design) rides through the private link into a routing gateway inside the provider - MACsec then optionally underneath for the physical leg. Either way there is a residual: gateway-to-workload traffic inside the cloud is typically back in the provider's hands, so the honest deliverable states exactly where enterprise-managed encryption stops and what covers each remaining segment.
Post-quantum readiness for long-lived secrets
The threat is harvest now, decrypt later: traffic recorded today is broken once a cryptographically relevant quantum computer exists - so links carrying data whose confidentiality lifetime exceeds that horizon (government, health, financial archives) justify acting now. The exposed piece is the asymmetric key exchange, not the symmetric cipher (AES-256 is considered quantum-resistant); available-today mitigations therefore inject additional shared secrets into the key agreement: PPKs (RFC 8784) mixed into IKEv2 for IPsec, and the analogous MKA extensions for MACsec, optionally fed by an external quantum-safe key source (SKIP) rather than static configuration. Scenario reflex: when a requirement mentions decades-long secrecy, name the HNDL threat and layer a PQ pre-shared secret onto the existing MACsec/IPsec design - it is additive, not rip-and-replace.
Recommendation / justification
Use MACsec where you control the links and want line-rate, low-overhead encryption (campus uplinks, DCI, WAN MACsec over carrier Ethernet, Ethernet as transport); use IPsec (Tunneling technology selection) across untrusted L3 / the internet where hop-by-hop isn't possible. They're complementary: MACsec for the trusted-but-exposed links, IPsec for the routed overlay. This complements transport-layer encryption (Transport security and encrypted-traffic implications).
What would change this (mid-scenario twist)
- Compliance mandates link encryption on a carrier-Ethernet WAN -> WAN MACsec.
- Encryption needed across the internet / many routed hops -> IPsec (VTI/DMVPN/SD-WAN).
Validation checks
- Is encryption applied at the layer that matches the trust boundary (link vs routed path)?
- Is key management (MKA for MACsec; IKEv2 for IPsec) sound and is throughput sufficient?
IPv6 / dual-stack note
MACsec is L2 and address-agnostic; IPsec secures v4 and v6 - confirm both families are protected on the path.
Related
- Tunneling technology selection
- Transport security and encrypted-traffic implications
- Ethernet as transport
Spaced repetition
MACsec vs IPsec by layer/scope: MACsec = [...]; IPsec = [...].
MACsec vs IPsec by layer/scope: MACsec = L2 hop-by-hop link encryption (line-rate ASIC); IPsec = L3 encryption across routed/untrusted paths.
You'd choose WAN MACsec over IPsec when [...].
You'd choose WAN MACsec over IPsec when you control the links (e.g., carrier Ethernet/DCI) and want low-overhead line-rate encryption per hop.
MACsec's key-agreement protocol is [...]; IPsec's is [...].
MACsec's key-agreement protocol is MKA; IPsec's is IKEv2.
Why is "VPN" not a synonym for "IPsec"?
VPN is the overlay (MPLS L3VPN/L2VPN, SSL, DMVPN, GETVPN, remote-access); IPsec is the network-layer crypto applied to secure it. Protection models: peer-to-peer (IPsec) vs group (GETVPN, tunnel-less, preserves routing/multicast).
Why is XPN effectively mandatory for 100G+ MACsec?
The classic ciphers' 32-bit packet number exhausts in seconds-to-minutes at that rate, forcing disruptive constant SAK rekeys; XPN's 64-bit numbering restores sane rekey intervals.
MACsec on provider transport - three design parameters: [...].
MACsec on provider transport - three design parameters: ~32 B/frame MTU tax, replay window sized to the transport's reordering, and should-secure vs must-secure fail posture.
A compliance team declares the cloud provider untrusted for transit. What changes on the private link?
Enterprise-controlled encryption must extend past the MACsec-protected physical leg - an IPsec/GRE or SD-WAN overlay through the link into a routing gateway inside the provider - while documenting the residual gateway-to-workload segment.
"Harvest now, decrypt later" is countered today by [...] because the weak point is [...].
"Harvest now, decrypt later" is countered today by mixing post-quantum pre-shared keys into the key agreement (RFC 8784 PPK for IKEv2, MKA extensions for MACsec, external source via SKIP) because the weak point is the asymmetric key exchange, not AES-256.
In GETVPN, KEK vs TEK
The KEK encrypts the key server's rekey messages; the TEK is the shared traffic key all group members use - and rekeys are pushed before expiry so the data plane never pauses.
What actually fails when a GETVPN key server dies, and what limits the blast radius?
Traffic keeps flowing (the KS is outside the data path); rekeys and new registrations stop - so key servers run as a COOP pair that elects a primary and synchronises policy and keys.
The GETVPN crypto policy must explicitly exclude [...] - and migration uses [...] for a single-point network-wide cutover.
The GETVPN crypto policy must explicitly exclude the underlay control plane (PE-CE routing), GDOI itself, and management access - and migration uses receive-only SAs flipped to full SAs at the KS for a single-point network-wide cutover.
Sources
- Cisco Live BRKRST-2041 (2013): GDOI/KEK/TEK, COOP key servers, policy exclusions, receive-only SA migration.
- Cisco Live BRKNWT-2126 (Hill, 2024): XPN, MACsec transport parameters, cloud private-link encryption domains, post-quantum options.
- Cisco Press, SCOR; IEEE 802.1AE; Cisco MACsec/WAN MACsec guides.