Contributors: Suzan Bayhan (University of Twente), Ralph Holz (University of Munster and University of Twente), and Cristian Hesselman (SURF and University of Twente).
Autonomous Systems (ASes) mitigate Distributed Denial of Service (DDoS) attacks by redirecting traffic to scrubbers using the Border Gateway Protocol (BGP). The scrubbers filter malicious traffic and forward legitimate traffic to the ASes they protect.
Despite its usage, the behaviour of BGP-based scrubbers is not well understood, such as whether scrubbers are always on-path or activated on-demand. Prior work does not distinguish between these modes and is limited to cases where the protected AS remains the origin of its prefixes.
In a recent study, we analysed public BGP data to detect scrubbing behaviours of five popular scrubbers, including whether scrubbers act as upstream providers or originate prefixes on behalf of protected ASes. Our research provides a broader view of DDoS protection across regions than our prior work, which we detailed in our paper presented at the Passive and Active Measurement Conference 2026. This post will summarize those findings.
What is DDoS scrubbing?
Scrubbing is a mechanism to mitigate DDoS attacks by diverting traffic toward specialized 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 the five leading scrubbers
We focused on five leading scrubbers in our study: Cloudflare, Akamai Prolexic, Vercara (formerly Neustar), Imperva, and Radware. We used them because they are among the global top five in terms of bandwidth capabilities to mitigate DDoS attacks and are also recognized as leading scrubbers in the 2021 Forrester wave market analysis, which other studies also use as a source.
Datasets used in our study
We used 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 determined 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 used a 30-day timeframe for both datasets, from 1 to 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 classified 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 an on-demand scrubbing if the prefix temporarily changes origin or upstream in the 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 (UTC+1), whereas it is normally originated by AS 48695. 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 (UTC+1), while AS45753 typically uses AS9744 as its upstream. We further analysed 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 was to determine whether p4 was scrubbed on day D1 rather than how frequently it was scrubbed on that day. We therefore looked 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 collected 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 analysed the BGP updates in the RIS route collectors (five-minute sampling rate) and detected 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 looked for a scrubbing deactivation signal. We saw 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 revisited the BGP updates of day D₁ and saw that p4 was last observed with Vercara as an upstream at time t₂. We can 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 five studied scrubbers, both for single-day and cross-day scrubbing. We see that Cloudflare regularly engages in this type of scrubbing, with the daily number of scrubbed prefixes ranging from a minimum of two to a maximum of 16. We observe that the frequency of activation and deactivation cycles for protected ASes of Cloudflare is higher than that of 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 2025: 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 it handled the most DDoS attacks. The next highest is Cloudflare (250 prefixes). Radware was activated for the lowest number of prefixes (55).
| Scrubbers | Number of origin-changed prefixes | Number of upstream-changed prefixes | Total prefixes |
| Cloudflare | 1 | 249 | 250 |
| Akamai | 4 | 66 | 70 |
| Vercara | 82 | 621 | 703 |
| Imperva | 0 | 96 | 96 |
| Radware | 17 | 38 | 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 Route Origin Authorizations (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 NotFound (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 visualization 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 economies.
- 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 RIB 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.
Shyam Krishna Khadka is a final-year PhD student at the University of Twente, with research interests in BGP security and DDoS. He has over 13 years of combined professional experience, having worked at Nepal Telecom and Cloudfactory across multiple domains, including software development and network technologies.
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).
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.