Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring Media Access Control Security (MACsec) on MX Series 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.

You can enable MACsec using static connectivity association key (CAK) security mode on a point-to-point Ethernet link connecting switches.

When you enable MACsec using static CAK security mode, a preshared key is exchanged between the switches 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, which enables and maintains MACsec on the link, is enabled. The MKA is responsible for selecting one of the two switches 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:

  1. Create a connectivity association. You can skip this step if you are configuring an existing connectivity association.
    [edit security macsec]

    user@host# set connectivity-association connectivity-association-name

    For instance, to create a connectivity association named ca1, enter:

    [edit security macsec]

    user@host# set connectivity-association ca1
  2. Configure the MACsec security mode as static-cak for the connectivity association:
    [edit security macsec]

    user@host# set connectivity-association connectivity-association-name security-mode static-cak

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

    [edit security macsec]

    user@host# set connectivity-association ca1 security-mode static-cak
  3. Create the preshared key by configuring the connectivity association key name (CKN) and connectivity association key (CAK):
    [edit security macsec]

    user@host# set connectivity-association connectivity-association-name pre-shared-key ckn hexadecimal-number

    user@host# set connectivity-association connectivity-association-name pre-shared-key cak hexadecimal-number

    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:

    [edit security macsec]

    user@host# set connectivity-association ca1 pre-shared-key ckn 37c9c2c45ddd012aa5bc8ef284aa23ff6729ee2e4acb66e91fe34ba2cd9fe311

    user@host# set connectivity-association ca1 pre-shared-key cak 228ef255aa23ff6729ee664acb66e91f
    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

  4. (Optional) Set the MKA key server priority:
    [edit security macsec connectivity-association connectivity-association-name]

    user@host# set mka key-server-priority priority-number

    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:

    [edit security macsec connectivity-association ca1]

    user@host# set mka key-server-priority 0

    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:

    [edit security macsec connectivity-association ca1]

    user@host# set mka key-server-priority 255
  5. (Optional) Set the MKA transmit interval:
    [edit security macsec connectivity-association connectivity-association-name]

    user@host# set mka transmit-interval 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:

    [edit security macsec connectivity-association ca1]

    user@host# set mka transmit-interval 6000
  6. (Optional) Disable MACsec encryption:
    [edit security macsec connectivity-association connectivity-association-name]

    user@host# set no-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.

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

    [edit security macsec connectivity-association connectivity-association-name]

    user@host# set cipher-suite (gcm-aes-128 | gcm-aes-256 | gcm-aes-xpn-128 | gcm-aes-xpn-256)

    For instance, if you wanted to encrypt using gcm-aes-xpn-128 algorithm in the connectivity association named ca1:

    [edit security macsec connectivity-association ca1]

    user@host# set cipher-suite gcm-aes-xpn-128
  8. (Optional) Set an offset for all packets traversing the link:
    [edit security macsec connectivity-association connectivity-association-name]

    user@host# set offset (0 | 30 | 50)

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

    [edit security macsec connectivity-association ca1]

    user@host# set offset 30

    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.

  9. (Optional) Enable replay protection.
    [edit security macsec connectivity-association connectivity-association-name]

    user@host# set replay-protect replay-window-size number-of-packets

    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:

    [edit security macsec connectivity-association ca1]

    user@host# set replay-protect replay-window-size 5
  10. (Optional) Exclude a protocol from MACsec:
    [edit security macsec connectivity-association connectivity-association-name]

    user@host# set exclude-protocol protocol-name

    For instance, if you did not want Link Level Discovery Protocol (LLDP) to be secured using MACsec:

    [edit security macsec connectivity-association connectivity-association-name]

    user@host# set exclude-protocol lldp

    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.

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

    To assign the CA to a physical interface:

    [edit security macsec]

    user@host# set interfaces interface-name connectivity-association connectivity-association-name

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

    [edit security macsec]

    user@host# set interfaces ge-0/0/1 connectivity-association ca1

    You can also assign the CA to a logical interface:

    [edit security macsec]

    user@host# set interfaces interface-name unit unit-number connectivity-association connectivity-association-name
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 on MX-series Routers (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.

  1. Synchronize the time in the participating nodes to the same NTP server.
    user@host# set date ntp servers

    For instance, to set the date and time as per the NTP server 192.168.40.1, enter:

    user@host# set date ntp 192.168.40.1
  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.
      [edit]

      user@host# set security authentication-key-chains key-chain key-chain-name key key secret secret-data

      For instance, to create the secret password 01112233445566778899aabbccddeeff for the keychain macsec_key_chain and key 1,, enter:

      [edit]

      user@host# set security authentication-key-chains key-chain macsec_key_chain key 1 secret 01112233445566778899aabbccddeeff
    2. Configure the authentication key name. It is a string of hexadecimal digits up to 32 characters long.
      [edit]

      user@host# set security authentication-key-chains key-chain macsec_key_chain key key key-name authentication_key_name

      For instance, to create the key name 01112233445566778899aabbccddeefe, enter:

      [edit]

      user@host# set security authentication-key-chains key-chain macsec_key_chain key 1 key-name 01112233445566778899aabbccddeefe
    3. Configure the time when the preshared rollover keychain starts.
      [edit]

      user@host# set security authentication-key-chains key-chain macsec_key_chain key key start-time "PSK keychain rollover start time"

      For instance, if you want the key name with 01112233445566778899aabbccddeefe to start rollover at 2017-12-18.20:55:00 +0000, enter:

      [edit]

      user@host# set security authentication-key-chains key-chain macsec_key_chain key 1 start-time "2017-12-18.20:55:00 +0000"
  3. Associate the newly created keychain with a MACsec connectivity association.
    1. Configure the MACsec security mode for the connectivity association.
      [edit]

      user@host# set security macsec connectivity-association connectivity-association-name security-mode security-mode

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

      [edit]

      user@host# set security macsec connectivity-association ca1 security-mode static-cak
    2. Associate the preshared keychain name with the connectivity association.
      [edit]

      user@host# set security macsec connectivity-association connectivity-association-name pre-shared-key-chain macsec-key-chain-name

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

      [edit security macsec]

      user@host# set security macsec connectivity-association ca1 pre-shared-key-chain macsec_key_chain
  4. Assign the configured connectivity association with a specified MACsec interface.
    [edit]

    user@host# set security macsec interfaces interface-name connectivity-association connectivity-association-name

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

    [edit]

    user@host# set security macsec interfaces ge-0/0/1 connectivity-association ca1

Configuring MACsec Key Agreement Protocol in Fail Open Mode on MX2020 and MX2010 Routers

In the MACsec implementation in static CAK mode (prior to release 17.4R1), MACsec Key Agreement (MKA) protocol does not allow transmission (ingress or egress) of cleartext messages with or without secure channels. If an MKA session is not established, the data is dropped.

Service providers prioritize network availability over information security. Starting with Junos OS Release 17.4R1, transmission of clear text data is possible with or without the MKA protocol session being established. A new configuration statement, should-secure, introduced in 17.4R1 makes the transmission of cleartext data possible. There can be two scenarios for data transmission with the introduction of the should-secure configuration statement:

  • should-secure not configured

    This is the default CAK mode for MACsec and in this mode, traffic is allowed to pass encrypted with MACsec headers only when the MKA session is established. If the MKA session is not established, all traffic is discarded except Extensible Authentication Protocol over LAN (EAPoL).

  • should-secure configured

    If should-secure is configured and if the MKA session is not established, traffic is still allowed in cleartext without the MACsec header. If the MKA session is established successfully, traffic is allowed with 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;

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 StatusDescription

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 and received 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 this session 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 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
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.
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.