Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Configuring Advanced MACsec Features

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.

Use Feature Explorer to confirm platform and release support for MACsec and related features.

Review the Platform-Specific Behavior for Advanced MACsec Features section for notes related to your platform.

Configure Encryption Options

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:

We strongly recommend using XPN when using MACsec on 40G and 100G links.

For example, if you wanted to encrypt using the GCM-AES-XPN-128 algorithm in the connectivity association named ca1:

Disable Encryption

The default behavior for MACsec is to encrypt traffic traversing the link. You can disable encryption if you want to use MACsec only to authenticate an endpoint and guarantee integrity of the link. This is called integrity-only mode. Integrity-only mode is useful if you need the unencrypted payload to be visible when carrying MACsec over multiple hops.

When you disable encryption, traffic is forwarded across the Ethernet link in clear text. You can 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.

To disable encryption, use the following command:

Configure an Offset

Offset provides an option between full encyption and no encryption. Configue an offset to expose a set number of bytes of the payload and encrypting the rest. This could be used for intermediate load balancing or for load distribution at the host, in the case of switch-to-host links.

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.

To configure an offset, use the following command:

For example, if you wanted to set the offset to 30 in the connectivity association named ca1:

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

Previously, in the MACsec implementation using static connectivity association key (CAK), 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.
  1. 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:

  2. 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:

  3. Associate the newly created keychain with a MACsec connectivity association.
    1. Configure the MACsec security mode for the connectivity association.

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

    2. 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:

  4. 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:

Configure MACsec Key Agreement Protocol in Fail Open Mode

By default, all traffic traveling on a MACsec-secured link must be MACsec-secured to be forwarded onward. The device drops all traffic that is not MACsec-secured that it receives on the interface. This is known as must secure mode.

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.

We recommended using must secure mode whenever possible. However, you can disable must secure mode and use fail open mode instead. Fail open mode for MACsec prevents the device from dropping traffic when the MKA session is inactive. Fail open mode allows service providers that prioritize network availability over information security to allow non-secure traffic on their network.

You can configure fail open mode using the should-secure CLI statement. This mode 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:

To disable fail open mode, either delete the configuration or enable must secure mode using the must-secure statement. Must secure mode is equivalent to the default MACsec behavior:

Configuring Replay Protection

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.

Note:

You can require that all packets arrive in order by setting the replay window size to 0. Replay protection should not be enabled in cases where packets are expected to arrive out of order.

To enable replay protection use the following command:

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

Configuring Bounded Delay Protection

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:

Note:

Bounded delay impacts CPU utilization which can degrade performance. We recommend only configuring bounded delay on interfaces on which it is absolutely required.

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

Configuring MACsec with GRES

The graceful switchover (GRES) feature enables a switch or router with redundant Routing Engines to continue forwarding packets, even if one Routing Engine fails. Nonstop active routing (NSR) is an enhancement on GRES that does not rely on helper routers (or switches) to assist the routing platform in restoring routing protocol information. You can configure MACsec to provide uninterrupted MACsec service and secure your traffic during a Routing Engine 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 a Routing Engine 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 and NSR for MACsec, you must configure the suspend-for statement on the local node so that it sends a suspension request in the event of a Routing Engine 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 NSR.

Use Feature Explorer to confirm platform and release support for specific features.

Note:

During GRES, the following MACsec features are disabled:

  • Primary, fallback, or preceding key switch.

  • Keychain key switch.

  • SAK rekey timer.

For best results on devices running Junos OS Evolved, before you begin:

  • Disable the SAK rekey timer.

  • Ensure both MACsec nodes support IEEE standard 802.1Xbx™-2014.

  • Use XPN ciphers (AES-GCM-XPN-128 or AES-GCM-XPN-256).

To enable GRES and NSR for MACsec, configure the following on the local node:

  1. Configure GRES.
  2. Configure NSR.
  3. Configure the node to send suspension requests when initiating Routing Engine switchover.
  4. (Key server only.) Configure the node to accept suspension requests.

Platform-Specific Behavior for Advanced MACsec Features

Use the following table to review platform-specific behaviors for your platforms.

Table 2: Platform-Specific Behavior for Advanced MACsec Features

Platform

Difference

EX Series

  • The EX9200-40XS line card supports AES-256 encryption.

MX Series

  • Routers with the MPC7E-10G line card do not support encryption algorithms with XPN mode.

  • Routers with MIC-3D-20GE-SFP-E or MIC-3D-20GE-SFP-EH line cards only support the GCM-AES-128 encryption algorithm.

  • Routers with the MIC-MACSEC-20GE MIC support the GCM-AES-256 and GCM-AES-XPN-256 encryption algorithms.

SRX Series

  • (SRX1600, SRX4120, SRX2300, and SRX4300) The configurations for must-secure and should-secure are mutually exclusive. Only configure one option on a given physical interface for MACsec logical interface sessions. However, you can configure different options on different physical interfaces.