Safe blackholing: three points to verify in your own network

Blackholing (RTBH), also known as blackhole routing, is the fastest way to cut off attack traffic, but enabling it on its own guarantees nothing. Safe blackholing is the term we use for verifying a few specific points in the network: only once they have all been checked can you be confident that the mechanism works end to end and that attack traffic will not land where it does the most damage.

This article first explains how blackholing works, then where it most often fails, and finally how to eliminate each of those problems in turn.

How blackhole routing works, step by step

1. The detection system identifies a volumetric attack aimed at a specific address in your network.
2. The WanGuard console announces that address as a prefix (/32 for IPv4) over a BGP session.
3. The prefix is tagged with a BGP community (e.g. 5617:666), by which the uplink provider recognises it as a BGP blackhole (RTBH).
4. Your transit providers, seeing that BGP community, discard traffic to the address on their side, before it reaches them or your network.
5. Your own edge router discards whatever still gets through, provided local RTBH is configured.

Three points to verify

Verify the following three conditions in this order: each one only makes sense once the previous one is met.

Point 1. A complete set of BGP communities on announcement

This is the most important condition and also the one most often overlooked. A blackhole prefix must be announced with every BGP community used by your transit providers and by your peering partners. Each operator has its own BGP community for signalling a blackhole and honours only that one: alongside the standard 65535:666, network-specific values remain in widespread use.

The consequence is simple: if the announcement is missing one provider’s BGP community, that provider will not discard the traffic, and the full attack volume will enter over its link even though all the other providers acted correctly. Blackholing then appears to be ‘working but ineffective’, and the only cause is the missing BGP community.

Once the full set of BGP communities is covered, traffic to the attacked address stops reaching your network. Bear in mind, however, that some residual traffic may still arrive from internet exchange points: blackholing does not always behave there as it does on transit links, because some peers do not honour blackhole BGP communities at all or apply their own, different rules. That is precisely why points two and three are needed.

Point 2. The next-hop must not point at the WanGuard console

In BGP, every prefix carries a next-hop attribute stating the next IP address through which the network is reachable. A blackhole prefix arrives at the router from the WanGuard console, so by default its next-hop points at the console address.

The effect shows up at exactly the worst moment. If elevated traffic appears on your links despite blackholing, for example from an internet exchange point as described above, the router treats the console as the last element of the path to the attacked address and sends that traffic to it. The WanGuard console is a management machine, not a forwarding device; at sufficient volume it loses performance, stops responding and may drop the BGP session that maintains the protection of the entire network. At that point you lose protection, and the full DDoS attack traffic appears on your links.

The remedy: in the import policy on the BGP session with the console, rewrite the next-hop of incoming prefixes to an address belonging to the router.

Point 3. Local blackholing on the router

Rewriting the next-hop on its own moves the problem rather than solving it: traffic stops flowing to the console but starts arriving at a router that has nowhere to send it. The address used as the new next-hop must therefore have a local discard rule on the router: a route stating explicitly that traffic sent to that address is to be dropped.

This element is essential regardless of whether you run a hardware or a software router. A correctly configured discard route makes packets disappear in the forwarding plane, so they never reach the control-plane CPU. Without it, the router starts handling the traffic in software, which under a volumetric attack means rising CPU load, BGP session problems and loss of stability: the same outcome you set out to avoid at the console, merely moved somewhere else.

As the destination for local blackholing, choose any unused address from the RFC 1918 private ranges: 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. The examples below use 10.255.255.1. Addresses from these ranges are not routed on the internet, so nothing real can be cut off by accident, and they do not collide with the default martians list in Junos.

The result of combining the three points

With a complete set of BGP communities on announcement, a rewritten next-hop on import and local blackholing on the router, you can be confident that attack traffic:

• is for the most part discarded at the providers, before it reaches your links,
• does not reach the WanGuard console, so the detection system keeps running and sees how the incident unfolds,
• does not load the edge router, but is simply dropped as unwanted and dangerous traffic.

