As of today, little is known about the kind and effectiveness of its use, and about the need for more fine grained filtering. That is why our recently published research paper is analysing the efficiency of RTBH as a mitigation tool and whether mitigation is the only use-case of RTBH. We cooperated with one of the largest IXPs world-wide and analysed each RTBH during a measurement period of more than 3 months.

Background: Blackholing at IXPs

The Border Gateway Protocol (BGP) is used to exchange IP prefix reachability information between Autonomous Systems (ASes) to form the global Internet. Yet, one BGP application has the opposite effect in practice: Signalling RTBH based on BGP informs a neighboring AS to discard traffic destined towards an owned IP prefix. The most prominent and well-established use case for RTBH filtering is the mitigation of attack traffic towards a victim, identified by an IP prefix. Thereby, attack traffic is dropped before it reaches the final destination which alleviates the damage to the network infrastructure under attack.

Figure 1: Blackholing drops all traffic towards a prefix. This might introduce collateral damage

IXPs are particularly well suited for this kind of prevention, since they provide a convergence point where hundreds of ASes meet and exchange inter-domain traffic. Route servers at the IXP propagate the RTBH signals from the victim to all other IXP members, which, after accepting the signal, forward all traffic destined to the victim prefix to the blackhole. Hence, attack traffic as well as legitimate traffic is dropped, which we call collateral damage.

Blackholing Acceptance and Drop Rates

Any BGP peer that does not accept a blackhole route from the routeserver will continue to forward the traffic that was intended to be filtered. Acceptance of blackhole routes is beyond the control of the triggering AS, but subject to local BGP policies of the receiving peer.

Figure 2: Not every IXP member drops traffic due to BGP rejection policies

Quantifying the RTBH acceptance rates and the triggered packet drop rates shows how effective RTBH is in the wild. Hopefully, this also helps to understand why RTBH is not accepted and to unveil potential misconfigurations. To find this out, we grouped the RTBHs by prefix lengths. Then, for each blackhole in a group we calculated how much of the traffic was really dropped and plotted the CDF.

Figure 3: Blackholing announcements are rejected for more specific prefix lengths

Successful mitigation depends highly on the announced RTBH prefix length. A perfect mitigation in this plot is a vertical line at 100%. Although not perfect, we observed a significant drop rate for /24-prefixes. However, that is a really large network range to blackhole, which might blackhole hosts that are not under attack. The prefix length /32 has only a mean drop rate of 50%. This is disappointing because it is the most important prefix length for RTBHs as /32-prefixes covered 99% of traffic that should have been blackholed.

This analysis shows that RTBHs are surprisingly ineffective, mainly due to misconfigurations, i.e., not accepting more-specific prefixes than /24 in the case of RTBH. Such most specific prefixes are usually not accepted globally in order to prevent sub-prefix hijacks.

Blackholing Events and DDoS Traffic Anomalies

An effective DDoS mitigation requires also a fast reaction to DDoS events. Looking for volumetric traffic changes right before each RTBH announcement, however, can be misleading. This is because RTBHs as DDoS mitigation are announced and withdrawn repeatedly to check whether the attack event is still ongoing.

Figure 4: Individual blackholes have to be grouped into blackholing events

We use this on-off pattern to identify RTBH announcements that target at the same attack event and merge them into a single RTBH event. Each RTBH event reflects the mitigation process after the attack was detected. So, a traffic change is only expected before the first RTBH of an RTBH event.

Using a sliding window algorithm (EWMA) we monitored a total of 5 features that we expect to change during attack events, such as Amplification, TCP Syn or GRE flooding attacks:

1. Number of packets
2. Number of unique destination ports
3. Number of flows
4. Number of unique source IP addresses
5. Number of non-TCP flows

The following heatmap shows all anomalies that we found before the corresponding blackhole events. We observe a high number of anomalies up to 10 minutes before an RTBH Event. Usually, all 5 features are affected.

Figure 5: Time offset between anomalous traffic bursts and start of Blackholing events

This short reaction time indicates automatic DDoS mitigation. Hence, RTBH as DDoS mitigation is fairly effective with respect to time; most anomalous bursts are mitigated via RTBH within 5 minutes.

Other Use-cases for Blackholing

Although we found many anomalies, a substantial share of RTBH events has not a corresponding traffic anomaly. To be precise: Only 27% of all RTBH events experience traffic in the preceding 72 hours and a traffic anomaly in the last 10 minutes. For all the other RTBH events, we either did not observe an anomaly or traffic at all. We identify a surprising practise that significantly deviates from the expected DDoS mitigation use patterns. We survey two new RTBH use-cases:

• Prefix Squatting Protection: IP prefix squatting is a variant of prefix hijacking, where third parties take over address space that is assigned to another AS but not announced from this legitimate origin actively. One common mitigation technique for prefix squatting is to announce the assigned address space. To ensure the address space is not used at the same time, the same prefix is announced as an RTBH.

• Content Blocking: Applying RTBH to block clients from accessing content occurs rarely but is possible. Attackers (e.g., port scanners, vulnerability scanners) and not victims have been blocked by network operators to block outgoing malicious behaviour. Another motivation for the deployment of BGP blackholing is censorship. RTBH can be used to block traffic towards an IP address hosting undesirable content.

Collateral Damage and Fine-grained Filtering

RTBH is a coarse-granular traffic filtering tool. Although having the advantage of dropping DDoS traffic early in the network, there is a major drawback: RTBHs complete the attack, the victim is unreachable. Remember the IXP example and the collateral damage in the background section?

In order to reduce collateral damage and keep the victim reachable during the attack events, we could extend the filter rules, e.g. by port information. We can either whitelist legitimate traffic or blacklist attack traffic.

Figure 6: Fine-granular Blackholing based on port information

Whitelisting Does Not Help

We cannot whitelist client traffic, because client traffic is highly variable. That is why we categorised each blackholed DDoS victim as a server or client by looking at the regular traffic patterns (outside of RTBH events). Moreover, we correlated our classification with data from PeeringDB.

It turns out that a lot of DDoS victims are clients located in eyeball providers. Professional e-gamers, Twitch streamers etc experience DDoS attacks frequently due DDoS-as-a-service websites called booters. This means that whitelisting of regular patterns, e.g., HTTP traffic for a web server, is in many cases not an option.

Blacklisting is Effective

However, fine-grained blacklisting is. Most volumetric attacks (90%!) which were mitigated with RTBH utilised only 3 attack vectors such as NTP and DNS. So, blocking these attack vectors, each identified by the default source-port of the misused application, can effectively block the attack and prevent collateral damage. BGP Flowspec (RFC 5575) is one of the standards that offers such an exchange of fine-granular blackholing information.

Summary: Advices for operators

We would like to sum up this article with three advices for operators

1. Check your BGP policies: Accept more specific RTBH prefix announcements, in particular /32. It is worth noting that some IXPs provide a dedicated RTBH route server that only advertises blackholes, which eases BGP policy configuration as you need to accept /32 announcements only from this peer.
2. Check your routing tables for RTBH “zombies”: RTBH zombies are active RTBHs for which data plane activities do not justify a blackhole. Your routing tables may contain outdated RTBH entries or those that do not relate to DDoS. Contact your peers to understand their RTBH use case.
3. Consider fine-grained filtering: Majority of volumetric DDoS attacks are still not complex to detect in terms of traffic features. Simple port-based blacklisting (ACLs, BGP Flowspec) can be very effective and would be a cheap solution to limit collateral damage.

 This research was presented at RIPE 79 under the RACI programme.

Paper

The full paper was published at the ACM Internet Measurement Conference (IMC) 2019.

• Marcin Nawrocki, Jeremias Blendin, Christoph Dietzel, Thomas C. Schmidt, Matthias Wählisch, “Down the Black Hole: Dismantling Operational Practices of BGP Blackholing at IXPs,” In: Proc. of ACM Internet Measurement Conference (IMC), pp. 435-448, New York: ACM, 2019.

The paper is freely available via https://doi.org/10.1145/3355369.3355593.