The DDoS Attack Taxonomy

Section 01

How DDoS Works: 6 Resources to Exhaust

A DDoS attack exhausts a finite resource. There are exactly six, and every technique in this taxonomy targets one of them. The first five are nested: each one lives inside the layer above it. The sixth, Wallet, cuts orthogonally across all of them.

1

Bandwidthbits per second

Fill the pipe, nothing else gets through. UDP floods, amplification, ICMP. Needs 100 Gbps to matter. Trivially visible on any traffic graph.

2

ConnectionsTCP sockets / QUIC conns

Fill the connection table. New clients cannot connect. SYN flood, Slowloris, TCP conn flood. Easy to detect on HTTP/1.x, misleading on HTTP/2 where one connection hides 100 streams.

3

StreamsH2/H3 only

Fill stream slots inside a single connection. Invisible to L4 firewalls. Requires TLS termination plus binary frame parsing. This is where Rapid Reset, CONTINUATION flood, and stream exhaustion live.

4

RequestsCPU per request

Overwhelm request processing capacity. GET floods, cache busting, random URIs. Protocol-agnostic: same server work whether delivered via HTTP/1.1, H2, or H3. Only attacker efficiency and detection difficulty change.

5

Applicationbackend logic

Trigger expensive logic: DB queries, full-text search, file render, parser bombs, external API chains. One XML bomb (1 KB) can consume GBs of server memory. No traffic spike, no bandwidth anomaly, the server just dies.

6

Walletcloud bill

Trigger paid side-effects per request: LLM tokens, SMS, transactional email, egress GB, autoscaling hours, API gateway calls. Server stays healthy. SLOs stay green. The attack only surfaces on the next monthly invoice. No vendor taxonomy covers this class.

Network Pipe +-- carries Packets +-- establish Connections (TCP socket / QUIC connection) +-- carry Streams (HTTP/2 and HTTP/3 only) +-- carry Requests (GET /path HTTP/1.1) +-- trigger Application Logic (SQL query, XML parse, PDF render) \=> may also incur WALLET cost (LLM tokens, SMS, egress GB)

Lower levels are easier to detect but require more volume. A UDP flood needs 100 Gbps to matter. Anyone can see it.

Higher levels are harder to detect but devastating per hit. An XML bomb needs one request. A 1 KB payload consumes gigabytes of memory.

Wallet attacks are invisible to traditional DDoS defense. Traffic looks legitimate, the server stays healthy. Rate limiting helps, but billing-aware defense (per-route cost budgets, per-IP cost quotas) is the real mitigation.

Section 02

24 Core Mechanisms vs 3 Marketing Categories

Cloudflare, Akamai, NETSCOUT, and Radware group every attack into three buckets: Volumetric, Protocol/State, Application. That's good for boardroom slides, useless for engineering. When a vendor says "we protect against protocol attacks," they usually mean SYN floods, a problem solved in 1996 with SYN cookies. Each marketing category contains multiple distinct server-side effects that require different detection and different mitigation. We decompose the three categories into twenty-four mechanisms, and add a fourth category for the wallet-attack class no traditional taxonomy covers.

Industry Marketing Class	Code	DDactic Mechanisms	Count	Why the Industry Class Is Too Coarse
Volumetric	VOL	M-01 Bandwidth Saturation, M-02 Amplified Bandwidth, M-17 L7 Bandwidth Amp	3	Direct pipe-fill, reflector-based, and server-generated amp need three different defense architectures.
Protocol / State	STATE	M-03 to M-14, M-23. Includes SYN flood, slow headers/body/read, idle hold, TLS handshake CPU, TLS renegotiation, conn churn, H2 stream churn (M-11), H2 stream hold (M-12), QUIC state, fragment reassembly	12	"Protocol protection" usually means SYN cookies (1996). M-11 and M-12 are invisible to L4 appliances because they happen inside an encrypted TCP connection.
Application	APP	M-13 H2/H3 Frame Flood, M-15 Request Flood, M-16 Cache Bypass, M-18 Parser Bomb, M-19 Backend Query Amp, M-20 Session Exhaust, M-21 Redirect Amp, M-22 Protocol Service Flood	8	A request flood (RPS-driven) and a parser bomb (1 request, GBs of memory) need completely different defenses. Lumping them is how vendors claim coverage they don't have.
Wallet (DDactic)	WLT	M-24 Cost Amplification. LLM token burn, API Gateway request burn, email/SMS send bombs, auth-provider login bombs, cache-miss egress bombs, autoscaling cost triggers, upload pipeline cost bombs.	1	No traditional taxonomy covers this. Traffic is well-formed, the server is healthy, the SLOs are green. The damage appears on next month's invoice.

What "Protocol Protection" Really Means

When a vendor says "we mitigate protocol attacks" they usually mean M-03 (SYN flood) and M-08 (TLS handshake), the well-understood mechanisms documented in textbooks. They rarely mention M-11 (H2 stream churn) or M-12 (H2 stream hold), which require H2-aware L7 inspection to detect at all.

Same marketing class. Completely different capability. The gap is what makes the 2023-2024 H2 CVEs (Rapid Reset, CONTINUATION) work against vendors who claim full coverage.

Section 03

HTTP Version Changes Everything

Each HTTP version has a different relationship between connections, streams, and requests. This single fact determines which attacks work, how efficient they are, and whether they can be detected. "HTTP GET Flood" is not one attack. It is four.

Connections needed for a 10,000 RPS attack

Same payload, same server work. Only the visibility changes.

Metric	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3 (QUIC)
Connections needed for 10K RPS	10,000one per request	~100keep-alive amortized	~10stream multiplexed	~10over UDP, no TCP
Streams per connection	N/A	N/A	~100	~100
Requests per connection	1	~100	~1,000	~1,000
TCP handshakes/sec at 10K RPS	10,000	~1-2	~0.1	0UDP, no TCP
What L4 firewalls actually see	10K SYNs, obvious	100 long-lived conns, visible	10 TCP conns, looks normal	UDP packets, nearly blind
Server work per request	Identical. Only detection difficulty changes.

The same 10,000 RPS attack looks like 10,000 connections on HTTP/1.0 (trivial to detect) but 10 connections on HTTP/2 (invisible to connection-counting firewalls). This is why HTTP/2 Rapid Reset (CVE-2023-44487) was the largest DDoS attack ever recorded. L4 devices saw a few normal TCP connections. Inside each one, thousands of streams were being opened and reset per second.

Same attack concept, 4 different protocol variants

A "Slowloris" or "GET flood" is shorthand for four distinct attacks. Each has different mechanics, different mitigations, and different detection requirements.

Attack Concept	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3
Connection Exhaustion	Open N conns, very expensive	Slowloris: hold conns with slow headers	Stream Exhaustion: fill max_concurrent_streams, 1 TCP holds 100+	QUIC CID Exhaustion: fill connection ID tracking table
Slow Body	N/A (no keep-alive)	Slow POST / R.U.D.Y.: drip body 1 byte / 10s	DATA Trickle across many streams	Same as H2 over QUIC streams
Slow Read	N/A	Tiny TCP window, server buffers response	WINDOW_UPDATE Abuse: manipulate flow control	QUIC ACK Manipulation: abuse congestion control
Request Flood	Expensive: new TCP+TLS per request	Pipelining: 50 reqs/TCP write, HOL blocking	Mux Flood: 100s of reqs on 1 TCP, no HOL	HEADERS Flood: 100s of reqs, no TCP HOL
Header Abuse	1 request then close	Slowloris: slow headers	CONTINUATION flood: endless header fragments (CVE-2024-27316)	Same via QPACK
Reset / Cancel	N/A	FIN/RST after partial request	Rapid Reset: open + RST_STREAM at max rate (CVE-2023-44487)	QUIC RESET_STREAM
Frame/Packet Abuse	N/A	N/A	SETTINGS Flood, PING Flood, Empty Frames	Malformed QUIC Frames
Compression Bomb	Omit Accept-Encoding	HTTP BOMB gzip POST	HPACK Bomb: header decompression to huge values	Slow QPACK
WAF Evasion	Some WAFs skip 1.0 rules	Standard WAF coverage	Encrypted mux harder to inspect at line rate	Even harder: UDP, encrypted, multiplexed

