Day 64 — BGP BLACKHOLE Community and Remote Triggered Black Holing

1. Opening

During a volumetric attack, preserving the rest of the network can require intentionally discarding traffic to the attacked destination before it consumes constrained links. BGP-based blackholing turns routing policy into a controlled discard signal. Because the signal intentionally destroys reachability to a prefix, authorization and scope must be exceptionally strict.

Internet-edge security works best when each source of routing truth has a clearly defined job. The local configuration expresses business policy. IRR data documents routing intent. RPKI validates origin authorization. BGP exposes what is actually being announced. None of those sources alone replaces the others.

The objective is therefore not merely to create a filter. It is to create a repeatable authorization workflow with enough evidence to explain why a prefix is accepted, rejected, blackholed or escalated.

2. Concept and standards behavior

RFC 7999 defines the well-known BLACKHOLE community as an advisory transitive community for destination-based blackholing. RFC 5635 documents RTBH techniques including source-based filtering with uRPF. RFC 7454 treats RTBH as an operational BGP security technique. A provider may also use documented provider-specific communities, but those values must never be invented.

The series continues to separate four layers:

1. Standards behavior — what an RFC defines.
2. Registry or authorization data — what IRR/RPKI/IANA sources say.
3. Cisco implementation — how IOS XE expresses the mechanism.
4. Operator policy — what this network chooses to accept, advertise or discard.

A safe production design must state which layer is making each decision. For example, a route can be RPKI NotFound yet explicitly authorized by a customer contract and IRR object; conversely, an IRR object does not cryptographically prove resource control.

3. Scenario

Customer-A is allowed to request blackholing only for its own 203.0.113.0/24 and only for /32 hosts in the lab. EDGE1 maps an approved blackhole signal to a discard next hop/Null route according to the validated platform design.

Common lab topology

                    Transit-A / AS65020
                           |
                     192.0.2.0/30
                           |
                    EDGE1 / AS65010
                      /           \
             Customer-A           Scrubber/RTBH
              AS65030               control
                 |
          203.0.113.0/24
                           |
                    Transit-B / AS65040

All addresses and ASNs are documentation/private lab values. External registry examples are conceptual; no real organization is impersonated and no real ROA is created.

Success criteria

1. Only explicitly authorized customer prefixes are accepted.
2. Export policy cannot accidentally create transit.
3. RPKI validation state is visible but policy action remains explicit.
4. Special-purpose/bogon controls are registry-aware.
5. Blackhole signaling can be invoked only by approved sources and prefixes.
6. Incident containment is reversible and evidence-preserving.

4. Topology diagram

A matching editable SVG and PNG are stored under media/diagrams/.

5. Prerequisites

• IOS XE 17.18.x documentation baseline.
• Stable eBGP sessions.
• A documented customer prefix inventory.
• Time-synchronized logging.
• Independent management access.
• For IRR/RPKI exercises: local snapshots or lab fixtures, not live production credentials.
• For blackhole exercises: a dedicated discard next hop/community policy and strict trigger authorization.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete deployable configuration.

ip prefix-list BH-AUTH seq 10 permit 203.0.113.0/24 le 32

route-map BLACKHOLE-IN permit 10
 match ip address prefix-list BH-AUTH
 match community BLACKHOLE-COMMUNITY
 ! Set discard next-hop / local action only using validated
 ! platform-specific design.

! Define the RFC 7999 BLACKHOLE community using exact IOS XE
! community syntax verified on the target image.

Generated policy must be reviewed before deployment. Registry automation must never push directly to production without validation, diff, canary and rollback controls.

7. Verification before modification

show bgp ipv4 unicast summary
show bgp ipv4 unicast
show bgp ipv4 unicast neighbors
show bgp ipv4 unicast neighbors 192.0.2.2 received-routes
show bgp ipv4 unicast neighbors 192.0.2.2 advertised-routes
show ip prefix-list
show route-map
show logging
show bgp ipv4 unicast community
show route-map BLACKHOLE-IN
show ip route 203.0.113.10

The verification question is not “does the prefix exist somewhere?” but “which evidence source authorized it, which policy matched it, and what did the router actually do?”

8. Controlled modification

Inject an authorized /32 blackhole request for 203.0.113.10/32. Verify that only that host route is discarded and the covering /24 remains reachable.

Before the change, predict whether the affected object is Adj-RIB-In, Loc-RIB, Adj-RIB-Out, FIB forwarding or an external authorization state. Re-check the same evidence after the change.

9. Fault injection

Illustrative lab — not a real incident.

Send a BLACKHOLE-tagged prefix outside Customer-A's authorized aggregate. The edge must reject the trigger rather than discarding unrelated traffic.

The lab changes one authorization or policy variable at a time. Do not combine an RPKI fault, IRR fault and BGP policy fault in the same experiment unless the post explicitly reaches the capstone stage.

10. Step-by-step troubleshooting

1. Identify the exact prefix, origin AS and neighbor relationship.
2. Confirm the BGP session remains Established unless session loss is part of the event.
3. Capture the received AS_PATH, origin and communities.
4. Compare the prefix against the approved customer inventory.
5. Check current IRR/RPSL data or the lab fixture.
6. Check RPKI validation state where available.
7. Check special-purpose/IANA classification when relevant.
8. Inspect import policy and prefix-list/AS-path/community matches.
9. Inspect export policy before changing inbound controls.
10. Determine whether the issue is unauthorized origin, route leak, stale registry data, bad automation or a legitimate operational change.
11. Apply the narrowest proven containment.
12. Verify forwarding, negative containment and rollback readiness.

