RTBH and BGP Flowspec DDoS Mitigation Guide

Remotely triggered black hole (RTBH) routing and BGP Flow Specification (Flowspec) are the fastest DDoS controls a network operator has, and they are also among the fastest ways to take your own network offline. Both use BGP to push drop or rate-limit decisions to every edge router in seconds, which is exactly what you want against a volumetric flood and exactly what you do not want when the rule is wrong. This guide is for network engineers at ISPs, hosting providers, content networks and large enterprises that run their own BGP edge. It explains how destination-based and source-based RTBH, the BLACKHOLE community and Flowspec work according to the IETF specifications, when to use each, how to build guard rails, how to test and roll back, and what to monitor. For the wider DDoS programme (scrubbing, CDN, application defences) see the DDoS Protection Guide.

Key takeaways

RTBH completes the attack for you, on purpose. Destination-based blackholing drops all traffic to the victim address to save everything else; use it for a single /32 or /128 when the alternative is losing the link.
Flowspec is surgical but runs on router hardware you must protect. RFC 8955 rules match up to 12 packet fields and can discard, rate-limit, mark or redirect; a bad rule or a flood of rules can exhaust router resources.
Never accept triggers you cannot validate. Honour a BLACKHOLE community only for prefixes the neighbour is authorised to announce, and keep Flowspec validation (RFC 8955 as updated by RFC 9117) switched on for external sessions.
Scope every action. Tag blackhole routes NO_EXPORT, keep prefixes as specific as possible, apply Flowspec only where it is needed and set expiry on every rule.
Treat the trigger system as privileged infrastructure. The controller or route injector that can blackhole any prefix is a high-value target and needs the same access controls as your core routers.

The three tools and when to use each

Technique	What it matches	Action	Effect on the victim	Best used when	Main risk
Destination-based RTBH (RFC 5635)	Destination prefix only	Next hop set to a discard address, traffic dropped at the edge	Victim fully offline, rest of network saved	Flood exceeds link or scrubbing capacity; target is a single non-critical address	Completes the denial of service for that address
Source-based RTBH with uRPF (RFC 5635)	Source address via loose-mode uRPF	Drops traffic from listed sources	Victim stays reachable for other sources	A small, stable set of attack sources; botnets that re-resolve DNS to new targets	Drops all traffic to and from listed addresses, including legitimate use; spoofed sources make it useless
Upstream blackholing with BLACKHOLE community (RFC 7999)	Destination prefix announced to a provider or IXP	Provider drops traffic before it reaches your links	Victim offline, your links saved	Your own links are saturated, so local filtering is too late	Over-broad prefixes, propagation beyond the provider
BGP Flowspec (RFC 8955, RFC 8956)	Combinations of prefixes, protocol, ports, ICMP, TCP flags, packet length, DSCP, fragments	Discard, rate-limit, mark DSCP, redirect to VRF	Victim reachable; only matching traffic affected	Attack has a clear signature (for example UDP source port 123 or 11211 reflection)	Router resource exhaustion, over-broad matches, conflicting rules

Decision guidance: start with the most specific action that will work in time. If the attack has a signature and your edge hardware supports Flowspec at line rate, rate-limit or discard the signature. If the links themselves are full, local actions cannot help and you need upstream action: a provider Flowspec service, cloud scrubbing, or upstream blackholing of the target. Blackholing is the last resort that protects the many by sacrificing the one. Small enterprises with one or two transit providers usually rely on their providers' RTBH communities and a scrubbing service rather than running Flowspec themselves; large operators run both and automate the trigger from flow telemetry.

Destination and source RTBH in practice

RFC 5635 (Informational, 2009) describes the classic design. Every edge router carries a static route sending a discard address to the null interface. The documentation examples use 192.0.2.1 from the TEST-NET range. A trigger router, controlled by the operations team, announces the victim's address over iBGP with that discard address as next hop, so every edge router forwards the traffic to null.

Trigger router: a dedicated BGP speaker, not a production edge router, that originates only tagged blackhole routes. RFC 5635's appendix example uses a route tag (666) on the static trigger route.
Source-based variant: when the attacker's source addresses are announced to the discard next hop, loose-mode unicast Reverse Path Forwarding on the edge interfaces drops packets from those sources, on platforms where a route pointing to the discard next hop fails the check. Strict mode is unsuitable on asymmetric paths because it drops legitimate traffic.
Who may trigger: RFC 5635 says operators should not accept source-based RTBH announcements from peers or customers; these should come only from local or attack management systems.
Containment of the route: tag trigger routes NO_EXPORT, reject externally learned announcements of trigger communities except from customers you have agreed this with, and filter long prefixes and trigger communities on egress.

The BLACKHOLE community and upstream blackholing

RFC 7999 (Informational, October 2016) registers the well-known BLACKHOLE community 65535:666 (0xFFFF029A) so a customer can ask a neighbouring network to drop traffic to a prefix. Many providers also publish their own provider-specific blackhole communities; check each provider's documentation for which they honour.

RFC 7999 rule	What it means operationally
Both parties must agree to use the community on the session	Document it in the peering or transit agreement; do not honour it by default on every session
Honour only if the prefix is covered by an equal or shorter prefix the neighbour is authorised to announce	Your prefix filters (IRR, RPKI) must be in place before you accept blackhole more-specifics
Receiver should add NO_ADVERTISE or NO_EXPORT	The blackhole must not leak beyond the receiving network
Prefixes should be as specific as possible, typically /32 or /128	Accept longer prefixes than your normal /24 or /48 limit only when tagged BLACKHOLE, and only from that customer
Origin validation must not block legitimate BLACKHOLE announcements	Where a ROA's maximum length would invalidate a /32, check how your route origin validation policy interacts with blackhole routes
Vendors should not discard traffic unless the operator configures it	Receiving the community does nothing until your policy maps it to a discard next hop
Log BLACKHOLE updates	Keep an audit trail of who blackholed what, when

For the routing security foundations these rules depend on, including prefix filtering and RPKI, see the BGP and Routing Security Guide.

How Flowspec works

RFC 8955 (Standards Track, December 2020, obsoleting RFC 5575 and RFC 7674) defines Flowspec for IPv4 as AFI 1, SAFI 133 (SAFI 134 for VPNv4). RFC 8956 (December 2020) adds IPv6 as AFI 2, SAFI 133 (134 for L3VPN), a Flow Label component (type 13) and prefix offsets. A packet matches a rule only if it matches every component present.

Match components (RFC 8955)

Type	Component	Typical DDoS use
1	Destination Prefix	The victim address; always include it
2	Source Prefix	Known attacking ranges, rarely useful against spoofed floods
3	IP Protocol	UDP (17) for reflection floods
4, 5, 6	Port, Destination Port, Source Port	Reflection source ports such as 53, 123, 389, 1900, 11211
7, 8	ICMP Type and Code	ICMP floods
9	TCP Flags	SYN or ACK floods
10	Packet Length	Amplified responses of a known size
11	DSCP	Rarely used for mitigation
12	Fragment	Fragment floods; drop non-initial fragments to the victim

Actions

traffic-rate-bytes (0x8006) and traffic-rate-packets (0x800c): rate-limit; a rate of 0 discards. Prefer a rate limit over a discard where legitimate traffic shares the signature, such as DNS responses to a resolver.
traffic-action (0x8007): terminal and sample bits, controlling whether further rules are evaluated and whether traffic is sampled.
rt-redirect (0x8008, 0x8108, 0x8208), and rt-redirect-ipv6 in RFC 8956: send matching traffic into a VRF, typically towards a scrubbing appliance; useful for diversion without full blackholing.
traffic-marking (0x8009): rewrite DSCP so downstream queues deprioritise attack traffic.

Validation

Under RFC 8955 a rule learned from another AS is valid only if it carries a destination prefix, its originator matches the best-match unicast route for that prefix, and no more-specific unicast route for that prefix comes from a different neighbouring AS. RFC 9117 (Standards Track, August 2021) relaxes the originator check so a central controller inside your own domain can originate rules (empty AS_PATH or confederation-only segments pass by default), and allows exchange through route servers by comparing the left-most AS with the best unicast route. RFC 9117 warns that accepting rules from route servers weakens security. Both RFCs state that relaxing validation or accepting actions from untrusted parties can lead to unwanted filtering, remarking or redirection.

Guard rails that prevent self-inflicted outages

The best-known Flowspec failure is public. In March 2013 Cloudflare pushed a Flowspec rule to drop DNS packets between 99,971 and 99,985 bytes long, a length no real packet could have. Its edge routers consumed their memory processing the rule and crashed across all of its data centres, with service restored about an hour later, according to Cloudflare's post-mortem. Its stated lessons were more testing of Flowspec rules and applying rules only where they are needed. That incident, and the warnings in the RFCs, lead to these guard rails.

Policy on the receiver, not just the sender: on edge routers, limit the number of Flowspec rules accepted per session (a maximum-prefix limit for the Flowspec address family), reject rules without a destination prefix inside your own address space, and reject actions you do not use (for example redirect, if you do not run a scrubbing VRF).
Controller-side sanity checks: reject rules whose destination is broader than a set length (for example shorter than /24 IPv4 or /48 IPv6), rules that match your own infrastructure or management ranges, rules with impossible values (packet length above your maximum MTU), and any rule that would match routing protocol traffic such as TCP 179.
Allow lists of protected ranges: never blackhole or Flowspec-drop DNS anycast, BGP peering addresses, or management networks; keep the list in the controller.
Expiry by default: every blackhole and Flowspec rule gets a time to live (for example 30 to 120 minutes) and is withdrawn automatically unless renewed by a human or by detection that still sees the attack.
Staged scope: apply new rule types to one site or router first; use communities to steer rules only to the routers that face the attack.
Hardware awareness: know the filter capacity (TCAM entries) and supported components and actions per line card; not every platform implements every component at line rate.
Fast rollback: one command or API call that withdraws all controller-originated rules, documented in the runbook and practised.

