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

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

• Support for Point-to-Multipoint (P2MP) deployment models.

• Support for multiple P2P and P2MP deployments on the same physical interface.

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

• Support for 128- 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.

• 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 WAN 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 the access-control should-secure command while enabling MACsec for the first time and subsequently remove the command to change to default access-control must-secure , once the session establishment is successful, unless it is needed for migration.

• 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 is 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 an MKA policy is not configured on a subinterface, a policy that is configured on the physical interface is be applied at session start.

• 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 at which time 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 to configure the MACsec key chain.

You can 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 need 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]

It is recommended to change data packets cipher suite in the key server for the cipher suite rollover to be seamless, if the nonkey servers have the same cipher-suite configured in the list or is with default configuration.

Refer the following table to understand the port speed for each of the ciphers supported with MKA policy

When MACsec is enabled on an interface, the entire interface traffic is secured, by default. MACsec does not allow any unencrypted packets to be transmitted or received from the same physical interface. However, to enable MACsec on selected subinterfaces, an additional Cisco proprietary extension has been implemented to allow unencrypted packets to be transmitted or received from the same physical interface.

Use the macsec access-control {must-secure | should-secure} command to control the behavior of unencrypted packets.

• The should-secure keyword allows unencrypted packets from the physical interface or subinterfaces to be transmitted or received.

• The must-secure keyword does not allow unencrypted packets from physical interface or subinterfaces to be transmitted or received. All such packets are dropped except for MKA control protocol packets

• If MACsec is enabled only on selected subinterfaces, configure the should-secure keyword option on the corresponding interface.

The default configuration for MACsec on subinterfaces is macsec access-control must-secure . This option is enabled by default when the macsec command is configured on an interface.

Note	The macsec access-control should-secure command can be configured only at the interface level and not the subinterface. Configuring this command allows unencrypted traffic on a secured MACsec session.

Note	For non-MACsec subinterface, you must configure the should-secure option for traffic to pass.

Before establishing a MACsec secure session, MKA (MACsec Key Agreement) is used as the control protocol. MKA selects the cipher suite to be used for encryption and to exchange the required keys and parameters between peers.

MKA uses Extensible Authentication Protocol over LAN (EAPoL) as the transport protocol to transmit MKA messages. By default, EAPoL uses a destination multicast MAC address of 01:80:c2:00:00:03 to multicast packets to multiple destinations. EAPoL is a standards-based protocol and other authentication mechanisms such as IEEE 802.1X also use the same protocol. Devices in the service provider cloud might consume this packet (based on the destination multicast MAC address), and try to process the EAPoL packet and eventually drop the packet. This causes MKA session to fail.

Use the eapol destination-address command to change the destination MAC address of an EAPoL packet that is transmitted on an interface towards the service provider. This ensures that the service provider tunnels the packet like any other data packet instead of consuming them.

Note

The EAPoL destination address can be configured independently on either physical or subinterface level. If it is configured on the physical interface, it is automatically inherited by the subinterfaces. Explicit configuration on the subinterface overrides the inherited value or policy for that subinterface.

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.

Note

A replay protection window can be configured independently on either physical interface or subinterface. If it is configured on the physical interface, it is automatically inherited by the subinterfaces. Explicit configuration on subinterface overrides the inherited value or policy for that sub-interface.

In Cisco IOS XE Release 3.16S, MACsec is introduced on WAN interface cards (NIM-2GE-CU-SFP and NIM-2GE-CU-SFP) on Cisco 4000 Series Integrated Services Routers (ISRs).

This WAN interface card is a two one-Gigabit Ethernet-port Next Generation WAN Interface Card.

The following platforms support the Next Generation WAN Interface Card:

• Cisco ISR 4451

• Cisco ISR4431

• Cisco ISR4351

• Cisco ISR 4331

• Cisco ISR 4321

The following tables show the performance numbers on Cisco ASR 1000 routers from Cisco IOS XE 16.6 release onwards.