Configuring Media Access Control Security (MACsec) on Routers

Media Access Control Security (MACsec) is an industry-standard security technology that provides secure communication for almost all types of traffic on Ethernet links. MACsec provides point-to-point security on Ethernet links between directly-connected nodes and is capable of identifying and preventing most security threats, including denial of service, intrusion, man-in-the-middle, masquerading, passive wiretapping, and playback attacks. MACsec is standardized in IEEE 802.1AE.

Starting with Junos OS Release 15.1, you can configure MACsec to secure point-to-point Ethernet links connecting MX Series routers with MACsec-capable MICs, or on Ethernet links connecting a switch to a host device such as a PC, phone, or server. Each point-to-point Ethernet link that you want to secure using MACsec must be configured independently. You can enable MACsec on router-to-router links using static connectivity association key (CAK) security mode. The process is provided in this document.

Configuring MACsec Using Static Connectivity Association Key (CAK) Mode

You can enable MACsec using static CAK security mode on a point-to-point Ethernet link connecting routers.

When you enable MACsec using static CAK security mode, a preshared key is exchanged between the routers on each end of the point-to-point Ethernet link. The preshared key includes a connectivity association name (CKN) and a connectivity association key (CAK). The CKN and CAK are configured by the user in the connectivity association and must match on both ends of the link to initially enable MACsec.

After the preshared keys are exchanged and verified, the MACsec Key Agreement (MKA) protocol is enabled. The MKA enables and maintains MACsec on the link, and is responsible for selecting one of the two routers on the point-to-point link as the key server. The key server then creates a randomized security key that is shared only with the other device over the MACsec-secured link. The randomized security key enables and maintains MACsec on the point-to-point link. The key server will continue to periodically create and share a randomly-created security key over the point-to-point link for as long as MACsec is enabled.

You enable MACsec using static CAK security mode by configuring a connectivity association on both ends of the link. All configuration is done within the connectivity association but outside of the secure channel. Two secure channels—one for inbound traffic and one for outbound traffic—are automatically created when using static CAK security mode. The automatically-created secure channels do not have any user-configurable parameters that cannot already be configured in the connectivity association.

To configure MACsec using static CAK security mode to secure a router-to-router Ethernet link:

Create a connectivity association. You can skip this step if you are configuring an existing connectivity association.
For instance, to create a connectivity association named ca1, enter:

Configure the MACsec security mode as static-cak for the connectivity association:

For instance, to configure the MACsec security mode to static-cak on connectivity association ca1:

Create the preshared key by configuring the connectivity association key name (CKN) and connectivity association key (CAK):
A preshared key is exchanged between directly-connected links to establish a MACsec-secure link. The preshared-key includes the CKN and the CAK. The CKN is a 64-digit hexadecimal number and the CAK is a 32-digit hexadecimal number. The CKN and the CAK must match on both ends of a link to create a MACsec-secured link.

Note:
To maximize security, we recommend configuring all 64 digits of a CKN and all 32 digits of a CAK.

If you do not configure all 64 digits of a CKN or all 32 digits of a CAK, however, all remaining digits will be auto-configured to 0.

After the preshared keys are successfully exchanged and verified by both ends of the link, the MACsec Key Agreement (MKA) protocol is enabled and manages the secure link. The MKA protocol then elects one of the two directly-connected switches as the key server. The key server then shares a random security with the other device over the MACsec-secure point-to-point link. The key server will continue to periodically create and share a random security key with the other device over the MACsec-secured point-to-point link as long as MACsec is enabled.

To configure a CKN of 37c9c2c45ddd012aa5bc8ef284aa23ff6729ee2e4acb66e91fe34ba2cd9fe311 and CAK of 228ef255aa23ff6729ee664acb66e91f on connectivity association ca1:
Note:
- MACsec is not enabled until a connectivity association is attached to an interface. See the final step of this procedure to attach a connectivity association to an interface.
- In FIPS mode, instead of using set connectivity-association ca1 pre-shared-key cak command, you must use the following command:
  
  user@host# prompt connectivity-association ca1 pre-shared-key cak
(Optional) Set the MKA key server priority:
Specifies the key server priority used by the MKA protocol to select the key server. The switch with the lower priority-number is selected as the key server.

The default priority-number is 16.

If the key-server-priority is identical on both sides of the point-to-point link, the MKA protocol selects the interface with the lower MAC address as the key server. Therefore, if this statement is not configured in the connectivity associations at each end of a MACsec-secured point-to-point link, the interface with the lower MAC address becomes the key server.