The Protocol Paradox

HTTP/2 is more resilient to brute-force request floods (empirical IIS testing showed 2,500 RPS killed HTTP/1.1; HTTP/2 needed 10,000 RPS for the same outcome) and introduces new attack surfaces (Rapid Reset, CONTINUATION, Stream Exhaustion) that did not exist in HTTP/1.1.

Upgrading to HTTP/2 is a net positive for defense against unsophisticated attackers. It is a net negative against advanced adversaries who can exploit stream-level mechanisms. Correct posture: use H2 for the efficiency gain, but deploy H2-aware L7 inspection (not just L4 firewalls) to cover the new blind spots.

Section 04

Vendor H2/H3 Frame Inspection Reality (2026)

The gap between "supports HTTP/2" and "inspects HTTP/2 frames" is enormous. Of 16 major DDoS / WAF vendors, only five have custom H2 stacks that see frame-level abuse. The rest use nginx/Apache-based proxies that terminate H2, convert to requests, and forward, structurally blind to RST_STREAM floods, CONTINUATION bombs, SETTINGS abuse, PING floods, HPACK bombs, and WINDOW_UPDATE manipulation.

Tier 1 Native Frame Inspection + H3/QUIC Custom HTTP/2 stacks that monitor individual frame types. Can detect Rapid Reset, CONTINUATION flood, and stream-level abuse natively.

Vendor	H2 Frames	H3 / QUIC	QUIC Streams	CVE-2023-44487	CVE-2024-27316
Cloudflare	Yes, custom stack	Yes (GA 2021)	Likely	Co-discoverer, real-time mitigation	Custom stack, likely handled
Google Cloud (GFE)	Yes, custom stack	Yes (invented QUIC)	Yes, deepest impl	Co-discoverer, 398M RPS mitigated	Custom stack
Akamai	Yes, custom edge	Yes	Limited detail	Mitigated proactively	"Not Affected" per CERT/CC

Tier 2 Strong H2 Awareness, H3 Varies Custom or configurable H2 handling. Stream limits and some frame abuse detection, but may not cover all frame types.

Vendor	H2 Frames	H3 / QUIC	CVE-2023-44487	CVE-2024-27316
F5 BIG-IP	Yes, configurable H2 profile	No H3	Configurable mitigations	"Not Affected" per CERT/CC
Fastly	Partial (H2O-based)	Yes (edge H3)	Mitigated	Affected by Go variant, patched

Tier 3 H2 Termination, Request-Level Only Terminate H2 at edge, apply WAF rules on extracted requests. Blind to frame-level attacks. This is the majority of the market.

Vendor	H2 Terminated?	Frame Inspection?	H3 / QUIC	Downgrade to Origin?	CVE-2023-44487	CVE-2024-27316
AWS CloudFront + WAF	Yes	No	Yes (since 2022)	Yes (H1.1 to origin)	Co-reporter, infra-wide fix	No public statement
Azure Front Door	Yes	No	No GA	Yes (H1.1 to origin)	Patched HTTP.sys / IIS	"Not Affected" (server resilience)
Imperva Cloud WAF	Yes	No	No	Yes	Likely patched infra	No statement
Radware Cloud WAF	Yes	No	No	Yes	Behavioral rate detection	No statement

Tier 4 No Frame Inspection, No H3 Signature-based, patched their own vulnerability, or L3/L4 only. No visibility into H2 frame types.

