Blackhole Routing vs. Edge Scrubbing | DDoS Mitigation Compared

When a volumetric DDoS attack hits its target, the connectivity provider often offers a “solution”: blackhole routing. In March 2013, the attack against Spamhaus generated reported peaks near 300 Gbps, based on DNS reflection and amplification. Applying blackhole routing to the attacked IP does not necessarily stop the attack: it discards, at the operator’s network edge, both the malicious traffic and the legitimate traffic destined to the target. While it protects adjacent infrastructure from saturation, it temporarily sacrifices service availability and may produce exactly the denial-of-service effect the attacker intended.

Blackhole routing (or null routing) is a network engineering technique that discards all traffic destined for a specific IP address by redirecting it to a null interface. Attack traffic is eliminated — but so is all legitimate traffic. Scrubbing, on the other hand, is the process of selectively inspecting and filtering traffic, discarding only malicious packets and forwarding legitimate ones to their destination.

How blackhole routing works — RTBH and RFC 7999

Blackhole routing operates via BGP (RFC 4271). The most widely used mechanism is RTBH (Remotely Triggered Black Hole), standardized by RFC 5635, which allows triggering the discard on multiple remote routers through a BGP signaling session.

Operationally, the flow proceeds as follows:

1. The operator detects a volumetric attack targeting IP 192.0.2.10/32.
2. A trigger router announces via iBGP the route 192.0.2.10/32 with the next-hop set to 192.0.2.1 (an address reserved as the blackhole trigger).
3. Edge routers, upon receiving this announcement, consult their static table and redirect the prefix to the null0 interface.
4. All traffic destined to the victim’s IP is dropped at the operator’s network edges.

RFC 7999 standardized the BGP well-known community BLACKHOLE (65535:666) to signal blackhole routes in an interoperable manner between autonomous systems. When an organization announces a prefix with this community to its upstream provider, the prefix is dropped throughout the provider’s network. The attributes NO_ADVERTISE and NO_EXPORT are frequently combined to limit announcement propagation:

• NO_ADVERTISE (community 0xFFFFFF02): prevents the receiving router from propagating the announcement to any peer.
• NO_EXPORT (community 0xFFFFFF01): prevents propagation to eBGP peers outside the confederation, containing the blackhole within the receiving AS.

The availability outcome is unambiguous: blackhole activates in seconds and protects upstream infrastructure (ISP links and routers) from saturation. But from a business perspective, the effect is identical to the attack: total unavailability.

When blackhole routing is used

Despite its limitations, blackholing has valid use cases:

• Shared infrastructure protection: When an attack threatens to impact other ISP customers beyond the victim, blackhole isolates the problem and protects shared link capacity.
• Sacrificed IP: When the attacked IP is secondary and the main service can be maintained via other IPs or prefixes.
• Emergency temporary measure: As a first-aid response while a scrubbing solution is activated and propagated.
• Non-critical IP under attack: When the attacked IP is not required for operational service continuity.

BGP FlowSpec — granular filtering in the control plane

BGP FlowSpec, originally defined by RFC 5575 and updated by RFC 8955, represents a significant evolution over RTBH: instead of discarding all traffic for a prefix, it allows creating granular ACL rules distributed via the BGP control plane.

FlowSpec operates through match tuples combined with actions via extended communities:

Match fields:

• Source and destination IP address (prefix)
• Transport protocol (TCP, UDP, ICMP)
• Source and destination ports (ranges and lists)
• TCP flags (SYN, ACK, RST, FIN)
• Packet size (range)
• DSCP value (QoS marking)
• Packet fragmentation

Actions (via extended communities):

• traffic-rate:AS:rate — discards (rate=0) or limits forwarding rate in bits/s
• traffic-action — marks or redirects for analysis (mirroring)
• redirect:VRF — diverts matching traffic to a dedicated scrubbing VRF
• redirect-to-NH — redirects to a specific next-hop (scrubbing center)

FlowSpec rule example:

A rule that drops UDP packets with destination port 53, size between 60 and 80 bytes, and destination IP 198.51.100.0/24 — a DNS amplification pattern — would be distributed to all edge routers via BGP without manual intervention on each device.

FlowSpec positions itself as an intermediate technique between total blackhole and the scrubbing center:

• More granular than RTBH: allows dropping only malicious traffic while preserving legitimate traffic.
• Simpler than a scrubbing center: operates in the BGP control plane without requiring traffic diversion to dedicated infrastructure.
• Has limitations: does not inspect Layer 7 content and does not scale well for highly dynamic or high-cardinality rules.