To change the key server priority to 0 to increase the likelihood that the current device is selected as the key server when MACsec is enabled on the interface using connectivity association ca1:
To change the key server priority to 255 to decrease the likelihood that the current device is selected as the key server in connectivity association ca1:
(Optional) Set the MKA transmit interval:
The MKA transmit interval setting sets the frequency for how often the MKA protocol data unit (PDU) is sent to the directly connected device to maintain MACsec connectivity on the link. A lower interval increases bandwidth overhead on the link; a higher interval optimizes MKA protocol communication.

The default interval is 2000ms. We recommend increasing the interval to 6000 ms in high-traffic load environments. The transmit interval settings must be identical on both ends of the link when MACsec using static CAK security mode is enabled.

For instance, if you wanted to increase the MKA transmit interval to 6000 milliseconds when connectivity association ca1 is attached to an interface:
(Optional) Disable MACsec encryption:
Encryption is enabled for all traffic entering or leaving the interface when MACsec is enabled using static CAK security mode, by default.

When encryption is disabled, traffic is forwarded across the Ethernet link in clear text. You are able to view unencrypted data in the Ethernet frame traversing the link when you are monitoring it. The MACsec header is still applied to the frame, however, and all MACsec data integrity checks are run on both ends of the link to ensure the traffic sent or received on the link has not been tampered with and does not represent a security threat.
Assign an Encryption Algorithm
You can encrypt all traffic entering or leaving the interface using any of the following MACsec encryption algorithms:
- gcm-aes-128—GCM-AES-128 cipher suite without extended packet numbering (XPN) mode
- gcm-aes-256—GCM-AES-256 cipher suite without XPN
- gcm-aes-xpn-128—GCM-AES-XPN_128 cipher suite with XPN mode
- gcm-aes-xpn-256—GCM-AES-XPN_256 cipher suite with XPN mode
If MACsec encryption is enabled and if no encryption algorithm is specified, the default (gcm-aes-128) encryption algorithm is used without XPN mode.
Note:
- The encryption algorithms with XPN mode are not supported on MX-series MPC7E-10G routers.
- Only GCM-AES-128 is supported on MIC-3D-20GE-SFP-E and MIC-3D-20GE-SFP-EH.
For instance, if you wanted to encrypt using gcm-aes-xpn-128 algorithm in the connectivity association named ca1:
(Optional) Set an offset for all packets traversing the link:
For instance, if you wanted to set the offset to 30 in the connectivity association named ca1:
The default offset is 0. All traffic in the connectivity association is encrypted when encryption is enabled and an offset is not set.

When the offset is set to 30, the IPv4 header and the TCP/UDP header are unencrypted while encrypting the rest of the traffic. When the offset is set to 50, the IPv6 header and the TCP/UDP header are unencrypted while encrypting the rest of the traffic.

You would typically forward traffic with the first 30 or 50 octets unencrypted if a feature needed to see the data in the octets to perform a function, but you otherwise prefer to encrypt the remaining data in the frames traversing the link. Load balancing features, in particular, typically need to see the IP and TCP/UDP headers in the first 30 or 50 octets to properly load balance traffic.
(Optional) Enable replay protection.
When MACsec is enabled on a link, an ID number is assigned to each packet on the MACsec-secured link.

When replay protection is enabled, the receiving interface checks the ID number of all packets that have traversed the MACsec-secured link. If a packet arrives out of sequence and the difference between the packet numbers exceeds the replay protection window size, the packet is dropped by the receiving interface. For instance, if the replay protection window size is set to five and a packet assigned the ID of 1006 arrives on the receiving link immediately after the packet assigned the ID of 1000, the packet that is assigned the ID of 1006 is dropped because it falls outside the parameters of the replay protection window.

Replay protection is especially useful for fighting man-in-the-middle attacks. A packet that is replayed by a man-in-the-middle attacker on the Ethernet link will arrive on the receiving link out of sequence, so replay protection helps ensure the replayed packet is dropped instead of forwarded through the network.

Replay protection should not be enabled in cases where packets are expected to arrive out of order.

You can require that all packets arrive in order by setting the replay window size to 0.

To enable replay protection with a window size of five on connectivity association ca1:
(Optional) Exclude a protocol from MACsec:
For instance, if you did not want Link Level Discovery Protocol (LLDP) to be secured using MACsec:
When this option is enabled, MACsec is disabled for all packets of the specified protocol—in this case, LLDP—that are sent or received on the link.

Assign the connectivity association (CA) to the interface you want to secure.

To assign the CA to a physical interface:

For example, to assign ca1 to interface ge-0/0/1:

You can also assign the CA to a logical interface:

Note:

When assigning a CA to a logical interface, the following limitations apply:

