Security breaches can occur at any layer of the OSI model. At Layer 2, some of the common breaches are MAC address spoofing, ARP spoofing, Denial of Service (DoS) attacks against a DHCP server, and VLAN hopping.

MACsec secures data on physical media, making it impossible for data to be compromised at higher layers. As a result, MACsec encryption takes priority over any other encryption method such as IPsec and SSL at higher layers. MACsec is configured on the Customer Edge (CE) router interfaces that connect to Provider Edge (PE) routers and on all the provider router interfaces.

MACsec provides the secure MAC Service on a frame-by-frame basis, using GCM-AES algorithm. MACsec uses the MACsec Key Agreement protocol (MKA) to exchange session keys, and manage encryption keys.

The MACsec encryption process is illustrated in the following figure and description.

Step 1: When a link is first established between two routers, they become peers. Mutual peer authentication takes place by configuring a Pre-shared Key (PSK).

Step 2: On successful peer authentication, a connectivity association is formed between the peers, and a secure Connectivity Association Key Name (CKN) is exchanged. After the exchange, the MKA ICV is validated with a Connectivity Association Key (CAK), which is effectively a secret key.

Step 3: A key server is selected between the routers, based on the configured key server priority. Lower the priority value, higher the preference for the router to become the key server. If no value is configured, the default value of 16 is taken to be the key server priority value for the router. Lowest priority value configures that router as the key server, while the other router functions as a key client. The following rules apply to key server selection:

• Numerically lower values of key server priority and SCI are accorded the highest preference.

• Each router selects a peer advertising the highest preference as its key server provided that peer has not selected another router as its key server or is not willing to function as the key server.

• In the event of a tie for highest preferred key server, the router with the highest priority SCI is chosen as key server (KS).

Step 4: A security association is formed between the peers. The key server generates and distributes the Secure Association Key (SAK) to the key client (peer). Each secure channel is supported by an overlapped sequence of Security Associations (SA). Each SA uses a new Secure Association Key (SAK).

Step 5: Encrypted data is exchanged between the peers.

The MACsec header in a frame consists of three components as illustrated in the following figure.

• SecTAG: The security tag is 8-16 bytes in length and identifies the SAK to be used for the frame. With Secure Channel Identifier (SCI) encoding, the security tag is 16 bytes in length, and without the encoding, 8 bytes in length (SCI encoding is optional).The security tag also provides replay protection when frames are received out of sequence.

• Secure Data: This is the data in the frame that is encrypted using MACsec and can be 2 or more octets in length.

• ICV: The ICV provides the integrity check for the frame and is usually 8-16 bytes in length, depending on the cipher suite. Frames that do not match the expected ICV are dropped at the port.

• Data Integrity Check: Integrity check value (ICV) is used to perform integrity check. The ICV is sent with the protected data unit and is recalculated and compared by the receiver to detect data modification.

• Data Encryption: Enables a port to encrypt outbound frames and decrypt MACsec-encrypted inbound frames.

• Replay Protection: When frames are transmitted through the network, there is a strong possibility of frames getting out of the ordered sequence. MACsec provides a configurable window that accepts a specified number of out-of-sequence frames.

• Support for Clear Traffic: If configured accordingly, data that is not encrypted is allowed to transit through the port.

The MACsec technology is supported on 48-port 100GE line cards and 36-port 400GE line cards.

Also, see MACsec on Layer 3 Subinterface Hardware Support Matrix.

A pre-shared key includes a connectivity association key name (CKN) and a connectivity association key (CAK). A pre-shared key is exchanged between two devices at each end of a point-to-point (P2P) link to enable MACsec using static CAK security mode. The MACsec Key Agreement (MKA) protocol is enabled after the pre-shared keys are successfully verified and exchanged. The pre-shared keys, the CKN and CAK, must match on both ends of a link.

For more information on MACsec PSK configuration, see Applying MACsec Configuration on an Interface.

Fallback is a session recovery mechanism when primary PSK fails to bring up secured MKA session. It ensures that a PSK is always available to perform MACsec encryption and decryption.

• In CAK rollover of primary keys, if latest active keys are mismatched, system performs a hitless rollover from current active key to fallback key, provided the fallback keys match.

• If a session is up with fallback, and primary latest active key configuration mismatches are rectified between peers, system performs a hitless rollover from fallback to primary latest active key.

Note

