What is QUIC Flood? DDoS Attacks Against HTTP/3 and How to Mitigate Them

QUIC Flood is a family of DDoS attacks that exploits the QUIC protocol — the foundation of HTTP/3 — to pressure CPU, memory, connections, and applications. Unlike classic attacks such as SYN Flood over TCP, QUIC floods operate over UDP with encryption integrated into user-space, which changes how security devices observe and control traffic.

QUIC, TLS 1.3, and HTTP/3: architecture and security visibility

QUIC was standardized by the IETF in RFC 9000, published in 2021. RFC 9001 defines the integration of TLS 1.3 with QUIC, and RFC 9114, published in 2022, defines HTTP/3 over QUIC. QUIC was initially developed by Google, but the IETF version is its own standardization with a distinct specification.

The integration of transport and encryption in QUIC has direct security implications. In the TCP/TLS stack, the TCP handshake occurs before TLS — allowing stateful devices to observe connection establishment at the transport level before any encrypted data flows. In QUIC, the transport handshake and cryptographic handshake occur in an integrated manner. The QUIC stack — including TLS — typically runs in user-space; the kernel provides the UDP socket but has no visibility into the internal structures of the QUIC protocol.

This does not make QUIC traffic completely opaque for all control purposes. Network devices and firewalls can observe and control attributes such as IP addresses, ports, datagram size, PPS, duration, and flow patterns. QUIC Initial packets have identifiable fields and can be partially processed by specialized tools. What requires QUIC and TLS termination is full inspection of HTTP/3 — requests, headers, body, and application logic — and content-based policies.

The following table summarizes security-relevant properties across the three stacks:

Without QUIC and TLS termination, security devices cannot fully inspect HTTP/3 content. They can still apply L3/L4 controls, flow analysis, rate limiting, malformed packet filtering, and policies by address, prefix, ASN, port, or behavior.

How does a QUIC Flood work?

QUIC Flood exploits protocol characteristics to pressure server resources in ways that tools designed exclusively for TCP may not detect or control. Vectors vary in mechanism, target resource, and mitigation difficulty — and are frequently combined in sophisticated campaigns.

The pressured resource depends on the vector: a UDP/443 flood pressures bandwidth and PPS; an Initial packet flood can pressure parsing CPU and key derivation; HTTP/3 stream abuse pressures application logic. The actual effect depends on the server’s QUIC implementation, defense configuration, infrastructure capacity, and the specific attack profile.

Main attack vectors against QUIC and HTTP/3

UDP/443 flood

The most direct vector: flooding the server with UDP datagrams on port 443. When UDP/443 traffic reaches the QUIC stack or implementation, the destination may need to classify and process some datagrams to identify valid packets or apply discard rules. Network controls, firewall, load balancer, upstream mitigation, XDP/eBPF, or edge filters may filter some of that traffic before it reaches the application server. At high PPS volumes, this processing can pressure CPU even when part of the traffic is discarded before reaching the QUIC implementation.

Fully blocking UDP 443 as an immediate response resolves the flood but eliminates HTTP/3 for all legitimate users — a trade-off most operators cannot accept throughout an incident. More granular controls, such as rate limiting by prefix, malformed packet filtering, and version validation, allow reducing the impact without eliminating the service.

QUIC Initial flood

The attacker sends large volumes of QUIC Initial packets. A QUIC Initial flood can pressure CPU, parsing, token validation, buffers, and handshake resources. The impact depends on how much work the implementation performs before validating the client’s address and applying rate limits.

Robust implementations can apply address validation and limit resources before maintaining full state. Even so, floods of valid Initials can generate cost in parsing, initial key derivation, Retry generation, timers, or buffers — especially when originating from botnets with real IPs that complete validation.

Spoofed IP attacks and real-IP botnet attacks have different characteristics: in the first case, the Retry mechanism may reduce work before validation; in the second, validation is completed and the cost falls on the subsequent handshake stages.

Malformed or invalid-version packets

Sending QUIC packets with malformed content, invalid fields, or unsupported versions forces the server to attempt to parse and classify each packet before discarding it. At high volumes, this can pressure parsing CPU. Devices that can identify and filter these packets before deeper processing reduce that cost.

HTTP Flood over HTTP/3