Configuring a CA on a physical interface and a logical interface is mutually exclusive.
MACsec is not supported on logical interfaces with a native VLAN configuration.
MACsec is not supported for logical aggregated interfaces.

Assigning the connectivity association to an interface is the final configuration step to enabling MACsec on an interface.

MACsec using static CAK security mode is not enabled until a connectivity association on the opposite end of the link is also configured, and contains preshared keys that match on both ends of the link.

Note:

Starting in Junos OS Release 16.1R2, when Media Access Control Security (MACsec) is enabled on an interface, the interface flow control capability is enabled by default, regardless of the configuration that you set using the (flow-control | no-flow-control) statement at the [edit interfaces interface- name gigether-options] hierarchy level. When MACsec is disabled, interface flow control is restored to the configuration that you set using the flow-control statement at the [edit interfaces] hierarchy level. When MACsec is enabled, additional header bytes are added to the packet by the MACsec PHY. With line rate traffic, when MACsec is enabled and flow control is disabled, the pause frames sent by the MACsec PHY are terminated by the MIC’s MAC (enhanced 20-port Gigabit Ethernet MICs on MX Series routers) and not transferred to the Packet Forwarding Engine, causing framing errors. Therefore, when MACsec is enabled on an interface, flow control is also automatically enabled on such an interface.

Configuring MACsec Using Preshared Key Hitless Rollover Keychain (Recommended for Enabling MACsec on Router-to-Router Links)

In the MACsec implementation using static connectivity association key (CAK) prior to release 17.4R1, the user is allowed to configure one static CAK for every connectivity association. Whenever CAK configuration changes, the MACsec session is dropped, resetting peer sessions or interrupting the routing protocol.

For increased security and to prevent session drops when the CAK configuration changes, the hitless rollover keychain feature is implemented. In this implementation, a key chain that has the multiple security keys, key names and start times is used. Each key in the keychain has a unique start time. At the next key’s start time, a rollover occurs from the current key to the next key, and the next key becomes the current key. With the implementation of the hitless rollover keychain feature, the MACsec Key Agreement (MKA) protocol establishes MACsec sessions successfully without any session drop when the CAK configuration changes.

For a successful MACsec configuration using preshared key (PSK) hitless rollover keychain:

The keychain names, keys and start time of each key must be the same in both the participating nodes.
The order of the keychain names, keys and start time must be same in both the participating nodes.
The time must be synchronized in the participating nodes.

The existing authentication-key-chains and macsec connectivity-association commands are used for implementing hitless rollover keychain with the addition of two new attributes:

key-name—Authentication key name, and this key-name is used as the CKN for MACsec.
pre-shared-key-chain—The preshared connectivity association keychain name.

To secure a router-to-router Ethernet link by using MACsec with PSK hitless rollover keychain configuration:

Note:

Ensure that you execute the following steps in both the participating nodes in the same order.

Synchronize the time in the participating nodes to the same NTP server.
For instance, to set the date and time as per the NTP server 192.168.40.1, enter:
Configure a set of PSKs in a keychain. A keychain consists of a security key, key name, and start time.
To configure a keychain:
1. Create the secret password to use. It is a string of hexadecimal digits up to 64 characters long. The password can include spaces if the character string is enclosed in quotation marks. The keychain's secret-data is used as a CAK.
  For instance, to create the secret password 01112233445566778899aabbccddeeff for the keychain macsec_key_chain and key 1, enter:
2. Configure the authentication key name. It is a string of hexadecimal digits up to 32 characters long.
  For instance, to create the key name 01112233445566778899aabbccddeefe, enter:
3. Configure the time when the preshared rollover keychain starts.
  For instance, if you want the key name with 01112233445566778899aabbccddeefe to start rollover at 2017-12-18.20:55:00 +0000, enter:

Associate the newly created keychain with a MACsec connectivity association.

Configure the MACsec security mode for the connectivity association.

For instance, to configure the connectivity association ca1 with security mode static-cak, enter:

Associate the preshared keychain name with the connectivity association.

For instance, if you want to associate the keychain name macsec_key_chain with the connectivity association ca1, enter:

Assign the configured connectivity association with a specified MACsec interface.

For instance, to assign the connectivity association ca1 to the interface ge-0/0/1:

Configuring MACsec Key Agreement Protocol in Fail Open Mode

You can configure fail open mode for MACsec to prevent traffic from being dropped when the MKA session is inactive. This is recommended for service providers that prioritize network availability over information security.

MACsec maintains data integrity by appending a MACsec header to Ethernet frames transmitted on a MACsec-secured link. When the MKA session is active, traffic is allowed on the link only for frames with a MACsec header. When the MKA session is inactive, frames do not receive a MACsec header. All traffic, both ingress and egress, is dropped. The only exception is EAPoL traffic.

