Beyond Their Intended Scope: DDoS Mitigation Leak
Summary
In this edition of Beyond Their Intended Scope, we take a look at last week’s BGP leak by a DDoS mitigation company which impacted networks around the world. We look at the impacts in both BGP and traffic data, and discuss how RFC 9234’s “Only to Customer” BGP Path Attribute could have helped.
Late last year, we published the first edition of Beyond Their Intended Scope, our new blog series intended to shed light on BGP mishaps which may have escaped the attention of the internet community but are still worthy of analysis.
In this episode, let’s take a look at a BGP routing mishap from last Tuesday that briefly disrupted and misdirected internet traffic from around the world through Bucharest, Romania, due to a BGP leak by a DDoS mitigation provider.
It may come as a surprise to many that route leaks continue to occur with some regularity. The difference today is that routing hygiene has improved to such a point that these leaks are often contained to the country or region where they originated, limiting the disruption. In this case, route propagation was not limited, but it’s possible the duration of the leak may have been.
Join Doug Madory on April 24 for an in-depth look at the current state of routing security — the progress made and work yet to be done.
What are BGP leaks?
“A route leak is the propagation of routing announcement(s) beyond their intended scope.”
That was the overarching definition of a BGP route leak introduced by RFC7908 in 2016. Border Gateway Protocol (BGP) enables the internet to function by providing a mechanism by which autonomous systems (e.g., telecoms, companies, universities, etc.) exchange information on how to forward packets based on their destination IP addresses.
In this context, the term “route,” when a noun, is shorthand for the prefix (range of IP addresses), AS_PATH, and other associated information relating to packet delivery. When routes are circulated farther than where they are supposed to go, traffic can be misdirected, or even disrupted, as happens numerous times per year.
RFC7908 went on to define a taxonomy for BGP leaks by enumerating six common scenarios, half of which appear in the two leaks covered in this post. In my writing on route leaks, I like to group them into two broad categories: mis-originations and path errors. As I described in my blog post, A Brief History of the Internet’s Biggest BGP Incidents, this distinction is useful because the two types of errors require different mitigation strategies.
- A mis-origination occurs when an AS originates (announces with its ASN as the origin) a new advertisement of a route to an IP address block over which it does not possess legitimate control, consequently soliciting traffic destined for those IP addresses.
- An AS path error occurs when an AS inserts itself as an illegitimate intermediary into the forwarding path of traffic bound for a different destination.
With those definitions out of the way, let’s get into the details of this particular incident.
What happened?
Beginning at 07:35 UTC on April 1, 2025, AS3223 (Voxility) began leaking routes learned from its peers through its transit provider, Lumen (AS3356). BGP-based DDoS mitigation providers like Voxility play a unique role in internet routing, which can complicate efforts to filter leaked routes, given their global customer base.
At any given time, such networks can legitimately be transiting thousands of routes from different customer ASNs. In fact, according to web resource bgp.tools, the AS-SET of AS3223 expands to include 28,720 different ASNs, 875,309 IPv4 prefixes, and 632,221 IPv6 prefixes. If accepted into a router configuration, this AS-SET would generate an allowlist millions of lines long, covering the vast majority of IP space in the global routing table.
First reported by our friends over at Qrator, the incident involved the leak of over 30,000 routes lasting around 20 minutes, during which time it misdirected and disrupted traffic to providers around the world.
| Mis-origination or path error? | Path error |
| How many leaked routes? | 31,258 (7,381 seen by 50+ Routeviews peers) |
| New more-specifics? | 2 (normally seen by 10 or fewer Routeviews peers) |
This was a sizable leak lasting as much as 20 minutes and touching companies in numerous countries. Since we didn’t see any surge of new more-specifics (aside from 89.238.228.0/24 and 5.154.239.0/24), then we can assume there wasn’t a route optimizer involved in this leak. Owing to the fact that this was not an origination leak (leaker originates leaked routes) and there were virtually no new more-specifics, RPKI ROV would not have been able to help limit the disruption of this BGP mishap.
In the following post, we’ll take a closer look at what happened, the impact on traffic, as well as what can be done to prevent these types of incidents in the future.
Impacts
BGP
As we did last time, let’s start at the individual BGP message level and work our way out from there. The two BGP messages below, collected from Routeviews, show the AS paths before and during the leak from the perspective of one BGP source, California research and education network CENIC (AS2152).
Reading the highlighted AS path from left to right, we can see that this route is normally originated by TPG Telecom of Australia (AS7545) and prepended three times to Tata (AS6453) before arriving at Lumen (AS3356) over a peering connection 3356:666 in San Jose, California 3356:2011 according to the community strings.
TIME: 04/01/25 06:00:20 FROM: 137.164.16.84 AS2152 ORIGINATED: 03/28/25 02:00:29 ORIGIN: IGP ASPATH: 2152 3356 6453 7545 7545 7545 7545 NEXT_HOP: 137.164.16.84 COMMUNITY: 2152:65493 2152:65497 2152:65499 2152:65511 3356:3 3356:22 3356:86 3356:575 3356:666 3356:903 3356:2011 ANNOUNCE 220.240.123.0/24
However, during the leak, the Lumen passes to CENIC is learned from the leaker (AS3223) over a transit customer connection 3356:123 in Bucharest 3356:2088. In doing so, 3356 preferred the route with a shorter AS path from a customer.
TIME: 04/01/25 07:36:18.623710 FROM: 137.164.16.84 AS2152 ORIGIN: IGP ASPATH: 2152 3356 3223 7545 NEXT_HOP: 137.164.16.84 ATOMIC_AGGREGATE AGGREGATOR: AS7545 10.20.23.131 COMMUNITY: 2152:65495 2152:65497 2152:65499 2152:65511 3356:2 3356:22 3356:100 3356:123 3356:515 3356:903 3356:2088 ANNOUNCE 220.240.123.0/24 … (truncated for space)
In this second example below, GTT (AS3257) normally receives this Yahoo (AS10310) route over its peering relationship with PCCW (AS3491) in Frankfurt, Germany 3257:54901. Note that this route is prepended by Yahoo towards AS3491 and other transit providers.
TIME: 04/01/25 06:00:01 FROM: 89.149.178.10 AS3257 ORIGINATED: 03/20/25 08:00:33 ORIGIN: IGP ASPATH: 3257 3491 10310 10310 10310 10310 NEXT_HOP: 89.149.178.10 COMMUNITY: 3257:8059 3257:8927 3257:30275 3257:50001 3257:54900 3257:54901 ANNOUNCE 27.123.34.0/23
In the BGP announcement for the same route during the AS3223 leak, AS3257 opts for the shorter leaked route from a peer (AS3356) in Bucharest 3257:54001.
TIME: 04/01/25 07:36:18.286854 FROM: 89.149.178.10 AS3257 ORIGIN: IGP ASPATH: 3257 3356 3223 10310 NEXT_HOP: 89.149.178.10 COMMUNITY: 3257:8099 3257:30658 3257:50001 3257:54000 3257:54001 ANNOUNCE … 27.123.34.0/23 …
Both of these examples involve cases of needless prepending contributing to leak propagation.
Now, let’s zoom out and see what this routing change looks like in the aggregate. Using Kentik’s BGP visualization, shown below, we can see how the internet reached AS10310 for 27.123.34.0/23 around the time of the leak.
While the lower portion of the visualization shows a pruned ball-n-stick AS-level diagram, the upper graph depicts the ASes observed upstream of AS10310 for this route by count of BGP vantage points. The evidence of the leak is marked in orange boxes.
Let’s look at another example visualized below.
207.180.128.0/24 is announced by RCN (AS6079) and is normally only seen by about 50% of BGP sources in Routeviews. Oftentimes, routes with limited propagation are sometimes called “regional routes,” — intended only to direct traffic for a part of the world — it’s not clear that explains the limited propagation in this case.
The problem for routes with limited propagation like this one is that when someone leaks these routes, they spread widely due to the lack of contention as a result of the limited propagation. This manifests as the hump in the stacked plot below as AS3223 temporarily appears that the world’s most popular upstream of AS6079 for this and the other leaked routes with limited propagation.
Since regional routes are often more-specifics of less-specific routes (used to handle traffic outside of the region), they tend to attract a lot of traffic, leading to traffic disruption. Regional routes are risky for that reason.
Traffic
One of the amazing things that Kentik has the ability to do is to take a BGP incident and analyze its impact on internet traffic. Using Kentik’s unique aggregated NetFlow data, we can peer into the impact on internet traffic, specifically how much traffic was misdirected vs dropped entirely.
During ingest, Kentik annotates each NetFlow record with the AS path of the destination IP from the perspective of the router producing the NetFlow. This allows us to then make a query that retrieves NetFlow records which were annotated with AS paths that match the leak.
Let’s first take a look at all of the traffic that was sent along AS paths with the subsequence “3356 3223” by the top destination country. Running that query across our aggregate NetFlow yields the following graph with South Korea (40.1%), Vietnam (15.5%), Myanmar (10.5%), and Hong Kong (5.4%) as the top three impacted destination countries in bits/sec.
When we look at all of the traffic destined for IP space contained in the top leaked routes, we can gain a sense of how much traffic was misdirected versus dropped altogether. (Note: in this case, I focused on traffic destined for the top 500 leaked routes seen by the most Routeviews sources.)
In the graphic below, a steady state of traffic flows from our customers’ networks to these routes. During the leak, the overall amount of traffic drops due to its disruptive effect. Marked along the bottom, we can also see a smaller portion of traffic sent to routes with the leak in the AS paths. This is the portion of traffic that is misdirected but ultimately reaches its destination.
I have found that, often the case with routing leaks like these, the amount of traffic that is dropped or disrupted exceeds the amount that is misdirected. Traffic gets dropped during leaks because an unexpected volume of traffic is directed down a link that isn’t adequately provisioned to handle it.
We don’t know where the bottleneck was exactly along the leak path (“3356 3223”), but likely, something got overwhelmed, and packets couldn’t be delivered where they needed to go in a timely manner.
Call to action
The BGP leak analyzed in this post can be referred to as a “path leak” or “adjacency leak,” meaning that the mistake occurred in the middle of the AS path, not at the beginning (rightmost ASN). And since no routes were mistakenly originated in a problematic way, origin-based solutions like RPKI ROV would not be in a position to help.
Another tool in the routing hygiene toolkit is the proposed configuration parameter, BGP Role as defined in RFC 9234. It defines an optional, transitive BGP Path Attribute, called “Only to Customer” or OTC in a BGP announcement.
How it would work is this: AS3223 would accept routes from its peers marked with the OTC attribute, signaling to AS3223 that those routes should only be sent to its direct customers. If AS3356 were to somehow receive routes marked with the OTC Attribute from its customer AS3223, it would immediately know these routes were leaked and not accept them.
Technologies like RFC 9234 and ASPA are mechanisms that help reduce the disruption caused by the inevitable BGP mishap.
