MACsec Hardware Testing—Why Back-to-Back Validation Falls Short

By Yuanwen (Daisy) Sun |

MACsec has become an important encryption technology that is shipped with next-generation chips, routers, and switches. Silicon vendors and NEMs now support MACsec in almost all the next-generation products they are building. Due to the lack of effective test tools, most vendors are testing MACsec using their own devices in a back-to-back configuration. This negatively impacts test coverage and quality, causing interoperability issues in the field.

This is the first of a series of blogs to discuss what you need to validate in MACsec implementations. I’ll explain why back-to-back testing is not enough and how thorough validation is needed with an effective third-party test tool. To start, let’s overview MACsec technology and then focus on validating MACsec hardware implementations.

TECHNOLOGY OVERVIEW

MACsec 802.1AE is an industry-standard security technology that provides secure communication for Ethernet networks. It operates at the link layer (Layer 2) and secures point-to-point links or shared Ethernet networks to provide confidentiality, integrity, and authenticity for user data. MACsec can protect against most security threats, including denial of service, intrusion, man-in-the-middle, playback attacks, and passive wiretapping.

MACsec was first standardized in 2006 by IEEE 802.1AE-2006. Multiple revisions since then have added strong cipher suites, extended packet number, and provider network support. These innovations are driven by continuously increasing bandwidth demand in wide-area network (WAN) to support use cases such as data center interconnect, branch back-haul, and metro Ethernet. MACsec has evolved from a local-area network (LAN) encryption technology to a much wider area in WAN transport, cloud and data center, 5G, and automotive networks.

MACsec is based on the standard Ethernet frame format and its encoding is as follows:

1

MACsec Frame Encoding

MACsec uses the Galois/Counter Mode Advanced Encryption Standard (AES-GCM) for authentication and encryption, with the AES-GCM-128 and AES-GCM-256 cipher suites. Two additional cipher suites, GCM-AES-XPN-128 and GCM-AES-XPN-256, are added to support extended packet numbers (64 bites) for higher-speed Ethernet operation.

MACsec also offers the following enhanced features to support transparent secure connectivity across the bridged network as well as in the WAN network.

By leaving VLAN tags, MPLS labels, or a portion of frames after SecTAG in clear text, the intermediate nodes in the network can make forwarding decisions transparently without participating in hop-by-hop MACsec secure association.

TESTING MACSEC HARDWARE IMPLEMENTATIONS

MACsec encryption and decryption is done in hardware to support line-rate encryption throughput for high-speed Ethernet. Many silicon vendors have MACsec built into PHY or their switch chips. Network equipment manufacturers (NEMs) utilize the MACsec functions in chips and integrate them at the system level with software to manage connectivity associations and distribute secure association key (SAK) used by hardware for encryption/decryption. Therefore, the first natural step of MACsec validation is to validate the functionality and performance of the encryption engine built into the hardware. Key validation areas include

Validate the proper functionality of encryption and decryption.

This is typically done through integrity check value (ICV) validation, packet formatting check, and inspection of decrypted packets. There are two scenarios here.

With back-to-back vendor devices, there is no full visibility of encryption/decryption state between the devices. If there is a bug in the encryption algorithm or ICV calculation, it may not be captured as both devices have the same bug. The result may be a false correct, causing potential interoperability issues in the field. Validation using a third-party tool will help to eliminate false corrects. More importantly, it provides full visibility to MACsec encryption/decryption with statistics to show ICV validation, frame encoding validation, as well as other statistics at per port, per device, and per secure association (SC) level to help with validation and troubleshooting.

Stress encryption engine and measure encryption throughput

Achieving line-rate encryption in high-speed Ethernet is very challenging, especially as speeds increase to 100G and above. Measuring encryption engine performance at various conditions provides a benchmark of MACsec performance in hardware. Consider the following during such validation.

You can see that many aspects need to be validated to ensure proper function and performance. It is not possible to exercise all these validation points without a third-party tool that provides full control and deterministic traffic profiles. One example is bursty traffic. The vendor device may smooth out the traffic sent to the other device and there is no control to send bursty traffic profiles between vendor devices. It is also not easy to validate encryption throughput for smaller frame sizes depending on device capability. Other validation points will be limited too and I will not list them one by one.

