Configuring Advanced MACsec Features

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

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:

[edit security macsec connectivity-association connectivity-association-name]
 user@host# set mka should-secure;

MACsec assigns an ID number to each packet on a MACsec-secured link. When replay protection is enabled, the receiving interface checks the ID number of all packets that 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 receiving interface drops the packet.

For example, 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 with ID 1006 is dropped because it falls outside of the replay protection window.

Replay protection is 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.

To enable replay protection use the following command:

[edit security macsec connectivity-association connectivity-association-name]
user@host# set replay-protect replay-window-size number-of-packets

For example, to enable replay protection with a window size of five on connectivity association ca1:

[edit security macsec connectivity-association ca1]
user@host# set replay-protect replay-window-size 5

You can configure bounded delay protection to ensure that a Media Access Control Security (MACsec) frame will not be delivered after a delay of two seconds or more. This ensures that a delay of MACsec frames resulting from a man-in-the-middle attack will not go undetected.

When you configure bounded delay protection, you must also configure replay protection. This is the window during which duplicate and replay packets are allowed. Bounded delay takes precedence over replay protection. You can increase the effectiveness of bounded delay protection by configuring a lower value for the window size.

Before you configure bounded delay protection, you must configure replay protection. See Configuring Replay Protection.

To configure bounded delay protection, use the following command:

[edit security macsec connectivity-association connectivity-association-name mka]
user@host# set bounded-delay

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.

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.

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:

[edit security macsec connectivity-association ca-name]
user@switch# set fallback-key cak key
user@switch# set fallback-key ckn key-name

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.

The graceful switchover (GRES) feature enables a switch or router with redundant routing engines to continue forwarding packets, even if one routing engine (RE) fails. You can configure MACsec to provide uninterrupted service during RE switchover.

The MACsec Key Agreement (MKA) protocol maintains the MACsec session between two nodes on a point-to-point MACsec link. The MKA protocol works at the control plane level between the two nodes. One node acts as the key server and generates a secure association key (SAK) to secure the link.

When the local nodes initiates an RE switchover, it sends a request to the remote peer node to suspend the MACsec session at the control plane. At the data plane, traffic continues to traverse the point-to-point link during suspension. The SAK that was programmed prior to suspension remains in use until the switchover is complete. After the switchover, the key server generates a new SAK to secure the link. The key server will continue to periodically create and share a SAK over the link for as long as MACsec is enabled.

To enable GRES for MACsec, you must configure the suspend-for statement on the local node so that it sends a suspension request in the event of an RE switchover. You must also configure the node acting as key server to accept suspension requests using the suspend-on-request statement. Otherwise, the key server rejects any suspension requests, resulting in termination of the MACsec session.

When you configure the suspend-for and suspend-on-request statements, you must also configure GRES and nonstop routing.

To enable GRES for MACsec, use the following configuration on the local node: