RTBH Does What It Was Designed to Do
Remote Triggered Black Hole routing drops all traffic to a target prefix at the upstream edge. You announce a /32 route with a blackhole community (typically 65535:666 per RFC 7999, or a provider-specific community). The upstream installs a null route for that prefix. Traffic destined for that IP is discarded before it reaches your network.
RTBH protects your network links from congestion. When a 10 Gbps flood saturates your 1 Gbps transit link, every service behind that link suffers. RTBH removes the target from the routing table, so the flood traffic is dropped at the upstream edge. Your transit link recovers. Other services resume normal operation.
This is a well-understood, widely deployed technique. It works exactly as designed. The target IP becomes unreachable, but the rest of your network is preserved.
When RTBH Becomes the Default
The problem is when every attack triggers a blackhole. Many detection tools offer RTBH as the only automated mitigation response. When a threshold is crossed, the tool announces a blackhole. The server goes offline. The attack stops hitting your link. Problem "solved."
But most attacks do not saturate transit links. A 200,000 PPS SYN flood consumes maybe 100 Mbps of bandwidth. A DNS amplification burst at 500 Mbps on a 10 Gbps port has 9.5 Gbps of headroom. These attacks cause problems for the target server (connection exhaustion, CPU load, service degradation), but they do not threaten the transit link.
Blackholing these attacks takes the server offline when it did not need to go offline. The server could have stayed up with targeted filtering. Instead, it is unreachable for the duration of the blackhole announcement plus whatever holddown timer is configured. Legitimate users get the same result as if the attack succeeded.
FlowSpec: The Surgical Alternative
BGP FlowSpec pushes specific filtering rules to upstream routers using standard BGP. Where RTBH says "drop everything to this destination," FlowSpec says "drop traffic matching these specific criteria to this destination." The difference is surgical precision.
FlowSpec can express filtering rules like:
- Drop UDP traffic from source port 53 to destination 203.0.113.50 exceeding 10,000 PPS (DNS amplification)
- Rate-limit TCP SYN packets to destination 203.0.113.50 above 50,000 PPS
- Block all traffic from source prefix 198.51.100.0/24 to destination 203.0.113.50
- Drop ICMP echo-reply packets to destination 203.0.113.50 exceeding 5,000 PPS
Legitimate traffic passes normally. Only the attack traffic is filtered. The server stays online and continues serving real users throughout the attack.
FlowSpec is supported by Juniper MX series, Nokia SR series, Cisco IOS-XR, and several other router platforms. Your upstream provider needs to accept FlowSpec announcements from your AS, and the rules propagate via BGP, so there is a brief propagation delay (typically a few seconds).
On-Server Mitigation: The Fastest Alternative
Firewall rules on the target server are the fastest possible response. There is no BGP propagation delay, no upstream coordination, no external system to trigger. The agent on the server detects the attack and applies kernel-level rules in 1-2 seconds.
- SYN cookies: The Linux kernel's SYN cookie mechanism handles SYN floods without consuming connection table entries. No packets need to be dropped for this to work.
- Conntrack tuning: Adjusting connection tracking timeouts and limits prevents connection table exhaustion during state-exhaustion attacks.
- Rate limiting by source: Hashlimit rules in iptables/nftables rate-limit traffic per source IP, throttling attack sources while allowing legitimate sources through.
- Port-specific filtering: Dropping traffic from source ports associated with reflection attacks (chargen, SSDP, CLDAP, memcached) when those ports should never appear in legitimate traffic to your service.
On-server mitigation handles any attack that does not saturate the inbound link. The server stays online. Response time is measured in seconds. No external dependencies. This is the most responsive option available for sub-link-capacity attacks.
When You Still Need RTBH
RTBH remains the right tool when:
- Attack volume genuinely exceeds your bandwidth. When the flood is larger than your transit link, on-server filtering cannot help because the packets never reach the server. FlowSpec may not be granular enough if the attack traffic is indistinguishable from legitimate traffic at the router level.
- Upstream routers do not support FlowSpec. Not all transit providers accept FlowSpec announcements. If your only upstream BGP option is community-based RTBH, that is what you have.
- The attack is too large for on-server filtering. When attack volume overwhelms the server's NIC or kernel processing capacity, no amount of iptables rules will help. The packets need to be dropped before they reach the server.
In these scenarios, RTBH protects the rest of your network. The target goes offline, but the alternative is that everything behind the congested link goes offline. RTBH is the correct choice in that situation.
Automated Escalation
The ideal architecture does not choose one response. It uses all of them in sequence, starting with the least disruptive and escalating only when monitoring confirms the current level is not working:
- On-server rules (Level 1): Applied in 1-2 seconds. Handles the attack without any external coordination. If packet rate or bandwidth continues to climb despite the rules, escalate.
- FlowSpec (Level 2): Pushes surgical filtering to upstream routers. Drops specific attack traffic at the network edge while preserving legitimate traffic. If the attack volume exceeds what FlowSpec rules can contain, escalate.
- Cloud scrubbing (Level 3): Diverts traffic through a scrubbing provider. Cleans traffic at scale. Services stay online. If the attack overwhelms the scrubbing capacity or activation is not fast enough, escalate.
- RTBH (Level 4): Blackhole the target at the upstream edge. Protects the transit link when nothing else can keep up.
Automated escalation means no human has to make the call during an attack. The system monitors whether the current mitigation level is effective and escalates when it is not. Automated de-escalation means mitigation rules are withdrawn in reverse order when the attack subsides. On-server rules come off last, FlowSpec rules withdraw, scrubbing diverts back to direct routing.
The result: RTBH triggers only when it is genuinely needed, not as the default response to every threshold crossing.
Start with surgical mitigation. Escalate to RTBH only when necessary. Flowtriq provides four mitigation levels with automatic escalation and de-escalation. $9.99/node/month, 14-day free trial.