Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

MACsec: a different solution to encrypt network traffic

October 14, 2016
Sabrina Dubroca
Related topics:
Linux
Related products:
Red Hat Enterprise Linux

Share:

    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.

    Introduction

    The 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.

    headersFigure 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

    LAN

    The 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

    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

    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.

    VXLAN

    MACsec 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

    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/TLS

    SSL/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 example

    Going  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.

    Example LAN setup with a standard switchNote: 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# ip link show eth0
    7: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
        link/ether 42:f8:ad:3a:e6:08 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    host1# ip link add link eth0 macsec0 type macsec encrypt on
    host1# ip link show macsec0
    8: macsec0@eth0: <BROADCAST,MULTICAST> mtu 1468 qdisc noop state DOWN mode DEFAULT group default qlen 1000
        link/ether 42:f8:ad:3a:e6:08 brd ff:ff:ff:ff:ff:ff
    host1# ip macsec show
    8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off
        cipher suite: GCM-AES-128, using ICV length 16
        TXSC: 42f8ad3ae6080001 on SA 0
    

    And similarly, on the second machine:

    host2# ip link show eth0
    7: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
        link/ether 32:53:41:bd:7c:27 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    host2# ip link add link eth0 macsec0 type macsec encrypt on
    host2# ip link show macsec0
    8: macsec0@eth0: <BROADCAST,MULTICAST> mtu 1468 qdisc noop state DOWN mode DEFAULT group default qlen 1000
        link/ether 32:53:41:bd:7c:27 brd ff:ff:ff:ff:ff:ff
    host2# ip macsec show
    8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off
        cipher suite: GCM-AES-128, using ICV length 16
        TXSC: 325341bd7c270001 on SA 0
    

    We can now add matching receive channels on both machines:

    host1# ip macsec add macsec0 rx port 1 address 32:53:41:bd:7c:27
    host1# ip macsec show
    8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off
        cipher suite: GCM-AES-128, using ICV length 16
        TXSC: 42f8ad3ae6080001 on SA 0
        RXSC: 325341bd7c270001, state on
    

    And similarly, on the second machine:

    host2# ip macsec add macsec0 rx port 1 address 42:f8:ad:3a:e6:08
    host2# ip macsec show
    8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off
        cipher suite: GCM-AES-128, using ICV length 16
        TXSC: 325341bd7c270001 on SA 0
        RXSC: 42f8ad3ae6080001, state on
    

    Let's now generate some keys. We need a key for each machine's transmit channel. That same key must be configured on the peer's matching receive channel.

    These commands will generate two 128-bits keys, in a format suitable to configure with the ip command.

    # dd if=/dev/urandom count=16 bs=1 2>/dev/null | hexdump | cut -c 9- | tr -d ' \n'
    ead3664f508eb06c40ac7104cdae4ce5
    # dd if=/dev/urandom count=16 bs=1 2>/dev/null | hexdump | cut -c 9- | tr -d ' \n'
    dffafc8d7b9a43d5b9a3dfbbf6a30c16
    

    We can now configure the transmit keys on the first machine:

    host1# ip macsec add macsec0 tx sa 0 pn 1 on key 00 ead3664f508eb06c40ac7104cdae4ce5
    host1# ip macsec show
    8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off
        cipher suite: GCM-AES-128, using ICV length 16
        TXSC: 42f8ad3ae6080001 on SA 0
            0: PN 1, state on, key 00000000000000000000000000000000
        RXSC: 325341bd7c270001, state on
    

    And on the second machine:

    host2# ip macsec add macsec0 tx sa 0 pn 1 on key 01 dffafc8d7b9a43d5b9a3dfbbf6a30c16
    host2# ip macsec show
    8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off
        cipher suite: GCM-AES-128, using ICV length 16
        TXSC: 325341bd7c270001 on SA 0
            0: PN 1, state on, key 01000000000000000000000000000000
        RXSC: 42f8ad3ae6080001, state on
    

    We also need to configure the receive keys, so that machine 1 can decrypt the traffic coming from machine 2:

    host1# ip macsec add macsec0 rx port 1 address 32:53:41:bd:7c:27 sa 0 pn 1 on key 01 dffafc8d7b9a43d5b9a3dfbbf6a30c16
    host1# ip macsec show
    8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off
        cipher suite: GCM-AES-128, using ICV length 16
        TXSC: 42f8ad3ae6080001 on SA 0
            0: PN 1, state on, key 00000000000000000000000000000000
        RXSC: 325341bd7c270001, state on
            0: PN 1, state on, key 01000000000000000000000000000000
    

    And on machine 2, to decrypt traffic coming from machine 1:

    host2# ip macsec add macsec0 rx port 1 address 42:f8:ad:3a:e6:08 sa 0 pn 1 on key 00 ead3664f508eb06c40ac7104cdae4ce5
    host2# ip macsec show
    8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off
        cipher suite: GCM-AES-128, using ICV length 16
        TXSC: 325341bd7c270001 on SA 0
            0: PN 1, state on, key 01000000000000000000000000000000
        RXSC: 42f8ad3ae6080001, state on
            0: PN 1, state on, key 00000000000000000000000000000000
    

    Our MACsec links are now ready, we can enable them and add IP addresses on both machines:

    host1# ip link set macsec0 up
    host1# ip addr add 10.1.0.1/24 dev macsec0
    
    host2# ip link set macsec0 up
    host2# ip addr add 10.1.0.2/24 dev macsec0
    

     

    All the traffic between machines 1 and 2 using the addresses 10.1.0.1 and 10.1.0.2 will be protected by MACsec.

    If you send some traffic directly on eth0, using the IP address configured on that interface, that traffic won't be protected.
    You can still use eth0 to communicate with machines that are not configured to use MACsec, or to connect to other networks.

    Limitations

    As stated earlier, MACsec only operates on layer 2, so it can only protect a single LAN, and offers no protection when traffic is routed. This single LAN can be a physical LAN, or a virtual LAN, such as those provided by overlay network technologies like VXLAN, GENEVE, etc.

    MACsec also cannot protect against malicious layer 3 traffic coming from a different network interface, on a machine connected to multiple LANs. For example, attacks that rely on forcing traffic to leave from other interfaces, using ARP spoofing or IP redirects, cannot be prevented using MACsec alone. As always with security-related matters, careful configuration is necessary to eliminate flaws that lead to a weakening of the entire setup.

    Conclusion

    MACsec was standardized 10 years ago, but has only made its way into the Linux kernel a few months ago. We hope it will see further adoption, both in use cases we had in mind when we decided to write this implementation and in new setups.

    Since MACsec provides different security properties than those of other cryptographic protocols, it might enable the use of strong encryption in cases where it would not have been convenient before.

    We are still working on integration with other components (mainly NetworkManager and wpa_supplicant), and further improvements to the kernel parts.

    Last updated: February 22, 2024

    Recent Posts

    • Assessing AI for OpenShift operations: Advanced configurations

    • OpenShift Lightspeed: Assessing AI for OpenShift operations

    • OpenShift Data Foundation and HashiCorp Vault securing data

    • Axolotl meets LLM Compressor: Fast, sparse, open

    • What’s new for developers in Red Hat OpenShift 4.19

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue