DDoS scrubbing with BGP: how routing-level mitigation works for operators
DDoS attacks remain one of the most frequent disruption vectors for ISPs and critical infrastructure in Latin America. Many operators’ instinctive response is to look for appliances or cloud scrubbing services, but the reality is that the first effective line of defense runs through BGP — the same protocol that moves internet traffic can also be used to divert, filter, and block attacks before they saturate customer links.
RIPE Labs published an analysis in April 2026 of the world’s five major scrubbers as seen from BGP routing data. The patterns that analysis reveals are something LATAM operators should understand: the differences between always-on and on-demand mitigation are not just operational — they have direct implications for RPKI visibility and for how an attack is (or isn’t) seen from outside your network.
The problem BGP solves
When a volumetric attack arrives — 50 Gbps of UDP flood, for example — the problem isn’t just that the destination server can’t process it. The problem is that the traffic has already consumed the link before reaching the destination. If the customer’s uplink is 1 Gbps and the attack reaches 10 Gbps, the 9 Gbps of excess is saturating your distribution network and affecting other customers.
The only way to solve this is to act higher up in the topology: divert or block attack traffic before it enters the congested segments. BGP is the natural mechanism for this because it allows you to signal to neighboring routers to treat a prefix in a specific way.
The three main techniques are RTBH, BGP Flowspec, and diversion-based scrubbing (sink-then-reinject).
Technique 1: RTBH — Remote Triggered Black Hole
RTBH (Remotely Triggered Black Hole, RFC 5635) is the simplest and most widely implemented technique. The principle is straightforward: when a prefix is under attack, a route toward it is announced with a special community that tells upstream routers to discard that traffic instead of forwarding it.
How it works in practice
Most upstreams have documented BGP communities for RTBH. For example, in the classic format:
64496:666 → blackhole the destination prefix (destination-based RTBH)
64496:9999 → blackhole the source prefix (source-based RTBH)
When you announce the attacked prefix with that community, the upstream discards traffic toward that destination at its border routers — before it enters your network.
Destination-based RTBH blocks all traffic toward the attacked IP or prefix. It’s effective but also blocks legitimate traffic: the customer stops receiving attacks but also stops receiving service. For short attacks or when the customer is willing to temporarily sacrifice availability, it’s the fastest response.
Source-based RTBH is more surgical: it blocks traffic originating from specific IPs or prefixes known to be attack sources. It requires that you’ve identified the sources (which in amplified attacks can be thousands of legitimate reflectors) and that your upstream supports this variant.
Basic configuration on IOS-XR
route-policy RTBH-TRIGGER
set community (64496:666) additive
set local-preference 50
set next-hop 192.0.2.1 # null route address
pass
end-policy
router bgp 65000
neighbor 203.0.113.1
address-family ipv4 unicast
route-policy RTBH-TRIGGER out
What this example does: when an operator wants to activate RTBH for a prefix, they manually add a static route toward 192.0.2.1 (the null route address), which is redistributed into BGP with the blackhole community. The upstream receives the route with that community and discards the traffic.
Technique 2: BGP Flowspec
BGP Flowspec (RFC 5575 / RFC 8955) is a BGP protocol extension that allows distributing detailed traffic filtering rules as if they were routes. Unlike RTBH (which works only with source/destination prefixes), Flowspec can filter by combining:
- Source and destination IP
- Source and destination port
- Protocol (TCP, UDP, ICMP)
- TCP flags
- DSCP
- Packet length
- Fragmentation
A real-world case: filtering DNS amplification
A DNS amplification attack uses open DNS servers to amplify traffic toward the target. The attack traffic has very specific characteristics: UDP, source port 53, large response packets (>512 bytes). Flowspec can filter exactly that without blocking legitimate traffic to the same destination:
ip flowspec address-family ipv4 unicast
match destination-prefix 192.0.2.100/32
match source-port 53
match ip protocol 17 # UDP
match packet-length 512-65535
action drop
This rule is distributed via BGP to all routers that support it and have Flowspec enabled. On your own network or with an upstream that supports it, this can be activated in seconds and block the malicious component of the attack without discarding the entire service.
Flowspec limitations
Flowspec is not universally supported. Major tier-1 and tier-2 upstreams have variable support — some offer it as an additional service, others simply don’t have it available. In practice, Flowspec is more useful within the ISP’s own network than as a tool for signaling toward upstreams.
Another challenge: operational complexity. Misconfigured Flowspec rules can block legitimate traffic very easily. They require a careful activation and validation process.
Technique 3: Diversion-based scrubbing (sink-then-reinject)
This is the architecture used by professional scrubbing services (Cloudflare, NETSCOUT, Radware, etc.) and that larger ISPs implement internally. The concept: instead of discarding attacked traffic, it’s diverted to a scrubbing center where it’s filtered, and the legitimate traffic is reinjected toward the real destination.
The mitigation flow
- The attack is detected (by volume anomalies, traffic type, or manual alerts)
- The border router announces the attacked prefix with a more specific route that diverts it to the scrubbing center
- The scrubbing center receives all the traffic (attack + legitimate)
- It applies analysis and filters: stateful inspection, rate limiting, pattern matching, challenge-response for HTTP
- Clean traffic is reinjected toward the destination via a GRE tunnel, MPLS, or VPN
How this looks in BGP
From outside the network, diversion-based scrubbing looks like a route change: the attacked prefix starts being announced from a different address (the scrubbing center). If scrubbing is always-on, that route exists permanently. If it’s on-demand, the route appears when mitigation is activated.
Here’s where the RPKI implication mentioned in the RIPE Labs analysis comes in: if the scrubbing center is in a different ASN than the legitimate prefix owner, the prefix’s ROA may not cover that ASN. An external observer with active RPKI would see the announcement of the prefix from the scrubbing center as RPKI Invalid — which can cause some peers with strict validation to discard those routes.
The correct solution is for the scrubbing center to announce the prefix using the customer’s ASN (through direct transit) or for the customer to create an additional ROA authorizing the scrubbing center’s ASN as a valid origin. Operators deploying third-party scrubbing with active RPKI need to coordinate this explicitly.
Always-on vs on-demand: what to choose
| Criterion | Always-on | On-demand |
|---|---|---|
| Activation latency | Instantaneous | Minutes (manual) or seconds (automatic) |
| Traffic cost | High (everything goes through scrubbing) | Low (only traffic under attack) |
| BGP visibility | Stable, always from scrubber | Changes during activation |
| RPKI risk | Requires coordinated ROA from the start | Risk during transition |
| Suitable for | Critical customers, low tolerance threshold | Most ISP customers |
For most mid-sized LATAM ISPs, the recommended architecture is on-demand with automatic activation: a detection system (NetFlow + SNMP or a dedicated solution like NETSCOUT/NSFOCUS) triggers the BGP diversion automatically when an anomalous traffic threshold is exceeded, without requiring manual intervention.
The minimum viable setup for a LATAM ISP
If you’re starting from scratch, the defense stack by priority:
Level 1 — RTBH with upstream (1-2 weeks to implement)
- Document the RTBH communities for each upstream
- Create the operational process for activating blackhole manually
- Integrate with the NOC: who authorizes, how to activate, how to deactivate
Level 2 — Automatic RTBH (1 month)
- Add per-prefix volume monitoring (NetFlow)
- Script for automatic RTBH activation when a prefix exceeds a threshold
- Alerts and event logging
Level 3 — Internal Flowspec (3-6 months)
- Validate support on the router platform
- Develop mitigation playbooks by attack type
- Integrate with ticketing/NOC system
Level 4 — Dedicated scrubbing (if scale justifies it)
- Evaluate own solution vs cloud service
- Coordinate ROAs with scrubbing ASN if applicable
- Implement GRE/VPN for clean traffic reinsertion
RPKI and scrubbing: the verification checklist
If your network has active RPKI and you’re implementing or already have scrubbing, verify:
- Does the scrubbing center use your same ASN or a different one?
- Do your ROAs cover the prefixes being diverted to scrubbing?
- If the scrubbing center has its own ASN, have you created a ROA with appropriate max-length authorizing it?
- Will your peers with strict RPKI validation see the announcement as Valid or Invalid during mitigation?
- Do you have a rollback procedure if mitigation introduces an invalid RPKI state?
The interaction between scrubbing and RPKI is one of the areas where configuration errors most often occur silently — scrubbing works but introduces an invalid validation that can affect prefix reachability from networks with a policy of rejecting RPKI Invalid routes.
Does your network have active RPKI but you’ve never coordinated validation with your scrubbing provider? Write to us at [email protected] — we perform BGP/RPKI configuration audits and help you close that gap before it becomes a problem during a real incident.