Understanding DDoS Scrubbing in BGP: Five Leading Scrubbers

DDoS attacks remain a persistent operational challenge for network operators, and scrubbing services have become a common way to mitigate their impact. These services rely on changes in BGP to redirect traffic, but the resulting routing behaviour can vary depending on how mitigation is deployed. In this article, we analyse global BGP data to examine how five major scrubbing providers operate and how different mitigation approaches can be identified in practice.

What is DDoS scrubbing?

Scrubbing is a mechanism to mitigate DDoS attacks by diverting traffic toward specialised infrastructure, known as scrubbers. The scrubber filters DDoS traffic and forwards the clean traffic to the AS that it protects.

Scrubbers operate in one of two modes: always-on or on-demand. An always-on scrubber permanently appears as the upstream of a prefix’s origin AS. In contrast, an on-demand scrubber dynamically appears in AS paths when the protected AS activates the scrubber. This can happen in two ways: origin-change and upstream-change. We refer to the case as origin-change when the scrubber is set up such that the origin of the prefix dynamically changes from the protected AS to the scrubber during the attack (see Figure 1a).

Alternatively, the protected AS continues to announce the prefix that is being attacked but sends the BGP announcements for that prefix to the Internet through the scrubber (Figure 1b). We call this an upstream change because now the scrubber becomes an upstream of the protected AS.

In both scrubbing modes, only the inbound traffic flows through the scrubber. The outbound traffic from the protected AS continues to exit normally through its ISP toward the Internet.

Focus on five leading scrubbers

We focus on five leading scrubbers in our study: Cloudflare, Akamai Prolexic, Vercara (formerly Neustar), Imperva, and Radware. We use them because they are among the global top five in terms of bandwidth capabilities to mitigate DDoS attacks and are also recognised as leading scrubbers in the 2021 Forrester wave market analysis, which other studies also use as a source.

Datasets

We use three datasets. The first is the set of AS Numbers (ASNs) that the five scrubbers use for scrubbing purposes. Following the approach we developed in prior work, we determine these ASNs by manually inspecting sources such as the technical documentation of scrubbers, conversations with scrubber engineers, and past scrubbing events reported on mailing lists and elsewhere.

Our other two datasets are publicly available BGP Routing Information Bases (RIBs) and BGP updates from RIS route collector, with the latter collecting BGP updates every five minutes. We use these two datasets to infer always-on and on-demand scrubbing. We use a 30-day timeframe for both datasets, from 1-30 May 2025.

Detecting always-on scrubbing

We label a prefix as using always-on scrubbing if the BGP RIBs data shows that a scrubber appears as the upstream for that prefix for a continuous 30-day period. For example, we observed an AS path [513 25091 25091 13335 24864] for prefix 2.58.145.0/24 throughout our study period and therefore classify the prefix as using always-on scrubbing. Here, 13335 is the ASN that Cloudflare uses for DDoS scrubbing, while 24864 is the protected AS.

Figure 2 shows that Cloudflare and Akamai account for the largest number of prefixes in always-on mode: 2,876 and 5,861, respectively. Imperva and Radware have a more moderate number of always-on protected prefixes (1,325 and 1,082). In contrast, Vercara covers only 264 prefixes in always-on mode, indicating that a small number of prefixes use Vercara for always-on protection.

Detecting on-demand scrubbing

We classify a prefix as being protected by on-demand scrubbing if the prefix temporarily changes origin or upstream in BGP update data. For example, we classify the prefix 46.184.90.0/24 as being protected by origin-change scrubbing because Vercara originated it between 13:17 and 13:39 on 10 May 2025, whereas it is normally originated by AS48695. Similarly, we classify prefix 182.16.18.0/24 as being protected by upstream-change scrubbing because Vercara appeared as the upstream between 11:17 and 11:25 on 12 May 2025, while AS45753 typically uses AS9744 as its upstream. We further analyse the RPKI practices of prefixes identified in origin-change scrubbing (details can be found in our paper).

Figure 3 shows our methodology for detecting upstream-change-based on-demand scrubbing involving Vercara using prefix p4 as an example. Our objective is to determine whether p4 was scrubbed on a day D1 rather than how frequently it was scrubbed on that day. We therefore look for scrubbing activation and deactivation signals within D1. Our methodology does not track individual cycles of activation, deactivation, or reactivation of a prefix in a day.