How centralized scrubbing works

Centralized scrubbing diverts traffic to a dedicated cleaning center where it is inspected across multiple layers. The process occurs in four steps:

1. During an attack, the operator announces via BGP that the affected prefix should be routed to the scrubbing center (typically via a provider-specific BGP community).
2. Traffic from the entire internet is redirected to the scrubbing center, where it undergoes Layer 3 and 4 inspection (IP, port, protocol filtering) and Layer 7 inspection (HTTP behavioral analysis, rate limiting, signature detection).
3. Clean traffic is forwarded back to the origin server via GRE or MPLS tunnel.
4. When the attack subsides, the operator reverts the BGP announcement and traffic returns to the normal path.

Limitations of centralized scrubbing — hairpin and L7 attacks

The centralized scrubbing center model has two critical structural problems.

Hairpin latency: Traffic from a user in São Paulo to a server in São Paulo may be diverted to a scrubbing center in Miami or Amsterdam, increasing latency by 50–150ms.

Layer 7 attacks and cryptographic exhaustion: Traditional scrubbing centers primarily operate at Layers 3 and 4. HTTP Flood, Slowloris, and R.U.D.Y. attacks use syntactically valid HTTP requests at low volume — invisible to L3/L4 filtering.

Even more critical: TLS/SSL handshake exhaustion attacks like THC-SSL-DoS exploit the computational asymmetry of the TLS protocol, where establishing a TLS session costs approximately 15 times more CPU on the server than on the client. An attacker with modest hardware can initiate mass renegotiations and saturate the origin server’s cryptographic capacity before saturating the network. A scrubbing center that does not perform TLS termination passes these connections to the origin server uninspected, leaving it vulnerable.

Distributed edge scrubbing

The most modern model eliminates hairpin and resolves L7 and TLS limitations: instead of diverting traffic to a centralized scrubbing center, scrubbing happens at each data center in the distribution network, close to the attack source.

The protection flow with distributed scrubbing works as follows:

1. Attack traffic originating in Europe reaches the nearest European edge data center via Anycast routing.
2. The European data center applies L3/L4 inspection (volumetric), L7 inspection (HTTP behavior), and inspects connections after TLS termination.
3. Only traffic that passes all inspection layers is forwarded to the origin server.
4. The same process occurs simultaneously in US, APAC, and other regional data centers for traffic generated in those locations.
5. The origin server receives exclusively complete, valid, and inspected requests — regardless of attack scale.

The benefits are structural:

• Attack traffic filtered close to the source, reducing load transported across the network.
• Legitimate users experience no route detour and maintain their original latency.
• TLS termination at the edge enables Layer 7 inspection over decrypted traffic, without exposing the origin server to cryptographic processing load.

Edge TLS Termination and protection against cryptographic exhaustion

TLS termination at the edge specifically resolves the cryptographic exhaustion vector. The process works as follows:

1. TLS connections from clients are terminated at edge data centers, which operate hardware with dedicated cryptographic acceleration (AES-NI, Intel QAT).
2. After the TLS handshake is completed at the edge, the HTTP request is decrypted and submitted to real-time WAF inspection and behavioral analysis.
3. Only approved requests are forwarded to the origin server — on a separate connection that may be plain HTTP or TLS with an already-established handshake.
4. The origin server never processes TLS handshakes from external clients, completely eliminating the cryptographic exhaustion vector.

Comparative matrix of the four architectures

The collateral damage problem of blackhole

A frequently overlooked aspect: when an ISP applies blackhole routing, the victim’s IP may be announced as a “black hole” across multiple BGP routers. This can cause:

• Reputation damage: IP reputation systems record the IP as problematic, affecting email delivery and CDN trust.
• Impact on related services: Other services on the same /24 block may be affected by subnet-based filters.
• Slow removal: Withdrawing the blackhole can take hours to propagate via BGP depending on network topology and peer timers.

Signs that blackhole was applied to your IP

Common mistakes and solutions

Mistake: Accepting blackhole as an ISP “mitigation solution” without questioning alternatives. Solution: Demand scrubbing SLAs with legitimate traffic preservation. Blackhole protects the ISP’s infrastructure — it is not a solution for the victim’s business.

Mistake: Implementing centralized scrubbing without considering latency impact. Solution: Evaluate your users’ geographic distribution. If they are globally distributed, a single scrubbing center introduces unacceptable hairpin. Prefer distributed scrubbing or FlowSpec for simple L3/L4 attacks.