11. Root cause and correction

The blackhole trigger lacked prefix authorization. Correct the policy so community match is necessary but not sufficient: the prefix must also be inside the customer's approved blackhole range and within permitted prefix lengths.

The correction must repair the relevant trust source or policy boundary rather than broadening filters simply to make the route appear.

12. Post-fix verification

Confirm:

• intended BGP sessions remain Established;
• approved prefixes are accepted;
• unauthorized prefixes are absent or explicitly contained;
• RPKI state/policy matches the design;
• per-neighbor export remains default-deny;
• forwarding and discard behavior match the service objective;
• logs identify the triggering event.

13. Rollback

Restore the last approved filter/policy snapshot. If the change was incident containment, preserve the evidence before removal. Never roll back by replacing a default-deny policy with permit any. A temporary exception must be prefix-, peer- and time-bounded with an owner.

14. Deep-dive engineering notes

Community is a trigger, not authorization

Anyone able to send the community should not automatically be allowed to blackhole arbitrary prefixes. Bind triggers to neighbor identity, prefix ownership, length limits and max-prefix controls.

More-specific behavior

Blackholing often relies on a more-specific route so only the attacked host/service is discarded. Confirm upstream prefix-length acceptance and RPKI/IRR implications before using public propagation.

Destination versus source RTBH

Destination RTBH discards traffic to the victim prefix. Source-based RTBH uses source validation/uRPF concepts to drop traffic from identified attack sources. They have different operational risks.

Fail-safe design

Pre-stage discard routes/policy and test them before an incident. During an attack is the worst time to discover the blackhole next hop resolves incorrectly.

Withdrawal

A blackhole must have a clear removal/expiry procedure. The DDoS can end while the route remains intentionally discarded, turning mitigation into self-inflicted outage.

14A. Production workflow — safe blackhole activation

Build the blackhole service before an attack. Define who may request it, which prefixes they may blackhole, the allowed prefix lengths, how the request is authenticated, whether the route stays local or is propagated upstream, and the maximum lifetime of a blackhole action.

The trigger policy should require multiple conditions. A community match alone is insufficient. Match the authorized customer neighbor or controller, verify the prefix is inside the customer's approved aggregate, enforce an allowed more-specific length, and apply a low maximum-prefix to the blackhole session or trigger class. This prevents a compromised customer router from requesting discard of unrelated address space.

Pre-stage the discard next hop or forwarding action and verify it does not accidentally resolve back into the normal network. A mis-resolved “blackhole” next hop can loop traffic or send it somewhere unexpected. The test must prove packets are discarded where intended.

Decide whether blackhole signaling remains inside the operator network or is propagated to a transit/provider. If propagation is required, use RFC 7999 where supported or the provider's documented community. Never assume every network honors BLACKHOLE identically. Upstream prefix-length filters and route-origin policy can also affect whether a /32 request is accepted.

Activation should create an incident record automatically: prefix, customer, trigger source, timestamp, reason, operator/automation identity and expiry. Monitoring should confirm the blackhole route is installed and that traffic volume on constrained links falls as expected. If utilization does not improve, the attack may target multiple destinations or the discard point may be too far downstream.

Withdrawal is a first-class operation. When the incident ends, remove the trigger, verify the discard route disappears from BGP/FIB, and test service restoration. An orphaned blackhole can persist after everyone believes the DDoS is over.

For exercises, distinguish destination RTBH from source-based RTBH. Source-based techniques can be valuable when attack sources are stable and identifiable, but spoofed or rapidly changing sources reduce usefulness and increase risk. Destination blackholing intentionally sacrifices the victim prefix to protect wider network availability; that trade must be explicitly approved.

Blackhole observability

Blackhole monitoring should expose both control-plane state and service consequence. Record which peer supplied the trigger, the exact prefix and community, the installed discard path, and traffic counters before and after activation. If a blackhole route exists but upstream link utilization does not fall, the mitigation point may be too far downstream or the attack may target additional prefixes. Treat lack of expected traffic reduction as a failed mitigation test, not merely a monitoring curiosity.

15. Production lessons

• Authorize blackhole triggers by peer, prefix and length.
• Use RFC 7999 semantics where interoperable and provider-documented communities where required.
• Pre-stage and test discard behavior.
• Monitor every blackhole route with owner and expiry.
• Verify withdrawal as carefully as activation.

16. Knowledge check

1. Which source in this post documents intent, and which source can cryptographically validate origin authorization?
2. What evidence proves the router actually enforced the expected policy?
3. Why should a temporary incident exception be narrower than the permanent policy?

Answers

1. IRR/RPSL documents routing intent; RPKI ROAs support cryptographic origin authorization.
2. Received/accepted/advertised route evidence plus policy counters/logs and forwarding tests.
3. Broad exceptions can outlive the incident and silently create a new leak or hijack acceptance path.

17. Sources

• RFC 7999 — BLACKHOLE Community
• RFC 5635 — Remote Triggered Black Hole Filtering with uRPF
• RFC 6666 — IPv6 Discard Prefix / RTBH considerations
• RFC 7454 — BGP Operations and Security
• Cisco security guidance — Remotely Triggered Black Hole Filtering