A valid Fallback PSK (CKN and CAK) must be configured with infinite lifetime. If the fallback PSK is configured with CAK mismatch, the only recovery mechanism is to push a new set of PSK configurations (both on fallback PSK keychain and primary PSK chain, in that order) on all the association members. In P2P topologies, a rollover to the fallback PSK happens when either of the nodes in the Secure Association (SA) cannot peer up with the primary PSK. Whereas, in P2MP, the fallback happens only at the expiry or deletion of the primary key on all peers, not just on one of the peers. On deletion or expiry of the primary PSK on one of the nodes, say R1, a new key server is chosen among the peer nodes that does a SAK rekey for the remaining nodes. This ensures that R1 is no longer part of the SA, and the network drops all traffic to and from R1.

The following is a sample syslog for session secured with fallback PSK:

%L2-MKA-5-SESSION_SECURED_WITH_FALLBACK_PSK : (Hu0/1/0/0) MKA session secured, CKN:ABCD

For more information on MACsec fallback PSK configuration, see Applying MACsec Configuration on an Interface.

Active Fallback

The Cisco IOS XR Software Release 7.0.14 introduces the support for active fallback feature that initiates a fallback MKA session on having fallback configuration under the interface.

The key benefits of active fallback feature are:

• Faster session convergence on fallback, in the event of primary key deletion, expiry or mismatch.

• Faster traffic recovery under should-secure security policy when both primary and fallback mismatch happens.

With the introduction of active fallback functionality, the output of various MACsec show commands include the fallback PSK entry as well. If the session is secured with primary key, the fallback session will be in ACTIVE state. See, Verifying MACsec Encryption on IOS XR for details and sample outputs.

Note	If the peer device is running on an older release that does not support active fallback feature, you must configure the enable-legacy-fallback command under the macsec-policy to ensure backward compatibility.

MACsec can be configured on physical Ethernet interfaces or interface bundles (link bundles), as explained in this section.

Note

Enabling MACsec encryption on any on physical Ethernet interfaces or interface bundles (link bundles) will add an overhead of 32 bytes on the maximum transmission unit (MTU) size of link-state packets (LSPs). Therefore, you must set the LSP MTU to 32 bytes less than the interface MTU, to account for MACsec overhead. Use the lsp-mtu command to configure the maximum transmission unit (MTU) size of link-state packets (LSPs) on each router where MACsec is enabled.

Use Case 1: MACsec in a VPLS/EVPN

A typical VPLS network often suffers the injection of labeled traffic from potential hackers. The following figure illustrates the use of MACsec in a VPLS/EVPN network for encrypting the data being exchanged over the VPLS cloud. In this topology MACsec is configured on the PE-facing interfaces of the CE routers.

Use Case 2: MACsec in an MPLS Core Network

MACsec in an MPLS core network can be configured on physical interfaces or link bundles (Link Aggregation Group or LAG).

In the following topology, MACsec is configured on all router links in the MPLS core. This deployment is useful when the MPLS network spans data centers that are not co-located in the same geography. Each link is, therefore, a link between two data centers and all data exchanged is encrypted using MACsec.

The following figure illustrates the use of MACsec on physical interfaces in an MPLS core network.

When MACsec is configured on the members of a LAG, an MKA session is set up for each member. SAK is exchanged for each LAG member and encryption or decryption takes place independently of other members in the group.

The following figure illustrates the use of MACsec on a link bundle in an MPLS core network.

A MACsec keychain is a collection of keys used to authenticate peers needing to exchange encrypted information. While creating a keychain, we define the key(s), key string with password, the cryptographic algorithm, and the key lifetime.

Guidelines for Configuring MACsec Keychain

MACsec keychain management has the following configuration guidelines:

• To establish MKA session, ensure that the MACsec key (CKN) and key-string (CAK) match at both ends.

• MKA protocol uses the latest active key available in the Keychain. This key has the latest Start Time from the existing set of currently active keys. You can verify the values using the show key chain keychain-name command.

• Deletion or expiry of current active key brings down the MKA session resulting in traffic hit. We recommend you to configure the keys with infinite lifetime. If fallback is configured, traffic is safeguarded using fallback on expiry or deletion of primary-keychain active key.

• To achieve successful key rollover (CAK-rollover), the new key should be configured such that it is the latest active key, and kicks-in before the current key expires.

• We recommend an overlap of at least one minute for hitless CAK rollover from current key to new key.

• Start time and Expiry time can be configured with future time stamps, which allows bulk configuration for daily CAK rotation without any intervention of management agent.

