Stateful vs Stateless Filtering

What stateful filtering means

A stateful filter keeps information about flows, sessions or connection progress. It does not evaluate a packet in isolation. Instead, it asks whether the packet matches the expected behavior of an already known session.

Protocol validation can benefit from state, but each tracked flow consumes memory, timers, lookups and CPU time.

What stateless filtering means

A stateless filter decides based on the current packet only. It can match on source, destination, protocol, ports, flags, length or simple signatures without maintaining per-flow state.

This reduces per-flow overhead and improves scaling when packet rate is high.

Direct comparison

Stateful

• Tracks sessions or flow progress
• More precise protocol awareness
• Higher memory and CPU cost
• Breaks earlier under high PPS

Stateless

• Evaluates packets independently
• Lower per-packet overhead
• Scales better under load
• Less context and less precision

Stateful processing limits

Under attack, a stateful system has to keep up with both packet rate and state growth. That means every spoofed SYN, every incomplete flow and every short-lived packet burst can create additional lookup and memory pressure.

Once connection tables, timers or lookup structures become the bottleneck, the mitigation path starts failing before bandwidth is exhausted.

Stateless processing

A stateless filter can often make a decision with a small number of comparisons and then drop or rate-limit the packet immediately. There is no need to create session state for traffic that is clearly abusive.

High-PPS mitigation commonly starts with stateless filtering and applies stateful validation only where the additional processing cost is justified.

Combined approach

• Use stateless filtering for obvious attack signatures and early drops
• Use stateful validation only where additional precision is worth the cost
• Keep high-PPS traffic away from conntrack-heavy paths whenever possible
• Treat packet rate and lookup complexity as primary design limits