• Layer 2 transparent Ethernet Services must be present.

• The service provider network must provide a MACsec Layer 2 Control Protocol transparency such as, Extensible Authentication Protocol over LAN (EAPoL).

• MACsec port license is supported on both 1GE and 10GE interfaces for Cisco ASR 903 and 907 routers from Cisco IOS XE Bengaluru 17.6.1 release onwards.

• MACsec supports No License Mode.

• For Ethernet service instance on the customer edge (CE) copper link to work, the Ethernet service instance, where xconnect is present in the provider edge (PE) must have the remote link failure notification command that is configured on the link.

  Following is a sample configuration.

  interface TenGigabitEthernet x/y/z
    description ### X connect 1 <name> ###
    mtu 9216
    no ip address
    negotiation auto
    no keepalive
    service instance 10 ethernet
    encapsulation default
    l2protocol tunnel cdp stp vtp pagp dot1x lldp lacp udld loam esmc elmi ptppd mmrp mvrp
    xconnect x.x.x.x 10 encapsulation mpls
    remote link failure notification
  

• On Cisco ASR 903 and 907 Series Aggregation Services Routers, MACsec doesn’t support AAA accounting.

• MACsec is supported up to line rate on each interface. However, the forwarding capability may be limited by the maximum system forwarding capability.

• MACsec is supported on PE label on Cisco ASR 903 and 907 routers of A900-IMA8CS1Z-M interface module.

• MACsec configuration on Ether Channel (Link bundling) isn’t supported.

• Any interface that is configured with MACsec can’t be part of Ether Channel.

• If the MKA session is torn down because of key unwrap failure, re-configure the pre-shared key-based MKA session using MACsec configuration commands on the respective interfaces to bring up the MKA session.

• MACsec-configured on physical interface with Ethernet Virtual Circuits (EVC) isn’t supported. The EAPoL frames get dropped in such cases.

• On Cisco ASR 903 and 907 Series Aggregation Services Routers, the following table lists the Gigabit Ethernet interface and the maximum number of peers that are supported per interface.

  Gigabit Ethernet Interface	Peers per Interface
  1G	8
  10G	32

• When macsec dot1q-in-clear is enabled, the native VLAN isn’t supported.

MACsec is an IEEE 802.1AE standards based Layer 2 hop-by-hop encryption that provides data confidentiality and integrity for media access independent protocols.

MACsec, provides MAC-layer encryption over wired networks by using out-of-band methods for encryption keying. The MACsec Key Agreement (MKA) protocol provides the required session keys and manages the required encryption keys. Only host facing links (links between network access devices and endpoint devices such as a PC or IP phone) can be secured using MACsec.

The 802.1AE encryption with MACsec Key Agreement (MKA) is supported on downlink ports for encryption between the routers or switches and host devices.

MACsec encrypts the entire data except for the Source and Destination MAC addresses of an Ethernet packet.

To provide MACsec services over the LAN or Metro Ethernet, service providers offer Layer 2 transparent services such as E-Line or E-LAN using various transport layer protocols such as Ethernet over Multiprotocol Label Switching (EoMPLS) and L2TPv3.

The EAP framework implements MKA as a newly defined EAP-over-LAN (EAPOL) packet. EAP authentication produces a master session key (MSK) shared by both partners in the data exchange. Entering the EAP session ID generates a secure connectivity association key name (CKN). Because the switch is the authenticator, it is also the key server, generating a random 128-bit secure association key (SAK), which it sends it to the client partner. The client is never a key server and can only interact with a single MKA entity, the key server. After key derivation and generation, the switch sends periodic transports to the partner at a default interval of 2 seconds.

The packet body in an EAP-over-LAN (EAPOL) Protocol Data Unit (PDU) is referred to as a MACsec Key Agreement PDU (MKPDU). When no MKPDU is received from a participants after 3 hearbeats (each hearbeat is of 2 seconds), peers are deleted from the live peer list For example, if a client disconnects, the participant on the switch continues to operate MKA until 3 heartbeats have elapsed after the last MKPDU is received from the client.