We first collect daily BGP RIB snapshots at midnight over a 30-day period where Vercara appears as an upstream. Prefix p4 is not in the daily snapshot for day D1 (R1 in Figure 3), which means that we consider it not being scrubbed at that time. Next, we analyse the BGP updates in the RIS route collectors (five-minute sampling rate) and detect that Vercara appears as a new upstream for prefix p4 at time t₁, which we consider a signal of Vercara being activated for scrubbing. Next, we look for a scrubbing deactivation signal. We see that p4 switches to a different upstream in day D2’s RIB snapshot (R2), which means that Vercara stopped scrubbing somewhere on D1. We therefore revisit the BGP updates of day D₁ and see that p4 was last observed with Vercara as an upstream at time t₂. We infer the scrubbing session for p4 as the interval between t₁ (activation) and t₂ (deactivation).

Our methodology also detects activation and deactivation signals for origin-change-based scrubbing on day D1, which we call same-day scrubbing. We also infer cross-day scrubbing, which is when the scrubber activation signal occurs on day D1 and deactivation on D2. We refer to our paper for the details of these cases.

Findings of upstream-change-based on-demand scrubbing

Figure 4 shows our findings of upstream-change scrubbing for the studied five scrubbers, both for single-day and cross-day scrubbing. We observe that Cloudflare regularly engages in this type of scrubbing, with the daily number of scrubbed prefixes ranging from a minimum of 2 to a maximum of 16.

We observe that the frequency of activation and deactivation cycles for protected ASes of Cloudflare is higher than other scrubbers. Akamai and Imperva follow Cloudflare in terms of scrubbing frequency, as we did not see any activations for them for some days. Vercara showed a high number of prefixes scrubbed on 13 May: 282 prefixes. Radware also scrubbed a relatively low number of prefixes: 38 prefixes in 30 days.

Scrubbed prefixes

Table 1 presents our findings of origin-change and upstream-changed-based on-demand scrubbing using 30 days of data. Vercara was activated for the largest number of prefixes (703), suggesting they handled the most DDoS attacks. The next highest is Cloudflare (250 prefixes). Radware was activated for the lowest number of prefixes (55).

Key takeaways

• We observed a higher number of always-on protected prefixes compared to on-demand protection in our study period. This may be due to the operational simplicity of always-on scrubbing compared to the attack-driven (de)activation of on-demand protection.
• We observed a dominance of upstream-change over origin-change based scrubbing. One reason for this dominance could be that upstream-change mode gives the owner AS of a prefix flexibility and control to originate their prefix themselves, rather than delegating the prefix origination task to the scrubber AS. In this way, the protected AS also does not need to create ROAs for scrubbers for its prefixes.
• For prefixes using origin-change scrubbing, 52% of the prefixes have RPKI Valid status, while the remaining 48% of the prefixes have RPKI Invalid (12.5%) or Not Found (35.5%) status. RPKI-invalid routes may be dropped by ROA-validating ASes, undermining mitigation effectiveness. Operators should ensure valid ROAs for effective scrubbing.
• Our work can serve as a visualisation tool for network operators and regulators, providing insights into DDoS attacks from a scrubbing perspective, including the frequency and duration of attacks. These observations can help policymakers assess the level of DDoS protection across networks, regions, or countries.
• Insights into on-demand scrubbing can enhance BGP monitoring platforms such as GRIP and Cloudflare Radar, helping operators distinguish legitimate mitigation events from real hijacks. This improves detection accuracy and reduces false positives in routing incident alerts.

Summary and future work

We presented a novel methodology to detect scrubbing by combining BGP RIBs snapshots and BGP updates. Our study of five leading scrubbers over a period of 30 days in 2025 shows the dominance of always-on scrubbing (11k prefixes) over on-demand scrubbing (5.6k). We observed the dominance of the upstream-change model (1k prefixes) over origin-change (104). We plan to measure the effectiveness of scrubbing by measuring the time lag between actual DDoS attacks and scrubbing start times.

Acknowledgements

This research received funding from the Dutch Research Council (NWO) as part of the projects CATRIN (NWA.1215.18.003) and UPIN (CS.004). CATRIN is part of NWO’s National Research Agenda (NWA).