Ephemeral Leaks and Automated BGP Route Leak Detection

Subscribe

Summary

Many BGP route leaks reported by automated detection systems are actually brief, low-impact artifacts of normal BGP convergence. Doug Madory examines examples from Cloudflare Radar, Routeviews, and Jared Mauch’s long-running leak detector to show how these “ephemeral leaks” arise, why they usually don’t disrupt traffic, and why they still matter for routing security.

In January, following the U.S. seizure of Venezuelan President Nicolás Maduro, a cybersecurity engineer published an analysis noting “BGP anomalies” in Venezuelan network routes on Cloudflare Radar during the day of the raid, suggesting they could be linked to U.S. cyber operations against the country.

Cloudflare later responded in a blog post, explaining that the route leaks cited in the analysis were likely benign incidents that happened to coincide with the U.S. raid.

In this post, I go further: many (perhaps most) of the BGP route leaks reported on Cloudflare Radar (as with its predecessors) are what I term “ephemeral leaks,” brief routing anomalies that exist only momentarily during convergence and have little to no operational impact.

A (Probably) Incomplete History of Public BGP Leak Detection Tools

Internet luminary Jared Mauch was the first to create a free tool that would chew through public BGP data (Routeviews, in his case) to identify leaks by looking for update messages containing problematic AS paths. The tool was not designed to detect misoriginations, but rather to uncover more complex path errors, such as when an AS incorrectly propagates routes from one neighboring AS to another.

In my Brief History of the Internet’s Biggest BGP Incidents post from 2022, I provide some examples of famous BGP leaks, including both misoriginations as well as path errors.

During a Lightning Talk at NANOG 41 in Albuquerque, New Mexico, Jared described his simple methodology: make a list of transit-free ASNs and count how many were present in the AS path. If the count exceeded two, there was a leak since there can only be two or less transit-free ASNs in an AS path without causing a valley-free violation.

Born in the Chihuahuan Desert in 2007, Jared’s spartan BGP Routing Leak Detection System is remarkably still in operation 19 years later.

Andree Toonk, founder of BGPmon, followed Jared’s model for the leak-detection component of his BGPstream service, which was unveiled during a talk at Black Hat in 2015. OpenDNS’s BGPstream service included an automated Twitter account and a (now defunct) website and was focused primarily on reporting on BGP outages and hijacks. Following Cisco’s acquisition of OpenDNS and Andree’s departure to found another company, BGPstream was discontinued.

In 2022, Cloudflare unveiled a new capability within its free Radar site that would report on route leaks using a more sophisticated approach. It first classifies AS-AS relationships and then looks for update messages that include AS paths that violate the valley-free violation, greatly expanding the detection coverage of previous approaches.

The Mad Scramble of BGP Convergence

In routing protocol terminology, convergence refers to the process by which routers reach a new stable and consistent routing state. When a network change occurs (e.g., a link failure or activation), that information must be propagated throughout the network before routers can converge on a new state.

In routing protocol design, faster convergence can be achieved at the cost of increased overhead, such as more frequent update messages or higher computational load on routers. Broadly speaking, the BGP design favors scalability and stability at the cost of slower convergence.

During BGP convergence, routers engage in path hunting, where they sequentially explore backup routes before either settling on a stable path, if one exists, or ultimately withdrawing the route if no valid path remains. This sequential exploration of alternatives is why a route withdrawal triggers far more announcements than withdrawal messages, something I discussed in my post on the Optus outage of 2023, once again addressing another Twitter analyst divining something nefarious on the Cloudflare Radar page:

Perhaps surprisingly, when a route is withdrawn, the number of announcements exceeds the number of withdrawals by an order of magnitude. If we take a look at the plight of the withdrawn Optus prefix from earlier in this post (49.2.0.0/15), we can see the following.

The lower graph tracks the number of Routeviews BGP sources carrying 49.2.0.0/15 in their tables over time. The line begins a descent at 17:04 UTC when the outage begins and takes more than 20 minutes to be completely gone.

Coinciding with the drop in propagation on the bottom, the upper graph shows spikes in announcements and withdrawals — much more of the former than the latter. The spike in BGP announcements was simply the natural consequence of those withdrawals.

What are Ephemeral Leaks?

During the path-hunting phase, thousands of routes with different AS paths are announced by BGP-speaking routers as they scramble for a viable option. I refer to the short-lived options that contain valley-free violations as ephemeral leaks, because they come into existence and often immediately disappear without ever disrupting or misdirecting a single packet.

Like its predecessors, Cloudflare Radar takes a “message-by-message” approach to finding leaks. If a single BGP announcement is found to contain an AS path with a valley-free violation, then a leak is reported. Let’s take a look at an example.

Unfortunately, Cloudflare Radar’s leak detection page oddly doesn’t list the affected prefixes, so I wrote a little utility that uses the ASNs and timings to find the prefixes involved in the leaks in order to enable a little scrutiny.

In the first example, route leak event #497796 refers to 193.201.241.0/24, a prefix that experienced a partial withdrawal beginning around 13:08 UTC on March 31, 2026, as is illustrated in a reachability chart below.

As this prefix begins its withdrawal, Radar detects a leak at 13:08 UTC and publishes the following report, citing that a single prefix (route) was mistakenly passed by AS48452 from AS8262 to AS3257.