• From Cisco IOS XR Software Release 7.2.1 and later, the MACsec key IDs (configured through CLI using the macsec key command under the key chain configuration mode) are considered to be case insensitive. These key IDs are stored as uppercase letters. For example, a key ID of value 'FF' and of value 'ff' are considered to be the same, and both these key IDs are now stored in uppercase as 'FF'. Whereas, prior to Release 7.2.1, both these values were treated as case sensitive, and hence considered as two separate key IDs. Hence it is recommended to have unique strings as key IDs for a MACsec key chain to avoid flapping of MACsec sessions. However, the support for this case insensitive IDs is applicable only for the configurations done through CLI, and not for configurations done through Netconf protocol.

  Also, it is recommended to do a prior check of the MACsec key IDs before upgrading to Release 7.2.1 or later.

  Consider a scenario where two MACsec key IDs with the same set of characters (say, ff and FF) are configured under the same key chain.

  
  key chain 1
   macsec
    key ff
     lifetime 02:01:01 may 18 2020 infinite
    !
    key FF
     lifetime 01:01:01 may 18 2020 infinite
  
  

  When you upgrade to Release 7.2.1 or later, only one of these key IDs is retained. That is 'FF', the one that was applied second in this example.

Follow these steps to configure a MACsec keychain:

Keychain Name: Provide a name for the MACsec keychain.

Router#configure
Router(config)#key chain kc

MACsec Mode: Enter the MACsec mode.

Router(config-kc)#macsec
Router(config-kc-MacSec)#

MACsec key: Provide a name for the MACsec key.

The MACsec key can be up to 64 characters in length. The key must be of an even number of characters. Entering an odd number of characters will exit the MACsec configuration mode.

You can also configure a fall-back pre-shared key(PSK) to ensure that a PSK is always available to perform MACsec encryption and decryption. The fallback PSK along with the primary PSK ensures that the session remains active even if the primary PSK is mismatched or there is no active key for the primary PSK.

The configured key is the CKN that is exchanged between the peers.

See the guidelines section to know more about the need for a unique key ID for a MACsec key chain.

Note

If you are configuring MACsec to interoperate with a MACsec server that is running software prior to Cisco IOS XR Release 6.1.3, then ensure that the MACsec key length is of 64 characters. You can add extra zero characters to the MACsec key so that the length of 64-characters is achieved. If the key length is lesser than 64 characters, authentication will fail.

Router(config-kc-MacSec)#key 1234

AES Encryption: Enter the key string and the cryptographic algorithm to be used for the key.

! AES 128-bit encryption  

Router(config-kc-MacSec-1234)#key-string 12345678
Router(config-kc-MacSec-1234)#cryptographic-algorithm AES-128-CMAC-96

MACsec key (CKN) lifetime or validity period: The lifetime period can be configured as a validity period between two dates (for example, Jan 01 2019 to Dec 31 2019), or with infinite validity. The key is valid from the time you configure (in HH:MM:SS format). Duration is configured in seconds.

Note	When a key has expired, the MACsec session is torn down and running the show macsec mka session command does not display any information. If you run the show macsec mka interface detail command, the output displays *** No Active Keys Present *** in the PSK information.

Router(config-kc-MacSec-1234)#lifetime 05:00:00 01 January 2019 duration 1800
! Configuring  lifetime for a defined period 

Router(config-kc-MacSec-1234)#lifetime 05:00:00 20 february 2019 12:00:00 30 september 2019 

! Configuring  lifetime as infinite 

Router(config-kc-MacSec-1234)#lifetime 05:00:00 01 January 2019 infinite 
Router(config-kc-MacSec-1234)#commit 

• MACsec policy - Create a MACsec policy and configure the cipher suite to be used for MACsec encryption, including the confidentiality offset.

  Note	We recommend to change the offset value of the conf-offset <offset_value> command (MACsec encryption command) in the routers only when the port is in admin down state (that is, when the interface is shut down). Changing the offset value otherwise may result in traffic loss.

  In this example, the GCM-AES-XPN-256 encryption algorithm is used. A 256-bit encryption algorithm uses a larger key that requires more rounds of hacking to be cracked. 256-bit algorithms provide better security against large mass security attacks, and include the security provided by 128-bit algorithms. Extended Packet Numbering (XPN) is used to reduce the number of key rollovers while data is sent over high speed links. It is therefore highly recommended to use GCM-AES-XPN-256 encryption algorithm for higher data ports.

  Note	For Cisco 8000 Series Routers to interoperate with Cisco ASR9000 Series Routers that are older than Release 6.2.3, configure a user defined MACsec policy with the policy-exception lacp-in-clear command to bring up the MKA sessions over bundle interfaces running in LACP modes.

  Router# configure terminal
  Router(config)# macsec-policy mp-SF
  Router(config-macsec-policy)# cipher-suite GCM-AES-XPN-128
  Router(config-macsec-policy)# conf-offset CONF-OFFSET-30
  

• Key server priority - You can enter a value between 0-255. Lower the value, higher the preference to be selected as the key server. In this example, a value of 0 configures the router as the key server, while the other router functions as a key client. The key server generates and maintains the SAK between the two routers. The default key server priority value is 16.

  
  Router(config-macsec-policy)# key-server-priority 10
  