You can configure fail open mode using the should-secure CLI statement. This allows traffic on the MACsec-secured link even when the MKA session is inactive. Traffic is transmitted as cleartext, without MACsec headers.

To configure the MKA Protocol in Fail Open Mode:

Configuring MACsec with Fallback PSK

When you enable MACsec using static CAK security mode, a preshared key (PSK) is exchanged between the devices on each end of the point-to-point Ethernet link. The PSK is includes a connectivity association name (CKN) and a connectivity association key (CAK). The PSK must match across devices for a MACsec session to be established. If there is a mismatch, the session will not be established and all packets will be dropped.

You can configure a fallback PSK to prevent traffic loss in case the primary PSK fails to establish a connection. The fallback PSK is used when primary keys do not match for the initial MACsec negotiation.

If a MACsec session has already been established, and the primary PSK is changed on one device but not the other, the resulting mismatch is resolved by using the older primary PSK. The older primary PSK is a temporary key known as the preceding PSK.

With fallback PSK configured, a MACsec session can be secured with one of the following keys:

Primary PSK (configurable)—The preferred key.
Fallback PSK (configurable)—Used when the primary PSK fails to establish a MACsec session.
Preceding PSK (non-configurable)—When a new primary PSK is configured, the old primary PSK becomes the preceding PSK.

The status of the CAK for each key can be either live, active or in-progress. See Table 1 for a description of each status.

Table 1: CAK status descriptions
CAK Status	Description
Live	CAK has been validated by MKA. MACsec session is live. SAK is successfully generated using this key. CAK is used for encryption and decryption of the MACsec session. MKA hello packets are sent and received for this key at a configured interval.
Active	CAK has been validated by MKA. MACsec session is live. SAK is not generated using this key. CAK is not used for encryption and decryption of the MACsec session. MKA hello packets are sent and received for this key at a configured interval.
In-progress	No valid live or potential peer is found. The MACsec session is in-progress to find a peer. MKA hello packets are sent for this key at a configured interval.

A mismatch of keys occurs when a new PSK is configured on one side of the MACsec link and the other side is either misconfigured or not configured with the new key. The fallback behavior depends on which components of the PSK are changed (CAK, CKN, or both). Each mismatch scenario is described below:

If the CAK is changed, and the CKN remains the same, the existing MACsec session will be disconnected. A new session will be initiated with the old CKN and new CAK value.
If the CKN is changed, and the CAK remains the same, the old CKN paired with the existing CAK becomes the preceding PSK, and the session will be live with preceding PSK. A new session is initiated with the newly-created CKN and the CAK, which will be in-progress until the peer node is also configured with the same CKN.
If both the CAK and the CKN are changed, the old CAK+CKN pair becomes the preceding PSK, and the session will be live with the preceding PSK. A new session is initiated with the new CAK+CKN pair, which will be in-progress until the peer node is also configured with the same CAK+CKN.

Note:

The preceding PSK takes priority over the fallback PSK, so if the session is live with the preceding PSK, the fallback PSK will not take effect. If you want the session to be live with the fallback PSK, you must configure the disable-preceding-key statement.

Fallback PSK is supported for preshared keychains. You can configure a fallback PSK along with a preshared key, or with a preshared keychain. The preshared key and preshared keychain are mutually exclusive.

If only a fallback PSK is configured, and there is no primary PSK, both devices attempt to establish a session with the fallback PSK. If the session comes up, the SAK derived from the fallback PSK is used for data traffic encryption. If the established session is broken, the devices continue attempting to reestablish the session and traffic will be dropped until the session is reestablished.

The fallback PSK is configured as part of the connectivity association (CA). The CA can be configured globally for all interfaces or on a per-interface basis, allowing different fallback keys for different interfaces.

To configure the fallback PSK, configure the CAK and the CKN as part of the CA:

The following restrictions apply to fallback PSK configuration:

Fallback CAK and CKN should not match the preshared key CKN and CAK or any key configured in the keychain under the same CA.
Security mode configuration must be present to configure the fallback key.
Key length restrictions for the configured cipher suite apply to the fallback CAK and CKN.

Release History Table

Release

Description

16.1R2

15.1

ON THIS PAGE

Configuring Media Access Control Security (MACsec) on Routers

Configuring MACsec Using Static Connectivity Association Key (CAK) Mode

See Also

Configuring MACsec Using Preshared Key Hitless Rollover Keychain (Recommended for Enabling MACsec on Router-to-Router Links)

Configuring MACsec Key Agreement Protocol in Fail Open Mode

Configuring MACsec with Fallback PSK