Using raw BGP data available via Routeviews, we can see what this leak looked like from one BGP vantage point. The series of abbreviated BGP messages below are color-coded as announcements and a withdrawal (the reported leak in bold).

While different vantage points may experience slightly different timings, in this particular case, neither leaked message was in circulation for more than an entire second.

Or take route leak event #498317, in which a single prefix was mistakenly passed by AS3758 from AS6453 to AS7473 — a clear valley-free violation.

That prefix was 67.215.94.0/24, and this leak occurred soon after it began being withdrawn at 10:22 UTC on April 1, 2026, as is illustrated below.

Again, going to Routeviews data, we can see how this leaked route appeared in the context of the withdrawal from a BGP vantage point that observed it. Again, the series of abbreviated BGP messages below are color-coded as announcements and a withdrawal (the reported leak in bold).

A little more than two seconds this time — a duration I would again classify as ephemeral.

With its signature eggplant favicon (🍆), Jared’s BGP Routing Leak Detection System is still up and running after nearly 20 years. And in it, we can find the same phenomenon of withdrawals triggering ephemeral leaks.

At the time of this writing, one can find the following leak entry (re-written vertically below) which helpfully includes the prefix, Routeviews source file and time. However, I would have preferred it be in UTC, because UTC removes the idiosyncrasies of local time and daylight savings.

The entry above asserts that at 18:28 UTC, AS7713 leaked 103.116.16.0/24 from AS1299 to AS3356, another clear valley-free violation. At that time, 103.116.16.0/24 was still in the process of being withdrawn, as is depicted below.

Here is the path hunting from the perspective of AS2152 as it cycles through options, including the above leak, which lasts for almost a full minute from this vantage point. The abbreviated BGP messages below are color-coded as announcements and a withdrawal (the leaked paths in bold).

It doesn’t have to be a route withdrawal to trigger an ephemeral leak; in fact, any significant routing churn can summon a leaked route into brief existence. Withdrawals, by their nature, trigger a more exhaustive exploration of possible AS paths and therefore create greater potential for ephemeral leaks.

In order to focus on leaks that are the most disruptive, one would need to go beyond analyzing individual messages in isolation. It would require maintaining state to determine duration and propagation of problematic routes in order to weed out what amounts to a lot of innocuous noise from the perspective of operational impact. My friends over at Qrator do a good job of this in their periodic posts about major leaks. I’ve drawn on several of those incidents for my series analyzing leaks, Beyond Their Intended Scope.

That is not to say that there is no value in capturing these incidents, as we will get to later.

Not-so-suspicious BGP Anomalies

With all that said, we return to the January analysis of Venezuela. The primary leak highlighted by the security blogger — and examined in the Cloudflare post by Bryton Herdes — was #462460:

One of the prefixes involved in this leak was 200.74.226.0/24. When we look at what was happening to this prefix at the time, we can see two brief outages represented below by two dips in reachability at 15:35 and 16:31 UTC.

As I suspected at the time, #462460 was another ephemeral leak, although with a slight variance from the ones discussed earlier. The leaked AS path in this event was of the following formats (with a prepended AS8048 appearing nine consecutive times):

What makes this leak different is the fact that it wasn’t really new. At the top of the hour, the leak existed with a slightly different format as AS8048 is a transit customer of both AS52320 and AS23520:

The leak reported under #462460 was an ephemeral version of an existing leak that briefly came into existence at 15:40 UTC as 200.74.226.0/24 was recovering from a temporary withdrawal.

AS52320’s perspective is shown below. The previous leak returned within a minute of the reported leak. It’s leaks all the way down. The abbreviated BGP messages below are color-coded as announcements and a withdrawal (the reported leak in bold).

The reality is that there is a steady drumbeat of ephemeral leaks occurring as a consequence of normal routing churn all over the global internet. As a result, the likelihood of a momentary routing mishap coinciding with an unrelated event like a military operation is greater than one might assume.

Conclusion

Back in 2018 at the APRICOT conference in Kathmandu, Nepal, my friend Alexander Azimov (formerly of Qrator, currently Head of Network R&D at Yandex) and I were gently pushing back on the gaudy stats presented in a talk about the MANRS program, which advocates for routing security.

I argued that many of the leaks pushing the counts into the thousands were merely transient byproducts of normal BGP churn. Azimov, a key architect behind leak mitigation efforts like Autonomous System Provider Authorization (ASPA) and RFC 9234, agreed, but pointed out a value in highlighting these incidents that I had not considered.

He explained that they expose gaps in current routing policy where a more substantive routing leak of the future could get through and cause disruption (a point echoed by Bryton at Cloudflare). Rather than tallying them up into histograms or pie charts, they should be used to alert ASes where they need to improve their safeguards against leaks. The Internet’s backup paths must also be checked for safety.

Path error leaks like the ones described in this post are exactly the kind of routing mishaps that ASPA was designed to address. RPKI ROV can address mis-originations, but can’t do much for properly originated routes sent the wrong way.

Cloudflare Radar recently added a helpful page tracking the adoption of ASPA, and it’s clearly picking up steam. With wider adoption, we can greatly reduce the number of path error leaks, ephemeral and otherwise.

Special thanks to Job Snijders and Alexander Asimov for their input on this post.