The MKA feature support provides tunneling information such as VLAN tag (802.1Q tag) in the clear so that the service provider can provide service multiplexing such that multiple point to point or multipoint services can co-exist on a single physical interface and differentiated based on the now visible VLAN ID.

In addition to service multiplexing, VLAN tag in the clear also enables service providers to provide quality of service (QoS) to the encrypted Ethernet packet across the SP network based on the 802.1P (CoS) field that is now visible as part of the 802.1Q tag.

Starting with Cisco IOS XE Release 17.8.1, full HA, Power on Self Test (POST) and double tag support are available on A900-IMA8CS1Z-M interface module. The POST tests the hardware to verify that all components of the device are operational and present. In the double tagging (qinq tag) method, the VLAN tag simply adds another tag to the tagged packets that enter the network. The purpose is to expand the VLAN space by tagging the tagged packets, thus producing a “double-tagged” frame. The expanded VLAN space allows the service provider to provide certain services, such as Internet access on specific VLANs for specific customers, and yet still allows the service provider to provide other types of services for their other customers on other VLANs. The Single Sign-On (SSO) and IM Online Insertion and Removal (OIR) triggers preserve MKA sessions.

• Support for both Copper SFP 10M and 100M speed for MACsec.

• Support for point-to-point (P2P) deployment models.

• Support for 128 bit and 256 bit Advanced Encryption Standard–Galois Counter Mode (AES-GCM) encryption for data packets.

• Support for 128 bit and 256 bit Advanced Encryption Standard-Cipher-based Message Authentication Code (AEC-CMAC) encryption for control packets.

• Support for VLAN tag in the clear option to enable Carrier Ethernet Service Multiplexing.

• Support for coexisting of MACsec and Non-MACsec subinterfaces.

• Support for configurable Extensible Authentication Protocol over LAN (EAPOL) destination address.

• Support for configurable option to change the EAPOL Ethernet type.

• Support for configurable replay protection window size to accommodate packet reordering in the service provider network.

• Support for MACsec stateless switchover. During route processor (RP) switchover on dual RP setup, there is a teardown of existing MACsec session and the session is re-negotiated/reinitiated automatically (stateless switchover). During this process, some traffic drop might occur for a few seconds.

• Ensure basic Layer 2 Ethernet connectivity is established and verified before attempting to enable MACsec. Basic ping between the customer edge devices must work.

• When you are configuring MACsec for the first time, ensure that you have out of band connectivity to the remote site to avoid locking yourself out after enabling MACsec, if the session fails to establish.

• We recommend that you configure an interface MTU, adjusting it for MACsec overhead, for example, 32 bytes. Although MACsec encryption and decryption occurs at the physical level and MTU size does not effect the source or destination router, it may effect the intermediate service provider router. Configuring an MTU value at the interface allows for MTU negotiation that includes MACsec overhead.

On WAN routers, MKA policy is inherited and also it has a default value. When a new session is started, the following rules apply:

• If an MKA policy is configured on a subinterface, it will be applied when an MKA session is started.

• If a MKA policy is not configured on a subinterface or physical interface, default policy is applied at session start.

A MACsec key chain can have multiple pre-shared keys (PSK) each configured with a key ID and an optional lifetime. A key lifetime specifies when the key expires. In the absence of a lifetime configuration, the default lifetime is unlimited. When a lifetime is configured, MKA rolls over to the next configured pre-shared key in the key chain after the lifetime is expired. Time zone of the key can be local or UTC. Default time zone is UTC.

Use the key chain name macsec command to configure the MACsec key chain.

The key rolls over to the next key within the same key chain by configuring a second key in the key chain and configuring a lifetime for the first key. When the lifetime of the first key expires, it automatically rolls over to the next key in the list. If the same key is configured on both sides of the link at the same time, then the key rollover is hitless, that is, key rolls over without traffic interruption.

Note	The lifetime of the keys needs to be overlapped in order to achieve hitless key rollover.

Cryptographic Algorithm selection for MKA control protocol packets encryption is as follows:

• Cryptographic Algorithm to encrypt MKA control protocol packets is configured as part of the key chain. There can be only one cryptographic algorithm configured per key chain.

