RTBH Explained: How & When to Use Remotely Triggered Black Hole

RTBH (Remotely Triggered Black Hole) is a DDoS mitigation technique that uses BGP to tell every edge router in a network to drop traffic to a targeted address, network-wide, in seconds. It leverages the router’s forwarding table — routing the victim prefix to a discard (Null0) next hop — rather than slower packet-by-packet ACLs, which is why it scales to line rate across dozens of routers almost instantly.

Key takeaways
– RTBH null-routes traffic using BGP + a discard next hop (Null0) — fast, line-rate, network-wide.
– Destination-based RTBH drops all traffic to the victim IP; source-based RTBH drops traffic from attacker sources (via uRPF).
– Defined in RFC 5635; the well-known blackhole community 65535:666 comes from RFC 7999.
– The trade-off: destination RTBH completes the DoS for that one IP — you sacrifice the host to save the network.
– Use RTBH as a last resort; use BGP FlowSpec first when you can preserve legitimate traffic.

What is RTBH?

RTBH (Remotely Triggered Black Hole filtering) is a BGP-based method for dropping unwanted traffic across an entire network from a single trigger point. Rather than configuring filters on each router during an attack, an operator advertises one BGP route that carries a special marking; every router that receives it installs a drop for that traffic. It’s standardized in RFC 5635, which builds on the earlier RFC 3882 (“Configuring BGP to Block Denial-of-Service Attacks”).

The technique exists because ACL-based filtering doesn’t scale under a large flood. RFC 5635 notes RTBH’s origin in the response to the February 2000 attacks: by using the forwarding table instead of ACLs, black-hole routes could be pushed to 60+ routers within about 60 seconds, at line rate — fast enough to matter during a live attack.

How RTBH works

RTBH turns a routing update into a network-wide drop. The trigger router advertises the victim prefix into iBGP with a next hop that resolves to a discard/Null0 interface (or tagged with a blackhole community that each router maps to Null0). Once the route propagates, every edge router forwards traffic for that prefix straight to the bit bucket — no ACL lookup, just a normal (very fast) forwarding decision.

There are two common ways to trigger it:

• Next-hop method — set the advertised route’s next hop to a pre-configured discard address (statically routed to Null0 on every router).
• Community method — tag the route with a blackhole BGP community. RFC 7999 standardized the well-known value 65535:666, so a customer or peer can signal “please black-hole this /32 (or /128)” to an upstream that honors it.

Destination-based vs source-based RTBH

The two flavors of RTBH differ in what they drop:

• Destination-based RTBH black-holes all traffic to the targeted address. It’s simple and universally supported, but it drops legitimate traffic to the victim too — it finishes the attacker’s job for that one IP in order to protect everything else.
• Source-based RTBH drops traffic from the attacking sources, using a uRPF (unicast Reverse Path Forwarding) loose check: if the source of a packet points to a null-routed prefix, the packet is discarded. RFC 5635 extended RTBH to source-based filtering precisely so operators could drop by attacker instead of sacrificing the victim — though it depends on knowing (and being able to enumerate) the sources.

RTBH vs BGP FlowSpec: when to use which

RTBH is blunt; BGP FlowSpec is surgical. FlowSpec can match a specific 5-tuple and drop or rate-limit only the malicious flows, keeping the targeted service online. RTBH drops everything to the destination. The practical rule:

• Use BGP FlowSpec when you can characterize the attack and want to preserve legitimate traffic to the target.
• Use RTBH when the flood exceeds your edge or scrubber capacity, when the target is a single sacrificial IP, or when the attack is too randomized to express as a compact FlowSpec rule.

Most mature edges automate both: filter granularly with FlowSpec, and fall back to RTBH only when uplinks approach saturation.

The trade-off you must accept

Destination-based RTBH completes the denial of service for the targeted IP — that’s the point, and it’s a deliberate choice: lose one host to keep the network and every other customer online. Treat it as an emergency brake, not a routine control. This is exactly why detection accuracy and automation matter: you want to reach for RTBH only when granular filtering genuinely can’t hold, and you want that decision made in seconds, not minutes.

How WanGuard automates RTBH

In production, RTBH shouldn’t be a manual scramble during an outage. WanGuard anti-DDoS detects the attack in seconds, mitigates first with granular BGP FlowSpec on your routers (or the Juniper MX filtering gateway), and triggers RTBH automatically only as a last resort — when an attack is too large to filter granularly or uplinks approach saturation — with alerts to your NOC the whole time. That layered automation keeps customers online for as long as possible and reserves the blunt tool for when it’s truly needed.

ITORO installs, tunes and operates this for ISPs, telecoms and data centers; see Plans & Pricing for an itemized estimate.

Frequently asked questions

What does RTBH stand for?

RTBH stands for Remotely Triggered Black Hole filtering. It’s a BGP-based DDoS mitigation technique that lets an operator drop traffic to (or from) a targeted address across every router in a network from a single trigger, by routing that traffic to a discard (Null0) next hop.

What is the difference between destination-based and source-based RTBH?

Destination-based RTBH drops all traffic to the victim IP — simple but it also drops legitimate traffic to that host. Source-based RTBH drops traffic from attacking sources using a uRPF loose check, so it can spare the victim, but it depends on being able to identify the sources.

What is the RTBH blackhole community?

RFC 7999 defines the well-known BGP blackhole community 65535:666. Tagging a /32 (IPv4) or /128 (IPv6) route with this community signals to an upstream that honors it to null-route that address, letting a customer trigger RTBH on a provider’s network.

When should I use RTBH instead of BGP FlowSpec?

Use BGP FlowSpec first — it drops only malicious flows and keeps the service online. Use RTBH when the attack exceeds your edge or scrubber capacity, targets a single sacrificial IP, or is too randomized to express as a FlowSpec rule. RTBH is the last-resort fallback.

Does RTBH stop the DDoS attack?

Destination-based RTBH stops the attack from reaching the rest of your network, but it also drops all legitimate traffic to the targeted IP — effectively completing the denial of service for that one address. It protects the network at the cost of the single host, which is why it’s used as a last resort.

Sources
– IETF — RFC 5635, Remote Triggered Black Hole Filtering with Unicast RPF: https://www.rfc-editor.org/rfc/rfc5635
– IETF — RFC 3882, Configuring BGP to Block Denial-of-Service Attacks: https://datatracker.ietf.org/doc/html/rfc3882
– IETF — RFC 7999, BLACKHOLE BGP Community: https://www.rfc-editor.org/rfc/rfc7999
– Cisco — Remotely Triggered Black Hole Filtering (destination & source based): https://www.cisco.com/c/dam/en_us/about/security/intelligence/blackhole.pdf