• Security policy parameters - Enable the Must-Secure or Should-Secure parameter.

  Must-Secure imposes that only MACsec encrypted traffic can flow. Hence, until the MKA session is secured, traffic is dropped.

  Should-Secure allows unencrypted traffic to flow until the MKA session is secured. After the MKA session is secured, only encrypted traffic can flow.

  Note

  Unlike in P2P scenarios, the traffic drops in P2MP if a third peer that is added with should-secure security policy fails to establish secure connection with two other peers that have already established a secure connection using should-secure . This is because, the first two peers update their configurations to drop all untagged (unencrypted) packets, once they establish a secure connection.

  
  Router(config-macsec-policy)# security-policy should-secure
  

• Data delay protection - Data delay protection allows MKA participants to ensure that the data frames protected by MACsec are not delayed by more than 2 seconds. Each SecY uses MKA to communicate the lowest PN used for transmission with the SAK within two seconds. Traffic delayed longer than 2 seconds are rejected by the interfaces enabled with delay protection.

  By default, the data delay protection feature is disabled. Configuring the delay-protection command under MACsec-policy attached to MACsec interface will enable the data delay protection feature on that interface. When enabled, the show macsec mka session interface interface detail command output displays the Delay Protection field as TRUE.

  Router(config-macsec-policy)# delay-protection
  

• Replay protection window size - The window size dictates the maximum out-of-sequence frames that are accepted. You can configure a value between 0 and 1024.

• ICV for the frame arriving on the port - This parameter configures inclusion of the optional ICV Indicator as part of the transmitted MACsec Key Agreement PDU (MKPDU). This configuration is necessary for MACsec to interoperate with routers that run software prior to IOS XR version 6.1.3. This configuration is also important in a service provider WAN setup where MACsec interoperates with other vendor MACsec implementations that expect ICV indicator to be present in the MKPDU.

  Router(config-macsec-policy)# window-size 64
  Router(config-macsec-policy)# include-icv-indicator
  Router(config-macsec-policy)# commit
  

Running Configuration

The following is a sample output of the show running-config macsec-policy command.

Router# show running-config macsec-policy mp-SF

macsec-policy mp-SF
 conf-offset CONF-OFFSET-30
 security-policy should-secure
 cipher-suite GCM-AES-XPN-128
 window-size 64
 include-icv-indicator
 delay-protection
 key-server-priority 10
!

The MACsec service configuration is applied to the host-facing interface of a CE router.

Guidelines for MACsec Interface Configuration

• Configure different keychains for primary and fallback PSKs.

• We do not recommend to update both primary and fallback PSKs simultaneously, because fallback PSK is intended to recover MACsec session on primary key mismatch.

• When using MACsec, we recommend you adjust the maximum transmission unit (MTU) of an interface to accommodate the MACsec overhead. Configuring MTU value on an interface allows protocols to do MTU negotiation including MACsec overhead. For instance, if the default MTU is 1514 bytes, configure the MTU to 1546 bytes (1514 + 32).

• The minimum MTU for IS-IS protocol on the MACsec interface is 1546 bytes.

• To enable MACsec on bundles:

  • Enable MACsec on all bundle members.

  • We recommend configuring the maximum possible MTU on the bundle interface.

  • The MTU configurations must account for the maximum packet size of the protocols running on the bundle interface and 32 bytes of MACsec overhead.

  • For IS-IS protocol running on the bundle interface, hello-padding must be disabled.

Tip	You can programmatically view the MACsec configuration using the openconfig-macsec.yang OpenConfig data model. To get started with using data models, see Programmability Configuration Guide for Cisco 8000 Series Routers.

MACsec PSK Configuration on an Interface

Router#configure
Router(config)#interface hundredGigE 0/1/0/10
Router(config-if)# macsec psk-keychain kc policy mp-SF

To enable MACsec PSK on a physical interface without the MACsec policy, use this command:

Router(config-if)#macsec psk-keychain script_kc

MACsec Fallback PSK Configuration on an Interface

It is optional to configure a fallback PSK. If a fallback PSK is configured, the fallback PSK along with the primary PSK ensures that the session remains active even if the primary PSK is mismatched, or there is no active key for the primary PSK.

Router(config-if)#macsec psk-keychain kc fallback-psk-keychain fallback_kc policy mp-SF
Router(config-if)#commit

Verification

Before the introduction of active fallback functionality:

Router# show macsec mka session detail 

NODE: node0_1_CPU0

MKA Detailed Status for MKA Session
===================================
Status: Secured - Secured MKA Session with MACsec

