MACsec is an IEEE standard for security in wired ethernet LANs. This blog , will give an overview of what MACsec is, how it differs from other security standards, and present some ideas about how it can be used.
MACsec is a Layer 2 protocol that relies on GCM-AES-128 to offer integrity and confidentiality, and operates over ethernet. It can secure all traffic within a LAN, including DHCP and ARP, as well as traffic from higher layer protocols. It is an extension to 802.1X provides secure key exchange and mutual authentication for MACsec nodes. IPsec (a Layer 3 security protocol) and TLS (a Layer 4 security protocol) offer different guarantees and can be a better fit, depending on the use case. IntroductionThe current landscape of cryptographic network protocols is rather narrow. By default, TCP/IP doesn’t offer any security guarantee. Besides TLS and IPSec, most other protocols in use today are proprietary.
MACsec hasn’t gained much traction yet, but now with an open source implementation available in the linux kernel, this is will very likely change.
What is MACsec?As a layer 2 specification, MACsec can protect not only IP traffic, but also ARP, neighbour discovery, and DHCP. It relies on GCM-AES to ensure the confidentiality and integrity of all the network traffic.
MACsec was standardized in 2006 by IEEE (standard IEEE 802.1AE-2006), but support was only recently added to the mainline Linux kernel (as of 4.6). In MACsec, packets flow over “secure channels”, which are supported by “secure associations”. The secure associations each use a separate, randomly generated key.
IEEE 802.1X-2010 defines a companion protocol, MACsec Key Agreement (MKA), which provides key exchange and allows mutual authentication of nodes that want to take part in a MACsec connectivity association. On Linux machines, this is implemented in wpa_supplicant. wpa_supplicant uses some authentication token (a pre-shared key, or a username/password pair, similarly to the authentication mechanisms used in WiFi) to establish a session with the authentication server, which can be a switch or a Linux host running hostapd. After authentication, keys are generated and exchanged (over an encrypted channel), and are used to configure the MACsec secured link.
On the wire, a MACsec packet starts with an Ethernet header with EtherType 88E5. This is followed by the MACsec SecTAG, which contains information that help the receiver identify the decryption key, as well as a packet number (for replay protection). After the SecTAG comes the payload, which can be encrypted, and the ICV (Integrity Check Value), which is generated by GCM-AES, and guarantees that the packet was indeed created by a node which was in possession of the key, and hasn’t been modified on the way.
Figure An Ethernet frame, before (above) and after (below) MACsec processing and encryption Architecture of a MACsec network
In a MACsec-protected network, each node has at least one transmit secure channel . This transmit secure channel is associated with an identifier: the secure channel identifier (SCI). The transmit secure channel also stores various configuration parameters, such as whether to perform replay protection, or whether to enable encryption.
Each node which expects to receive traffic sent through a particular transmit secure channel must configure a matching receive secure channel . This receive secure channel must have a SCI corresponding to the SCI of the transmit secure channel of the peer.
Within each secure channel (both transmit and receive), secure associations are defined. The secure associations hold the encryption keys, and are identified by their association number . Another important parameter is associated with each secure association: the packet number . On the transmit side, this packet number is put in the MACsec header and used in the encryption process. On the receive side, the packet number from the MACsec header can be checked against the packet number locally stored in the corresponding secure association to perform replay protection.
Use cases LANThe main use case for MACsec is to secure a standard LAN. In this setup, multiple machines connected to the same LAN are configured so that all packets exchanged between them are encrypted and can only be received by these nodes.
In these figures, a red link means that packets are not protected by MACSec. Only grey links are secured by MACsec.
Example LAN setup with a standard switch
In this first setup, the switch is not capable of encrypting frames, but it can forward MACsec-protected frames between ports. MACsec is terminated on the hosts.
An alternative solution is to use a switch which supports MACsec. In that case, MACsec is enabled on the client machines as well as on the switch ports to which these machines are connected. Those access switches often also provide 802.1X services to allow strong authentication, authorization and accounting to occur before finally allowing the client to join the network.
Example LAN setup with a MACsec-capable switch
The second of these LAN setups uses a MACsec-capable switch, but hosts 3 and 4 are not using MACsec. MACsec is terminated on the switch ports.
VXLANMACsec is also compatible with VXLAN and other tunneling technologies such as GENEVE and GRETAP. A cloud customer with a virtual private LAN can use MACsec to encrypt all the internal traffic before it leaves the virtual machines. That way the cloud provider cannot peek into the communication between the VMs.
Example Cloud topology with VXLAN Comparison to other security protocols IPsec
First of all, MACsec and IPsec operate on different network layers. IPsec works on IP packets, at layer 3, while MACsec operates at layer 2, on ethernet frames. Thus, MACsec can protect all DHCP and ARP traffic, which IPsec cannot secure. On the other hand, IPsec can work across routers, while MACsec is limited to a LAN.
With both MACsec and IPsec, user applications do not need to be modified to take advantage of the security guarantees that these standards provide.
In Red Hat Enterprise Linux, IPsec support is provided by the libreswan package.
SSL/TLSSSL/TLS operates on yet another layer, namely the fifth (application) layer. Thus securing applications might require application changes, which can prove to be quite problematic.
On the other hand, embedding the cryptographic layer directly into applications also offers some advantages. The software is capable of checking on its own the state of encryption and authenticity based on policies and can react accordingly. Verifying those security properties directly in the application can provide end-to-end security.
In Red Hat Enterprise Linux, SSL/TLS is provided by several libraries like GnuTLS, NSS, OpenJDK/JSSE, and OpenSSL (in alphabetical order).
Configuration exampleGoing back to the first use case, where MACsec was used in a LAN with a legacy switch. We will create MACsec devices on both machines, and setup channels and encryption keys so that they can communicate.
Note: the MAC addresses in the examples below are the addresses used by the devices in my environment. You will need to replace them with the MAC addresses of the interfaces in your setup.
On the first machine:
host1