BGP FlowSpec limitations: what it can filter and where it becomes dangerous

The operational problem

The first limitation is semantic. FlowSpec matches header fields: destination, source, protocol, ports, packet length, TCP flags and similar components depending on implementation. That is very useful for patterns such as a repeated UDP flood, but it cannot know whether a packet belongs to a real player session, a valid API client or an expected burst after a release. It sees fields, not business context.

The second limitation is operational. Providers may restrict the number of rules, the supported components, the acceptable destination scope or the available actions. Some will accept only a small set of matches. Others may normalize or reject complex rules. A mitigation design that assumes unlimited FlowSpec precision can fail at the exact moment the customer needs it.

Why it matters before an attack

Understanding these limits prevents expensive mistakes. A FlowSpec rule pushed too broadly can drop production traffic before it reaches the customer’s own filters. Because the rule is applied upstream, the blast radius is larger than a local firewall mistake. The customer may see a clean graph while users still cannot connect.

It also helps set the right commercial expectation. FlowSpec is not “DDoS protection by itself”. It is a way to remove heavy, obvious and repetitive attack traffic upstream, so that protected transit ports, filtering servers and application-aware systems can finish the job with less pressure.

FlowSpec is a coarse upstream tool

It is excellent for reducing obvious attack volume, not for making every application-aware decision.

Rule scope is the main danger

A rule that is too wide can remove legitimate traffic at network scale.

Provider support is not uniform

Actions, components, limits and propagation behavior vary between networks.

Possible technical approaches

The safest approach is to use FlowSpec for de-grossing. In other words: target the parts of the attack that are clearly bad, short-lived and measurable. Rules should prefer narrow destinations, narrow protocols, precise port ranges, packet length ranges only when justified and clear expiry logic.

For more complex decisions, use downstream intelligence: DPDK/VPP filtering, XDP, proxy logic, game-aware validation, connection heuristics or customer-specific firewall rules. This is where state, baselines and service knowledge can be applied without asking an upstream router to behave like an application firewall.

Use narrow rules

Limit destination, protocol and match scope to reduce collateral damage.

Expire automatically

Short-lived rules reduce the risk of stale filters hurting later traffic.

Keep downstream intelligence

Let specialized filters make decisions that require state or service context.

Measure legitimacy

Watch allowed traffic, not only dropped traffic, during each rule change.

Concrete use case

A provider receives a 180 Gbps UDP flood with a repeated destination port and packet size. A narrow FlowSpec rule can remove a large part of the attack upstream, preventing the customer port from saturating. But if the rule matches every UDP packet to the customer prefix, it may also kill DNS, game sessions or monitoring traffic.

The safer design is progressive: start with the obvious malicious signature, monitor accepted traffic, then let the downstream mitigation layer handle the remaining mixed traffic. If the attack mutates, generate another narrow rule instead of widening the first one until it becomes a blackhole in disguise.

1. Identify what is truly stable

   Do not build a rule from one short packet sample if the attack changes every few seconds.

2. Scope the destination

   Prefer the attacked host or prefix slice rather than a broad customer-wide rule when possible.

3. Add an expiry

   A FlowSpec rule without a lifetime becomes technical debt.

4. Keep a rollback path

   Operators must know how to withdraw or override the rule immediately.

Frequent mistakes to avoid

• Using FlowSpec as a permanent firewall policy engine.
• Matching too wide a destination or too broad a protocol.
• Forgetting provider rule quotas and supported components.
• Assuming packet length or TCP flags are always safe signals.
• Not measuring legitimate traffic after rule propagation.

FAQ