Local Tx-SCI                    : 7872.5d1a.e7d4/0001
Local Tx-SSCI                   : 1
Interface MAC Address           : 7872.5d1a.e7d4
MKA Port Identifier             : 1
Interface Name                  : Hu0/1/0/10
CAK Name (CKN)                  : 1234
CA Authentication Mode          : PRIMARY-PSK
Keychain                        : kc
Member Identifier (MI)          : C12A70FEE1212B835BDDDCBA
Message Number (MN)             : 395
Authenticator                   : NO
Key Server                      : NO
MKA Cipher Suite                : AES-128-CMAC
Configured MACSec Cipher Suite  : GCM-AES-XPN-128

Latest SAK Status               : Rx & Tx
Latest SAK AN                   : 0
Latest SAK KI (KN)              : 018E2F0D63FF2ED6A5BF270E00000001 (1)
Old SAK Status                  : FIRST-SAK
Old SAK AN                      : 0
Old SAK KI (KN)                 : FIRST-SAK (0)

SAK Transmit Wait Time          : 0s (Not waiting for any peers to respond)
SAK Retire Time                 : 0s (No Old SAK to retire)
Time to SAK Rekey               : NA
Time to exit suspension         : NA

MKA Policy Name                 : mp-SF
Key Server Priority             : 16
Delay Protection                : FALSE
Replay Window Size              : 64
Include ICV Indicator           : FALSE
Confidentiality Offset          : 30
Algorithm Agility               : 80C201
SAK Cipher Suite                : 0080C20001000003 (GCM-AES-XPN-128)
MACsec Capability               : 3 (MACsec Integrity, Confidentiality, & Offset)
MACsec Desired                  : YES

# of MACsec Capable Live Peers           : 1
# of MACsec Capable Live Peers Responded : 0

Live Peer List:
-------------------------------------------------------------------------------
           MI                  MN             Rx-SCI          SSCI  KS-Priority 
-------------------------------------------------------------------------------
018E2F0D63FF2ED6A5BF270E       86       008a.962d.7400/0001    2        16      

Potential Peer List:
-------------------------------------------------------------------------------
           MI                  MN             Rx-SCI          SSCI  KS-Priority 
-------------------------------------------------------------------------------

Peers Status:
 Last Tx MKPDU          : 2019 Oct 08 07:39:56.905
 Peer Count             : 1

 RxSCI                  : 008A962D74000001
  MI                    : 018E2F0D63FF2ED6A5BF270E
  Peer CAK              : Match
  Latest Rx MKPDU       : 2019 Oct 08 07:39:57.363

With the introduction of active fallback functionality:

The following is a snippet from the sample output that displays entry for active fallback PSK as well. The secured primary session output part is truncated here, which is exactly same as the output given above.

Router# show macsec mka session detail
NODE: node0_1_CPU0

MKA Detailed Status for MKA Session
===================================
Status: Secured - Secured MKA Session with MACsec

Local Tx-SCI                    : 0257.3fae.5cda/0001
Local Tx-SSCI                   : 1
- - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - -
MKA Detailed Status for MKA Session
===================================
Status: Active - Marked Peer as Live (Waiting for SAK generation/distribution)

Local Tx-SCI                    : 0257.3fae.5cda/0001
Local Tx-SSCI                   : 1
Interface MAC Address           : 0257.3fae.5cda
MKA Port Identifier             : 1
Interface Name                  : Hu0/1/0/0
CAK Name (CKN)                  : 1111
CA Authentication Mode          : FALLBACK-PSK
Keychain                        : fb1
Member Identifier (MI)          : FC53A31E030E385981E0AACE
Message Number (MN)             : 178
Authenticator                   : NO
Key Server                      : NO
MKA Cipher Suite                : AES-256-CMAC
Configured MACSec Cipher Suite  : GCM-AES-XPN-256
Key Distribution Mode           : SAK

Latest SAK Status               : Rx & Tx
Latest SAK AN                   : 1
Latest SAK KI (KN)              : 725FF8F6605A3D428972538F00000001 (1)
Old SAK Status                  : No Rx, No Tx
Old SAK AN                      : 0
Old SAK KI (KN)                 : RETIRED (0)

SAK Transmit Wait Time          : 0s (Not waiting for any peers to respond)
SAK Retire Time                 : 0s (No Old SAK to retire)
Time to SAK Rekey               : NA
Time to exit suspension         : NA

MKA Policy Name                 : *DEFAULT POLICY*
Key Server Priority             : 16
Delay Protection                : FALSE
Replay Window Size              : 64
Include ICV Indicator           : FALSE
Confidentiality Offset          : 0
Algorithm Agility               : 80C201
SAK Cipher Suite                : 0080C20001000004 (GCM-AES-XPN-256)
MACsec Capability               : 3 (MACsec Integrity, Confidentiality, & Offset)
MACsec Desired                  : YES

