Pith. sign in

REVIEW 4 major objections 6 minor 2 cited by

QFAM: Mitigating QUIC Handshake Flooding Attacks Through Crypto Challenges

T0 review · 4 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read By embedding a proof-of-work puzzle in QUIC's RETRY token, a server can push the CPU cost of a handshake flood onto the attacker and shrink the amplification factor.

desk verdict Plausible puzzle-in-Retry idea, but the evaluation skips the cheapest attack, leaving the central claim unproven. read the letter →

arxiv 2412.08936 v1 pith:SD6VF3WM submitted 2024-12-12 cs.CR

Abdollah Jabbari , Y A Joarder , Benjamin Teyssier , Carol Fung This is my paper · ORCID
classification cs.CR
keywords QUIChandshakefloodingproof-of-workRETRYtokenCPUamplificationDDoSmitigationcryptographicchallengeaddressvalidation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

QFAM proposes to modify the QUIC RETRY token so that, when the server suspects a handshake flooding attack, each client must solve a cryptographic puzzle before its connection request gets full server-side processing. The puzzle is a hash preimage search: the client must find a random value such that a hash output has a required number of leading zeros, with the difficulty set by the server. Because solving the puzzle costs the client exponential work while the server verifies in constant time, the CPU amplification that makes QUIC handshake floods dangerous is reduced. The paper argues this is a root-cause fix rather than a detection-and-filtering approach, and reports testbed experiments on an open-source QUIC implementation showing attacker CPU rises and the achievable attack rate falls as challenge difficulty increases. If correct, the scheme gives QUIC servers a tunable knob to rebalance resource consumption during floods without blocking traffic.

What carries the argument

The load-bearing object is the enhanced RETRY token, a drop-in modification of the RFC 9000 Retry token: its 96-bit Unique Token Number is split into a 64-bit Token Identifier Number, a 28-bit Matched Random Number, and a 4-bit Challenge Complexity Index. The client solves the challenge by finding a 28-bit value $R$ such that $Z = h(\mathrm{ICV} \| \mathrm{TIN} \| \mathrm{Port} \| \mathrm{CCI} \| R)$ has at least $\mathrm{CCI}$ leading zeros; the server checks the same hash in constant time. The token remains a valid QUIC address-validation token for clients that do not support the enhancement, so those requests can be deprioritized rather than dropped.

What would settle it

Run the paper's one-server, two-client testbed with an intentionally flawed detector, e.g., a fixed threshold that misses a slow ramp-up of handshake requests, and show that a moderate flood below the threshold still drives server CPU to saturation because no challenges are issued; or, on the calculation side, show that at maximum difficulty the expected client solve time is so low that a botnet with many cores can still sustain an attack rate that exhausts the server.

Watch

Extended reading notes

Core claim

The central claim is that the QUIC handshake's CPU amplification vulnerability can be neutralized at its source by folding a cryptographic challenge into the existing address-validation RETRY token. The server's enhanced token carries a 4-bit Challenge Complexity Index and a 64-bit token identifier; the client must append a 28-bit matched random number so that the hash of the token fields plus its answer has the specified number of leading zeros. The server's verification requires only one hash and token check, so the client's expected work grows as $O(2^n)$ while the server's stays $O(1)$. With a suitable difficulty level the attacker spends more CPU per accepted handshake than the server, eliminating the amplification factor rather than merely detecting the flood.

Load-bearing premise

The whole mitigation depends on the server correctly deciding when a flood is happening: the cryptographic challenges are only issued when the server's unspecified detector flips into mitigation mode, so a missed attack leaves the server as exposed as before and a false alarm makes every legitimate client pay puzzle cost for no benefit.

Editorial extensions

