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.
This is useful for protocol validation, but it also means the system needs memory, timers, lookups and CPU time for every tracked flow.
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.
That usually makes it much faster and easier to scale, especially when packet rate is high and per-packet work must stay minimal.
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
Why stateful paths fail first
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.
Why stateless paths scale better
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.
That is why high-PPS mitigation commonly starts with stateless filtering first and only applies stateful validation where it is still affordable.
Real-world 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