MACsec Hardware Testing—Why Back-to-Back Validation Falls Short
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.
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:
MACsec Frame Encoding
- MACsec Header – Security tag (SecTAG), 8 bytes or 16 bytes, positioned after Ethernet header:
- MACsec EtherType: 0x88e5
- TCI/AN: TAG Control Information (TCI)/Association Number.
- SL: Short length, length of the encrypted data
- PN: Packet number used for replay protection
- SCI: Secure channel identifier of a connectivity association (CA), concatenation of the MAC address and a 16-bit port ID
- Encrypted user data
- Integrity Check Value (ICV) – 16 bytes, generated by GCM-AES to ensure source node identity and integrity of the frame
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.
- VLAN in clear text before SecTAG
- Confidentiality offset
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.
- The device under test (DUT) encrypts the clear text frames and sends them to the receive side. The received frames are decrypted and ICV is validated. ICV validation typically indicates that packet content is not altered after encryption or on the wire. You can also inspect sample packets in a capture after decryption to verify the correct encryption.
- DUT receives encrypted frames and sends clear text frames after decryption to the receive side. In this case, you can enable additional data integrity validation to verify the correctness of decryption at the DUT. You can also inspect sample packets in a capture to verify the correct decryption.
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.
- Can the encryption engine keep up with line-rate traffic?
- Can the encryption engine encrypt and decrypt frames at high rates for various frame sizes, especially small frames such as 64 bytes?
- Can the encryption engine handle short-length payloads at line rate?
- Will the encryption engine perform as expected when receiving high-rate traffic with mixed frame sizes, such as IMIX?
- Will the encryption engine perform as expected when receiving bursty traffic?
- Will the switch queuing and buffer management for different priority traffic flows work as expected along with encryption/decryption?
- Will switch priority flow control works along with encryption/decryption?
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.
- One or multiple VLAN tags in clear text before MACsec header
- One or multiple VLAN tags in encrypted payload after MACsec header
- Mixed VLAN tagging in clear and encrypted payload
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.
- What will be the impact of this additional element in the forwarding path?
- Is the impact on latency and jitter in the allowed budget?
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:
- Out-of-window packet
- Malformed TCI flags
- Incorrect SAK
- Bad ICV
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 of the series, I will discuss MACsec control-plane validation with the MACsec key agreement (MKA) protocol.