arXiv:2608.02264v1 [cs.CR] 3 Aug 2026
TurboRetry: Mitigating Large-Scale QUIC Handshake Floods with Off-the-Shelf DPU Offloading Jiahao Wu
Heng Pan∗
Kai Lv
Institute of Computing Technology, Chinese Academy of Sciences Beijing, China University of Chinese Academy of Sciences Beijing, China [email protected]
Computer Network Information Center, Chinese Academy of Sciences Beijing, China [email protected]
Institute of Computing Technology, Chinese Academy of Sciences Beijing, China University of Chinese Academy of Sciences Beijing, China [email protected]
Zhenyu Li
Yanbiao Li
Gaogang Xie
Institute of Computing Technology, Chinese Academy of Sciences Beijing, China University of Chinese Academy of Sciences Beijing, China [email protected]
Computer Network Information Center, Chinese Academy of Sciences Beijing, China University of Chinese Academy of Sciences Beijing, China [email protected]
Computer Network Information Center, Chinese Academy of Sciences Beijing, China University of Chinese Academy of Sciences Beijing, China [email protected]
Abstract
Keywords
The modern transport protocol QUIC is designed to enhance network performance and security, but it remains vulnerable to handshake flooding attacks. Such attacks exhaust CPU resources by forcing the server to perform expensive cryptographic operations via a large number of handshaking requests. QUIC provides a builtin defense mechanism, the Retry mechanism, to mitigate these attacks. However, our experiments reveal that it can still become a performance bottleneck under large-scale QUIC handshake floods due to substantial computational overhead. In this paper, we design and implement TurboRetry, a split design, that offloads the Retry mechanism onto DPUs to efficiently mitigate QUIC handshake floods. TurboRetry partitions the tasks of the Retry into two categories, and then assigns them to the DPUs and the host, respectively. To preserve QUIC semantics and reduce the coordination overhead, TurboRetry designs an extended Retry token format and an efficient cooperation scheme. In addition, TurboRetry offloads the connection authorization task to the onpath DPA to further improve both performance and security. Our evaluation shows that TurboRetry outperforms the host-side implementation by a wide margin, improving throughput by 10–20×.
DDoS detection and mitigation, Data processing unit, QUIC
CCS Concepts • Security and privacy → Denial-of-service attacks. ∗ Corresponding author.
This work is licensed under a Creative Commons Attribution 4.0 International License. CCS ’26, The Hague, Netherlands © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2871-6/2026/11 https://doi.org/10.1145/3830454.3832585
ACM Reference Format: Jiahao Wu, Heng Pan, Kai Lv, Zhenyu Li, Yanbiao Li, and Gaogang Xie. 2026. TurboRetry: Mitigating Large-Scale QUIC Handshake Floods with Off-theShelf DPU Offloading. In Proceedings of the 2026 ACM SIGSAC Conference on Computer and Communications Security (CCS ’26), November 15–19, 2026, The Hague, Netherlands. ACM, New York, NY, USA, 17 pages. https://doi. org/10.1145/3830454.3832585
1
Introduction
QUIC (Quick UDP Internet Connections) is a modern transport protocol built on UDP that combines the features of HTTP/2 and TLS, serving as the foundation of HTTP/3 [5, 23, 26, 36]. Its widespread adoption has made it a target for Distributed Denial-of-Service (DDoS) attacks against HTTP/3 servers [46–48]. In particular, the connection establishment process has emerged as a critical attack surface, which is called QUIC handshake floods [7, 15, 25, 26, 40, 44, 59]. In such attacks, adversaries send massive volumes of initial handshake packets to overwhelm servers, causing CPU-intensive cryptographic operations during the TLS-based handshake to become a major performance bottleneck [61, 66]. QUIC introduces the Retry1 mechanism as a built-in defense against handshake floods [23]. Its core idea is to validate the source address of a client before performing the computationally expensive cryptographic handshake. Although the Retry mechanism indeed improves resilience against handshake floods [44], it can still become a bottleneck under large-scale QUIC handshake floods (see Section 2.2). This is because it requires several operations, including token generation, integrity tag computation, and token verification, which impose additional computational overhead that does not 1 To avoid confusion, we denote the retry mechanism as Retry and the corresponding
packet as the Retry packet.
CCS ’26, November 15–19, 2026, The Hague, Netherlands
scale well under heavy traffic. Consequently, offloading Retry to hardware emerges as a promising approach, with several drafts being proposed [12]. However, existing proposals either incur significant overhead due to encryption key synchronization or fail to satisfy required security guarantees. Recently, Data Processing Units (DPUs), such as BlueField-3 [51], provides a promising platform for offloading Retry. By extending network interface cards with integrated CPU cores and hardware look-aside accelerators [8, 38], DPUs offer high programmability, high-bandwidth interfaces and efficient processing of encrypted traffic (e.g., Pigasus [69]). Offloading defense mechanisms to DPUs enables the filtering of large volumes of attack traffic before it reaches the host, thereby effectively protecting critical services. Despite this potential, designing a practical offloading system to efficiently defend against QUIC handshake flood attacks is challenging, as a DPU-based Retry mechanism must carefully balance task allocation, maintain protocol correctness, and ensure high performance. First, careful task partitioning is required because some Retry operations are poorly suited for the DPU’s relatively weaker processors, while others can benefit from hardware lookaside accelerators. The partitioning must consider both security and performance constraints to maximize throughput. Second, the correctness and consistency of the protocol must be preserved, as the Retry mechanism is tightly coupled with the QUIC protocol stack, and all connection states must be synchronized between the DPU and the host stack to ensure correct connection establishment. Third, most DPU processors and hardware accelerators reside off the fast path, requiring packets to be forwarded from the on-path pipeline to off-path units, which introduces significant additional latency. Minimizing this latency while maintaining high throughput is therefore a challenge. To cope with these challenges, we propose a defense system TurboRetry that adopts a split design to offload the QUIC Retry mechanism onto DPUs, thereby achieving high-performance mitigation against QUIC handshake floods. To this end, we introduce a universal token format, secured with AES-GCM encryption, to enhance protection. We partition the Retry mechanism into two categories of tasks: (i) stateless tasks (i.e., token generation, integrity tag computation, and token verification), and (ii) stateful tasks (i.e., connection management). Stateless tasks are well-suited for acceleration by DPU hardware accelerators, whereas stateful tasks are processed by the more powerful host processors. To preserve protocol correctness, we design an efficient cooperation scheme between the host and DPUs, leveraging the universal token to synchronize connection states while maintaining compliance with QUIC semantics. We further offload the connection authorization task to the data path accelerator (DPA), an on-path component in DPUs, which directly forwards verified flows to the host with low transmission latency while proactively discarding unverified flows to enhance protection. We also support the 0-RTT feature of QUIC via the universal token design. Experimental results demonstrate that TurboRetry achieves strong resilience against adaptive adversaries, consistently maintaining reliable delivery of legitimate traffic under large-scale handshake flood attacks. Compared to a purely host-side implementation, TurboRetry delivers a 10∼20× throughput improvement while introducing only a negligible delay,
Wu et al.
and gracefully falls back to the host-based solution upon failures without disrupting service availability. In summary, our primary contributions are as follows: • We propose a defense system, TurboRetry, with a split design (Section 4) that offloads the QUIC Retry mechanism onto DPUs (Section 5.1) to efficiently mitigate large-scale QUIC handshake floods. • We devise an efficient cooperation scheme (Section 6) where DPUs and the host coordinate via encrypted tokens to synchronize connection states without violating QUIC semantics. In addition, we offload the connection authorization task to the DPA (Section 5.2), which directly forwards verified flows to the host while proactively discarding unverified flows, thereby improving both performance and security. • We implement the TurboRetry prototype on the BlueField 3 DPU and make it publicly available [3]. Experiments show that it is resilient against attack rates of 3 Mpps without any packet loss, gains 10-20× throughput improvement over software solutions, and only introduces minimal additional latency (Section 8). We begin by outlining the limitations of the existing Retry mechanism in Section 2, and then present the threat model, key challenges, and system architecture of TurboRetry in Section 3. A security analysis is provided in Section 7. We further discuss additional features and potential future directions in Section 9, present related work in Section 10, and conclude in Section 11.
2
Background and Motivation
In this section, we first recall the key features of QUIC, with a focus on its handshake and retry mechanisms. We then further analyze the limitations of existing retry mechanisms and discuss the new opportunities enabled by DPUs.
2.1
QUIC Handshake and Retry Mechanism
QUIC is designed to improve the performance and security of network transmission [26]. It merges TCP’s three-way handshake and TLS negotiation into a single handshake [23, 61], significantly reducing connection establishment latency. QUIC’s mandatory endto-end encryption hides protocol metadata from on-path devices, effectively mitigating the security risks associated with plaintext transmission in TCP [16]. QUIC packet formats. QUIC packets are carried inside UDP payloads and come in two forms: long-header and short-header packets. Long-header packets are used for connection establishment, involving Initial, Retry, Handshake, 0-RTT, and Version Negotiation packets. Short-header packets (i.e., 1-RTT packets) are used for normal data transmission. Note that the payloads of Initial, Handshake and 1-RTT packets are encrypted using Authenticated Encryption with Associated Data (AEAD) algorithms [42] (e.g., AES-GCM [58]). QUIC handshake mechanism. A typical QUIC handshake comprises three main steps (Figure 1a). ① The client sends an Initial packet containing a TLS ClientHello (CH) message encrypted in its payload. ② Upon receiving this packet, the server decrypts its payload and replies with an Initial packet containing a TLS ServerHello (SH) message. The server then sends a Handshake
TurboRetry : Mitigating Large-Scale QUIC Handshake Floods with Off-the-Shelf DPU Offloading Client
Server Initial [0]: CRYPTO[CH]
Initial [1]: CRYPTO[SH] Handshake [1]: CRYPTO[EE,CERT,CV,FIN] 1-RTT [1]: STREAM[“…”]
Initial [2]: ACK Handshake [2]: CRYPTO[FIN], ACK 1-RTT [2]: STREAM[“…”], ACK
DCID=S1 SCID=C1
DCID=C1 SCID=S2 DCID=C1
DCID=S2 SCID=C1 DCID=S2
(a) 1-RTT handshake.
CCS ’26, November 15–19, 2026, The Hague, Netherlands
Client
Server Initial [0]: CRYPTO[CH]
DCID=S1 SCID=C1
Retry [1]: Token
DCID=C1 SCID=S2
Initial [2]: Token, CRYPTO[CH]
DCID=S2 SCID=C1
Initial [3]: CRYPTO[SH] Handshake [3]: CRYPTO[EE,CERT,CV,FIN] 1-RTT [3]: STREAM[“…”] Initial [4]: Token, ACK Handshake [4]: CRYPTO[FIN], ACK 1-RTT [4]: STREAM[“…”], ACK
DCID=C1 SCID=S3
DCID=C1 DCID=S3 SCID=C1 DCID=S3
(b) 1-RTT handshake with Retry.
Attacker
QUIC Initia l QUIC Initia l QUIC Initia l
Retry n + Toke Retry ken o T y + n Retr o ke Server +T try Re No subsequent handshake packets
Stateless
Token Generation
Integrity Tag Computation Token Verification
Stateful Connection Management
(c) Main functions of Retry.
Figure 1: QUIC handshake and the Retry mechanism. The numbered labels indicate the order of packet-exchange rounds. packet with its TLS handshake messages—Encrypted Extensions (EE), Certificate (CERT), and Certificate Verify (CV)—followed by a 1-RTT packet containing application data. ③ The connection is established once the server receives a sequence of packets from the client, including an Initial packet with ACK, a Handshake packet with the client’s TLS information, and a 1-RTT packet. Retry mechanism. Retry [23] is a built-in defense designed to mitigate QUIC handshake floods and has been widely adopted by QUIC implementations listed by the QUIC Working Group [54]. As illustrated in Figure 1b, Retry introduces two additional steps prior to connection establishment: ① The server responds to the client’s first Initial packet with a Retry packet containing a stateless token (Token), without decrypting the payload; ② The client retransmits the Initial packet carrying the token (Token) in the header. The server proceeds with the handshake only after successfully verifying the token. By deferring decryption and other expensive cryptographic operations, Retry prevents CPU exhaustion caused by spoofed Initial packets. Note that clients are required to include the retry token 𝑇 in all the subsequent Initial packets to prove its authenticity. Although Retry introduces additional interaction delay, it provides strong protection against QUIC handshake floods [44]. We summarize the main operations involved in Retry into two groups: stateless and stateful functions (shown in Figure 1c). Stateless functions include token generation, Retry packet integrity tag computation, and token verification, which respectively generate tokens for client validation, protect Retry packets against tampering using AEAD algorithms (e.g., AES-GCM), and validate returned tokens without maintaining per-connection state. The stateful function primarily involves connection management, which requires maintaining server-side state across connections. Among these, only token-related functions (token generation and verification) vary significantly across different implementations, as retry tokens are self-produced and self-consumed by the same server and their formats are independently defined by each implementation [23]. Connection identifier negotiation. QUIC decouples a connection from the traditional five-tuple by using connection identifiers (CIDs). In a long-header packet, the destination CID (DCID) identifies the intended receiver and is used for routing, while the source CID (SCID) advertises the CID that the peer should use as the DCID in subsequent packets. Therefore, the DCID used by an endpoint is negotiated during the handshake. Once the negotiation completes, 1-RTT short-header packets only need to carry the peer-selected CID as the DCID for routing. To authenticate this negotiation, QUIC encodes the relevant DCID choices into the transport parameters
extension, which are exchanged and authenticated as part of the TLS handshake to prevent CID tampering or Retry forgery. In the 1-RTT handshake (Figure 1a), the client’s DCID switches from its initial random value S1 to the server-selected CID S2, which is advertised as the server’s SCID during the handshake. Accordingly, S1 and S2 are encoded in the server’s transport parameters. When Retry is used (Figure 1b), the DCID transition includes an additional Retry-issued CID. The client first uses S1, the original DCID (ODCID), then switches to the Retry SCID (RSCID) S2 when retransmitting the Initial packet with the retry token, and finally uses the server’s post-validation SCID S3 for subsequent packets. In this case, S1, S2, and S3 are encoded in the server’s transport parameters. Version negotiation and Zero Round-Trip Time (0-RTT) resumption. Version negotiation is triggered when a client proposes an unsupported QUIC version, causing the server to negotiate a mutually supported version before the standard 1-RTT handshake. 0-RTT resumption reduces connection setup latency by allowing a client to send encrypted application data in its first flight using cryptographic parameters from a prior connection. It is commonly combined with a server-issued NEW_TOKEN, which lets the client prove prior address validation and avoid being downgraded by an additional Retry exchange. However, because 0-RTT sends data before full authentication and key confirmation, it also expands the attack surface [55].
2.2
Limitations of the Existing Retry Mechanism
We next introduce the limitations of existing Retry mechanisms, including host-based Retry mechanisms and Retry offloading drafts. Host-based Retry solutions. Host-based Retry solutions refer to QUIC implementations built on the host UDP stack that support the Retry mechanism. As mentioned before, one of their major differences lies in the token format, which provides varying levels of security. More complex token formats incur higher computational overhead, resulting in reduced Retry throughput. We evaluate the maximum attack rate that the host-based Retry can withstand using different token formats selected from [54] (see Appendix Table 5). In our experiment, we use Quiche [10], a Rust-based QUIC implementation, as the test platform. Specifically, we customize Quiche to implement five distinct token formats: plaintext, HMAC, AES encryption, RSA encryption, and ECC encryption (Ed25519). The plaintext format directly embeds the source IP address, source
CCS ’26, November 15–19, 2026, The Hague, Netherlands
Wu et al.
Request success rate (%)
port, and source connection identifier into the token without cryptographic protection. The HMAC-based format computes the hash value of the plaintext content and appends the resulting hash to the end. The AES- and ECC-based formats encrypt this plaintext content using the AES-GCM/Ed25519 algorithm. The RSA-based format generates and maintains an RSA key pair to encrypt the same plaintext content. We adopt the experimental setup described in Section 8.1 and use the successful request ratio as the metric to characterize the server’s state under attack. 100 80 w/o Retry w/ Retry (Plaintext) w/ Retry (HMAC) w/ Retry (RSA) w/ Retry (AES-GCM) w/ Retry (Ed25519)
60 40 20 0 0
25
50
75
100
125
150
Attack rate (kpps)
175
200
Figure 2: Retry performance measurement. Note that the attack rate is measured in kilo packets per second (kpps). Limitations of host-based Retry. As depicted in Figure 2, the basic QUIC handshake without Retry can withstand attacks of up to 28 kpps. When Retry is enabled, plaintext tokens, HMAC-based tokens, AES-encrypted tokens, ECC-encrypted tokens, and RSAencrypted tokens can mitigate attack rates of up to 209 kpps, 207 kpps, 188 kpps, 38 kpps, and 32 kpps, respectively. These results demonstrate that enabling Retry improves DDoS resistance by 1.1–7.5×. However, the host-based Retry can still become a performance bottleneck under large-scale attacks (> 209 kpps), and increasing the complexity of token-encryption operations can significantly reduce Retry throughput (i.e., defense efficiency). Therefore, the community has turned to offloading Retry to hardware to balance token security and Retry performance. Table 1: Comparison between the Retry offloading draft and TurboRetry. Solution
Fail-open
Easy-to-deploy
0-RTT
No-shared-state [12] Shared-state [12] TurboRetry
✗ ✓ ✓
✓ ✗ ✓
✗ ✓ ✓
Overall, a practical Retry offloading solution should satisfy three key requirements: (1) it should operate in a fail-open manner to preserve service availability when the offloading device fails or becomes unavailable, (2) it should be easy-to-deploy without complex host–device coordination, and (3) it should support the prominent 0-RTT resumption feature, rather than forcing resumed connections to fall back to a full 1-RTT handshake. Table 1 summarizes two approaches proposed in the existing Retry offloading draft [12]: no-shared-state and shared-state offloading.
In no-shared-state offloading, the device independently generates and validates plaintext Retry tokens without sharing state with the host. This design keeps the data path simple and avoids host–device synchronization. However, since the device does not share the server’s token format or cryptographic state, it cannot recognize server-issued NEW_TOKENs. As a result, 0-RTT packets carrying such tokens are dropped at the offloading device, forcing QUIC’s low-latency 0-RTT resumption to degrade into a full 1-RTT handshake. The design also makes availability depend on the offloading device. When the device fails, the host cannot directly take over token validation, causing the system to fail closed. In shared-state offloading, the device and the host share the cryptographic state needed to generate and validate encrypted retry tokens. This enables both sides to validate each other’s tokens and allows the device to support 0-RTT resumption with NEW_TOKEN. However, this benefit comes at the cost of deployability. The system must synchronize keys, nonces, and rotation epochs between the host and the device. More importantly, to avoid security vulnerabilities caused by nonce reuse in AES-GCM, the system ought to adopt an aggressive key-rotation strategy, such as enforcing key rotation after every 223 packets. Such frequent multi-state management and synchronization introduce substantial operational overhead, creating significant engineering barriers to deployment and scaling in practical network environments. Thus, shared-state offloading turns Retry offloading into a distributed cryptographic state-management problem. In summary, existing designs expose a tradeoff: no-shared-state offloading is easy to deploy but fails closed and breaks 0-RTT, whereas shared-state offloading supports 0-RTT but requires complex and frequent key and nonce synchronization. TurboRetry bridges this gap by deriving per-connection keys and nonces from a single pre-shared master key using HKDF (see Algorithm 1), eliminating complex cryptographic state distribution between the host and the offloading device. It further introduces a universal retry token format (mentioned in Section 5.1) that supports both Retry validation and NEW_TOKEN-based 0-RTT resumption, preserving simple deployment without sacrificing QUIC’s low-latency resumption feature.
2.3
Opportunities of Data Processing Units
A Data Processing Unit (DPU), also known as a Smart Network Interface Card (SmartNIC), is a high-performance programmable system-on-chip (SoC) processor that integrates a multi-core CPU, network interfaces, and hardware accelerator engines. It can replace traditional NICs and offer performance improvements by offloading specific tasks (e.g., networking, storage, security, etc.) from host CPU cores to the DPU. Table 2 compares the cost and key capabilities of representative off-the-shelf DPUs, highlighting the trade-offs between device functionality and deployment cost. DPUs have emerged as a promising solution for data centers and cloud environments [29, 41, 57]. In this paper, we focus on the state-of-the-art (SOTA) DPU, NVIDIA BlueField-3 [51]. BlueField-3 architecture. Figure 3 shows the overall architecture of BlueField-3 (BF3) DPU. BF3 comprises two ConnectX-7 NICs, several SoC cores and domain-specific hardware accelerators, and off-chip DDR5 memory. Each NIC supports 200/400 Gbps Ethernet
TurboRetry : Mitigating Large-Scale QUIC Handshake Floods with Off-the-Shelf DPU Offloading
Table 2: Comparison of representative off-the-shelf DPUs. Device
Cost Power Data Plane AES-GCM ($) (W) Programmability Accelerator
Cap.
Nvidia BlueField-3 400Gbps 3,455 AMD Pensando DSC3 400Gbps Intel IPU 200Gbps 4,318 Marvell OCTEON 16 × 50Gbps -
✓ ✓ ✓ ✓
75 75 50
✓ ✓ ✓ ✓
* Entries marked with ’-’ indicate that the corresponding information is not publicly
available.
or InfiniBand. The SoC includes two types of processors: (i) an offpath general-purpose processor with 16 Arm Cortex-A78 cores, and (ii) a programmable on-path Data Path Accelerator (DPA). These two processors are connected via an embedded PCIe switch.
CCS ’26, November 15–19, 2026, The Hague, Netherlands
on BF3 offers promising opportunities to both relieve CPU burden and accelerate these operations. Therefore, we measure the throughput and latency when invoking the hardware accelerator on both the host CPU and the DPU’s Arm processor using the doca_bench tool. Figure 4a and Figure 4b show that, compared with the host, invoking the AES-GCM accelerator on the Arm processor achieves higher throughput (≈4 million operations per second for one core) and lower latency (< 2 µs). This demonstrates the potential for offloading AES-GCM operations to BF3. Limitations of BlueField-3. Although the Arm processor provides hardware-accelerated processing capabilities that outperform host CPUs for specific tasks, it introduce additional latency because traffic must traverse the PCIe switch to reach them. This poses challenges in achieving both low latency and high throughput when offloading network functions from host CPUs to the DPU.
Host
3
Erasure Coding Compress
PCIe Switch 16-core Arm Cache
DPA (RISC-V)
DDR5 DRAM
ConnectX NIC
IB/Ethernet Port
Figure 3: BlueField-3 DPU architecture.
TurboRetry Problem Setting
To mitigate QUIC handshake floods, we design TurboRetry, a DPUbased Retry offloading mechanism (see Figure 5). In TurboRetry, stateless functions are offloaded to the DPU to leverage hardware accelerators for potential performance improvement, while stateful functions remain on the host to ensure correct maintenance of connection state within the protocol stack. Within the split design, the DPU synchronizes the necessary connection state with the host QUIC stack via the PCIe bus to ensure that verified connections continue to operate correctly. Under this design, we next present the threat model and the key technical challenges of TurboRetry.
The DPA processor features a 16-core, 256-thread RISC-V architecture and resides on the network critical path, providing inline programmability for every incoming and outgoing packet. In addition to its own three-level cache backed by NIC private memory, the DPA can access the last-level cache (LLC) and memory of both the Arm processor and the host system via the PCIe bus using load/store instructions [52]. In contrast, the Arm processor serves as a co-processor to the host CPUs, offloading computationintensive tasks. It is connected to 32GB DDR5 memory and a suite of hardware accelerators (e.g., AES-GCM engines, erasure coding units, compression modules, etc.).
DPU
QUIC Initial QUIC Initial QUIC Initial
Attacker
Arm Processor
Host CPU
Server
AES-GCM
BlueField-3
Lookaside Accelerators
AES-GCM
PCIe Gen 5.0 × 16
PCIe Connection State Sync
Stateless
Stateful
Token Generation Token Verification
No subsequent handshake packets
Integrity Tag Computation
Connection Management