If this is right

  • When mitigation mode is on, an attacker that solves puzzles sees its achievable attack rate drop as difficulty rises, because each accepted request costs it real CPU.
  • An attacker that refuses to solve puzzles no longer triggers expensive server-side key shares, so the CPU amplification collapses.
  • Legitimate clients face a bounded delay from puzzle solving; at high attack rates this delay is smaller than the latency caused by the server being overloaded.
  • The server can tune difficulty dynamically through the 4-bit Challenge Complexity Index, trading attacker cost against legitimate-client overhead.
  • The approach is a proactive complement to existing reactive defenses and does not block clients that lack the enhanced token; unmodified clients can still connect at lower priority.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same challenge-in-token pattern could be applied to other stateless transport handshakes, such as TCP SYN cookies or DTLS, that suffer from CPU amplification, though each protocol's token format would need a similar extension.
  • The scheme effectively converts a network-layer flood into an economic problem: puzzle difficulty is a price on connection establishment, and if the server can estimate its own CPU cost per handshake it can set difficulty to make each forged request net-negative for the attacker.
  • A testable extension is to benchmark the scheme under distributed botnet attacks where parallel puzzle solvers can be aggregated, since the single-client LAN experiment may not capture whether a difficulty setting that balances CPU there still protects a server against many attackers solving puzzles in parallel.
  • The paper's claim that the approach does not suffer from false positives or false negatives is only exactly true if the attack detector is perfect; a more precise statement is that misdetection changes the cost allocation rather than causing outright blocking.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes QFAM, a defense against QUIC handshake flooding attacks based on cryptographic challenges embedded in the QUIC Retry token. When the server detects an attack, it sends an enhanced Retry packet whose token contains a 4-bit Challenge Complexity Index and a 64-bit Token Identifier Number; the client must find a 28-bit Matched Random Number such that a hash of the token fields has the required number of leading zeros. The server verifies the solution in O(1) and only then proceeds with the expensive TLS key exchange. The authors integrate this into aioquic and evaluate on a LAN with one server, one attacker, and one legitimate client, measuring CPU usage, attack rate, challenge solving time, and legitimate-client response time across difficulty levels and attack rates. The paper claims that this reduces the CPU amplification factor and naturalizes the DDoS vulnerability.

Significance. If the mechanism worked as claimed, QFAM would be a useful, protocol-compatible addition to QUIC defenses: it shifts a tunable amount of handshake CPU cost to clients during attacks and can complement detection-based systems. The complexity argument is straightforward (O(2^n) client work versus O(1) server verification), the token-format modifications are concrete, and the authors correctly note that the approach does not require per-flow classification. However, the evaluation is far too thin to establish the central claim: it contains no repeated trials, error bars, comparison defenses, or measurements of the unsolved-flood branch, and the activation condition (attack detection) is left unspecified. The residual per-CHLO Retry-generation work may be small, but it is not measured. The paper's potential impact is therefore moderate but currently not demonstrated.

major comments (4)
  1. [Section 5.2.3 and Eq. (1)] The paper states that if the attacker chooses not to solve the challenge, "the server would not dedicate resources to process its CHLOs." This is inaccurate: before challenge verification can occur, the server must generate an enhanced RETRY packet for every Initial/CHLO that lacks a valid solved token. That generation includes the AES-128-GCM encryption of the Token Body and the ICV computation over the associated data A in Eq. (1) (Section 4.1.3). This per-CHLO work is O(1), but O(1) is not zero, and an attacker can request it cheaply by flooding unsolved CHLOs and discarding the RETRY packets. Figure 10 only measures an attacker that attempts to solve the challenges, and Section 5.2.3's unsolved-flood branch is asserted without data. The central claim that CPU amplification is naturalized requires either a measurement of the server's residual per-unsolved-CHLO cost under a maximal unsolved flood, or a revised claim limited to attackers who solve challenges.
  2. [Section 4 and Section 4.6] The claim that "our approach does not suffer from the consequence of false positives or false negatives" (Section 4) is contradicted by the activation mechanism in Section 4.6: the cryptographic challenges "are only used when the server detects handshake flooding attacks." No detector is specified. A false negative leaves the server in normal mode and fully exposed to the CPU-amplification attack; a false positive forces all legitimate clients to solve puzzles during a non-attack. Since QFAM's protection is gated by this unspecified detector, the no-FP/FN statement overstates what is demonstrated. The paper should either specify a detection scheme with an error analysis or weaken the claim to say that QFAM does not itself classify individual flows.
  3. [Section 5.1 and Figures 7-12] The evaluation is a single LAN testbed with one server, one attacker, and one legitimate client. There are no repeated trials, error bars, confidence intervals, or statistical hypothesis tests, and no comparison against QUICShield, QUICwand, QUICPro, or a standard Retry-only baseline. The figures show plausible trends, but they cannot support quantitative statements such as "the CPU amplification factor ... reached over 6" or the response-time curves in Figure 12. At minimum, the paper should report variance and run the attack-rate and complexity sweeps multiple times.
  4. [Section 4.1.3 and Algorithm 1] The 4-bit CCI limits the challenge to at most 15 leading zeros, i.e., an expected 2^15 hash evaluations. This is a very modest proof-of-work on modern hardware; Section 5.2.3's Figure 9 shows that even with complexity 15, the single-core attacker can still sustain roughly 20 solved requests per second, and the paper provides no analysis of what happens with multi-core attackers or botnets. Because the claimed defense relies on properly choosing the difficulty level to balance CPU consumption, the manuscript needs to either justify that 2^15 is sufficient for the threat model or extend the CCI field.
