Cisco MACSec Advanced Switch-to-Switch Configuration

This article is a follow-up to two articles on how to configure basic MACSec and assumes you have read one of the articles below or are already familiar with basic MACSec configuration.

Cisco MACSec Switch-to-Switch Configuration using Pre-Shared Key on IOS-XE

Cisco MACSec Switch-to-Switch Configuration using Pre-Shared Key between IOS-XE / IOS

Introduction

In this article, we take a look at two optional MACSec parameters called Confidentiality Offset and Replay Protection Window size, which could be useful for your network depending on where you plan to deploy MACSec technology.

This article assumes you have basic knowledge of MACSec configuration already or have read any of the two previous MACSec articles linked at the beginning of this article.

The following configuration has been tested:

  • Cisco Catalyst C9200L-48P-4X-E running IOS-XE 17.3.4

Confidentiality Offset

Confidentiality Offset is a MACsec feature that allows some portion (a select number of bytes) of the MACSec encrypted frames to NOT be encrypted, which will cause the frame to reveal certain parameters such as IPv4, IPv6, and TCP/UDP headers. This can be useful if you are running an in-line transparent firewall or a load balancer between two devices running MACSec, as you would then be able to perform actions based on information in these headers, like source/destination IP addresses and ports.

The “offset” in this feature refers to how many bytes of data will be unencrypted. There are three options to pick form here, described below.

  • Offset 0 = no change in transmitted frames, everything is encrypted

  • Offset 30 = IPv4 header and TCP/UDP header are sent unencrypted

  • Offset 50 = IPv6 header and TCP/UDP header are sent unencrypted

Configuring Confidentiality Offset

Inside the MKA Policy is where that Confidentiality Offset is configured. The MKA Policy is then applied to the physical interface where Confidentiality Offset will be configured, along with all the other settings belonging to the MKA Policy.

Make sure to configure both sides of the MACSec link to have the same offset value!

The relevant configuration is highlighted below.

mka policy MKA-POLICY
   macsec-cipher-suite gcm-aes-128
   key-server priority 10 (can vary depending on Key Server role or not)
   sak-rekey interval 30
   confidentiality-offset 30

Verifying Confidentiality Offset

Using the command “show macsec interface <interface>” we can confirm that Confidentiality Offset is enabled and see how many bytes are configured to offset in the encryption.

Replay Protection

Replay Protection is a MACSec feature that, by default, counters replay attacks by keeping track of sent and received frames by using the MACSec Packet Numbers (PN) feature, but there are instances where this protection can cause you trouble.

One scenario where this can occur is if you are running MACSec between two switches that are connected to each other using some sort of transparent transport, for example, over an ISP network or Metro Ethernet performing some sort of layer 2 transport service. Since this transport network could have multiple paths from your Switch 1 to Switch 2, packets sent between the two switches could arrive in a different order than they were sent.

To still make it possible to run MACSec between these two switches, a Replay Protection Windows Size can be enabled, which allows packets to arrive at an interface out-of-order, as long as the Packet Number (PN) is within a configured limit packet count.

Configuring Replay Protection

Replay Protection Window Size is configured as a set value between 0 and 4294967295. The default value on my lab C9200L-48P-4X switches is “0”, meaning packets must always arrive in order. This default value of “0” is fine if you are only directly connecting your devices running the MACSec link between them.

This Replay Protection Window Size is configured on a per-interface level using the command below. It is hard to say how big of a value you need to configure here in your specific case, you will probably have to do some testing to figure out the sweet spot between not having any packets dropped and not having too great of a window size to be vulnerable to replay attacks.

Make sure to configure both sides of the MACSec link to have the same window size value!

The relevant configuration is highlighted below.

interface te1/1/1
   switchport mode trunk
   macsec network-link
   mka policy MKA-POLICY
   mka pre-shared-key key-chain MKA-KC
   macsec replay-protection windows-size 100

Verifying Replay Protection

Using the command “show macsec interface <interface>” we can confirm that Replay Protection is enabled and see the window size which allows packets to arrive unordered at an interface and still be considered legit, and not discarded.