Remotely Triggered Black Hole Filtering (RTBH)

There is one thing you cannot do from inside your own network: stop traffic that has already filled the circuit feeding it. By the time a saturating flood reaches your edge the damage is upstream of everything you own, and the only instruments that help are the ones held by the network delivering it to you.

RTBH is the bluntest of those instruments, and the most reliable. It works by asking your upstream to throw away every packet addressed to a destination you nominate RFC 5635.

How it works

You announce a route for the address under attack — normally a host route, a /32 or /128 — tagged with a community your upstream recognises as “discard traffic to this”. Their edge routers install a route for that destination pointing at a null interface, and from that moment traffic to it is dropped at their border rather than carried to yours.

The signalling detail that makes this practical across providers is the well-known BLACKHOLE community, 65535:666 RFC 7999. Before it was standardised, every operator published their own value, so a multihomed customer had to configure a different trigger per upstream and remember which was which under pressure. A well-known value removes that class of mistake.

The two variants

Appliance	What it stops	What it costs	Where it acts
Destination-based RTBH	All traffic to one address, including the attack	That address is unreachable — the attacker's goal, achieved	Upstream, before your circuit
Source-based RTBH	Traffic from identified source prefixes	Legitimate traffic from those sources, and it needs uRPF	Upstream, before your circuit
BGP FlowSpec	One matched vector, leaving the destination reachable	Carrier support and accepted rule complexity vary	Upstream, before your circuit
Local mitigation	Whatever it can classify	Nothing, until the circuit fills	Your own edge — too late for saturation

Read the first two rows together: RTBH is the only row that is guaranteed to work and guaranteed to hurt. That is not a criticism of it — it is what makes it the last resort.

Destination-based RTBH is what people mean when they say blackholing. It is total, it is immediate once BGP converges, and it does not care what the attack looks like — which is exactly why it works when classification has failed or when there is no time to classify.

Source-based RTBH discards traffic arriving from nominated source prefixes rather than traffic destined for one address RFC 5635. It preserves the destination, which sounds strictly better until you look at what it requires: the router has to check the source address against its forwarding table, which is unicast reverse path forwarding, and on a multihomed network the strict form of uRPF drops legitimate asymmetric traffic RFC 3704.

It also requires the sources to be real. Most volumetric attacks use forged source addresses, and blackholing a forged source blackholes an innocent network while the attack continues. Source-based RTBH earns its place against attacks whose sources are genuine — some application-layer campaigns, some botnet traffic — and is close to useless against reflection.

What it works against

Saturation, and specifically saturation aimed at a small number of addresses. If one service IP is absorbing a flood that is filling a 10 Gbps circuit shared by everything else you run, blackholing that one address restores the rest of the estate in the time it takes BGP to converge.

It also works when nothing else can: no local device, however well specified, moves the ceiling imposed by the circuit.

What it does not work against

Attacks spread across many destinations. A carpet-bombing campaign distributes volume across a whole prefix precisely so that no single address is worth sacrificing. Blackholing address by address becomes a losing race; blackholing the aggregate prefix means taking the whole service down yourself.

Anything where the destination must stay reachable. If the address under attack is your only public service, blackholing it is indistinguishable from the outage you were trying to prevent.

Application-layer attacks. These rarely saturate anything. Reaching for RTBH against a request flood discards a service that was still mostly working.

Operational risk

The failure modes are worth naming because they are all recoverable if anticipated and all expensive if not.

Propagation is not guaranteed. Your immediate upstream may accept the announcement and not pass it to their upstreams. If the volume is arriving from further away than your provider’s own border, a blackhole that stops at their edge stops nothing useful for them and everything for you.

Withdrawal has to be as rehearsed as the trigger. An announcement left in place after the attack is a self-inflicted outage that nobody is looking for, because the graphs are clean.

Scope creep. Blackholing a /24 because a /32 was under attack takes down twenty-three services that were fine. Under pressure this happens more often than anyone admits.

Loss of visibility. Once traffic is discarded upstream you can no longer see it, which means the telemetry your incident report needs stops at the moment you act. Capture first, then blackhole.

False-positive risk

Total, by construction, for the nominated destination. RTBH does not classify, so there is no such thing as a false positive in the usual sense — every packet to that address is dropped, legitimate or not. The decision is not “will this block real users” but “is blocking all of them for this destination cheaper than the alternative”.

That is why the decision belongs to a named person, decided in advance, as the incident runbook sets out.

When something else is better

If the attack is one identifiable vector against a destination that must stay up, BGP FlowSpec can discard that vector while leaving the rest of the traffic flowing RFC 8955. If the relationship with the upstream mitigator supports it, DOTS lets you ask for help in a standard way rather than reaching for the blunt tool.

RTBH remains the fallback beneath both of them: FlowSpec rules can be rejected or unsupported, and a signalled request can go unanswered. Blackholing works when the relationship works at all.

How to verify it before you need it

1. Confirm which community your upstream accepts, and whether the well-known BLACKHOLE community is honoured.
2. Confirm whether they accept announcements more specific than your allocation.
3. Trigger it in a maintenance window against a test address and measure how long until traffic stops.
4. Establish whether the discard propagates beyond their own border.
5. Withdraw it and measure how long until the address is reachable again.
6. Write all five answers into the runbook, with the date you measured them.

Sources