Securing the trigger system

Whoever controls the RTBH trigger router or Flowspec controller can make any prefix in your network disappear. Treat it as privileged infrastructure.

Access: named accounts with phishing-resistant MFA, through PAM with session recording; no shared logins. See the Privileged Access Management Guide.
Automation identities: detection platforms that trigger mitigations automatically use API credentials or BGP sessions; scope them so automation can only act on customer ranges, and alert on every automated action. These are non-human identities with outsized power.
Customer self-service: where customers can trigger blackholes through a portal or BGP community, authorise against their assigned prefixes only, and log every request.
BGP session protection: RFC 7999 recommends the session protections of RFC 7454, such as TTL security and authentication, for sessions that carry blackhole routes.

Testing, rollout and rollback

Lab: build the trigger router, discard routes and Flowspec policy in a lab with the same router software; test each rule type and the receiver limits.
Dry run in production: announce a rule for an unused test address in your own space and confirm, through flow telemetry, that only that address is affected.
Pilot site: enable Flowspec acceptance on one site's edge routers; keep others on RTBH only until the pilot has handled a real event.
Runbook and roles: who may trigger, who approves, how to verify impact, how to withdraw; link it to the DDoS Response Playbook.
Exercise: rehearse at least twice a year, including the withdrawal of all rules.
Rollback: withdraw from the controller; if the controller is unreachable, shut the Flowspec sessions on edge routers, which removes their rules.

Detection and measurement

Telemetry: NetFlow or IPFIX and interface counters on all edge links, with per-prefix baselines, feed the decision to trigger.
Route audit: log every blackhole and Flowspec announcement and withdrawal with operator or automation identity, reason and ticket.
Router health: alert on memory, CPU and filter resource usage on edge routers whenever Flowspec rules change.
Customer impact: correlate blackholed addresses with service monitoring so you know which service you have taken offline.

Metrics:

Time to mitigate: minutes from attack detection to effective rule.
Precision: share of mitigations done with Flowspec or scrubbing rather than full blackholing.
Rule hygiene: number of active rules older than their intended expiry (target zero).
Collateral events: incidents where a mitigation affected traffic it was not meant to (target zero).
Exercise success: time to withdraw all rules in the last drill.

Framework mapping

Area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	MITRE ATT&CK (threat addressed)
DDoS mitigation capability	SC-5 Denial-of-service Protection, SC-7 Boundary Protection	PR.IR-04	T1498 Network Denial of Service, T1498.001, T1498.002
Rule change control and testing	CM-3 Configuration Change Control, CM-4 Impact Analyses	PR.PS-01	n/a
Traffic monitoring and triggers	SI-4 System Monitoring	DE.CM-01	T1498
Response and containment	IR-4 Incident Handling, CP-2 Contingency Plan	RS.MI-01	T1498, T1499

NIST SP 800-189 covers RTBH and Flowspec alongside route origin validation and source address validation; Revision 1 was released as an initial public draft on 3 January 2025 (comment period closed), so check its status before citing it as final guidance.

Common failure patterns

Unbounded Flowspec acceptance: edge routers accept any number of rules and any action, so one bad controller push becomes a network-wide outage, as Cloudflare experienced in 2013.
Blackholing the wrong prefix length: a /24 blackholed instead of a /32 takes 255 neighbours offline with the target.
Forgotten rules: mitigations left in place for months, silently breaking a customer's service.
Accepting BLACKHOLE from any neighbour: without prefix authorisation checks a peer can blackhole someone else's address space.
Source RTBH against spoofed floods: blackholing random source addresses has no effect on the attack and harms innocent hosts.
Weak trigger access: a shared login on the trigger router, or automation credentials with no scope, give one compromise the power to disconnect customers.

Practitioner checklist

Deploy discard routes and a dedicated trigger router; tag all trigger routes NO_EXPORT.
Agree BLACKHOLE community use per session and honour it only for authorised prefixes, /32 or /128 by preference.
Keep RFC 8955 and RFC 9117 validation on for external Flowspec sessions; reject rules from route servers unless you accept the weaker security.
Set per-session Flowspec rule limits and reject unused actions on edge routers.
Add controller sanity checks, protected range allow lists and default expiry to every rule.
Know the Flowspec component and filter capacity of each router platform.
Put trigger systems behind PAM and scope automation credentials to customer ranges.
Log every announcement and withdrawal with identity and reason.
Rehearse triggering and withdrawing all rules twice a year.

Standards and references

Related NHI Mgmt Group resources: DDoS Protection Guide · BGP and Routing Security Guide · DDoS Response Playbook · DDoS Protection Buyer's Guide

RTBH and BGP Flowspec DDoS Mitigation Guide: Using Blackholing and Flowspec Without Self-Inflicted Outages