ACK flood: exhausting lookups rather than memory

The reasoning is on attack layers.

Devices that track connections keep a table of active sessions. When a packet arrives claiming to be part of one, the device has to find the matching entry before it can decide anything: whether to forward the packet, whether it is in sequence, whether it belongs to a permitted flow.

That search is the cost. It happens before the device learns that the session does not exist, which means traffic referring to nothing still consumes the same work as traffic referring to something. Multiply by a sufficient packet rate and the device spends its capacity looking things up.

Three consequences follow, and they explain why this vector persists alongside better-known ones.

Defences aimed at connection setup do not apply. The mechanism that avoids allocating memory for pending connections addresses a different stage. These packets do not ask to establish anything.

The target is often not the server. Firewalls, load balancers, and address translation devices all maintain session tables, and they are frequently the component with the least headroom. The server behind them can be entirely healthy while nothing reaches it.

Bandwidth may be unremarkable. The load is packets per second rather than bits per second, which is the same distinction described on volumetric attacks: a link can look far from full while the equipment carrying it is saturated.

The mechanism is identical, and only the second-order effect differs.

A reset tells the other side that a conversation is over. Sent in volume toward sessions that do not exist, it produces the same lookup cost as the traffic above, and the defence is the same.

The additional concern is narrower. A reset that matches an existing session closely enough will terminate it, which turns the flood into an interruption of working connections rather than only a load problem. Protocol implementations validate resets strictly for this reason, and the validation is what makes the outcome unlikely but not impossible. The practical consequences are two: long-lived connections are the ones with exposure to consider, and encrypted transports that carry their own session integrity are less affected than plain ones.

Three signals, and the combination is what distinguishes this from its neighbours.

Packet rate is high while bandwidth is moderate. The ratio is the signature. Many small packets, not much data.

No new sessions are being established. Unlike a connection flood, the half-open state is not filling. Unlike a genuine traffic increase, the established count does not rise either.

Load appears on network equipment rather than on the server. Processor usage climbs on the firewall or balancer, and the application behind it reports nothing unusual because nothing is arriving.

That third signal is the one that misdirects investigations. Everything on the server looks correct, which sends people looking at the application while the constraint is a device they may not administer.

Four measures, and the order matters more here than usual.

Drop non-matching packets as early as possible. The cheapest place to discard traffic referring to no session is the furthest point upstream that can make the decision. Each device it passes pays the lookup.

Prefer filtering that does not itself keep state. As on any attack in this family, a device that must track sessions to filter has the same exhaustible resource as the one it is protecting.

Ask upstream for a packet rate limit. Because the load is measured in packets rather than bits, a limit expressed in bandwidth may not engage at all while the equipment is already saturated. The limit has to be in the right unit to help.

Terminate connections where capacity is larger. Where sessions are established at an edge, the tables and the lookups under attack belong to that edge rather than to your equipment.

What does not help: request rules and challenges, since this traffic never reaches the stage where a request exists.

Rarely the whole event, and knowing that changes what you look for.

Because the technique targets a different resource from a connection flood and a different one again from a bandwidth flood, combining them is straightforward and effective: one component fills the queue, another consumes lookups, a third fills the link. Each has a different remedy, and addressing one while the others continue produces the impression that nothing worked.

The practical response is to identify which resource is actually exhausted before choosing a measure, which is the point made on DDoS attack types, and the one to return to whenever a mitigation appears to have no effect.

Bridge WAF operates on requests, which is above the layer this attack targets. What applies is termination: when sessions are established at the platform's edge, the session tables and the lookups under attack are the platform's rather than your equipment's, and your origin receives traffic that already belongs to valid sessions. Which component covers which layer is a fair question to ask any provider. See what the platform offers at Bridge CDN.