An HTTP Flood transported via HTTP/3 follows the same logic as any application-layer attack: syntactically valid requests that exhaust CPU, database, third-party calls, or business logic. This vector requires QUIC/TLS termination for effective inspection and control.

The difference from HTTP Flood over TCP is that without QUIC termination, intermediate devices cannot inspect request content and apply WAF policies, per-route rate limiting, or API protection.

HTTP/3 stream abuse

QUIC allows multiplexing multiple streams over a single connection. A client can open a large number of simultaneous streams, each generating processing cost. The protocol defines stream limits via MAX_STREAMS frames, but the cost of managing limits and processing streams up to that limit can still be relevant under attack.

Stream limits per connection must be configured with attention to the legitimate usage profile — overly restrictive values can impact applications that depend on high stream concurrency.

0-RTT replay

0-RTT allows a client to reuse information from a previous TLS session — normally through PSK (Pre-Shared Key) or session tickets — to send data before full handshake completion. Address validation tokens and tickets/PSK for session resumption are distinct mechanisms.

0-RTT data may be subject to replay under specific conditions. Applications should accept it only for idempotent operations or implement their own anti-replay measures. It is not correct to treat 0-RTT replay as trivial traffic forgery by a third party without keys — an adversary without access to session keys cannot forge valid 0-RTT packets.

From an attack perspective, 0-RTT can be used by clients with valid tickets to send costly requests before full handshake validation, potentially amplifying the per-connection cost for non-idempotent operations.

Connection ID and migration

The Connection ID (CID) identifies a QUIC connection and allows it to persist through IP address changes. CIDs can be rotated or issued according to endpoint policies; during the initial handshake, CID values may be controlled by the client.

CID is not a reliable user identity and must not be the sole signal for security policies. It should be used as a complementary signal alongside IP, prefix, ASN, reputation, identity, session, credential, token, endpoint, and behavior.

QUIC migrations typically require path validation via PATH_CHALLENGE and PATH_RESPONSE before sending significant data on the new path. Excessive or anomalous-pattern migrations may signal attempted evasion of IP-based controls and should be monitored.

Address validation, Retry, and anti-amplification limits

Address validation and Retry

Address validation, defined in RFC 9000 Section 8, is the mechanism by which a server confirms that a client’s source address is reachable before investing significant resources in the handshake.

Retry is an optional address validation mechanism. The server may respond to an Initial packet with a Retry packet containing a token. The client must include that token in a new Initial packet to prove reachability. A client with a spoofed IP never receives the Retry and cannot complete the cycle.

Retry is optional: it is not automatically issued for every Initial. It may be used to require proof of reachability before investing more resources, but its use must balance protection, operational cost, and latency impact on connection establishment. Retry tokenization and validation have a cost; under an intense Initial flood, the processing of Retry itself may be relevant.

Other mechanisms may also contribute to address validation, such as tokens issued in previous connections.

When Retry and tokens are enabled, monitor their issuance, acceptance, rejection, and expiration as additional health and handshake-pressure indicators.

Anti-amplification limit

Before validating the client’s address, QUIC limits the amount of data a server can send in response to received traffic. As a general rule, before validation the endpoint must not send more than three times the bytes received on that path. This limit reduces the exploitable asymmetry in reflection attacks against QUIC.

Additionally, datagrams carrying a QUIC Initial must be at least 1,200 bytes, per RFC 9000. A datagrams carrying a QUIC Initial below 1,200 bytes must be discarded by the server per RFC 9000 rules. This requirement reduces the available amplification factor: the attacker must send at least 1,200 bytes for the server to process an Initial, which limits asymmetry compared to protocols without a minimum size requirement.

Together, the anti-amplification limit and the minimum size requirement reduce reflection/amplification potential, but do not eliminate real-IP attacks, high-PPS floods, or CPU pressure on parsing and handshake. Operators should apply rate limiting, anti-spoofing filtering, and capacity controls in addition.

Telemetry and anomaly detection in QUIC

Effective anomaly detection in QUIC requires protocol-specific telemetry — traditional TCP metrics do not capture relevant QUIC signals. Alerts must be calibrated with historical baseline and segmented by service, region, client version, access network, and traffic profile. A change may indicate an attack, a shift in HTTP/3 adoption, a compatibility issue, or legitimate demand variation.

