MACsec

MACsec uses Security Channels (SC) and Secure Association Keys (SAKs) to encrypt a Connectivity Association (CA).

A CA represents a group of nodes connected through a unidirectional secure channel. It is a security relationship, established and maintained by key agreement protocols comprised of a fully connected subset of the service access points. These access points are in stations attached to a single LAN that are supported by MACsec. Each CA has its own Security Association (SA) that uses its own SAK. More than one SA is permitted in a CA for the purpose of a key change without traffic interruption, but at least two SAs are required for rollover.

MACsec security TAG

The MACsec 802.1AE header includes a security TAG (SecTAG) field that contains the following information:

• association number within the channel
• packet number to provide a unique initialization vector for encryption and authentication algorithms, as well as protection against replay attack
• optional LAN-wide secure channel identifier

The SecTAG field, which is identified by the MACsec EtherType, conveys the following information:

• TAG Control Information (TCI)
• Association Number (AN)
• Short Length (SL)
• Packet Number (PN)
• Optionally-encoded Secure Channel Identifier (SCI)

The following figure shows the format of the SecTAG.

The main modes of encryption in MACsec are:

• VLAN in clear text (WAN mode)
• VLAN encrypted (LAN mode)

MACsec uses 802.1AE standard to encrypt the Layer 2 packet including the 802.1Q tag and the payload.

With 802.1AE encryption, the following apply to MACsec:

• frames are encrypted and protected with an integrity check value (ICV)
• MACsec EtherType is 0x88e5
• there is no impact to IP MTU or fragmentation

The following figure shows the MACsec LAN mode structure.

The original 802.1AE encrypts the 802.1Q and QinQ tags. In a WAN environment where the switching could be based on 802.1Q tag, Nokia recommends putting the 802.1Q in clear.

The following figure shows the MACsec WAN mode structure.

MACsec can be configured to leave one or two VLAN tags in clear. When MACsec is configured to put a single VLAN tag in clear, MACsec blindly puts 4 bytes in clear, regardless of whether there is a VLAN present. The same is true when two VLAN tags are in clear; when this occurs, MACsec blindly puts 8 bytes in clear.

When enabling encryption, MACsec can set an offset that sends the first 30 or 50 octets in unencrypted plain text.

When the offset is set to 30, the IPv4 and TCP and UDP headers are left unencrypted while the rest of the traffic is encrypted. When the offset is set to 50, the IPv6 and TCP and UDP headers are left unencrypted while the rest of the traffic is encrypted.

The MACsec encryption offset is typically used for forward traffic when a feature requires data to be expressed in octets to perform a function like load balancing (that is, where the IP and TCP and UDP headers in the first 30 or 50 octets need to be in clear text to properly load balance traffic).

The default offset is 0, so all traffic on the link is encrypted when the encryption option is enabled and an offset is not set.

MACsec uses pre-shared key (PSK) to wrap the SAK. SAKs are generated and distributed by the key server in CA to encrypt data plane PDUs. The key server on the CA is negotiated through MACsec Key Agreement (MKA) protocol based on a configurable key server value.

PSK is built using the following:

• Connectivity Association Name (CKN), a 64-digit hexadecimal number
• Connectivity Association Key (CAK), a 32-digit hexadecimal number

On SR Linux, the PSK is configured using keychains and can be rolled over based on the keychain lifetime. The CAK and CKN can only be changed in the key entry of a keychain when the key entry is administratively down.

The following figure shows how MACsec uses the CAK to secure the SAK to be distributed from the key server to the peer.

After the CAK is configured in the keychain it is used to obtain the following keys:

• KEK (Key Encryption Key), which is used to wrap encrypt the SAKs
• ICK (Integrity Connection Value (ICV) Key), which is used to check the integrity of each MKPDU send between two CAs

The key server then generates a SAK that is shared with the CAs of the security domain, and that SAK is used to secure all data traffic traversing the link. The key server periodically creates and shares a randomly created SAK over the point-to-point link for as long as MACsec is enabled.

The KEK is used by MKA to securely transport a succession of SAKs for use by MACsec to other members of a CA. It is derived from the CAK using the transformations described in the following table.

The ICK is used to verify the integrity of MKA PDUs and is derived from the CAK using the transformations described in the following table.

When configuring a MACsec keychain, Nokia recommends that key entries in a keychain:

• should not have the same start time
• should have a time distance of at least one minute
• should not have the same CKN

The following shows an example of a keychain configuration.

--{ * candidate shared default }--[ system authentication keychain AABBCCDD ]--
A:root@srl2# info with-context
    system {
        authentication {
            keychain AABBCCDD {
                admin-state enable
                type macsec
                key 1 {
                    algorithm aes-256-cmac
                    macsec {
                        cak $aes1$AWbFjByk7B2lWG8=$vzHM3n5itXoYRc2CceaTCpQv8QmKRlCiXO9NneByprL/T71keYsutp9SWHwT3ZLOuBLbSzJT0jLfhK6zgq6KVg==
                        key-name AABBCCDDEEFF0000000000000000000000000000000000000000000000000001
                        admin-state enable
                    }
                    send-lifetime {
                        start-time 2025-02-21T21:00:00.000Z
                    }
                }
                key 2 {
                    algorithm aes-256-cmac
                    macsec {
                        cak $aes1$AWZ90wmhzvYqFm8=$nkij57SBGanMvRjrLkXy0PM9tIG5BQ+boT0e9qGC+u3oLV5ZkeLWJHxC1Yq/gvl+4cBfwbyYru4vznc9xU2AfA==
                        key-name AABBCCDDEEFF0000000000000000000000000000000000000000000000000002
                        admin-state enable
                    }
                    send-lifetime {
                        start-time 2025-02-21T21:01:00.000Z
                    }
                }
            }
        }
    }

MACsec can exclude the following protocols from encryption and decryption:

• CPU SGT
• CPU generated protocols:
  • PTP
  • uBFD
• SGT from datapath ASIC (mostly OAM)