Route leaks: what they are and why they matter
Inter-domain routing depends on the Border Gateway Protocol (BGP), which assumes that networks exchange genuine and trustworthy reachability information. That assumption no longer holds. Networks can misconfigure their announcements or deliberately propagate false routes, and the consequences can disrupt Internet operations at scale. One prominent category of such incidents is route leaks: the propagation of routing announcements beyond their intended scope, as defined in RFC7908.
Route leaks are not abstract risks. In June 2019, a small network in Pennsylvania (AS396531 - Allegheny Technologies Inc) leaked a Cloudflare prefix to Verizon, which then propagated the route to its peers and customers. Traffic intended for Cloudflare was squeezed through the limited links of that small network, causing most traffic to the affected IP range to be dropped. A similar incident in November 2018 knocked Google offline for over an hour when a Nigerian ISP (AS37282 - Mainone) accidentally leaked a large number of Google prefixes to its peers and providers, violating the valley-free principle.
These examples show both the impact of route leaks and the snowball effect that a misconfiguration in one regional network can have on the global Internet. The difficulty in detecting and preventing route leaks stems from the fact that AS business relationships and BGP routing policies are generally undisclosed, and the network that suffers the impact is often remote from the source of the leak. Several proposals, including RFC9234 and ASPA, aim to prevent the propagation of leaked routes by annotating BGP sessions with relationship types or using BGP Communities to encode metadata. These approaches are promising but not yet adopted at scale.
Cloudflare has developed a system to detect route leak events automatically and feed the results into multiple channels. Today we are announcing an open data API for these detections, with the results also integrated into Cloudflare Radar ASN pages.
How route leaks are classified
To define route leaks, we use the IETF's published classification in RFC7908 ("Problem Definition and Classification of BGP Route Leaks").
A route leak is the propagation of routing announcement(s) beyond their intended scope.
The intended scope is usually defined by the business relationships between Autonomous Systems (ASes), which fall into four broad categories: customers, transit providers, peers, and siblings. In a customer-provider relationship, the customer pays the provider to transit its traffic to the global routing table. In a peer-to-peer relationship, two ASes exchange traffic for free, but only for their own IPs and those of their customers. ASes under the same administration are siblings and exchange traffic without restriction.
These relationship types translate into sequential phases of a route's propagation from its origin to its destinations:
- upward: all path segments are customer to provider
- peering: one peer-to-peer path segment
- downward: all path segments are provider to customer
A compliant AS path follows the valley-free routing principle, with the upward, peering, and downward phases in strict order (each phase is optional). For example:
RFC7908 defines six types of route leaks. Our system uses these definitions. Types 1 through 4 are illustrated below; types 5 and 6 are handled separately (see the note at the end).
Type 1: Hairpin Turn with Full Prefix
A multihomed AS learns a route from one upstream ISP and simply propagates it to another upstream ISP. Neither the prefix nor the AS path is altered.
An AS path containing a provider-customer segment followed by a customer-provider segment is a type 1 leak. For example, AS4 → AS5 → AS6 forms a type 1 leak.
Type 1 leaks are the most common and impactful. Because customer routes are generally preferred over peer or provider routes, downstream networks will prefer the leaked path, turning the leaking AS into an unintentional transit provider. If that AS is not provisioned for the increased traffic, performance degrades or outages follow. In June 2015, Telekom Malaysia (AS4788) leaked over 170,000 routes from its providers and peers to its provider Level3 (AS3549, now Lumen). Level3 accepted the routes and propagated them to its downstream networks, causing significant global network issues.
Type 2: Lateral ISP-ISP-ISP Leak
A type 2 leak occurs when routes obtained from one peer are propagated to another peer, creating two or more consecutive peer-to-peer path segments. For example, AS3 → AS4 → AS5 forms a type 2 leak.
Such leaks are indicated when very large networks, which do not purchase transit from each other, appear in sequence on a path. However, multiple small peering networks legitimately exchange routes among themselves. We are less concerned about type 2 leaks than type 1.
Types 3 and 4: provider/peer routes to the wrong neighbor
Type 3 and type 4 leaks involve propagating routes from a provider or a peer to another peer or provider, rather than only to customers.
The 2018 Nigerian ISP incident with Google is an example of a type 4 leak. The ISP, which peered with Google, accidentally leaked Google's route to its provider (AS4809). The provider, preferring customer routes, rerouted its Google-bound traffic via the leaking ISP, overwhelming it and taking Google down for over an hour.
Summary of leak types
All four types of route leaks share a common definition based on AS relationships. The table below classifies route leak types by where routes are learned and where they are propagated.
The entire table condenses to a single rule: routes obtained from a non-customer AS can only be propagated to customers.
Note: Type 5 and type 6 route leaks are defined as prefix re-origination and announcing of private prefixes. Type 5 is more closely related to prefix hijackings, which we plan to address next. Type 6 leaks are outside the scope of this work. For details, refer to sections 3.5 and 3.6 of RFC7908.
Inside Cloudflare's route leak detection pipeline
Cloudflare's route leak detection system is organized into three functional layers: data collection, leak detection, and storage/notification. The collection layer ingests BGP data, the detection layer evaluates individual announcements against routing policies, and the storage layer aggregates findings into events for downstream consumers like dashboards and APIs.
BGP data ingestion
The system draws from three categories of BGP data. Historical archives from RouteViews and RIPE RIS provide the baseline. Semi-real-time feeds deliver the same archive files as soon as they are published, typically within 10–30 minutes of collection. Real-time streams come from RIPE RIS Live and Cloudflare's internal BGP sources.
The current detection pipeline runs on semi-real-time data, processing update files from all public collectors in both projects — 63 collectors with over 2,400 peers. An on-premises BGPKIT Broker instance handles file indexing with Kafka for message passing. A custom concurrent MRT processing pipeline built on the BGPKIT Parser Rust SDK converts the binary archives into a stream of BGP messages, handling over two billion messages per day at roughly 30,000 per second.
Determining whether an announcement is a leak
Detection operates at the level of individual BGP announcements. Each message is examined to estimate the likelihood that it stems from a route leak event. The core algorithm relies on the valley-free model, which captures most significant leak incidents. The model's accuracy depends on knowing the business relationships between ASes — customer, provider, or peer — which are not publicly declared by every network.
Relationship inference from public BGP observations has been studied for over two decades, and modern algorithms are highly accurate. But even small inference errors can create false positives in leak detection. To reduce this, Cloudflare combines multiple AS relationship sources: CAIDA/UCSD's AS relationship dataset and an in-house dataset. These are further refined into per-prefix, per-peer relationship data, removing ambiguity for networks that maintain different relationships depending on the prefix or geographic region. The system also applies the AS Hegemony dataset from IHR IIJ as an additional false-positive filter.
Event storage and presentation
Validated leak entries are stored in a database. Individual announcements from the same leaking ASN within a short window are aggregated into route-leak events, which are then exposed through downstream applications including web interfaces, an API, and alerting systems.
Route leak visibility on Cloudflare Radar
The route leak detection system is now available as a public beta. Users visiting Cloudflare Radar ASN pages will see a list of route leaks affecting that AS. An AS is considered affected when the leaking AS is one hop away from it in either direction along the path.
ASN pages are directly accessible via https://radar.cloudflare.com/as{ASN} — for example, https://radar.cloudflare.com/as174 shows the overview page for Cogent. The page includes a dedicated card for route leaks detected within the selected time range.
Programmatic access is available through the public route leak events API, which supports filtering by time range and involved ASes. The API documentation is hosted on the Cloudflare Developers site.
Planned expansions for routing security
Cloudflare plans additional route leak features, including a global view page, notifications, more advanced API capabilities, automation scripts, and historical archive datasets. Feedback from the community will shape ongoing improvements to detection accuracy.
Beyond route leaks, the company is expanding work on other routing security topics: global BGP hijack detection outside its own customer networks, RPKI validation monitoring, open-sourcing tools and architecture designs, and a centralized routing security web gateway.
The Cloudflare team has opened a dedicated Radar room on its Developers Discord Server for questions and feedback on the new service.