Vendor	H2	Frame Inspection	H3	CVE-2023-44487	Notes
Fortinet (FortiWeb)	Yes	No	No	Vulnerable, patched 7.4.2+	IPS sig 40152 for RST_STREAM rate (pattern, not frame)
Check Point	Yes	No	No	No specific advisory	Connection-rate based
Palo Alto	Yes (TLS decrypt)	Signature only	No	Not affected natively	Threat ID 40152 (RST_STREAM rate)
Arbor / NETSCOUT	No (L3/L4)	No (flow telemetry)	No	Cannot detect (L3/L4 tool)	Detects volumetric spike, not H2 mechanism
Sucuri	Yes (nginx-based)	No	No	Dependent on nginx patches	Request-level WAF only
StackPath	Yes	No	No	No advisory	Acquired by Akamai (2024)
KeyCDN	Yes	No (nginx-based)	No	Dependent on nginx patches	Request-level only

The Bottom Line

Out of 16 major vendors: 5 truly inspect H2 frames (Cloudflare, Google, Akamai, F5, Fastly). 5 terminate H3/QUIC. 1-2 inspect QUIC streams (Google confirmed, Cloudflare likely).

When a vendor says "we mitigate Rapid Reset," it usually means they patched their own server, not that they detect it in customer traffic. If your target uses Fortinet, Check Point, or Palo Alto on-prem, it is blind to all 12 stream-level mechanisms (M-11, M-12, M-13). If it uses AWS WAF behind CloudFront, request-level rules work but frame-level H2 attacks pass through to origin.

Section 05

The 4 Classification Axes

Every entry in the taxonomy can be independently tagged on four axes. They cut orthogonally across the hierarchy and answer different operational questions than the resource/mechanism model does. Each axis determines which defenses will actually work.

Axis 01

CVE vs Protocol Design Vector

Will this attack be patched away, or does it exist forever?

CVE (Bug)

Cause: implementation mistake
Fix: patch the code
Lifecycle: degrades after patch date
Example: CVE-2023-44487, no RST_STREAM rate limit

Design Vector

Cause: the spec enables it
Fix: cannot be patched away
Lifecycle: constant forever
Example: stream multiplexing creates stream exhaustion

Axis 02

Flood vs Low-and-Slow

What does the attack look like on a traffic graph?

Flood

Signature: massive spike
Detection: threshold-based
Attacker cost: high (botnet, amplification)
Example: UDP flood, GET flood, Rapid Reset

Low-and-Slow

Signature: normal or below normal
Detection: behavioral (timeouts, windows)
Attacker cost: minimal, one laptop suffices
Example: Slowloris, Slow POST, Sockstress

Axis 03

Direct vs Amplified

Does the traffic come from the attacker, or from innocent third parties?

Direct

Source: real attacker IP
IP blocking: works
Defense: rate limits, challenges, reputation
Example: GET flood, Slowloris

Amplified

Source: spoofed via reflectors
IP blocking: useless (innocents)
Defense: BCP38, scrubbing, overprovision
Example: DNS amp 50x, NTP 500x, Memcached 50,000x

Axis 04

Stateful vs Stateless

Does the attacker need a real connection, or fire-and-forget?

Stateful

Handshake: completed
Source IP: real, visible
Challenges work: yes
Example: Slowloris, GET flood, Rapid Reset

Stateless

Handshake: none or spoofable
Source IP: fake or per-packet
Challenges work: no (spoofed source never receives)
Example: SYN flood, UDP flood, all amplification

Why Axis Combinations Matter

Every attack carries a tag on all four axes simultaneously. The combination determines which defenses are structurally useless.

Stateless + Amplified + Flood is the classic "dumb DDoS" that scrubbing centers handle well. Stateful + Low-and-Slow + Direct is the sophisticated attack that requires application-layer intelligence. A vendor that only sells rate limiting has a blind spot in low-and-slow. A vendor that only sells challenges has a blind spot in stateless amplification. The two skill sets do not transfer.