This blog’s already-completed EthTrcv MACsec series covers MACsec/MKA at the transceiver level. The real SWS EthSwt shows that the switch itself also has a complete MACsec implementation with its own API set — including bypass lists and the same MKA key infrastructure.

Every EthSwt_MacSec* API mentioned in this post is marked Status: DRAFT in the R25-11 SWS.

Why MACsec in the switch AND the transceiver?

EthTrcv/MKA secures a single point-to-point link. A switch with multiple ports can additionally encrypt/decrypt at line rate per port — relevant when different segments of a zonal network have different trust levels and the switch itself acts as a security boundary.

Enabling it per port

EthSwtPortMacSecEnabled enables MACsec for a port. If the parameter is absent or FALSE, the driver ignores all MACsec configuration on that port entirely and handles frames without any MACsec processing.

Bypass lists

Even with MACsec enabled, certain frames can be selectively exempted from encryption:

ParameterBypass criterion

EthSwtPortMacSecBypassEtherTypes

Frames with one of the configured EtherTypes

EthSwtPortMacSecBypassVlans

Frames with one of the configured VLAN IDs

EthSwtPortMacSecBypassDestinationMacAddresses

Frames with one of the configured destination MAC addresses

Bypass lists are essential in practice for boot and management traffic that has to flow before the MACsec session is even established (i.e. before valid secure associations exist).

Setting up secure channels and secure associations

MACsec secure association setup

Per the SWS, there may only ever be one secure association per association number (An) at a time. To create a new SA with the same An, the previous one must first be removed via EthSwt_MacSecDeleteRxSa/DeleteTxSa.

All of these APIs are addressed via EthSwt_MgmtInfoType (SwitchIdx+SwitchPortIdx) — the same structure also used by the switch management support for timestamp metadata (see this series' Global Time post). Notably, every secure-association function is asynchronous, hinting at potentially longer hardware access times during key loading.

Shared key infrastructure with EthTrcv

EthSwt_MacSecAddTxSa/AddRxSa expect a Mka_SakKeyPtrType pointer — the same type used by the MKA implementation on the EthTrcv side (see the EthTrcv MACsec post). That confirms: there’s one central MKA instance generating key material (SAK) — whether the actual encryption/decryption happens in the transceiver or the switch is purely a matter of hardware placement, not separate key management.

Statistics and PAE control

  • EthSwt_MacSecGetMacSecStatistics provides MACsec statistics for an MKA participant (Mka_Stats_SecYType)

  • EthSwt_MacSecGetTxSaNextPn returns the next packet number of a transmit SA — important for replay-protection monitoring

  • EthSwt_MacSecSetControlledPortEnabled enables/disables the PAE’s controlled port (Port Access Entity, IEEE 802.1X concept) — the port through which data traffic may only flow after successful authentication

Summary

AspectKey takeaway

Activation

EthSwtPortMacSecEnabled per port, with granular bypass lists for EtherTypes/VLANs/destination MACs

SA management

Init/Add/Update/Delete for Rx and Tx secure associations, exactly one SA per An

Addressing

Via EthSwt_MgmtInfoType (SwitchIdx + SwitchPortIdx)

Key infrastructure

Shared MKA types (Mka_SakKeyPtrType) with the EthTrcv side — one central key source, two possible encryption locations