Validate VLAN in clear text and encrypted payload

In WAN networks and Carrier Ethernet networks, VLAN is used as part of the forwarding decision to multiplex multiple LAN segments over the same bridged network. To support this, MACsec requests support of VLAN in clear text before the MACsec header, in addition to VLAN in the encrypted payload. Hence the following testing should be done to validate VLAN tagged traffic.

With a third-party test tool, various VLAN tagging in clear, encrypted payload, or mixed can be easily controlled, which is not possible when testing back-to-back between vendors’ own devices with the same implementation. Without this testing, potential interoperability issues may arise in the field.

Validate implementation of various cipher suites

Validate implementation of confidentiality offset

In MPLS networks, the switch makes forwarding decisions based on MPLS labels in the packets. MACsec added a confidentiality offset function that defines the starting offset to encrypt and leaves a portion of the bytes after the MACsec header in clear text. This enables network devices to forward traffic without decrypting every packet. Hardware needs to properly encrypt and decrypt traffic with supported confidentiality offset.

Validate the impact to forwarding throughput, latency, and jitter

With MACsec enabled, every packet needs to pass the encryption engine before being forwarded to the next node in the path.

Validate forwarding throughput, latency, and jitter during re-key

When a packet number (PN) is exhausted, the PN will be wrapped back and a new key will be used. There is a short period that both the old key and new keys are valid to take care of transit frames and the delay of key rotation in hardware. This needs to be fully validated to ensure no loss during re-key and unexpected latency/jitter.

This test needs to be exercised with various traffic patterns, such as frame sizes, mixed traffic flow ratio, and bursty and constant traffic rate. This test is also heavily impacted by software and hardware integration, which I will discuss in the last blog of this series.

Mixed MACsec and non-MACsec traffic flows

A device port may handle both MACsec-encrypted traffic flows and non-MACsec traffic flows. The later will bypass the encryption engine. Managing queuing and buffering under mixed traffic flows from different paths needs to be validated.

Inclusion/exclusion of control-plane protocol messages in MACsec encryption

If a port is in secured mode, all frames that include control-plane protocol messages will be encrypted. However, many devices offer the capability to exclude certain protocol messages from encryption for various reasons. As control-plane messages are typically generated from a higher layer and are processed in CPU, sending these packets down to the same pipe for encryption or to bypass encryption needs to be validated along with data-plane traffic.

With a third-party tool that supports comprehensive control-plane protocols, such tests can be conducted with ease. Users have full control of what gets encrypted or not encrypted. This helps them not only validate various deployment scenarios in the real world but add additional confirmation on correct encryption/decryption with approved protocol interoperability with many vendors in the field.

Error handling of MACsec traffic flows

It is important to validate various error conditions. Here are a few examples:

This cannot be done with back-to-back vendor devices. A third-party test tool focused on testing by design gives way more nobs and dials for negative testing. It makes the negative scenario creation controllable, measurable, and repeatable. This helps in debugging and enhances productivity.

THE INDUSTRY'S FIRST MACSEC TEST SOLUTION FOR HIGH-SPEED ETHERNET

It is apparent that testing back-to-back between a vendor’s own devices will not cover all the validation points and will negatively impact the product quality. As a leader in the network test and measurement market, Keysight’s mission is to help our customers accelerate innovation to connect and secure the world. We offer a comprehensive MACsec test solution to help you overcome MACsec test challenges, stay competitive, and avoid major issues in the field. For more details about the Keysight solution, please review the MACsec Test Solution datasheet.

By no means is the above list exhaustive, but these are all important validation points when it comes to hardware validation. There are many more detailed functional and performance validation points, such as optional secure channel identifier (SCI) and short-length MACsec frames, to ensure full test coverage. In the next blog, I discuss MACsec control-plane validation with the MACsec key agreement (MKA) protocol.

limit
3