# of MACsec Capable Live Peers           : 1
# of MACsec Capable Live Peers Responded : 0

Live Peer List:
-------------------------------------------------------------------------------
           MI                  MN             Rx-SCI          SSCI  KS-Priority 
-------------------------------------------------------------------------------
6A894FE1E984AD5314F33D21      188       0201.9ab0.85af/0001    0        16      

Potential Peer List:
-------------------------------------------------------------------------------
           MI                  MN             Rx-SCI          SSCI  KS-Priority 
-------------------------------------------------------------------------------

Peers Status:
 Last Tx MKPDU          : 2021 Apr 30 14:56:33.797
 Peer Count             : 1

 RxSCI                  : 02019AB085AF0001
  MI                    : 6A894FE1E984AD5314F33D21
  Peer CAK              : Match
  Latest Rx MKPDU       : 2021 Apr 30 14:56:34.638

The following is a sample output of the show macsec mka session interface command. With this command, you can verify whether the interface of the router is peering with its neighbor after MACsec configuration. The MACsec PSK validation detects inconsistency or mismatch of primary and fallback keys (CAK) being used by MKA, allowing operators to rectify the mismatch.

Verify whether the MKA session is secured with MACsec on the respective interface. The Status field in the output verifies if the MKA session is secured with MACsec encryption. The output also displays information about the interface and other MACsec parameters.

Router#show macsec mka session interface hundredGigE 0/1/0/10 

===============================================================================================
   Interface-Name        Local-TxSCI       #Peers   Status   Key-Server   PSK/EAP      CKN     
===============================================================================================
     Hu0/1/0/10      7872.5d1a.e7d4/0001     1      Secured      NO       PRIMARY     1234  
     Hu0/1/0/10      7872.5d1a.e7d4/0001     1      Secured      NO       FALLBACK      5678   

Before the introduction of active fallback functionality:

Router# show macsec mka session interface hundredGigE 0/1/0/10 detail 

MKA Detailed Status for MKA Session
===================================
Status: Secured - Secured MKA Session with MACsec

Local Tx-SCI                    : 7872.5d1a.e7d4/0001
Local Tx-SSCI                   : 1
Interface MAC Address           : 7872.5d1a.e7d4
MKA Port Identifier             : 1
Interface Name                  : Hu0/1/0/10
CAK Name (CKN)                  : 1234
CA Authentication Mode          : PRIMARY-PSK
Keychain                        : kc
Member Identifier (MI)          : C12A70FEE1212B835BDDDCBA
Message Number (MN)             : 433
Authenticator                   : NO
Key Server                      : NO
MKA Cipher Suite                : AES-128-CMAC
Configured MACSec Cipher Suite  : GCM-AES-XPN-128

Latest SAK Status               : Rx & Tx
Latest SAK AN                   : 0
Latest SAK KI (KN)              : 018E2F0D63FF2ED6A5BF270E00000001 (1)
Old SAK Status                  : FIRST-SAK
Old SAK AN                      : 0
Old SAK KI (KN)                 : FIRST-SAK (0)

SAK Transmit Wait Time          : 0s (Not waiting for any peers to respond)
SAK Retire Time                 : 0s (No Old SAK to retire)
Time to SAK Rekey               : NA
Time to exit suspension         : NA

MKA Policy Name                 : mp-SF
Key Server Priority             : 16
Delay Protection                : FALSE
Replay Window Size              : 64
Include ICV Indicator           : FALSE
Confidentiality Offset          : 30
Algorithm Agility               : 80C201
SAK Cipher Suite                : 0080C20001000003 (GCM-AES-XPN-128)
MACsec Capability               : 3 (MACsec Integrity, Confidentiality, & Offset)
MACsec Desired                  : YES

# of MACsec Capable Live Peers           : 1
# of MACsec Capable Live Peers Responded : 0

Live Peer List:
-------------------------------------------------------------------------------
           MI                  MN             Rx-SCI          SSCI  KS-Priority 
-------------------------------------------------------------------------------
018E2F0D63FF2ED6A5BF270E      123       008a.962d.7400/0001    2        16      

Potential Peer List:
-------------------------------------------------------------------------------
           MI                  MN             Rx-SCI          SSCI  KS-Priority 
-------------------------------------------------------------------------------

Peers Status:
 Last Tx MKPDU          : 2019 Oct 08 07:41:12.929
 Peer Count             : 1

 RxSCI                  : 008A962D74000001
  MI                    : 018E2F0D63FF2ED6A5BF270E
  Peer CAK              : Match
  Latest Rx MKPDU       : 2019 Oct 08 07:41:11.400

With the introduction of active fallback functionality:

