TCP ACK Flood

An ACK flood is unremarkable to look at. The packets are well-formed TCP segments carrying the ACK flag, of ordinary size, at high rate. What makes them hostile is that none of them belongs to a conversation the receiver has any record of.

At a glance

Appliance	Property	ACK flood	SYN flood
What the packet claims	To belong to an existing conversation	To be starting a new one
Resource consumed	Lookup budget, and reply generation	Half-open connection table
Handshake defences	Do not apply; there is no handshake	Apply directly; SYN cookies remove the cost
Typical detection signal	High ACK rate with no matching sessions	High SYN rate with low completion

The third row is why an estate can be well defended against SYN floods and completely exposed to this one.

What it exhausts

Two resources, and the first is the one people underestimate.

Lookup budget. Every arriving TCP segment must be matched against the session table before any decision can be taken. Deciding to drop something still costs the lookup, so a device is doing per-packet work at the attacker’s chosen rate regardless of the verdict.

Reply generation. Where a device or host answers an unmatched segment with a reset, each attack packet also produces an outbound packet. That doubles the work and, because the source is usually forged, sends the reset to somebody uninvolved.

Neither resource is bandwidth. An ACK flood can exhaust a stateful device well below the rate that would trouble the circuit.

How it differs from similar attacks

A SYN flood attacks the allocation of new state. An ACK flood attacks the searching of existing state. That difference decides which defences apply.

SYN protection works by refusing to allocate memory until the client proves it exists — the mechanism behind SYN proxy and cookies. An ACK flood never asks for an allocation. The packet claims the work was already done, and the device has to look to find out otherwise.

RST and FIN floods behave the same way and are frequently grouped with this vector. The mechanism is identical: a flag that implies an existing conversation, sent to a device that must check.

Observable telemetry

• Unmatched segment rate rising sharply, which most estates do not graph.
• ACK-to-session ratio departing from its normal band.
• Outbound reset rate rising, where the device replies to unmatched segments.
• CPU on stateful devices rising with no matching increase in session count — the signature that distinguishes this from a genuine traffic surge.
• Bit rate frequently unremarkable, because the packets are small.

Common false positives

Asymmetric routing. Where a device sees only one direction of a conversation, legitimate ACKs genuinely match no session. This is a configuration issue that looks exactly like the attack, and it is worth ruling out before tightening anything.

Load balancer or firewall failover. A device that has just taken over has no session table yet, so every packet from every established conversation is unmatched for a period.

Long-idle sessions. A conversation whose entry expired at the device but not at the endpoints resumes with a segment that matches nothing.

All three are reasons to alert on unmatched-segment rate rather than to drop on it automatically.

Mitigation by layer

Stateless filtering ahead of the stateful stage. The general principle in stateful and stateless defence applies directly here: a stage that discards segments by packet properties at fixed cost protects the lookup budget behind it.

Rate-limit unmatched segments rather than ACKs generally, so ordinary traffic is untouched while the attack’s characteristic is bounded.

Suppress or rate-limit reset generation for unmatched segments during an event. It halves the work and stops you sending resets to forged addresses.

Upstream filtering where the sources are concentrated enough to describe: FlowSpec can express a flag-and-rate match and push it above your circuit.

Operational pitfalls

Assuming SYN protection covers it. The commonest and most expensive assumption in this area.

Blocking ACK traffic broadly. ACK is most of TCP. A blunt rule breaks every established conversation on the estate.

Ignoring asymmetric routing first. Tightening unmatched-segment handling in an estate that routes asymmetrically produces an outage that looks like the attack succeeding.

Safe validation

Generate the flood against a lab target with a session table you can watch, and record three things: unmatched-segment rate, device CPU, and outbound reset rate. The useful measurement is the packet rate at which CPU saturates, which is usually far below the device’s advertised throughput and is the number to compare against a datasheet figure.

The environment and the isolation requirements are in the test lab guide, and the authorisation groundwork in authorised testing.