• A key server uses the configured MKA cryptographic algorithm from the key chain that is used.

• All nonkey servers must use the same cryptographic algorithm as the key server.

If an MKA cryptographic algorithm is not configured, a default cryptographic algorithm of AES-CMAC-128 (Cipher-based Message Authentication Code with 128-bit Advanced Encryption Standard) is used.

Encryption algorithm for Data packets:

mka policy p1
macsec-cipher-suite [gcm-aes-128 | gcm-aes-256

Encryption algorithm for MKA Control packets

key chain <name> macsec
key 01
key-string <Hex string>
cryptographic-algorithm [aes-256-cmac  | aes-128-cmac]

Replay protection is a feature provided by MACsec to counter replay attacks. Each encrypted packet is assigned a unique sequence number and the sequence is verified at the remote end. Frames transmitted through a Metro Ethernet service provider network are highly susceptible to reordering due to prioritization and load balancing mechanisms used within the network.

A replay window is necessary to support use of MACsec over provider networks that reorder frames. Frames within the window can be received out of order, but are not replay protected. The default window size is set to 64. Use the macsec replay-protection window-size command to change the replay window size. The range for window size is 0 to 4294967295.

The replay protection window may be set to zero to enforce strict reception ordering and replay protection.

The interface module N560-IMA-8Q/4L is supported on Cisco ASR 903 and 907 routers on 10GE interfaces.

The interface module A900-IMA8CS1Z-M is supported on Cisco ASR 903 and 907 routers on 1GE and 10GE interfaces.

To configure WAN MACsec for QINQ clear tag:

configure terminal
!
key chain k10 macsec 
key 10  cryptographic-algorithm aes-256-cmac  
key-string  1234567890123456789012345678901212345678901234567890123456789012!
mka policy p2 
key-server priority 223 
macsec-cipher-suite gcm-aes-256
!
interface TengigabitEthernet0/3/16 
no ip address 
ip mtu 1468 
macsec dot1q-in-clear 2 
service instance 200 ethernet  
encapsulation dot1q 200 second-dot1q 201  
rewrite ingress tag pop 2 symmetric  
mka pre-shared-key key-chain k10  
mka policy p2  
macsec  
bridge-domain 200
end

For MKA-PSK sessions, instead of fixed 32 bytes, the Connectivity Association Key name (CKN) uses the same string as the CKN, which is configured as the hex-string for the key.

Example Configuration:

     configure terminal
     key chain abc macsec
       key 11
         cryptographic-algorithm aes-128-cmac
         key-string 12345678901234567890123456789013
         lifetime local 12:21:00 Sep 9 2015 infinite
 
      end

For the previous example, following is the show command output for the show mka session command:

Device# show mka session
           
           Total MKA Sessions....... 1
           Secured Sessions... 1
           Pending Sessions... 0
           ====================================================================================================
           Interface      Local-TxSCI         Policy-Name      Inherited         Key-Server                                            
           Port-ID        Peer-RxSCI          MACsec-Peers     Status            CKN                                                   
           ====================================================================================================
           Et0/0          aabb.cc00.6600/0002     icv            NO                NO                                                    
           2              aabb.cc00.6500/0002 1                Secured           11   *Note that the CKN key-string is exactly the same that has been configured for the key as hex-string.*

In the case of interoperability between two images -- one having the CKN behavior change, and one without the CKN behavior change, then the hex-string for the key must be a 64-character hex-string with zero padded to work on a device that has an image with the CKN behavior change. See the following example:

Configuration without CKN key-string behavior change:
       
      config t
        key chain abc macsec
         key 11
         cryptographic-algorithm aes-128-cmac
         key-string 12345678901234567890123456789013
         lifetime local 12:21:00 Sep 9 2015 1-864000
 
 Configuration with CKN key-string behavior change:
                                                
      config t
        key chain abc macsec
         key 11000000000000000000000000000000000000000000000000000000000000000
         cryptographic-algorithm aes-128-cmac
         key-string 12345678901234567890123456789013
         lifetime local 12:21:00 Sep 9 2015 1-864000