Mitigating QUIC Flood in layers

An effective QUIC mitigation architecture combines controls across multiple layers. No single control resolves all vectors.

L3/L4 mitigation for UDP

• Rate limiting by IP, prefix, ASN, and port — applicable to UDP traffic without requiring QUIC termination.
• Filtering malformed packets or packets with invalid fields identifiable without TLS termination.
• Discard of datagrams carrying a QUIC Initial below 1,200 bytes, per RFC 9000 rules. The cost of this control depends on where validation is applied — for example, at the edge, the load balancer, the kernel via XDP/eBPF, or the QUIC implementation.
• Filtering unsupported QUIC versions before deeper processing.
• BCP 38/uRPF upstream to reduce the viability of IP spoofing at the source.
• Rate limiting of Initial packets per time window, per origin, or globally.

L3/L4 controls protect against volumetric floods and some Initial floods, but do not inspect HTTP/3 content or detect stream abuse or HTTP Flood.

Address validation, Retry, and tokens

• Enable address validation in the QUIC implementation, with Retry when appropriate to the latency and compatibility profile.
• Use tokens from previous connections to reduce validation latency for known clients.
• When Retry and tokens are enabled, monitor their issuance, acceptance, rejection, and expiration as additional health and handshake-pressure indicators.
• Evaluate the cost of Retry processing itself under intense floods and calibrate upstream limits in complement.

Connection, stream, and request limiting

• Connection limits per IP, prefix, and globally — to control the total cost of pending handshakes.
• HTTP/3 stream limits per connection — configured according to the legitimate usage profile.
• Rate limiting per HTTP/3 route, identity, token, tenant, and behavior — applicable after QUIC/TLS termination.
• 0-RTT limits per client, session, and operation — accept only for idempotent operations.

QUIC/TLS termination and L7 controls

When QUIC and TLS are terminated at the edge, Layer 7 controls can be applied to HTTP/3 requests: WAF, per-endpoint rate limiting, API protection, bot detection, and identity- and behavior-based policies. This is typically necessary for full HTTP/3 inspection and to respond to vectors such as HTTP Flood and stream abuse.

Without termination, it is still possible to apply the L3/L4 controls described above and reduce a significant portion of the risk — but not all vectors.

Observability and policy adjustment

• Separate telemetry for UDP/443 and QUIC — independent of TCP dashboards.
• Correlation between network metrics (PPS, bandwidth, discards) and application metrics (latency, errors, cost per endpoint).
• Continuous policy adjustment based on per-service, per-region, and per-period baseline.
• Periodic testing of the mitigation process in controlled exercises.

TCP fallback consideration

Operators may choose to temporarily reduce or suspend QUIC for specific segments or risk profiles during incidents. This may direct traffic to HTTP/2 over TCP, where stateful inspection tools are more mature. This fallback behavior may occur in browsers and clients that support Alt-Svc, but must not be treated as guaranteed. Changes must be tested, monitored, and have rollback criteria — they can affect performance, compatibility, and user experience.

A distributed edge or scrubbing architecture can help absorb and filter traffic before the origin. Results depend on topology, coverage, capacity, configuration, attack profile, and integration with published protocols.

Common mistakes when protecting QUIC and HTTP/3

Blocking UDP 443 as the immediate response to any anomalous QUIC traffic: this eliminates HTTP/3 for all legitimate users. Use granular controls — invalid packet filtering, prefix-based rate limiting, minimum size validation — as first responses, preserving the service while reducing impact.

Assuming TCP SYN Flood protections automatically apply to QUIC: SYN Cookies have no direct equivalent in all QUIC implementations. Explicitly verify that your implementation has address validation via Retry enabled and which mechanisms are configurable.

Not differentiating UDP/443 telemetry from TCP/443 telemetry: QUIC attacks are invisible in dashboards focused exclusively on TCP. Configure separate telemetry collection for UDP/443 and QUIC-specific metrics.

Treating QUIC termination as the only possible defense: termination is necessary for complete L7 inspection, but L3/L4 controls, rate limiting, address validation, and malformed packet filtering are effective for volumetric and Initial flood vectors without requiring termination.

