The Number of the Beast or the Practical usage of the Blackhole Community

Unwanted traffic that floods networks and machines from many different sources is often intentionally generated by the distributed-denial-of-service (DDoS) attack. The goal of a DDoS attack is the depletion of resources (CPU, RAM, bandwidth) of a remote target so that the service becomes unavailable for legitimate users. Typical symptoms of a DDoS attack are excessive bandwidth utilization on a targeted network and services crashing on victim’s machines. At the time when the day-long DDoS attacks against a small organization are offered for as low as $100, with a 5-minute test DDoS attack free of charge (showing the attacker capabilities), the importance of having a reactive defense strategy against such attacks is hard to underestimate.

DDoS traffic should be blackholed (dropped) closest to the source of the attack. Blackholing is based on either the source or destination IP address. Remote black hole filtering based on the destination IP address is a commonly used technique. The ISP sets a permanent static route utilizing the unused prefix pointing to the null interface on its PE routers, e.g. 192.0.2.1/32. It is a precaution measure that ISP installs in advance along with building a trigger machine. The trigger machine is a router or Unix machine running BGP daemon that is a part of ISP infrastructure. It has established internal BGP (iBGP) sessions with PE routers.

Let’s say that a DDoS attack is launched against a customer web server with IP address 172.12.0.1. As soon as a customer asks an ISP to filter the currently running DDoS, the ISP creates a static route to the targeted prefix 172.12.0.1/32 on the trigger machine pointing to a null interface. The static route to 172.12.0.1/32 is then redistributed via iBGP sessions from the trigger to PE routers but with the next hop changed to the IP 192.0.2.1. As a result, all traffic to the IP address 172.12.0.1 is sent to the 192.0.2.1 thus is effectively being dropped by the null route on PE routers. When the DDoS attack is finished, the static route 172.12.0.1/32 is removed from the trigger machine and withdrawn via iBGP session from the PE routers.

The method mentioned above requires customers to send an email to a service provider, requesting manual configuration of the null static route for targeted prefix on a trigger machine when DDoS attack is launched. Subsequently, a customer needs to send an email requesting the removal of a static null route once the DDoS attack is finished. Although this method has been  proven to work, it inserts a time delay into the attack mitigation process. Luckily, there is another, automated method for destination-based remote blackholing using Blackhole Community, which gives customers better control over the black holed prefixes.

The BGP blackhole transitive community is one of the well-known BGP communities defined in RFC 7999. The BGP blackhole community is attached to an announced prefix by an origin Autonomous System (AS) during a DDoS attack. Its purpose consists of signaling to a neighboring network that a neighbor router should discard all traffic destined for the received prefix with the attached BGP blackhole community. With this approach, customers can trigger blackholing of the targeted prefix by remote ISP routers, adding a simple configuration to their customer edge routers. In other words, blackholing can be initiated any time by customers requiring no cooperation with ISP during a DDoS attack. However according to RFC, accepting  the blackhole community, or ignoring it, is a choice that is made by each operator. That is why accepting blackhole community must be agreed by both networks prior to advertising it.

The blackhole community is registered in the “BGP Well-known Communities” registry as 0xFFFF029A. The low-order two octets in decimal are 666. We can only speculate why the value 666 (the number of the beast from the Bible) was chosen for this purpose. Nevertheless, the value is commonly used with BGP blackholing by network operators. As for a length of the blackhole prefix, it should be as long as possible. This prevents discarding traffic sent to the IP addresses that are not under the DDoS attack. Typically the length of a blackhole prefix is /32 (a single IP address). In any case, the length of the announced blackhole prefix must be equal or longer than the length of the entire IP prefix assigned to a customer.  

Below is a network topology that we use for testing of blackhole community usage. In our scenario, an attacker launched a DDoS attack against the customer web server (IP 198.51.100.2). If our configuration is correct as soon as the customer configures the commands below, DDoS traffic should be discarded on a router ISP. Traffic from the attacker to IP address 198.51.100.1 should not be discarded.

