Under Seal

Networks are exposed to more than external attacks. Appropriate defenses need to be implemented at the entry point to the internal network or, if third parties have physical access, to access points on the network. Initial authentication during access to the local area network (LAN) without downstream verification of the transmitted packets, as with classic network access control (NAC) systems, is no longer sufficient. One approach is Media Access Control Security, (MACsec), which encrypts in Layer 2, with virtually no loss of speed.

The MACsec [1] Layer 2 security protocol is used for cryptographic point-to-point security on wired networks (e.g., on switches). Network access controls compliant with IEEE 802.1X-2004 (i.e., port-based network access control) only provide authentication by the Extended Authentication Protocol (EAP) framework – in the best case combined with periodic re-authentication. However, without an integrity check, confidentiality cannot be guaranteed at this level of the communication relationship, unless you apply a later version, IEEE 802.1X-2010, in combination with 802.1AE (MACsec).

The standard offers better performance and is less complex to implement than classic Internet Protocol Security (IPsec)-based encryption. If required, however, a combination with other security protocols such as IPsec and Transport Layer Security (TLS) is also possible. At the same time, Layer 2 protocols such as Link Layer Discovery Protocol (LLDP), Cisco Discovery Protocol (CDP), and Link Aggregation Control Protocol (LACP), as well as Address Resolution Protocol (ARP), can be transmitted transparently. MACsec also is compatible with IPv4 and IPv6 because it resides one layer below in the OSI reference model.

Because MACsec is implemented at a low level close to the hardware, it demonstrates high performance up to the full line rate (i.e., the maximum possible data rate of the link). Attacks such as session spoofing, replay attacks, or man-in-the-middle attacks are thwarted. However, MACsec does not ensure end-to-end encryption.

Securing Switch to Terminal Device

In scenario 1, MACsec secures the link from a terminal device to the switch. The objective is encrypted transmission between the two devices after successful authentication and authorization. In the IEEE 802.1X terminology, the end device in this case is referred to as the supplicant, the switch is referred to as the authenticator, and the RADIUS server is the authentication server.

The first step after link building is to authenticate the supplicant with EAP over LAN (EAPoL) frames between the supplicant and the authenticator. To generate a RADIUS request for authentication from the authenticator to the authentication server on the basis of this type of EAP frame, the authenticator packages the requests into RADIUS request messages. The supplicant's corresponding EAP method must be enabled on the RADIUS server – for example, with the Protected Extensible Authentication Protocol and Microsoft Challenge-Handshake Authentication Protocol version 2 (PEAP-MSCHAPv2) for TLS-protected transfer of the username and password after validation of the RADIUS server's authentication certificate, or with EAP-TLS if you want two-way TLS authentication between the supplicant and the authentication server.

The main difference between authentication in the older variant by IEEE 802.1X-2004 and IEEE 802.1X-2010 in conjunction with 802.1AE is that authorization with additional attributes occurs on the basis of successful authentication. For this to happen, the authentication server returns a RADIUS Access-Accept with the MACsec policy to the authenticator. In this way, the authenticator recognizes that it needs to use MACsec (Figure 1). The matching encryption algorithms, such as the Advanced Encryption Standard in Galois Counter Mode at 128 or 256 bits (AES128-GCM or AES256-GCM), must be configured identically on the supplicant and authenticator. Additionally, the master session key is generated.

Figure 1: Communication between the authentication server, authenticator, and supplicant.

This master session key is then used as the basis for a key exchange with a MACsec Key Agreement (MKA; see Table 1 for MACsec terminology). After the MKA process, the authenticator and supplicant have the key material required to handle encrypted data transmission.

Securing Switch to Switch

In scenario 2, MACsec encryption is used for the connection between two switches. If third parties have physical access to the cabling, MACsec transmission is recommended if you have a corresponding need for protection and if no other adequate encryption methods are used. Examples of this scenario include Layer 2 connections by providers, as used in metropolitan area Ethernet environments. However, the same also applies to dark fiber connections operated by third parties or if your own fiber optic connections run through a third party.

Without encryption on these kinds of routes, someone could route data out by couplers or network TAPs for data analysis downstream. The payload of the MAC frame is encrypted if MACsec is used and therefore cannot be easily evaluated. For provider connections, however, you need to clarify whether you can transmit MACsec frames with an Ethertype of 0x88e5 on the provider's network. Because MACsec works on Layer 2, it must be individually enabled for each interface.

Encryption Method

MACsec uses AES-GCM as the encryption algorithm, encrypting hop-by-hop, which has both advantages and disadvantages. Key lengths of 128 and 256 bits are available. With the 802.1AEbw standard, IEEE introduced extended packet numbering (GCM-AES-XPN) for the current requirements for high data rates. As a result, MACsec can transmit 232 frames within a security association key (SAK). This extension enables MACsec to encrypt securely at data rates above 100Gbps. The algorithm used must match the configuration of the switch and the end device or match both switches.

The MACsec header in IEEE 802.1AE is also referred to as the security tag (SecTAG). Its length is 16 bytes. The same applies to the integrity check value (ICV) that MACsec appends to the frame. The security tag comprises five fields: EtherType, TAG control information/association number (TCI/AN), short length (SL), packet number (PN), and SCI. The MACsec EtherType contains the value 0x88E5. The TCI/AN defines a version number for MACsec without the need for a new EtherType. The SL field states the length of the encrypted data. The SCI is based on an identifier of the respective port on the component and the MAC address.

The entire MACsec frame is similar to an Ethernet frame. It also contains an ICV to ensure that the frame has not been manipulated en route. To this end, the MACsec peers decrypt incoming frames and calculate the expected ICV with the session key from the MKA. If this does not match the transmitted ICV, the receiving peer discards the frame.