Configuration, Juniper MX

Below is the complete configuration of the session with the WanGuard console, covering both RTBH and BGP FlowSpec:

set protocols bgp group eBGP-Wanguard type internal
set protocols bgp group eBGP-Wanguard description Wanguard
set protocols bgp group eBGP-Wanguard peer-as 65000
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 local-address 10.0.2.5
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 import import-Wanguard
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet unicast
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet flow no-validate NO-VALIDATION
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet6 unicast
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet6 flow no-validate NO-VALIDATION
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 export no-export

set policy-options policy-statement NO-VALIDATION then accept
set policy-options policy-statement REJECT-ALL term reject then reject
set policy-options policy-statement import-Wanguard term flowspec_import from rib inetflow.0
set policy-options policy-statement import-Wanguard term flowspec_import then accept
set policy-options policy-statement import-Wanguard term rtbh from protocol bgp
set policy-options policy-statement import-Wanguard term rtbh from community blackhole
set policy-options policy-statement import-Wanguard term rtbh then accept
set policy-options policy-statement import-Wanguard term last-deny-all then reject

set policy-options community blackhole members 5617:666

set routing-options rib inetflow.0 maximum-prefixes 5000
set routing-options flow term-order standard

The final term matters: the session with the WanGuard console exists solely to signal RTBH and BGP FlowSpec, so anything that does not match the pattern is rejected.

Two further elements implement points two and three, the next-hop rewrite on import and the discard route:

set routing-options static route 10.255.255.1/32 discard

set policy-options policy-statement import-Wanguard term rtbh then next-hop 10.255.255.1

Junos can also direct traffic to a discard interface instead of a static route. This option is more convenient where you want to count or sample the discarded traffic, since filters can be attached to the interface.

Configuration, Cisco

ip route 10.255.255.1 255.255.255.255 Null0

ip community-list standard BLACKHOLE permit 5617:666

ip prefix-list HOST-ROUTES permit 0.0.0.0/0 ge 32 le 32

route-map WANGUARD-IN permit 10
 match community BLACKHOLE
 match ip address prefix-list HOST-ROUTES
 set ip next-hop 10.255.255.1
route-map WANGUARD-IN deny 20

router bgp <ASN>
 neighbor <console-address> route-map WANGUARD-IN in

The Null0 interface is a pseudo-interface that is always up and never forwards traffic; pointing routes at it is the standard way of implementing local blackholing on Cisco platforms.

Verification

Three tests, ideally carried out calmly, outside an attack.

BGP communities. After triggering a test blackhole, check with each provider whether the prefix has been accepted and is marked as a blackhole on their side. This is the only way to catch a missing BGP community before an attack does.

Next-hop. On the router, check the route to the test address. The next-hop must point at the local blackholing address and never at the console address. This is the single most important test in the whole deployment.

Discard route. On Juniper, show route 10.255.255.1 should show a Discard entry; on Cisco, show ip route 10.255.255.1 should point at Null0. Ingress interface counters should rise, egress counters should not.

Checklist

• A written list of all providers and peering partners, together with the BGP communities they require.
• The console attaches the full set of these BGP communities when announcing a blackhole prefix.
• The import policy on the console session rewrites the next-hop to a local address.
• The policy acts only on host prefixes tagged with the blackhole BGP community; everything else is rejected.
• The local blackholing address has a discard or Null0 route.
• Test completed: the next-hop points at local blackholing, not at the console.
• Blackhole prefixes do not leak beyond the intended announcement scope.

Reference material

• Cisco: Remotely Triggered Black Hole Filtering (technical paper).
• Cisco: Remotely triggered blackhole filtering (BGP documentation, IOS XR).
• Juniper: discard (routing-options).
• Juniper: Example: Forwarding Packets to the Discard Interface.
• IETF: RFC 7999 (BGP community BLACKHOLE 65535:666) and RFC 5635 (remotely triggered blackholing).