minor comments (6)
  1. [Abstract] The abstract contains a grammatical error: "during of handshake flooding attacks."
  2. [Section 5.2.4] The text refers to a Challenge Complexity Index of "1100" and then explains it is decimal 12; write it as binary 1100 (12) to avoid confusion.
  3. [Section 5.2.6 and Figure 12] Figure 12 includes attack rates up to 120 Req/s, while Section 5.2.1 states that the server was fully saturated at 100 Req/s; clarify whether the curves in Figure 12 assume mitigation mode is active at all complexity levels.
  4. [Section 6] The discussion says clients that do not support mitigation can still connect by treating the enhanced Retry token as a standard token; the paper should explain how the server distinguishes a client that ignored the challenge from one that solved it, given that both return the same token fields.
  5. [Section 4.1 and Figure 3] Minor typographical issues include "a secrete" in Section 4.1, "regrading" and "bothe" in Figure 3, and "poses a cryptographic challenge" in Section 4.
  6. [Figure 1] The packet labels in Figure 1 use "Intial" instead of "Initial".

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the O(2^n) client cost follows directly from the leading-zero puzzle and the server's O(1) verification is arithmetic, so the central claim does not reduce to a fitted or self-cited input.

full rationale

QFAM's claimed derivation chain is not circular. The client-side complexity claim rests on Section 4.5: "Due to the nature of the challenge, the expected time to compute the result should increase exponentially with the difficulty level n. That means the computation complexity of Algorithm 1 is O(2^n) for the client to solve the challenge. On the other hand, the server uses constant time to generate the challenge and verify the answer... O(1)." This is a direct property of the brute-force leading-zero search in Algorithm 1, not an assumption equivalent to the target conclusion. The difficulty level is a tunable knob rather than a parameter fitted to the measured CPU amplification, so no fitted input is renamed as a prediction. The baseline amplification factor from Teyssier et al. [37] is a self-citation by overlapping authors, but it is not load-bearing: the paper independently measures a CPU amplification factor exceeding 6 in its own non-mitigation scenario (Figure 7), so the central mechanism is not justified only by the prior work. The paper's claim that its approach does not suffer from false positives or false negatives is a design-level statement about challenge-based mitigation, not a derived quantity that reduces to an input. The skeptical concern about the unsolved-challenge branch is real: Section 5.2.3 states that if the attacker does not solve challenges the server would not dedicate resources to process its CHLOs, while the server still performs Retry/token generation work before challenge verification, and Figure 10 does not measure that branch. However, this is an unmeasured behavioral assumption and a correctness/robustness gap, not a circular reduction. No equation is defined in terms of the claimed output, no fitted value is relabeled as a prediction, and no external uniqueness theorem or ansatz is imported via self-citation to force the result. Therefore the circularity score is 0.

Assumptions & free parameters 2 free parameters · 3 assumptions · 1 invented entities

The central mechanism depends on a few unverified assumptions: reliable attack detection to enter mitigation mode, a bound on the attacker's hashing advantage, and a random-oracle-like hash. The main tunable parameter is the 4-bit challenge difficulty, which the paper scans but never derives. The enhanced Retry token is the paper's contribution and is specified in enough detail to be re-implemented, which gives it independent evidence. No hidden fitted parameters were found.

