MAC Aggregation over Lossy Channels in DTLS 1.3

TL;DR

This work tackles the bandwidth overhead of MAC tags in secure DTLS 1.3 communications for bandwidth-constrained wireless IoT. It presents a DTLS 1.3 extension to negotiate and apply MAC aggregation, along with dynamic parameter updates and an optimistic data path, enabling progressive authentication. Through a real-world deployment on embedded hardware, the authors show up to $50\%$ goodput gains and up to $17\%$ energy savings, with adaptive schemes that maintain robustness in lossy channels. The study demonstrates the practical viability of MAC aggregation, highlighting significant potential for more efficient secure wireless communication in industrial and IoT environments.

Abstract

Aggregating Message Authentication Codes (MACs) promises to save valuable bandwidth in resource-constrained environments. The idea is simple: Instead of appending an authentication tag to each message in a communication stream, the integrity protection of multiple messages is aggregated into a single tag. Recent studies postulate, e.g., based on simulations, that these benefits also spread to wireless, and thus lossy, scenarios despite each lost packet typically resulting in the loss of integrity protection information for multiple messages. In this paper, we investigate these claims in a real deployment. Therefore, we first design a MAC aggregation extension for the Datagram Transport Layer Security (DTLS) 1.3 protocol. Afterward, we extensively evaluate the performance of MAC aggregation on a complete communication protocol stack on embedded hardware. We find that MAC aggregation can indeed increase goodput by up to 50% and save up to 17% of energy expenditure for the transmission of short messages, even in lossy channels.

Figures (11)

• Figure 1: During a DTLS 1.3 handshake, the client can append an extension to request MAC aggregation. The structure of this request is shown in Figure \ref{['fig:extension:request']} and contains a list of supported aggregation schemes and parameters for both communication directions. The response, depicted in Figure \ref{['fig:extension:response']}, selects the concrete schemes and parameters for the session. If no MAC aggregation is required, 0x00 is used, as in this response for server to client communication.
• Figure 2: The extension mechanism of DTLS 1.3 allows the seamless deployment of support for MAC aggregation alongside devices not supporting the extension.
• Figure 3: After agreeing on MAC aggregation, DTLS records carry the content type as the first field to make it easily recoverable during decryption. Consequently, MAC aggregation must be used in combination with a stream cipher, e.g., AES in counter mode, as the content type no longer acts as delimited between the payload and padding.
• Figure 4: We approximate the optimal aggregation parameters, i.e., those yielding the highest goodput, based on boundaries described by formulas of the form $y = a\cdot e^{\frac{b}{x}}+c$, where $x$ is the payload lengths, $y$ is the current PER, and $a$, $e$, $c$ as well as $b$ are parameters.
• Figure 5: As expected, the PER increase for longer payloads as the probability of uncorrectable bit flips increases.