On this page
Key points
- Blackhole protects capacityIt removes all traffic for a destination so the rest of the network survives.
- FlowSpec is selectiveIt can match protocol, ports, length, flags or fragments when the attack is identifiable.
- Automation needs limitsRules need thresholds, expiry and rollback.
Defining the problem
Remote triggered blackhole announces a special route to discard all traffic toward an IP or prefix. It is easy to operate and widely supported, but the protected service becomes unreachable.
FlowSpec carries filtering rules in BGP. A rule may match protocol, source and destination ports, packet length, TCP flags or fragments, then apply discard or rate-limit. This precision is powerful, but a broad rule can silently damage real traffic.
The operational difference becomes obvious during saturation. Blackhole changes reachability for a destination; FlowSpec changes packet treatment inside the routing infrastructure. That means FlowSpec needs a confidence level: which fields are stable, which fields are normal for users, and which action can be removed without waiting for a maintenance window.
Why this matters
The wrong mitigation choice can cost more than the attack. Blackholing a shared IP, a FiveM endpoint or a customer gateway prevents saturation but creates a full outage. A bad FlowSpec rule may look cleaner in graphs while real users fail.
For protected transit, customers pay for reachability, not only backbone survival. Decisions must rely on evidence: packets per second, Gbps, affected ports, packet profile, error rate and how stable the attack signature is.
A useful runbook should also define who is allowed to propagate a rule upstream. Local drops can be tested quickly; upstream FlowSpec affects a larger domain. For customers carrying third-party traffic, approval, logging and expiry are part of the product, not paperwork.
Possible solutions
Manual RTBH is appropriate when a destination must not threaten other customers or when volume exceeds available ports. It is an emergency brake, not fine mitigation.
Manual FlowSpec after packet capture works for stable attacks with clear characteristics. It becomes too slow when the signature changes frequently or when no engineer is available.
The strongest model is controlled automation: thresholds per port, short-lived rules, expiry, legitimate traffic monitoring and blackhole only as last resort.
Rate-limiting is sometimes safer than discard. If an attack signature overlaps with legitimate traffic, a temporary policer may reduce pressure while packet captures and application metrics confirm whether a stricter rule is safe.
- RTBH
- Fast and predictable, but the target is sacrificed.
- Precise FlowSpec
- Works when several fields describe the attack.
- Hybrid pipeline
- FlowSpec reduces gross volume; specialized mitigation protects the service.
| Criterion | BGP Blackhole | BGP FlowSpec |
|---|---|---|
| Service impact | Destination offline | Targeted filtering if precise |
| Complexity | Low | Medium to high |
| Ideal use | Last resort | Attack-volume reduction |
Concrete use case
A game server receives 80 Gbps of UDP on its public port. Blackholing the IP stops saturation but disconnects everyone. Dropping all UDP to the game port is almost as bad.
The safer response is to look at packet length, source-port ranges, pps/Gbps ratio and fragments. A combined FlowSpec rule can remove most of the attack while preserving real clients, then disappear when the signature changes.
The same logic applies to TCP floods. A rule on TCP flags may help for abnormal SYN or ACK patterns, but it must be compared against normal connection behavior for the protected service.
Frequent mistakes
Most mistakes come from reacting too fast without enough evidence. Speed matters, but an incorrect rule propagated upstream can be more damaging than a local filter.
Another common issue is forgetting the customer communication layer. When blackhole is used, the customer must know that reachability is intentionally sacrificed; when FlowSpec is used, the customer needs confirmation that the rule is temporary and monitored.
- Treating FlowSpec as an application firewall.
- Leaving rules active after the attack.
- Filtering on one field such as packet length.
- Blackholing a whole prefix for one attacked IP.
- Not comparing legitimate traffic before and after the rule.
FAQ
Does FlowSpec replace DDoS protection?
No. It reduces certain upstream traffic patterns but does not understand application legitimacy by itself.
Is blackhole still useful?
Yes, as a last resort when a destination threatens network stability.
Can FlowSpec be safe for UDP games?
Yes, with combined criteria, short lifetimes and active monitoring.
How long should a rule live?
As short as possible, usually minutes, renewed only while evidence remains.