Mistake: Automatically activating blackhole as the first response to any attack. Solution: Reserve blackhole for situations where upstream infrastructure is at immediate saturation risk. Use scrubbing or FlowSpec as the default response to preserve availability.

Mistake: Assuming centralized scrubbing resolves Layer 7 attacks and TLS exhaustion. Solution: L3/L4 scrubbing is effective against volumetric attacks. L7 attacks like HTTP Flood, Slowloris, and TLS handshake exhaustion require edge TLS termination and integrated Layer 7 inspection.

Frequently asked questions

What is the BGP BLACKHOLE community (65535:666) and how is it used? Community 65535:666, standardized by RFC 7999, is a BGP well-known community that signals to the receiver that the announced prefix should be blackholed. To use it, the organization announces the attacked prefix with this community to its upstream provider(s). Provider routers that recognize the community drop the traffic before forwarding it to the victim’s network. It is more interoperable than proprietary solutions, as it is recognized by equipment from multiple vendors and ISPs.

What is the difference between RTBH (RFC 5635) and BGP FlowSpec (RFC 8955)? RTBH drops all traffic for a /32 IP prefix (host-route) without distinction of protocol, port, or behavior — it is binary: everything or nothing. FlowSpec allows creating granular rules with multiple match fields (IP, port, protocol, packet size, TCP flags, DSCP) and different actions (discard, rate limiting, redirect to VRF). FlowSpec is distributed via BGP like RTBH, but acts as a remote ACL, allowing protection of legitimate traffic while dropping only malicious patterns.

Can blackhole routing be partial — only for certain traffic types? Traditional BGP blackhole via RTBH drops all traffic for the IP. The D/RTBH (Destination-based RTBH) variation allows filtering by attacker source prefix, but requires intelligence about the attack IPs. For filtering by protocol, port, or behavior, BGP FlowSpec is needed — which provides that granularity while maintaining BGP control plane distribution.

Does centralized scrubbing still make sense in 2026? Yes, in specific scenarios: when the scrubbing center is geographically close to users, when the attack is exclusively volumetric L3/L4, and when the organization doesn’t have access to a distributed edge network. For modern multi-vector attacks combining volumetric flood with HTTP Flood, TLS exhaustion, and Slowloris, the distributed edge model is superior because it operates across all layers simultaneously.

Why do Slowloris and R.U.D.Y. attacks pass through traditional scrubbing centers undetected? Low and slow attacks like Slowloris and R.U.D.Y. use syntactically valid HTTP connections transmitted at extremely slow rates. From a network volume perspective (packets per second, bits per second), they are invisible to L3/L4 filters. Detection requires Layer 7 inspection with behavioral analysis: open connections per IP, request completion rate, header transmission time, and client fingerprinting (JA3/JA4). This is only possible after TLS termination and with L7 analysis capability at the inspection point.

Can a scrubbing center be overwhelmed? Yes. Attacks above a provider’s scrubbing capacity can saturate the scrubbing center’s own inbound links. Providers with distributed scrubbing have greater total aggregate capacity because they distribute load across dozens of data centers. A 1 Tbps attack that would saturate a single 500 Gbps scrubbing center is diluted across 20 data centers of 100 Gbps each without saturating any of them individually.

How to implement on Azion

Azion operates an always-on distributed scrubbing model that addresses all vectors discussed in this article:

1. Edge scrubbing with a global Anycast network: Traffic is inspected at each of Azion’s 100+ data centers, close to the attack source. Anycast routing ensures legitimate users experience no route detour and no latency increase — inspection occurs on the same path traffic would normally take.
2. Always-on DDoS Protection: No manual activation, BGP redirection, or route announcement adjustment required during the attack. Protection is always active, with automatic mitigation starting in seconds for volumetric L3/L4 attacks.
3. Edge TLS Termination with L7 inspection: TLS connections are terminated at Azion’s data centers, which use hardware with cryptographic acceleration. The origin server never processes TLS handshakes from external clients, eliminating the cryptographic exhaustion vector (THC-SSL-DoS and similar). Over decrypted traffic, the integrated WAF applies real-time Layer 7 inspection, detecting HTTP Flood, Slowloris, R.U.D.Y., and other low and slow attacks.
4. No forced blackhole: Azion does not apply blackhole routing to customer IPs as a default response. The goal is to keep the service available during the attack, not just protect network infrastructure. The policy is to filter malicious traffic and forward legitimate traffic to its destination — regardless of attack scale.

Learn more in the Azion DDoS Protection documentation.