Modern networks are not only threatened by external attacks but are increasingly exposed to internal risks as well. These include unauthorized physical access to network components or manipulated data streams within the LAN. Classic Network Access Control (NAC) based on IEEE 802.1X-2004 often only provides one-time authentication but does not ensure continuous protection of transmitted packets. For companies and authorities requiring higher security standards, this gap becomes a risk factor.
This is where MACsec (Media Access Control Security) comes into play. The protocol encrypts and verifies the integrity of data at Layer 2, directly at the point of entry into the network. Thus, it protects not only against external attacks but also against internal manipulations and unauthorized access to sensitive communication paths.
What is MACsec?
MACsec secures communication in wired networks, such as between switches, using cryptographic mechanisms. While Network Access Control according to IEEE 802.1X-2004 only enables authentication via the EAP framework and, at most, provides for periodic re-authentication, it does not offer integrity checks or confidentiality at this communication level. This leads to significant vulnerabilities, especially for network connections in areas accessible to third parties, such as WiFi access points, multifunction devices, or PCs behind screens in public building corridors. Potential attackers could inject data packets into the network via a man-in-the-middle attack at an authenticated switch port.
Only the combination of IEEE 802.1X-2010 with the MACsec standard (IEEE 802.1AE) closes this gap: it ensures both data integrity and confidentiality. Compared to traditional IPsec-based encryption solutions, MACsec stands out due to its higher performance and lower implementation complexity, because it only has 4 cipher suites: AES128-GCM, AES256-GCM, AES128-GCM-XPN and AES256-GCM-XPN. However, it can also be combined with other security protocols such as IPsec or TLS at higher layers if required.
Another advantage of MACsec is its transparent transmission of Layer 2 protocols such as LLDP, CDP, LACP, or ARP. Since MACsec is located below IPv4/IPv6 in the OSI reference model, it remains compatible with both IP versions. The hardware-based implementation enables high performance up to full line rate and effectively protects against attacks such as session spoofing, replay attacks, or man-in-the-middle attacks.
MACsec Keywords
| Abbreviation | Term | Description |
|---|---|---|
| CA | Connectivity Association | Secured control-plane connection between MACsec peers. |
| CAK | Connectivity Association Key | Control-plane key from which the session key is derived. |
| SA | Security Association | Connection between two MACsec peers that guarantees an encrypted connection based on the SAK. |
| SAK | Security Association Key | Session key derived from the CAK, used for encryption between two MACsec peers. |
| SC | Secure Channel | Logical channel within which encrypted transmission takes place. |
| SCI | Secure Channel Identifier | Unique identifier for the secure channel, consisting of the MAC address and port designation. |
| MKA | MACsec Key Agreement | Key agreement protocol used to locate MACsec peers, generate, renew, and exchange keys. |
| CKN | Connectivity Association Key Name | Serves as a framework for the CAK. Peers transmit this to each other in plaintext for validation. |
| Supplicant | Supplicant | Client component for authentication according to IEEE 802.1X. |
| Authenticator | Authenticator | Component that performs authentication via EAPoL with the supplicant and via the RADIUS protocol with the Authentication Server. The RADIUS server denies or grants access based on authorization. |
| Authentication Server | Authentication Server | RADIUS server for authentication, authorization, and accounting according to IEEE 802.1X. |
Application Scenarios for MACsec
MACsec can be deployed in two central scenarios: securing the connection between a switch and an end device, or encrypting switch-to-switch connections. Both variants provide targeted protection against manipulation and eavesdropping on the network link.
Scenario: Switch ↔ End Device
In this scenario, MACsec secures the link between an end device (supplicant) and the switch (authenticator). After the physical link is established, the authentication process begins: The supplicant and authenticator exchange EAPoL frames. The switch forwards the authentication data to the Authentication Server (RADIUS server) as a RADIUS request.
The server verifies the certificate contents for EAP-TLS authentication (mutual certificate authentication). Unlike IEEE 802.1X-2004, the combination with IEEE 802.1X-2010 and 802.1AE enables enhanced authorization after successful authentication. The Authentication Server sends a MACsec policy to the switch in the “RADIUS Access-Accept” message. The switch then activates MACsec, provided both sides (supplicant and authenticator) support compatible encryption algorithms (e.g., AES-GCM-128 or AES-GCM-256).
Subsequently, the two communication partners generate a Master Session Key. Using the MACsec Key Agreement (MKA) over EAPoL Frames (Ethertype 0x888e), they exchange the required key material, which forms the basis for the subsequent encrypted data transmission.
Scenario: Switch ↔ Switch
Here, MACsec is used to encrypt the connection between two switches (point-to-point) or among multiple switches (point-to-multipoint). This is particularly relevant when third parties have physical access to the cabling or when connections pass through insecure environments, such as Metro Ethernet networks, dark fiber connections, or optical fibers running through external areas. Without encryption, attackers could intercept and analyze data via bend couplers or TAPs, or even inject malicious data.
MACsec encrypts the payload of MAC frames, making analysis without the key impossible. However, for Metro Ethernet connections over provider networks, it must first be clarified whether the provider allows the transmission of MACsec frames (EtherType 0x88e5) in their network.
Scenario: Cloud Provider
If you consider direct peerings to cloud providers like Amazon Web Services (AWS) with Direct Connect, Cloud Interconnect to Google Cloud Platform (GCP) or Express Route to Azure, the link between your on-premises datacenter equipment and cloud datacenter is encrypted by MACsec. Ciphers and link speeds differ by cloud provider. In the end, there should be no possibility to inject packets or capture packets via possible unauthorized TAPs in the link between on-premises and cloud datacenter.
How to Decrypt in Wireshark?
(The following packet captures are part of the Ultimate PCAP, incl. the session keys in the comments of the first MACsec packets. Have a look at them yourself.)
You have two options for decryption of MACsec in Wireshark depending on the key distribution. If you use so-called „Static SAK Mode“ with static session keys, you could decrypt by going to Preferences/Protocols/MACsec/Pre-Shared Key List and enter the static session key into the key column and key number into the info column. Afterwards, Wireshark will decrypt your MACsec frames:
If you use static CAK mode with dynamically generated SAKs, you could even decrypt MACsec frames based on CKN and CAK information and enable usage of MKA for decryption. For this, you need to go to Preferences/Protocols/MACsec and set the „Also Use MKA for Decode“ option to „True“. Afterwards, you need to set CKN and CAK under Preferences/Protocols/EAPOL-MKA. In the Info column, you could type in a description for this CKN/CAK value pair. Afterwards, Wireshark will decrypt your MACsec frames as well:
Photo by Sasun Bughdaryan on Unsplash.