The following is a snippet from the sample output that displays entry for active fallback PSK as well. The secured primary session output part is truncated here, which is exactly same as the output given above.

Router# show macsec mka session interface hundredGigE 0/1/0/10 detail 

MKA Detailed Status for MKA Session
===================================
Status: Secured - Secured MKA Session with MACsec

Local Tx-SCI                    : 7872.5d1a.e7d4/0001
Local Tx-SSCI                   : 1
- - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - 
MKA Detailed Status for MKA Session
===================================
Status: Active - Marked Peer as Live (Waiting for SAK generation/distribution)

Local Tx-SCI                    : 34ed.1b5b.d0d7/0001
Local Tx-SSCI                   : 1
Interface MAC Address           : 34ed.1b5b.d0d7
MKA Port Identifier             : 1
Interface Name                  : Hu0/4/0/27
CAK Name (CKN)                  : 2222
CA Authentication Mode          : FALLBACK-PSK
Keychain                        : fb1
Member Identifier (MI)          : C0978A6B0916C3FC959773FE
Message Number (MN)             : 24039
Authenticator                   : NO
Key Server                      : NO
MKA Cipher Suite                : AES-256-CMAC
Configured MACSec Cipher Suite  : GCM-AES-XPN-256

Latest SAK Status               : Rx & Tx
Latest SAK AN                   : 2
Latest SAK KI (KN)              : 3D008A7D75DF0A9A35F9E3A900000002 (2)
Old SAK Status                  : No Rx, No Tx
Old SAK AN                      : 1
Old SAK KI (KN)                 : RETIRED (0)

SAK Transmit Wait Time          : 0s (Not waiting for any peers to respond)
SAK Retire Time                 : 0s (No Old SAK to retire)
Time to SAK Rekey               : NA
Time to exit suspension         : NA

MKA Policy Name                 : r1
Key Server Priority             : 16
Delay Protection                : FALSE
Replay Window Size              : 64
Include ICV Indicator           : FALSE
Confidentiality Offset          : 0
Algorithm Agility               : 80C201
SAK Cipher Suite                : 0080C20001000004 (GCM-AES-XPN-256)
MACsec Capability               : 3 (MACsec Integrity, Confidentiality, & Offset)
MACsec Desired                  : YES

# of MACsec Capable Live Peers           : 1
# of MACsec Capable Live Peers Responded : 0

Live Peer List:
-------------------------------------------------------------------------------
           MI                  MN             Rx-SCI          SSCI  KS-Priority 
-------------------------------------------------------------------------------
B5ED6849883F34FEE89F74D1     26068      008a.9681.c02c/0001    2        16      

Potential Peer List:
-------------------------------------------------------------------------------
           MI                  MN             Rx-SCI          SSCI  KS-Priority 
-------------------------------------------------------------------------------

Peers Status:
Last Tx MKPDU          : 2021 Apr 28 02:08:03.795
Peer Count             : 1

RxSCI                  : 008A9681C02C0001
  MI                    : B5ED6849883F34FEE89F74D1
  Peer CAK              : Match
  Latest Rx MKPDU       : 2021 Apr 28 02:08:02.749

You can enable the MACsec mode for the physical layer transceiver (PHY) of a line card by using the hw-module macsec-mode command in XR Config mode mode.

Configuration Example

Router#configure
Router(config)#hw-module macsec-mode location 0/1/CPU0
Router(config)#commit

You must reload the line card for this configuration to take effect.

Note

If the MACsec mode is already enabled on a node such as a line card, then the system does not allow you to configure the hw-module macsec-mode location all command again. This restriction is in place to prevent conflicts in configuration, especially in a configuration restore scenario. In such scenarios, you can make use of the show hw-module macsec-mode command to know of the respective running configurations in place.

hw-module macsec-mode location 0/1/CPU0
!

Router#show hw-module macsec-mode location 0/1/CPU0
Sat Dec  7 14:31:52.668 UTC
Location       Configured     Running          Action        
-------------------------------------------------------------
0/1/CPU0       YES            NO               RELOAD  

Router#show hw-module macsec-mode location all
Sun Feb 16 21:06:07.726 UTC
 
Location       Configured     Running          Action         
-------------------------------------------------------------
0/0/CPU0       YES            NO               RELOAD           
0/7/CPU0       NO             NO               NONE           

You can now implement MACsec on L3 subinterfaces to provide secure communication within a specific L3 VLAN. On implementing MACsec on the L3 subinterface, the MACsec encryption and authentication are unique to the traffic on that subinterface. As a result, you can control the traffic encryption for individual subinterfaces of a physical interface by customizing MACsec policies.

