{"id":"0158d076-13dc-4a86-8c31-ca72f9e03bb3","arxiv_id":"2608.02264","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"TurboRetry offloads QUIC Retry token generation/verification to DPU hardware, sustaining 3 Mpps handshake floods and achieving 10–20× higher throughput than host-side QUIC implementations.","lead":"This paper presents TurboRetry, a system that moves QUIC's Retry anti-flood mechanism onto a data processing unit (DPU), offloading stateless token work from the server CPU. On a BlueField-3 testbed it sustains 3 million attack packets/sec with no loss, a 10–20× improvement over host-only QUIC stacks.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"On-path adversary can replay a valid Retry token within the 1s window, bypassing the DPU's address validation and forcing host-side handshake processing; the paper's off-path threat model is load-bearing for the 'fully shields host CPUs' claim.","rationale":"The reader's weakest assumption—off-path adversary—is also the most load-bearing concern I can identify. The paper's security analysis explicitly restricts the adversary to off-path (Section 3.1), but the abstract and strongest claim state a general mitigation of large-scale handshake floods and 'fully shields host CPUs.' The token is a bearer credential with no one-time-use mechanism, so an on-path observer can replay it within the 1s window and force the host to perform the exact cryptographic work the system is designed to prevent. This is a scoping issue rather than an internal inconsistency: the paper is transparent about the assumption, but the central claim overstates the guarantee if on-path adversaries are considered. I considered other possible concerns—the DPA Bloom filter false-positive rate (4.25%), the lack of error bars, and the single-DPU evaluation—but these are secondary to the security-model dependency. The throughput and architecture contributions are well supported by the paper's testbed, the 15k-LOC prototype, and the reproducible artifact; the 10-20x performance claim is credible. The reader's CONDITIONAL verdict already accounts for this weakness, so no verdict change is needed. A targeted same-window replay experiment would settle whether the concern actually lands in practice.","tokens_in":30171,"tokens_out":16878,"duration_ms":166496,"concrete_test":"Instrument a network tap or port mirror between a legitimate client and the TurboRetry server. Capture the Retry packet token for one connection. Within the 1-second validity window, send from a separate host a spoofed Initial packet carrying that token, with the victim client's source IP/port and the observed ODCID, to the server. Record whether the Arm agent validates the token and forwards the Initial to the host, and whether the host then allocates connection state and initiates TLS handshake processing. Repeat at scale (e.g., 1M replayed tokens); if the host processes these replays, the on-path replay concern is confirmed and the 'fully shields host CPUs' claim must be restricted to off-path adversaries.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central security claim is that TurboRetry 'fully shields host CPUs from handshake-flood resource exhaustion' (Section 8.5). This depends on the Retry token acting as proof that the client received the Retry packet. The paper explicitly assumes an off-path adversary (Section 3.1), meaning the adversary cannot observe the victim's return traffic. However, the token is a bearer credential: it is bound only to source IP, source port, ODCID, and a 1-second timestamp. An adversary with any vantage point that can observe the Retry packet—e.g., a compromised network element, a malicious ISP, or an on-path observer—can extract the token and replay it within the 1s window using a spoofed copy of the client's source IP and port. The Arm agent will validate the token and forward the second Initial to the host; the host revalidates and then performs the expensive TLS handshake. The paper's replay protection (Section 7) only rejects outdated tokens, not same-window replay, and the universal token format has no single-use state or client-held nonce to distinguish a replayed token from a legitimate one. This does not invalidate the throughput measurements, but it means the headline mitigation claim is scoped to off-path adversaries, and that scoping is not reflected in the abstract or the strongest claim. If an on-path adversary is in scope, the defense's core resource-exhaustion guarantee fails at trivial cost.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents TurboRetry, a DPU-based system that offloads the QUIC Retry address-validation mechanism to the Arm processor and hardware AES-GCM accelerators of an NVIDIA BlueField-3 DPU. The design partitions Retry into stateless functions (token generation, integrity-tag computation, token verification) on the DPU and stateful connection management on the host, with a universal AES-GCM-protected token format that also supports NEW_TOKEN-based 0-RTT validation. An on-path DPA processor maintains a dual-table Bloom-filter cache of verified DCIDs so that post-handshake traffic bypasses the off-path Arm path. The host cooperator revalidates tokens and recovers connection identifiers from the token payload, preserving QUIC semantics. The evaluation reports that TurboRetry sustains a 3 Mpps handshake-flood attack rate without packet loss (4.2x, 10x, and 20x over TurboRetry-XDP, Quiche, and Aioquic), introduces sub-millisecond connection-setup latency overhead, keeps data-transfer overhead near 1%, shields host CPUs from flood traffic, and fails open when the DPU program terminates.","tokens_in":30507,"tokens_out":11756,"duration_ms":117246,"significance":"If the results hold, TurboRetry is a useful systems contribution: it demonstrates a practical split between stateless DPU-side Retry processing and host-side connection management, and it shows that a commercial DPU with hardware AES-GCM can absorb handshake floods far beyond host-side QUIC stacks. The evaluation is broad in coverage (saturation throughput, setup latency, data latency, host CPU load, fail-open) and the comparison with an XDP-based variant helps isolate the benefit of DPU acceleration. The artifact is promised publicly. The security argument is not circular: token forgery is reduced to AES-GCM CPA security, the Bloom-filter FPR is computed from stated parameters, and the performance gains are measured rather than fitted. The main caveat is that the headline 'fully shields host CPUs' claim is stated more broadly than the off-path adversary model in Section 3.1 actually supports, and the nonce-uniqueness argument in Section 7 is worded too strongly. These are fixable with careful scoping and analysis, and I do not regard them as invalidating the measured results.","major_comments":[{"comment":"The headline security claims—'fully shields host CPUs from handshake-flood resource exhaustion' (§8.5) and 'strong resilience against adaptive adversaries' (§1)—are not qualified by the threat model. Under the stated off-path adversary (§3.1) the scheme is sound, but the Retry token is a bearer credential bound only to source IP/port, ODCID, and a timestamp. An adversary with any on-path vantage point can observe the Retry packet and replay the token within the 1-second validity window using a spoofed copy of the client's address tuple; the Arm agent will validate it, forward the Initial to the host, and the host will perform expensive TLS processing. §7 rejects only outdated tokens and does not address same-window replay. The abstract, contributions, and security analysis should either state the off-path scope explicitly or the design must add a mechanism that distinguishes replayed tok","section":"§3.1, §7, §8.5"},{"comment":"The statement in §7 that the key–nonce derivation 'ensuring nonce uniqueness for each key' is not established as written. K_enc is derived only from K_psk and TID; if the same TID occurs under the same K_psk, the only additional entropy in the nonce is the 32-bit random R and the timestamp, which is not unique. A collision in TID and R within the same timestamp granularity would reuse a (key, nonce) pair. The 64-bit TID makes this event negligible, but the paper should say that the uniqueness argument relies on the randomness/uniqueness of TID, not on the timestamp, and should not claim unconditional nonce uniqueness. Please also clarify the relationship between the 96-bit nonce shown in the token header (Figure 8) and N_enc in Algorithm 1: if the same nonce is transmitted in the plaintext header, the security argument should treat it as public input to the AEAD, not as a secret.","section":"§5.1 Algorithm 1, §7"},{"comment":"The DPA Bloom filter has a designed false-positive rate of 4.25%. This is acceptable for the stated handshake-flood attack model, because Initial packets are handled by the Arm agent and are not admitted based on the Bloom-filter result. However, the paper also says the DPA 'drops invalid flows before they reach the host' and that TurboRetry 'fully shields host CPUs.' A mixed flood containing crafted 1-RTT packets with random DCIDs would pass roughly 4.25% of its packets through the DPA cache, and the host would then perform AEAD decryption failures on those packets. At 3 Mpps this would be ~127 kpps of traffic reaching the host, which is comparable to the saturation rates of the host baselines. The paper should either bound this effect in the security analysis or explicitly state that the CPU-shielding claim applies only to Initial-only handshake floods.","section":"§5.2, §7"}],"minor_comments":[{"comment":"The text states that each measurement was repeated 10 times, but no error bars, confidence intervals, or per-run values are shown. Since the headline 3 Mpps number and the CPU-load comparison are point estimates, please report variance (e.g., min–max, standard deviation) or explain why the variation is negligible.","section":"Figures 9, 10, 12"},{"comment":"Figure 2 reports Quiche with AES-GCM tokens sustaining 188 kpps in the Retry-related measurement, while Figure 9 shows Quiche at approximately 0.15 Mpps at 15 cores (150 kpps). These two numbers are hard to reconcile as-is. Please clarify the definitions (single-core vs multi-core, success-ratio threshold vs zero-loss saturation, and the role of the token format) so the reader can compare the two baselines.","section":"§2.2 vs Figure 9"},{"comment":"The baseline connection-setup latencies (31.77 ms for Aioquic and 22.96 ms for Quiche) are an order of magnitude above typical QUIC 1-RTT setup latencies. Please state explicitly whether the measurement includes the full HTTP/3 request/response exchange or only the QUIC/TLS handshake, and why this is the relevant baseline for the overhead comparison.","section":"Table 3"},{"comment":"The fail-open description says the host QUIC stack implements the same stateless Retry logic as the DPU path. Please clarify how the host obtains the master key K_psk and what happens to a partially populated DPA Bloom filter when the DPU program recovers. Stale Bloom-filter entries could forward previously validated DCIDs to the host after failover, and the recovery procedure is not described.","section":"§6, Fail-open"}],"recommendation":"major_revision","confidential_remarks":"The paper is likely publishable after revision. The main risk is the on-path replay issue: the authors overclaim 'fully shields host CPUs' without prominently qualifying the threat model. I do not think this warrants rejection because the off-path adversary is explicit in §3.1 and is standard for spoofed-address flood defense, but the abstract and contributions must be aligned with that scope. The nonce-uniqueness wording also needs correction. In addition, the inconsistency between the Figure 2 and Figure 9 Quiche baselines should be reconciled before the paper is accepted; it affects the reader's ability to interpret the magnitude of the reported speedup. The artifact availability and the broad evaluation are clear strengths."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"TurboRetry is a well-engineered systems paper: the split stateless/stateful offload of QUIC Retry to a BlueField-3 DPU, with a universal AES-GCM token and HKDF-derived per-token keys, is genuinely new relative to the IETF offload draft, and the 10-20x throughput gain over host stacks is measured rather than fitted. The evaluation is thorough—attack-rate saturation, connection and data latency, host CPU, fail-open—and the 15k-LOC prototype is public. The design choices are sensible: keeping stateful connection management on the host, using a Bloom filter on the DPA fast path, and supporting 0-RTT without shared key state.\n\nThe main soft spot is the threat model. Section 3.1 explicitly assumes an off-path adversary, and the replay protection (Section 7) only checks a 1-second expiry. An on-path observer can capture a valid Retry token and replay it within that window with a spoofed copy of the client's address; the DPU and host will validate it and the host will spend resources on the handshake. That means the \"fully shields host CPUs\" claim in Section 8.5 is only true against blind spoofing, not against on-path attackers. This is a limitation, not a fatal flaw—address validation is traditionally aimed at off-path spoofing—but the abstract and headline claim should be scoped accordingly. I'd also like to see error bars or distributions for the ten repetitions, and an independent implementation or at least a second DPU platform would strengthen the generality claims. The security analysis is otherwise sound: token forgery reduces to AES-GCM CPA, and the key/nonce derivation avoids the shared-state sync of the draft.\n\nBottom line: this is a genuine contribution to QUIC DDoS defense and DPU offload. It deserves a serious referee, and with a scoped threat model and a few presentation fixes it should be publishable. I'd cite it and would bring it to the reading group.","headline":"Solid DPU offload paper with a measured 10-20x gain; just make the off-path threat model explicit in the headline claims.","tokens_in":31059,"tokens_out":3075,"would_cite":true,"duration_ms":28495,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"TurboRetry claims a DPU-split QUIC Retry offload lets one server absorb 3 Mpps handshake floods with negligible latency and 10–20× the throughput of host-side stacks.","keywords":["QUIC","handshake flooding","denial-of-service","DPU offloading","Retry mechanism","AES-GCM","Bloom filter","HTTP/3"],"falsifier":"Run an attacker with a vantage point between a legitimate client and the server so it can capture a Retry packet; within one second, have it send a spoofed Initial carrying that token from a different source address. If the host proceeds into the handshake, the claimed replay resistance is broken. Separately, sweep attack rates above 3 Mpps to observe the promised throughput ceiling.","tokens_in":30018,"feed_emoji":"🛡️","tokens_out":6395,"duration_ms":53641,"temperature":0.7,"pith_summary":"TurboRetry is a defense for QUIC servers that moves the protocol's built-in anti-flood check—the Retry address validation—off the host CPU and onto a data processing unit (DPU), a network card with its own processor. The paper claims this split lets one server absorb handshake floods of 3 million packets per second without packet loss, 10–20× more than host-side QUIC implementations, while adding only about 0.2 ms to connection setup and cutting host CPU load by over 99 percent. The design keeps token generation and verification on the DPU's AES-GCM hardware accelerator, leaves connection management on the host, and coordinates the two through a single encrypted token so no per-connection key synchronization is needed. If the claimed performance holds, large handshake floods stop being a host-CPU exhaustion problem for DPU-equipped cloud servers, without breaking QUIC semantics or 0-RTT resumption.","feed_headline":"DPU offload stops QUIC handshake floods at 3 million packets/s","feed_subtitle":"Moves QUIC's Retry check to a network-card processor, cutting host CPU load by 99 percent and beating software by 10-20x.","key_machinery":"The load-bearing object is the universal AES-GCM-128 retry token: a plaintext header (issuer, purpose, token ID, 96-bit nonce) authenticated as associated data, plus an encrypted payload binding a timestamp, client IP/port, and original connection ID. Both host and DPU derive identical per-token encryption keys from one rotating pre-shared master key using HKDF, which is what makes split processing possible without cryptographic state synchronization. Around it, the DPA cache—a pair of aging Bloom filters keyed by QUIC connection IDs—authorizes the fast path so verified flows bypass the off-path Arm processor.","core_discovery":"The paper's central claim is that QUIC's Retry mechanism splits cleanly into stateless and stateful halves, and that the stateless half—token generation, integrity-tag computation, and token verification—can run entirely on a DPU's hardware-accelerated AES-GCM pipeline while the host keeps connection management. A universal token format, an AES-GCM-128 encrypted payload bound to a plaintext header, carries both retry state and 0-RTT resumption state; per-token keys are derived from a single rotating pre-shared master key via HKDF, so the host and DPU never synchronize keys or nonces. An on-path data-path accelerator then authorizes verified connections by matching connection IDs, letting dat","pith_inferences":["Editorial inference: the replay-resistance guarantee holds only against an off-path adversary. An on-path observer that captures a Retry token can replay it with a spoofed copy of the client's source address within the 1-second validity window, and nothing in TurboRetry distinguishes that from the legitimate client's second Initial.","Editorial inference: the 1 MB dual-table Bloom filter admits roughly 4.25 percent of unverified 1-RTT packets under the stated load, so the system trades a small, bounded leakage of unverified traffic to the host for fast-path forwarding; under real-address short-lived connection floods this leakage could grow within a rotation window.","Editorial inference: since the design only depends on an AES-GCM engine and on-path packet steering, the split should port to other DPU families, but the DPA/Bloom-filter fast-path cache is the component most tied to a particular NIC architecture.","Editorial inference: coupling this offload with a proof-of-work or cryptographic challenge would shift the cost asymmetry from simply relocating the defense to making each spoofed attempt genuinely expensive for the attacker."],"forward_implications":["A DPU-equipped server can sustain flood traffic at 3 Mpps with no packet loss, versus at least an order of magnitude lower for host-side QUIC stacks.","Host CPUs are almost fully shielded: CPU load stays at the level of benign background traffic even under a 3 Mpps attack, a reduction of over 99 percent.","Connection setup latency stays effectively flat under attack, adding only ~0.2 ms, where host stacks become unresponsive at 20–150 kpps depending on implementation.","The fail-open path preserves service on DPU crash: a transient ~30 ms latency spike and no dropped requests.","0-RTT resumption keeps working because the same token format handles NEW_TOKEN-based address validation."],"fun_headline_variants":["DPU offload cuts QUIC handshake flood CPU cost 10-20x","TurboRetry: DPU handles QUIC Retry to beat floods by 20x","Move QUIC Retry to DPU: 10-20x faster flood defense","QUIC handshake floods? TurboRetry offloads Retry to DPU","Offload QUIC Retry to DPU for 10-20x flood mitigation speed"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The design assumes the attacker cannot observe the server's Retry traffic; an on-path adversary who sees a token can replay it under a spoofed source address within the 1-second validity window and pass the DPU's address check.","fun_headline_variants_meta":{"raw":{"variants":["DPU offload cuts QUIC handshake flood CPU cost 10-20x","TurboRetry: DPU handles QUIC Retry to beat floods by 20x","Move QUIC Retry to DPU: 10-20x faster flood defense","QUIC handshake floods? TurboRetry offloads Retry to DPU","Offload QUIC Retry to DPU for 10-20x flood mitigation speed"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000523,"raw_usage":{"total_tokens":2382,"prompt_tokens":777,"completion_tokens":1605,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":521,"completion_tokens_details":{"reasoning_tokens":1505}},"tokens_in":521,"tokens_out":1605,"duration_ms":8888,"temperature":1.0,"reasoning_tokens":1505,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T10:20:05.829851+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run an attacker with a vantage point between a legitimate client and the server so it can capture a Retry packet; within one second, have it send a spoofed Initial carrying that token from a different source address. If the host proceeds into the handshake, the claimed replay resistance is broken. Separately, sweep attack rates above 3 Mpps to observe the promised throughput ceiling.","supporting_citations":[],"review_version":1}