Picture 1 – Network Topology

1. Customer Router Configuration

2. ISP Router Configuration

The command above stops sending ICMP unreachables to the attacker when DDoS packets are discarded on an ISP router.

3. Additional Configuration on ISP PE Router

3.1. Restrict Customer to Advertise Only Authorized Prefix with Length from /24 to /32

Customer should only announce a prefix that is authorized to advertise (198.51.100.0), with the length from /24 to /32. For this reason ISP needs to filter BGP announcements carrying the blackhole community that are not authorized.

3.2. Prevent ISP to send Blackhole Prefix to eBGP Peers

A BGP speaker receiving an announcement tagged with the blackhole community (ISP) should add no_export community as to prevent propagation of the blackhole prefixes to eBGP peers. We have already done it with the command under the route-map customer-in in the ISP configuration.

4. Testing

If the DDoS attack is not launched, the attacker can ping the IP address 198.51.100.2.

Below is the RIB of the ISP router.

ISP# show ip bgp | begin Network 
    Network          Next Hop            Metric LocPrf Weight Path 
*>  198.51.100.0     198.51.200.2             0             0 64501 i 
*>  198.51.200.0/30  0.0.0.0                  0         32768 i 
*>  198.51.200.4/30  0.0.0.0                  0         32768 i

Once the DDoS attack is launched and detected by the customer, the customer adds the following lines to its router. Subsequently, once the attack is finished, the customer removes the lines from the configuration.

The RIB of an ISP router changes adequately. We see that route 198.51.100.2/32 with the next hope 192.0.2.1 was added.

ISP#show ip bgp | begin Network 
    Network          Next Hop            Metric LocPrf Weight Path 
*>  198.51.100.0     198.51.200.2             0             0 64501 i 
*>  198.51.100.2/32  192.0.2.1                0             0 64501 i 
*>  198.51.200.0/30  0.0.0.0                  0         32768 i 
*>  198.51.200.4/30  0.0.0.0                  0         32768 i

Inspection of the static route to 192.0.2.0 reveals that packets to the IP address 192.0.2.1 are discarded.

ISP# show ip route static | begin 192.0.2.0 
     192.0.2.0/32 is subnetted, 1 subnets 
S        192.0.2.1 is directly connected, Null0

The RIB of the attacker router has not changed.

Attacker# show ip bgp | begin Network 
    Network          Next Hop            Metric LocPrf Weight Path 
*>  198.51.100.0     198.51.200.5                           0 64500 64501 i 
*>  198.51.200.0/30  198.51.200.5             0             0 64500 i 
r>  198.51.200.4/30  198.51.200.5             0             0 64500 i

However DDoS traffic is successfully discarded on the ISP router.

The traffic to the IP address 198.51.100.1 should not be discarded as the DDoS attack is launched only against the web server.

5. Intelligent Routing Platform – Automated Threat Mitigation

Starting with v 4.1, IRP offers a fully automated threshold-based DDoS detection and mitigation instrument that uses FlowSpec and the Remote Triggered Blackholing mechanisms to defend your network against small and large-scale attacks.

IRP’s Threat Mitigation can operate in either automated or moderate modes. However, it is also extremely easy for the platform users to monitor and set up custom blackholing rules when such are required.

With this feature set up, there is no need for you to ssh to the remote trigger routers and type in specific configurations in the middle of the night. DDoS detection/mitigation becomes much easier, less time-consuming, and stress-free.

We should note that there are some pros and cons associated with the use of the BLACKHOLE community. While this approach is widely supported by transit providers, accepting the blackhole community, or ignoring it, as mentioned above, is a choice that is made by each operator. The use of the community should be agreed by both networks.

Moreover, one should be cautious about the possible abuse and the dangers of the BGP community attributes and the remote triggered blackhole mechanism (RTBH) described in The dark side of BGP community attributes article.