Understanding Network Infrastructure · Part 6 · Keeping connected networks secure and recovering from failures
Where should you block attack traffic to protect services?
Using RTBH, uRPF, sinkholes, and FlowSpec to control attack traffic at the right upstream boundary
Once attack traffic has filled an Internet circuit, dropping it at an internal firewall does not make room for legitimate traffic to get in. RTBH and BGP FlowSpec reduce attack traffic at upstream routers; a sinkhole directs suspicious traffic to an observation point. We compare their blocking scope, impact on legitimate services, risks with asymmetric paths, and safe withdrawal procedures.
Dropping attack packets at a firewall does not free a saturated Internet circuit↑
A firewall can protect a server, and a router in front of it can also reduce internal resource use by dropping attack packets. But if that traffic has already crossed the Internet circuit, it has already consumed the circuit's queues and bandwidth. Legitimate traffic is lost at the same bottleneck.
Choose the response point by asking 'Where is traffic saturating capacity?' before focusing on the device you want to protect. If your own edge lacks headroom, agree in advance on upstream mitigation with your ISP or DDoS scrubbing provider.
A 2 Gbps UDP flood aimed at a 1 Gbps Internet circuit saturates ingress even if the firewall drops every attack packet it receives. Legitimate HTTPS packets may be lost before reaching the firewall, in an ISP queue. Low firewall CPU use does not prove successful mitigation. Check interface utilization ahead of the bottleneck, drops, and legitimate transaction success together.
Upstream mitigation requires agreement on where the ISP accepts your prefixes and which communities and FlowSpec functions it supports. It is too late to find contacts and negotiate prefix filters after an attack begins. Record each service's acceptable full-block duration in the runbook. For scrubbing, specify the DNS, BGP, and tunnel changes needed, and who may withdraw the mitigation. Choose a blocking point where the action can take effect before attack traffic consumes the shared bottleneck—not just by device performance.
Upstream blocking requires cooperation among organizations that operate different networks. When a customer edge advertises a community, confirm through the contract and testing how the ISP matches it, where it acts, and how far it propagates. Compare time-aligned firewall drop counters, interface utilization, and ISP measurements to determine whether blocking protected only the server or also freed circuit capacity.
Sources for this section IETF RFC 3882
Destination RTBH drops all traffic to the targeted IP address upstream↑
With remotely triggered black holing (RTBH), a trigger router attaches a designated community or similar marker to a host route or prefix and advertises it through BGP. Receiving edge routers apply policy to use a discard address that resolves to a null interface as the next hop. Destination-based RTBH drops all traffic to the targeted address at that boundary.
This is quick and simple, but it does not distinguish attack packets from legitimate packets. It effectively sacrifices the targeted service temporarily to protect other prefixes and infrastructure. Strictly limit permitted prefix lengths, communities, receiving peers, expiration, and withdrawal authority to contain mistakes.
For the targeted 203.0.113.20/32, an operator can attach an agreed blackhole community and inject the route through the trigger router. Edge or upstream policy matches that community, sets the next hop to an address that resolves to a null interface, and drops traffic for the /32. It takes precedence over the broader 203.0.113.0/24 route through longest prefix match, allowing the other addresses to remain in service.
The policy may not take effect at the intended upstream point if the upstream provider does not accept a prefix length such as /32 or does not apply the blocking policy associated with the community at the agreed upstream point. Do not advertise blackhole routes beyond the agreed scope. Dropping a /32 can also have a substantial impact on users if the targeted IP address serves anycast or multiple services. Limit the permitted prefixes, maximum prefix length, communities, receiving sessions, and duration through policy, and use operational automation to manage the expiration and withdrawal of the route. After withdrawal, verify that both the null entry in the FIB and the upstream advertisement have disappeared.
Because this also blocks legitimate traffic to the target IP, prefix-length filters are critical. A provider should not accept arbitrary customer prefixes or a default route for RTBH; restrict requests to registered ranges and approved minimum and maximum lengths. Include advertisement lifetime, withdrawal checks, route collectors, and actual drop counters in the runbook. Verify propagation scope with a prearranged test address.
Sources for this section IETF RFC 3882
What to look for ISP A, B, and C have agreed to accept the attacked prefix. Each checks its own policy before dropping packets for that destination through Null0. Receiving a community does not, by itself, block traffic. Check where the policy takes effect and whether it also blocks legitimate traffic to the target address.
↔ Scroll horizontally to explore the diagram.
Source RTBH and uRPF can also block legitimate asymmetric traffic↑
Source-based RTBH can combine blackhole routes with unicast reverse path forwarding checks. For selected source prefixes, packets can then be discarded. A router looks up a reverse route to the source address. If the result is a discard route or fails the validation conditions, it drops the packet. Check the device's implementation and configuration to ensure that discard routes are not treated as valid routes.
Strict uRPF can require the best return interface for a source to match the receiving interface. That can block legitimate traffic under asymmetric routing. Loose mode and implementation options have different meanings. These checks help defend against source spoofing and attacks, but test actual path symmetry, multihoming, and the effect of a default route before deployment.
Strict uRPF can check a packet's source against the best reverse route, requiring its interface to match the actual receiving interface. In a multihomed network, a request may arrive through ISP-A while the best return route uses ISP-B. Even a legitimate packet may fail that check. Loose mode checks for any route to the source and is more tolerant of asymmetry, but verify default-route and discard-route handling, which vary by device implementation and configuration.
Source RTBH can mark an attack source prefix with an injected null route, then use uRPF results to drop packets from it. This is less effective against widely spoofed sources or botnets using many real addresses. An incorrectly specified source prefix can also block legitimate traffic from hosts within that prefix. Use NO_EXPORT and filters to keep source-blocking routes from propagating outside the AS. Before deployment, use flow data to check source distribution and symmetry. Distinguish this response from more fundamental anti-spoofing measures such as ingress filtering and provider cooperation.
Loose uRPF focuses on whether a route to the source exists. It tolerates asymmetry better, but offers different filtering strength. Platforms have their own feasible-path, VRF, and default-route options; do not infer behavior from the mode name alone. Measure ingress and return paths for legitimate sources, including failures that change multihoming, anycast, or traffic-engineered paths.
Sources for this section IETF RFC 5635
A sinkhole sends suspicious traffic to an isolated network for analysis instead of dropping it↑
Sinkhole routing changes suspicious traffic's next hop to an analysis network or a restricted collection system. It can reveal incoming sources and protocols, or identify internal hosts trying to reach malicious domains.
A sinkhole cannot absorb unlimited traffic. Redirecting a large attack can make the analysis link and collector the next bottleneck. Set policies for personal information, payload storage, access control, and packet retention. A scrubbing center that returns traffic to the service requires traffic inspection capacity and a return path, unlike a basic sinkhole.
Changing a suspicious destination route's next hop toward a sinkhole collector lets you observe source distribution, protocols, ports, and packet patterns. To identify internal users contacting malicious domains, a DNS sinkhole can instead return a safe destination address and keep connection logs. A routing sinkhole and a DNS sinkhole use different triggers and observation points. Do not confuse them just because they share a name.
Sending a multi-Gbps attack to a collector rated for only 100 Mbps spreads the outage to the analysis network. Limit the evidence collected through sampling, rate limits, and header-only capture. For payload storage, follow policies protecting personal information and the applicable legal requirements. A sinkhole route must not create another loop through a default route back to production: use an isolated VRF and explicit discard boundaries. Include route withdrawal and retention or deletion of collected data in the runbook.
Sending an entire large DDoS attack to a small analyzer overwhelms the sinkhole and collection network. Plan capacity around samples, rate limits, flow telemetry, or just scrubbing results. Captured packets may contain sensitive data. Assign responsibility for access rights, retention periods, legal and privacy procedures, and route withdrawal when analysis ends.
Sources for this section Cisco Performance Routing Security Policies
What to look for For comparison with a sinkhole, the diagram below shows traffic scrubbing. Suspect traffic is diverted to a scrubbing center, and traffic that passes inspection is returned to the service. A sinkhole used for observation and isolation does not inherently provide this return path. Follow the diversion point, scrubbing center, and path back to the service, checking capacity and whether normal service has been restored.
↔ Scroll horizontally to explore the diagram.
BGP FlowSpec distributes blocking rules that match IP, protocol, and port information↑
BGP FlowSpec distributes traffic matches—destination and source prefixes, IP protocols, ports, and TCP flags—along with drop, rate-limit, or redirect actions through BGP. Rather than discard all traffic to a destination prefix as RTBH does, it can target attack flows more narrowly.
That power makes propagation scope and rule validation critical. One wrong port or overly broad prefix match can block legitimate traffic on multiple routers at once. Verify supported matches and actions, rule precedence, redirect destinations, and IPv4/IPv6 differences in advance.
| Method | Primary match | Typical action | Key risk |
|---|---|---|---|
| Destination RTBH | Destination prefix | Discard via null | All target traffic blocked, including legitimate traffic |
| Source RTBH | Source prefix | Discard using uRPF | False positives on asymmetric paths |
| Sinkhole | Prefix and policy | Redirect to analysis network | Collector capacity and data protection |
| FlowSpec | Prefix, protocol, ports, and more | Drop, rate-limit, or redirect | Wide propagation of an incorrect rule |
If an attack targets 203.0.113.20 on UDP port 53, a FlowSpec rule can match the destination /32, UDP, and destination port 53 to rate-limit or drop it. On the same IP, TCP/443 can remain available, reducing collateral impact compared with destination RTBH. However, legitimate DNS traffic using the same UDP/53 is also restricted. Fragmented traffic or attacks spread across ports can make the match narrower or broader than expected.
Before a controller's rule reaches a router's hardware, validate the permitted prefixes, ports, actions, and rule precedence. Redirect-to-VRF and rate-action support may vary by vendor and line card, and FIB/TCAM resources are finite. Separate propagation through route reflectors from eBGP propagation; keep one customer's rules from affecting another customer's prefixes. Before deployment, use packet samples or a test network to check whether legitimate traffic matches, then deploy in stages within a limited scope.
Check the FlowSpec families, validation, actions, and precedence supported by receiving devices and providers. The controller should accept rules only from approved sources, restrict prefix and port ranges, and check expected matches and conflicting rules before deployment. Give each rule an owner, justification, expiration time, and automatic withdrawal conditions. Monitor actual matches through data-plane counters.
Sources for this section IETF RFC 8955 · IETF RFC 8956
Set blocking authority, scope, and withdrawal procedures before an attack↑
Scenario: One public IP address is under a high-volume UDP attack that saturates the external circuit.
- Identify the bottleneck link, attack destination and source distribution, protocols, ports, and the proportion of legitimate traffic.
- Assess whether an interruption of the targeted service is acceptable and how the response would affect other services, then choose the appropriate level of RTBH, FlowSpec, or scrubbing.
- Check advertised prefix lengths, communities, enforcement routers, and upstream acceptance against the preapproved list.
- Have a second operator review the match and expected impact before deploying within a limited scope.
- Watch interface rates, drop counters, and legitimate transactions together to confirm that blocking is ahead of the bottleneck.
- Remove rules through automatic expiration or a clear withdrawal procedure. Record the timeline and false-positive scope afterward.
The runbook should identify who requests, approves, applies, and withdraws a trigger, and which prefixes, communities, and FlowSpec matches are permitted. During an attack, capture the destination, protocol, ports, ingress points, peak rate, and legitimate-traffic baseline. Use these to choose the least disruptive option: complete blocking with RTBH, selective filtering with FlowSpec, or redirection through scrubbing. Automated accounts also need limits on prefix scope and maximum rule count.
After deployment, check together whether the upstream interface toward the protected circuit carries less traffic, drop counters rise at the expected point, and health checks for services not targeted by the block still succeed. If not, blocking may be after the bottleneck, or the upstream may not have accepted the route. Once attack-end criteria are met, withdraw rules in the planned order and check for residual entries in BGP, the FIB, and hardware filters. The post-incident review should record false positives, application and withdrawal times, and improvements to automation.
Verify withdrawal as carefully as deployment. Confirm that the BGP route or FlowSpec rule has disappeared from every enforcement point, and that normal routes and services have returned. Record the timeline from detection to full recovery.
Sources for this section IETF RFC 3882 · IETF RFC 5635 · IETF RFC 8955
Glossary↑
Sources and verification
- IETF RFC 3882 — Operational techniques for blocking DoS traffic with BGP
- IETF RFC 5635 — Remotely triggered black hole filtering with uRPF
- IETF RFC 8955 — IPv4 BGP Flow Specification
- IETF RFC 8956 — IPv6 BGP Flow Specification
- Cisco Performance Routing Security Policies — Implementation differences between blackhole and sinkhole routing, including analysis paths
RTBH communities, FlowSpec validation, supported actions, and rule precedence vary by provider and platform. Before deployment, agree with the ISP on the procedure, separate permissions, prepare expiration and rollback steps, and test legitimate traffic.