Using Connection ID as the sole identifier for security policies: CID is not a reliable identity. Use it as a complementary signal, not a substitute for IP, prefix, identity, session, and behavior.

Not calibrating alerts with per-service and per-region baselines: global thresholds generate false positives and may not detect anomalies concentrated in traffic subsets. Segment baselines by application, endpoint, client version, and period.

Frequently asked questions

Is QUIC intrinsically more vulnerable to DDoS than TCP because it uses UDP? Not necessarily. QUIC was designed with specific defense mechanisms — address validation, Retry, anti-amplification limit, and minimum size requirement for Initials. The main challenge is that tools and processes historically developed for TCP need to be adapted or complemented to effectively observe and control QUIC traffic.

How does QUIC Flood differ from low and slow attacks like Slowloris? They are different vectors. Slowloris keeps TCP connections open with minimal transmission, exhausting connection pools. QUIC Initial floods pressure parsing CPU and handshake resources; HTTP Flood over HTTP/3 pressures the application; volumetric UDP floods pressure bandwidth and PPS. Countermeasures are distinct for each vector.

Why is the 1,200-byte requirement for Initial packets important? A datagram carrying a QUIC Initial below 1,200 bytes must be discarded by the server per RFC 9000. The requirement reduces the size asymmetry that could favor reflection attacks. By requiring a larger datagram to carry an Initial, the protocol raises the bandwidth cost for the sender and limits the relationship between bytes sent by the attacker and bytes the server can transmit before validating the address. The rule does not eliminate the processing cost of high-PPS floods, parsing, key derivation, token validation, buffers, or handshake pressure.

Is Retry sufficient to protect against Initial floods? Retry can reduce work performed before address validation, especially against spoofed-IP attacks. It does not directly address real-IP botnet attacks that complete validation. Retry processing itself has a cost; under intense floods, complementing with upstream rate limiting is important.

How do I handle 0-RTT securely? Accept 0-RTT data only for idempotent operations. Implement adequate anti-replay measures in the application. Monitor the acceptance and rejection ratio of 0-RTT as part of security telemetry. 0-RTT data cannot be forged by third parties without session keys — the replay risk is for clients that have valid tickets, not for external adversaries without keys.

How do I distinguish a QUIC flood from a legitimate increase in HTTP/3 adoption? The distinction requires historical baseline per service and region. Floods may present abrupt peaks, validation failures, invalid packets, increased handshake CPU, or disproportionate growth of attempts relative to useful sessions and requests. However, distributed botnets with real IPs may look like legitimate traffic on some individual metrics. Analysis must correlate network, handshake, application, identity, and behavior — no single indicator is conclusive.

In environments that use observable address validation, legitimate growth tends to maintain completion rates consistent with the baseline. Even so, interpretation must consider the adopted Retry policy, token use, mobile networks, NATs, client versions, and configuration changes that can affect completion metrics independently of an attack.

Technical references

• RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport
• RFC 9001 — Using TLS to Secure QUIC
• RFC 9114 — HTTP/3
• RFC 9002 — QUIC Loss Detection and Congestion Control
• RFC 2827 — Network Ingress Filtering: Defeating Denial of Service Attacks (BCP 38)
• RFC 3704 — Ingress Filtering for Multihomed Networks

How to implement on Azion

Azion can compose a protection strategy for applications that publish QUIC and HTTP/3, according to contracted products, enabled protocols, and configured policies.

1. Edge controls for UDP and QUIC: network policies, rate limiting, and mitigation mechanisms can help reduce anomalous traffic before it reaches the origin.

2. Termination and application protection: when QUIC, TLS, and HTTP/3 are terminated at the edge, Layer 7 controls can be applied to requests, including security policies, rate limiting, and API protection, according to the environment configuration.

3. Connection and behavior controls: client validation, connection limits, request limits, and behavior analysis can help reduce exposure to handshake floods, stream abuse, and malicious automation.

4. Observability: logs, metrics, and telemetry can support anomaly detection, incident investigation, and mitigation policy adjustment.

Effective coverage depends on the application architecture, the QUIC and HTTP/3 implementations used, enabled products, configured policies, and the attack profile.

Learn more in the Azion DDoS Protection documentation.