free parameters (2)
  • Challenge Complexity Index (CCI) = 4-bit value 0-15, varied 1-15 in experiments
    The difficulty of the proof-of-work, set by the server. The paper does not derive an optimal value; effectiveness is demonstrated by scanning a small range. This is a protocol knob, not a hidden fit, but the central balance claim depends on choosing it appropriately.
  • Hash function h = unspecified (likely SHA-256 in implementation)
    The proof-of-work hash is not specified in the paper; the security and timing depend on its choice. Not fitted, but an unstated implementation parameter.
assumptions (3)
  • domain assumption The server can reliably detect a handshake flooding attack and decide when to activate mitigation mode.
    Challenges are only sent in mitigation mode (Section 4.6). No detector is proposed, so false positives and negatives can undermine the defense; this contradicts the paper's claim of being free of them.
  • domain assumption The attacker has roughly the same computational cost per hash as a legitimate client and no large hardware advantage.
    The maximum difficulty (15 leading zero bits, about 2^15 hashes) is low; a determined attacker with optimized code or GPUs may trivially maintain high request rates, which is not accounted for in the evaluation.
  • standard math The hash function h used in the challenge behaves as a random oracle with uniform output.
    The challenge's expected work is O(2^n) only if the hash output is uniformly random. The paper does not specify h or invoke the random oracle model, so this is a background cryptographic assumption.
invented entities (1)
  • Enhanced Retry Token fields (TIN, MRN, CCI) independent evidence
    purpose: Carries the server-issued challenge and the client's proof-of-work solution through the QUIC handshake without changing the overall packet format.
    This is a protocol data structure, not a physical entity. It is fully specified and implemented in the paper's aioquic testbed, and can be independently implemented and tested; however, it is not validated against a real deployment.

how reviews work

0 comments
Cite this review

Pith. "Pith review of QFAM: Mitigating QUIC Handshake Flooding Attacks Through Crypto Challenges." pith.science (2026). https://pith.science/paper/SD6VF3WM

@misc{pith2026241208936,
  author       = {Pith},
  title        = {Pith review of: QFAM: Mitigating QUIC Handshake Flooding Attacks Through Crypto Challenges},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SD6VF3WM}},
  note         = {Machine review of arXiv:2412.08936}
}
read the original abstract

QUIC protocol is primarily designed to optimize web performance and security. However, previous research has pointed out that it is vulnerable to handshake flooding attacks. Attackers can send excessive volume of handshaking requests to exhaust the CPU resource of the server, through utilizing the large CPU amplification factor occurred during the handshake process under attack. In this paper, we introduce a novel defense mechanism by introducing the concept of crypto challenges into the handshake protocol. This enhancement involves a proposal of modifying the RETRY token to integrate a cryptographic challenge into it. The client must solve crypto challenges during the handshake process in order to receive a high priority on the server side. By properly choosing the difficulty level of the challenges, the CPU amplification can be reduced, thus the DDoS vulnerability is naturalized. We evaluated the effectiveness of our proposed solution by integrating the crypto challenges into the clients and server of \textit{aioquic}. Our experimental results demonstrate that our solution can effectively balance the resource usage between the attacker and the server during of handshake flooding attacks while maintaining a low overhead for legitimate clients.

Figures

Figures reproduced from arXiv: 2412.08936 by the authors.