MACsec on L3 subinterface configurations are similar to the MACsec configurations on a physical interface. For a successful MACsec Key Agreement protocol (MKA) session to be up on any L3 subinterface, it must have a valid tagging protocol encapsulation and a VLAN identifier assigned. All L3 subinterfaces always default to the 802.1Q VLAN encapsulation. However, the VLAN identifier must be explicitly defined.

By default, the MACsec security policy uses must-secure option, that mandates data encryption. Hence, the packets cannot be sent in clear-text format. To optionally bypass the MACsec encryption or decryption for Link Aggregation Control Protocol (LACP) packets, and to send the packets in clear-text format, use the policy-exception lacp-in-clear command in macsec-policy configuration mode. This functionality is beneficial in scenarios such as, in a network topology with three nodes, where bundles are terminated at the middle node, whereas MACsec is terminated at the end nodes.

This MACsec policy exception is also beneficial in interoperability scenarios where the node at the other end expects the data packets to be in clear text.

From Cisco IOS XR Software Release 7.3.1 and later, an alternative option, allow , is introduced under the macsec-policy configuration mode, that allows packets to be sent in clear-text format. You can use the allow lacp-in-clear command for LACP packets.

Similarly, you can use the allow pause-frames-in-clear to allow Ethernet PAUSE frame packets in clear text, from Release 7.3.15 and later.

The following methods are used to query MACsec SecY statistics such as, encryption, decryption, and the hardware statistics.

• CLI

• SNMP MIB

The Cisco IOS XR Software Release 7.0.14 introduces the support for power-on self-test (POST) known answer test (KAT) for common criteria and FIPS compliance for the MACsec-enabled hardware on Cisco 8000 Series Routers. In POST KAT, the KAT is executed immediately after the cipher module is powered on. With this feature enabled, the system allows the traffic to pass through the MACsec-enabled hardware only if it passes the KAT. If the KAT fails, the modules shut down and the ports do not come up.

The POST KAT functionality is now available on Cisco 8800 48x100 GbE QSFP28 Line Card (8800-LC-48H) and Cisco 8800 36x400GE QSFP56-DD Line Card with MACsec (8800-LC-36FH-M).

The dynamic power management feature allocates total power to a router and its fabric cards or line cards based on certain factors like number and type of fabric cards and line cards installed on the router, operating modes of fabric cards, combination of line card and fabric card types installed, NPU power mode configured on a fabric card, optics, and so on.

For details on dynamic power management feature, see the Managing Router Hardware chapter in the System Management Configuration Guide for Cisco 8000 Series Routers.

Prior to Cisco IOS XR Software Release 7.3.3, enabling or disabling MACSec on line card interfaces was not accounted in dynamic power management functionality. Starting Release 7.3.3, when you configure MACSec on interfaces, the software internally checks if there is enough power to bring up MACSec sessions for all those configured interfaces. Accordingly, if there is shortage of power to cater to all MACSec sessions, some MACSec sessions might not come up, irrespective of the fact that MACSec feature configuration was successful on those interfaces. The router console displays the following log message in such cases indicating the reason for session failure.

LC/0/4/CPU0:Dec 21 07:35:27.977 UTC: macsec_mka[131]: %L2-MKA-5-MACSEC_POWER_STATUS_ERR : (Hu0/4/0/9), Insufficient power

You may choose to remove the MACSec configuration from the corresponding interfaces or re-provision the PSUs based on the additional power requirement for the new sessions.

Note	If you choose not to remove MACSec configurations for sessions which are down, there is no guarantee that the same MACSec sessions that were brought up earlier will come up after a router or line card reload.

By default, the dynamic power management is enabled on a router. You can disable the feature using the no power-mgmt action command in XR Config mode.

Cisco Secure Key Integration Protocol (SKIP) enables your router that supports encryption to use keys by a quantum distribution system. SKIP implementation in Cisco IOS-XR software supports integrating external Quantum Key Distribution (QKD) devices with your routers. With integration support between the routers and QKD devices, you can use the QKD devices to exchange encryption keys for communication between the routers. And this mechanism eliminates the key distribution problem in a post quantum world.

Quantum Key Distribution (QKD) is a method for securely transmitting a secret key between two parties. QKD uses the laws of quantum mechanics to guarantee security even when eavesdroppers monitor the communication channel. In QKD, the key is encoded in the states of single photons. The QKD transmits the keys over optical fiber or free space (vacuum). The security of the key relies on the fact that measuring a quantum state introduces a change in the quantum state. The change in quantum states helps the two end parties of the communication channel to identify any interception of their key.

QKD is a secure key exchange mechanism against quantum attacks and will remain so, even with future advancements in cryptanalysis or quantum computing. Unlike other cryptographic algorithms, QKD doesn’t need continual updates based on discovered vulnerabilities.

The following commands are available to verify the SNMP results.