There are various protocols that have been developed as a means of securing the network. One of these protocols is IEEE 802.1AE Media Access Control Security, better known as MACsec, which is designed to secure communication for authorized endpoints on the local area network (LAN). With MACsec, each packet on the wire is encrypted using specific key cryptography techniques to prohibit any communication from being monitored and/or altered on the wire.
It is common practice for network administrators to use MACsec to ensure data authenticity and confidentiality, prohibit any tampering with data on the wire as well as preventing DHCP and ARP attacks.
Let’s take a closer look at MACsec details. The protocol is typically broken down into three distinct components seen in Figure 1 below.
- Supplicant – The Client that runs on endpoint devices and submits credentials for authentication
- Authenticator – Network access device that facilitates the authentication process by relaying credentials to the server
- Authentication Server – Validates the credentials of the devices and determines what access the supplicant should receive.
Figure 1: MACsec protocol components
To encrypt a session, the Supplicant and Authenticator must first use the Extensible Authentication Protocol (EAP) to create a Master Session Key between each other to be used during the session. The Master Session Key is created through a protocol called connectivity association key (CAK). The CAK is a static key that is preconfigured on each MACsec enabled interface.
Once CAK is performed, a session key agreement (MKA) takes place. During the process, the two devices will show their capabilities to each other using EAPoL. EAPoL, like EAP, is a simple encapsulation that can run over any local area network. If MACsec is available, both devices will agree, and the master device then selects a cipher suite. Cipher suites are basically a complete set of algorithms needed to secure a network connection through SSL/TLS.
The default cipher suite used for most products including Cisco and Juniper is GCM-AES-128. Once a secure association key (SAK) is created from CAK, which is used to encrypt traffic on the wire, the key is sent over the wire with encrypted CAK-derived keys to ensure its security.
Once the key agreement and communication is complete, traffic that is transmitted between the two devices and non-encrypted traffic is dropped. Within the switch, the decrypted packet is used in order to use the native policies and QOS features of the switch. Upon transmit, the packet is encrypted and sent back onto the wire. The diagram below shows the MACsec packet structure.
Figure 2: MACsec packet structure
MACsec encrypts the Layer 2 payload by default including the ethernet type. The encrypted data is encapsulated with two headers: a Security Tag (SecTag) which gives information about the MACsec protocol (including which key to look up), and the ICV (Integrity Check Value) which validates that the transmitted encrypted packet has not been altered with. This field is between 8-16 bytes long, depending on the header information. Appended to the ICV is the new CRC of the packet. The Encryption Protocol used typically defaults to AES-128-GCM. However, the master Key Server can select whichever one is available. A common implementation is the AES-256-GCM because it is a more secure version of the 128-bit value. Figure 3 below shows the SecTag format.
Figure 3: SecTag format
The Security Tag consists of multiple fields. The SAKs (security association keys) are updated based on the packet number and a threshold that is assigned. Typically, these values are updated every five minutes.
Masterkeys (whether paired or group) are not used to encrypt data, but rather to produce encryption keys (called temporal keys) that are used to encrypt data. Currently, the key must be manually inserted in switches using the Pairwise Master Key (PMK). This value is then used along with a 128-bit nonce to generate a temporal key which is then used to encrypt data on the wire
How to configure cPacket’s cVu to decrypt MACsec links
To properly configure cVu to decode MACsec encrypted link, the user will have to enable the feature on the ports that will be carrying MACsec encrypted messages and then set the Pre-shared key (PSK). By design, the port mode will be set on groups of four consecutive ports simultaneously.
To begin the configuration, complete the following steps:
1. Login to cVu
2. Go to config/status and select Port Configuration
3. Set New Mode as MACsec for the desired ports (seen below in Figure 4)
Figure 4: cVu configuration
4. The system will ask for a reboot: select confirm and wait for the system to be rebooted. It’s important to note that if the port mode doesn’t display MACsec after the reboot, it’s recommended to clear the cache and reload the page
5. Select MACsec Decryption leaf from the Settings menu
6. Enable the ports that will be carrying the Encrypted messages through the checkmark and set the PreShared Key (seen below in Figure 5)
Figure 5: Enabling ports on cVu
On the switch side, the user needs to select the PSK as well.
In order for this feature to work, the handshake procedure for the key exchange must be intercepted. If it’s not intercepted, the system cannot obtain the correct key values to perform the decryption. Once properly configured, the user should be able to see that the cVu is decrypting network traffic by forwarding the traffic to a packet capture device such as cPacket’s cStor. The result should show cleartext packets.
There are several instances that require further analysis to verify that decryption is being performed correctly. One method of verification is to use filters on cVu to intercept MACsec encrypted packets as well as the key exchange to verify that the exchange is taking place. Without filters, the system will not be able to decode the packets properly. Figure 6 below shows an example of the filters that can be set on cVu to count MACsec signaling messages from the key exchange (which use a predefined ethertype in the packets).
Figure 6: Setting the filters on cVu
One succinct benefit of cPacket’s cStor is its built-in dissector. This is very helpful for decoding the MACsec handshake messages. To access the dissector, simply go to the admin menu on the top right of the screen and select download seen in figure 7 below.
Figure 7: Accessing the dissector feature in cStor
You will then be prompted to choose from a list of dissectors. Select the MACSEC EAPOL dissector and save it on your computer. The file will have a “. iua” extension.
Figure 8: Selecting from list on dissectors for Wireshark
To incorporate the dissector, invoke Wireshark using the following syntax:
wireshark -X lua_script:cpkt_eapol_key.lua &
In sum, the expansion of cloud services, increased usage of mobile devices and video traffic are all contributing factors to the demand for increased bandwidth. It becomes clear that the requirement for encryption rates to align at speeds beyond 100 G at any packet size, is vital. While MACsec continues to be the preferred choice for next-generation high-speed encryption in most industries like enterprise, financial and service providers, it still creates visibility challenges for network monitoring tools that are unable to analyze traffic at speeds of 100 G or more. In addition, network engineers often struggle to access the required cleartext packet information needed to diagnose network performance and/or security issues.
cPacket’s cVu overcomes these challenges with a multitude of capabilities. cVu can decrypt MACsec encrypted traffic at the wire which enables networking monitoring tools such as cVu traffic sensors to analyze this traffic accurately while still ensuring network security. In addition, cPacket’s cStor can show cleartext packets, a necessary feature to ensure network performance is fully optimized and secure.
Contact us for a free demo to learn more about cPacket’ s cVu and the benefits it can provide for your network.