Figure 1
Figure 1. 1-RTT and 0-RTT Handshake Mechanisms in details; (a) 1-RTT handshake without address validation mechanism; (b) [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Handshake flooding attack without QUIC Address [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. Illustration of QFAM 4 Proposed Mitigation Scheme In this section, we present QFAM, our proposed mitigation ap￾proach against QUIC handshake flooding attacks. Different from the conventional reactive approach to detect and block attack traf￾fic [24, 30, 38], this approach mitigates attacks by increasing the cost of attackers. Therefore, our approach does not suffer from the consequence of false positives or false ne… view at source ↗
Figures from the paper (6 more)
Figure 5
Figure 5. Figure 5: Structure of the QUIC RETRY Packet Token Sequence (TS) (7 bits) Unique Token Number (UTN) (96 bits) Protected Encrypted Opaque Data (OD) Timestamp (64 bits) Original Destination Connection ID Length (ODCIDL) (8 bits) Original Destination Connection ID (ODCID) (64 to 16…
Figure 6
Figure 6. Figure 6: Enhanced structure of the RETRY packet and its corresponding Retry Token in QFAM [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 8
Figure 8. Figure 8: Impact of Challenge Complexity on CPU Usage for [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: Impact of Increasing Challenge Complexity on At [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]
Figure 11
Figure 11. Figure 11: Impact of Challenge Complexity on Solving Time [PITH_FULL_IMAGE:figures/full_fig_p010_11.png]
Figure 12
Figure 12. Figure 12: Effect of Varying Attack Rates on Response Time [PITH_FULL_IMAGE:figures/full_fig_p010_12.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. TurboRetry: Mitigating Large-Scale QUIC Handshake Floods with Off-the-Shelf DPU Offloading

    cs.CR 2026-08 conditional novelty 6.0 of 10

    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.

  2. CDN Tsunami: Exploiting HTTP/3-HTTP/1.1 Conversion for DoS Attacks

    cs.CR 2026-07 conditional novelty 4.0 of 10

    New HBA and HCA attacks exploit HTTP/3-to-HTTP/1.1 conversion at CDNs, with up to 350x bandwidth amplification and 42,330 potentially vulnerable subdomains.

Reference graph

Works this paper leans on

44 extracted references · 37 canonical work pages · cited by 2 Pith papers

  1. [1]

    aioquic contributors. 2024. aioquic: A Python library for the QUIC network protocol. https://github.com/aiortc/aioquic

    work page 2024

  2. [2]

    Alcardo Alex Barakabitze, Nabajeet Barman, Arslan Ahmad, Saman Zadtootaghaj, Lingfen Sun, Maria G Martini, and Luigi Atzori. 2019. QoE management of multimedia streaming services in future networks: A tutorial and survey. IEEE Communications Surveys & Tutorials 22, 1 (2019), 526–565

    work page 2019

  3. [3]

    Efstratios Chatzoglou, Vasileios Kouliaridis, Georgios Karopoulos, and Georgios Kambourakis. 2023. Revisiting QUIC attacks: A comprehensive review on QUIC security and a hands-on study. International Journal of Information Security 22, 2 (2023), 347–365

    work page 2023

  4. [4]

    Quentin De Coninck and Olivier Bonaventure. 2017. Multipath quic: Design and evaluation. In Proceedings of the 13th International Conference on Emerging Networking Experiments and Technologies, 160–166

    work page 2017

  5. [5]

    Nimisha Dey, N Neha, Malavika Hariprasad, S Sandhya, Minal Moharir, Muteeb Akram, et al. 2022. A detail survey on QUIC and its impact on network data transmission. In 2022 6th International Conference on Trends in Electronics and Informatics (ICOEI). IEEE, 378–385

    work page 2022

  6. [6]

    Zhengjie Du, Yuekang Li, Yaowen Zheng, Xiaohan Zhang, Cen Zhang, Yi Liu, Sheikh Mahbub Habib, Xinghua Li, Linzhang Wang, Yang Liu, et al. 2024. Medusa: Abdollah Jabbari, Y A Joarder, Benjamin Teyssier, and Carol Fung Unveil Memory Exhaustion DoS Vulnerabilities in Protocol Implementations. In Proceedings of the ACM on Web Conference 2024 , 1668–1679

    work page 2024

  7. [7]

    Martin Duke. 2023. QUIC Version 2. Request for Comments RFC 9369. Internet Engineering Task Force. https://datatracker.ietf.org/doc/rfc9369/

    work page 2023

  8. [8]

    Fátima Fernández, Fátima Khan, Mihail Zverev, Luis Diez, José R Juárez, Anna Brunstrom, and Ramón Agüero. 2024. Exploiting stream scheduling in QUIC: Performance assessment over wireless connectivity scenarios. Ad Hoc Networks 164 (2024), 103599

    work page 2024

Show all 44 references
  1. [9]

    Yaodong Huang, Changkang Mo, Tianhang Liu, Biying Kong, Lei Zhang, Yukun Yuan, and Laizhong Cui. 2024. Quic meets icn: A versatile wireless transport strategy in multi-access edge environments. In2024 IEEE/ACM 32nd International Symposium on Quality of Service (IWQoS) . IEEE, 1–6

    2024

  2. [10]

    Jana Iyengar and Ian Swett. 2021. QUIC Loss Detection and Congestion Control. RFC 9002. https://doi.org/10.17487/RFC9002

    2021 doi

  3. [11]

    Jana Iyengar and Martin Thomson. 2021. QUIC: A UDP-Based Multiplexed and Secure Transport. RFC 9000. https://doi.org/10.17487/RFC9000

    2021 doi

  4. [12]

    YA Joarder and Carol Fung. 2022. A Survey on the Security Issues of QUIC. In 2022 6th Cyber Security in Networking Conference (CSNet) . IEEE, 1–8

    2022

  5. [13]

    YA Joarder and Carol Fung. 2024. QUICPro: Integrating Deep Reinforcement Learning to Defend against QUIC Handshake Flooding Attacks. In Proceedings of the 2024 Applied Networking Research Workshop , 94–96

    2024

  6. [14]

    YA Joarder and Carol Fung. 2024. QUICwand: A Machine Learning Optimization- Based Hybrid Defense Approach Against QUIC Flooding Attacks. In2024 20th In- ternational Conference on the Design of Reliable Communication Networks (DRCN) . IEEE, 92–99

    2024

  7. [15]

    Y A Joarder and Carol Fung. 2024. Exploring QUIC Security and Privacy: A Comprehensive Survey on QUIC Security and Privacy Vulnerabilities, Threats, Attacks and Future Research Directions.IEEE Transactions on Network and Service Management N/A, N/A (2024), 1–1. https://doi.org...

    2024

  8. [16]

    Matt Joras and Yang Chi. 2020. How Facebook is bringing QUIC to bil- lions. https://engineering.fb.com/2020/10/21/networking-traffic/how-facebook- is-bringing-quic-to-billions/

    2020

  9. [17]

    Arash Molavi Kakhki, Samuel Jero, David Choffnes, Cristina Nita-Rotaru, and Alan Mislove. 2019. Taking a long look at QUIC: an approach for rigorous evalu- ation of rapidly evolving transport protocols. Communications of the ACM 62, 7 (2019), 86–94

    2019

  10. [18]

    Reza Kalan and Ismail Dulger. 2024. A Survey on QoE Management Schemes for HTTP Adaptive Video Streaming: Challenges, Solutions, and Opportunities. IEEE Access N/A, N/A (2024)

    2024

  11. [19]

    Mirja Kühlewind, Matias Carlander-Reuterfelt, Marcus Ihlar, and Magnus West- erlund. 2021. Evaluation of QUIC-based MASQUE proxying. In Proceedings of the 2021 Workshop on Evolution, Performance and Interoperability of QUIC , 29–34

    2021

  12. [20]

    Sanjeev Kumar. 2007. Smurf-based distributed denial of service (ddos) attack amplification in internet. InSecond International Conference on Internet Monitoring and Protection (ICIMP 2007) . IEEE, 25–25

    2007

  13. [21]

    Anna Harbluk Lorimer, Nick Feamster, and Prateek Mittal. 2022. Poster: Investi- gating QUIC’s Potential Impact on Censorship Circumvention. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security , 3403–3405

    2022

  14. [22]

    Duke Martin and Banks Nick. 2022. QUIC Retry Offload. Request for Comments. Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/draft-ietf- quic-retry-offload-00

    2022

  15. [23]

    Wei Meng, Chenxiong Qian, Shuang Hao, Kevin Borgolte, Giovanni Vigna, Christopher Kruegel, and Wenke Lee. 2018. Rampart: Protecting Web Appli- cations from CPU-ExhaustionDenial-of-Service Attacks. In 27th USENIX Security Symposium (USENIX Security 18) , 393–410

    2018

  16. [24]

    Ayush Mishra and Ben Leong. 2023. Containing the Cambrian Explosion in QUIC Congestion Control. In Proceedings of the 2023 ACM on Internet Measurement Conference, 526–539

    2023

  17. [25]

    Jonas Mücke, Marcin Nawrocki, Raphael Hiesgen, Thomas C Schmidt, and Matthias Wählisch. 2024. ReACKed QUICer: Measuring the Performance of Instant Acknowledgments in QUIC Handshakes. In Proceedings of the 2024 ACM on Internet Measurement Conference , 389–400

    2024

  18. [26]

    Schmidt, and Matthias Wählisch

    Marcin Nawrocki, Raphael Hiesgen, Thomas C. Schmidt, and Matthias Wählisch

  19. [27]

    Schmidt, and Matthias Wählisch

    Marcin Nawrocki, Pouyan Fotouhi Tehrani, Raphael Hiesgen, Jonas Mücke, Thomas C. Schmidt, and Matthias Wählisch. 2022. On the interplay between TLS certificates and QUIC performance. In Proceedings of the 18th International Conference on Emerging Networking Experiments and Tec...

    2022

  20. [28]

    Mirko Palmer, Thorben Krüger, Balakrishnan Chandrasekaran, and Anja Feld- mann. 2018. The quic fix for optimal video streaming. In Proceedings of the Workshop on the Evolution, Performance, and Interoperability of QUIC , 43–49

    2018

  21. [29]

    picoquic contributors. 2018. picoquic: A C library for the QUIC network protocol. https://github.com/private-octopus/picoquic

    2018

  22. [30]

    Roberto Pietrantuono, Massimo Ficco, and Francesco Palmieri. 2023. Survivability analysis of IoT systems under resource exhausting attacks. IEEE Transactions on Information Forensics and Security 18 (2023), 3277–3288

    2023

  23. [31]

    G. J. Pottie and W. J. Kaiser. 2000. Wireless integrated network sensors.Commun. ACM 43, 5 (May 2000), 51–58. https://doi.org/10.1145/332833.332838

    2000

  24. [32]

    quic-go contributors. 2022. quic-go: A GO language library for the QUIC network protocol. https://github.com/quic-go/quic-go

    2022

  25. [33]

    Jim Roskind. 2015. QUIC: design document and specification rational. Tech. Rep. N/A (2015), N/A

    2015

  26. [34]

    Christian Rossow. 2014. Amplification Hell: Revisiting Network Protocols for DDoS Abuse. In NDSS, 1–15

    2014

  27. [35]

    Jan Rüth, Konrad Wolsing, Klaus Wehrle, and Oliver Hohlfeld. 2019. Perceiving QUIC: Do users notice or even care?. In Proceedings of the 15th International Conference on Emerging Networking Experiments And Technologies , 144–150

    2019

  28. [36]

    Jayasree Sengupta, Debasmita Dey, Simone Ferlin, Nirnay Ghosh, and Vaibhav Bajpai. 2024. Accelerating Tactile Internet with QUIC: A Security and Privacy Perspective. https://doi.org/10.48550/arXiv.2401.06657

    2024 doi arXiv

  29. [37]

    Benjamin Teyssier, YA Joarder, and Carol Fung. 2023. An empirical approach to evaluate the resilience of quic protocol against handshake flood attacks. In 2023 19th International Conference on Network and Service Management (CNSM) . IEEE, 1–9

    2023

  30. [38]

    Benjamin Teyssier, YA Joarder, and Carol Fung. 2023. QUICShield: A Rapid Detection Mechanism Against QUIC-Flooding Attacks. In 2023 IEEE Virtual Conference on Communications (VCC), 43–48

    2023

  31. [39]

    Martin Thomson. 2021. Version-Independent Properties of QUIC. Request for Comments RFC 8999. Internet Engineering Task Force. https://datatracker.ietf. org/doc/rfc8999/

    2021

  32. [40]

    Martin Thomson and Sean Turner. 2021. Using TLS to Secure QUIC. RFC 9001. https://doi.org/10.17487/RFC9001

    2021 doi

  33. [41]

    W3Techs. N/A. Usage Statistics of QUIC for Websites. https://w3techs.com/ technologies/details/ce-quic

  34. [42]

    Wikipedia. 2024. QUIC. https://en.wikipedia.org/w/index.php?title=QUIC& oldid=1253985773

    2024

  35. [43]

    Johannes Zirngibl, Florian Gebauer, Patrick Sattler, Markus Sosnowski, and Georg Carle. 2024. QUIC Hunter: Finding QUIC Deployments and Identifying Server Libraries Across the Internet. In International Conference on Passive and Active Network Measurement, 273–290

    2024

  36. [2021]

    In Proceedings of the 21st ACM Internet Measurement Conference , 283–291

    QUICsand: Quantifying QUIC Reconnaissance Scans and DoS Flooding Events. In Proceedings of the 21st ACM Internet Measurement Conference , 283–291. https://doi.org/10.1145/3487552.3487840

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.