How BGP Route Leaks Happen and How They're Prevented

A BGP route leak occurs when a network propagates BGP route announcements beyond their intended scope. Unlike a BGP hijack, where an attacker falsely claims to originate someone else's IP space, a route leak involves legitimate routes being forwarded to the wrong neighbors — violating the implicit or explicit routing policies agreed upon between networks. The result can be just as devastating: traffic for major services rerouted through networks that were never meant to carry it, causing congestion, outages, and potential interception.

Route leaks are one of the most common and damaging classes of BGP incidents. They typically stem from misconfigurations rather than malice, but the distinction offers little comfort when millions of users lose connectivity. Understanding how they happen — and the layered defenses designed to prevent them — is essential knowledge for anyone operating or studying internet infrastructure.

Route Leaks vs. BGP Hijacks

The terms "route leak" and "BGP hijack" are sometimes used interchangeably, but they describe distinct failure modes:

• BGP hijack — A network announces a prefix it does not own as if it were the origin. The AS path shows a false origin AS. RPKI Route Origin Validation (ROV) can detect and prevent this because the origin AS will not match the Route Origin Authorization (ROA).
• Route leak — A network receives a legitimate route from one neighbor and incorrectly re-announces it to another neighbor in violation of the intended routing policy. The origin AS remains correct, and the AS path is technically valid — it simply traverses networks it should not. RPKI ROV alone cannot detect this because the origin is legitimate.

RFC 7908 formally defines a route leak as "the propagation of routing announcement(s) beyond their intended scope." The key word is scope — every BGP announcement comes with implicit or explicit expectations about where it should and should not be forwarded, and a route leak violates those expectations.

The Gao-Rexford Model: Understanding Routing Relationships

To understand why route leaks happen, you need to understand the economic relationships that govern BGP. The Gao-Rexford model, formalized by Lixin Gao and Jennifer Rexford in 2001, describes three fundamental types of relationships between autonomous systems:

Customer-Provider

A customer pays a provider (also called a transit provider) to carry its traffic to the rest of the internet. The provider announces the customer's routes to all of its own neighbors — other providers, peers, and customers. The customer, in turn, announces only its own routes and its customers' routes to the provider. Examples: a small ISP buying transit from Lumen (AS3356), or an enterprise buying from a regional ISP.

Peer-Peer (Settlement-Free)

Two networks of roughly comparable size agree to exchange traffic destined for each other's customers at no cost — this is settlement-free peering. Each peer announces only its own routes and its customers' routes to the other. Neither peer announces routes learned from the other peer to its own providers or other peers. This restriction is critical: violating it is the most common form of route leak.

The Valley-Free Rule

The Gao-Rexford model establishes the valley-free property: a valid AS path should go "up" through providers, optionally cross a single peering link, then go "down" through customers. It should never go up-down-up — that is, a route learned from a provider should not be re-announced to another provider, because that would turn the announcing network into a free transit link.

In the diagram above, AS64500 is a customer of Tier 1 Provider A. It learns routes from Provider A (including routes to the Target Network reachable via Provider B). A properly configured AS64500 would only announce its own prefixes and its customers' routes to Provider A. But if it misconfigures its BGP filters and re-announces Provider A's routes to Provider B — or worse, announces all learned routes to another provider — it becomes an unintended transit path. Traffic that should flow directly between the two Tier 1 providers now detours through AS64500, which likely lacks the capacity to handle it.

Real-World Route Leak Incidents

Route leaks are not theoretical — they have caused some of the internet's most prominent outages.

Pakistan Telecom and YouTube (2008)

In February 2008, the Pakistani government ordered ISPs to block YouTube. Pakistan Telecom (AS17557) attempted to comply by announcing a more specific prefix for YouTube's IP space — 208.65.153.0/24 — to null-route traffic internally. However, the announcement was not contained: it leaked to Pakistan Telecom's upstream provider, PCCW (AS3491), which propagated it globally. Because the /24 was more specific than YouTube's /22, routers worldwide preferred Pakistan Telecom's route, effectively black-holing YouTube traffic globally for approximately two hours.

This incident is frequently cited as a BGP hijack because the origin AS was wrong (Pakistan Telecom instead of YouTube's AS36561), but the root cause was a route leak — the announcement should never have left Pakistan Telecom's network. It exposed how a single operator's internal routing decision, combined with missing export filters on a transit provider, could take down a global service.

Verizon / AS396531 and Cloudflare (June 2019)

On June 24, 2019, a small Pennsylvania ISP called AS396531 (Allegheny Technologies, later identified as a DQE Communications customer) leaked over 20,000 BGP routes to its transit provider. These routes included prefixes for Cloudflare (AS13335), Amazon, and other major networks. The routes were learned through an Optimum (AS6128) BGP session and should not have been re-announced.

Critically, the transit provider in this chain — Verizon (AS701), a Tier 1 network — accepted all of these routes without filtering. Because Verizon is a major transit provider with extensive peering, the leaked routes propagated widely. Traffic for Cloudflare and other affected networks was funneled through a small ISP that lacked the bandwidth to carry it, causing significant packet loss and service degradation for a substantial portion of internet users. The incident lasted for roughly three hours.

Cloudflare's post-mortem was blunt: Verizon should never have accepted 20,000 prefixes from a small customer ASN. Basic prefix-limit filters would have prevented the propagation entirely.

Google's Leaked Nigerian Prefixes (November 2018)

On November 12, 2018, Google (AS15169) accidentally leaked internal network prefixes through a Nigerian ISP, MainOne (AS37282). The leak involved Google's own traffic engineering prefixes being announced via a BGP session that was being configured. Traffic for Google services was redirected through MainOne's infrastructure and its upstream provider, China Telecom (AS4809), for approximately 74 minutes. Although Google's RPKI ROAs were in place, many networks along the path did not perform ROV, so the invalid routes were accepted anyway.

Telekom Malaysia (June 2015)

On June 12, 2015, Telekom Malaysia (AS4788) leaked over 170,000 prefixes learned from its peers and transit providers to its upstream provider, Level 3 (now Lumen, AS3356). Level 3 accepted and propagated these routes. Because the leaked paths were artificially short (having fewer hops than the legitimate paths through proper transit), networks worldwide preferred the leaked routes. The result was a widespread internet outage affecting services across Asia, Europe, and North America for several hours.

Rostelecom Leak (April 2020)

Russian state-controlled ISP Rostelecom (AS12389) leaked BGP routes for over 8,800 prefixes belonging to more than 200 CDNs and cloud providers, including Cloudflare, Amazon, and Akamai. The leaked routes passed through several upstream providers before being withdrawn approximately one hour later. Whether this was a misconfiguration or deliberate interception remains debated, but the mechanism was a classic route leak — routes learned from peers and providers being re-announced to other providers.

Why Route Leaks Are Hard to Prevent

Route leaks persist because of fundamental aspects of how BGP operates:

• No relationship encoding in BGP — The BGP protocol itself does not carry information about the business relationship between neighbors. A router receiving a route announcement has no way to know whether the sender is acting as a customer, peer, or provider, and therefore cannot automatically enforce valley-free routing.
• Trust-based filtering — Export filters (which routes a network sends to which neighbors) are configured manually by operators. A single misconfiguration — a missing filter, a wrong community tag, a fat-fingered route map — can cause a leak.
• RPKI does not help — RPKI ROV validates the origin AS of a route, but route leaks preserve the correct origin. The prefix 1.1.1.0/24 originated by AS13335 is still RPKI-valid whether it arrives via the legitimate path or via a leaked path through an unintended transit network.
• Cascading acceptance — Even if one network leaks routes, the damage depends on whether upstream providers accept and propagate them. Large transit providers that fail to filter their customers' announcements amplify leaks massively.

Defense Layer 1: IRR Filtering

The Internet Routing Registry (IRR) is a distributed set of databases (maintained by RIRs and independent operators) where network operators publish their routing intentions. An IRR entry declares which prefixes an AS is authorized to originate and which ASes it may include in its AS path.

Transit providers can use IRR data to build prefix filters for their customers. Before accepting routes from a customer, the provider queries the IRR to determine which prefixes the customer has registered, and rejects any announcements not in that set.

IRR filtering has significant limitations:

• Voluntary and often stale — There is no requirement to keep IRR data current. Many entries are outdated, and some prefixes are registered by entities that no longer control them.
• No cryptographic authentication — Unlike RPKI, IRR entries are not cryptographically signed. Anyone can register objects, and there is limited verification of authorization.
• Inconsistent adoption — Some regions (especially those covered by RIPE NCC) have strong IRR practices. Others have minimal adoption.

Despite these limitations, IRR filtering remains one of the most widely deployed defenses against route leaks. Networks that rigorously filter their customers' announcements based on IRR data significantly reduce the blast radius of leaks.

Defense Layer 2: Prefix Filters and Max-Prefix Limits

Prefix Filters

A prefix filter is a list of specific prefixes that a BGP neighbor is allowed to announce. Transit providers typically build these from IRR data or direct agreements with customers. If a customer tries to announce a prefix not on the list, the announcement is silently dropped.

The Verizon/AS396531 incident in 2019 would have been prevented if Verizon had maintained a prefix filter for its customer. A small ISP should not be announcing 20,000 prefixes, and a filter based on the customer's registered prefixes would have rejected the leaked routes immediately.

Max-Prefix Limits

A max-prefix limit is a safety mechanism where a BGP session is automatically shut down if a neighbor sends more prefixes than a configured threshold. For example, if a customer is expected to announce 10 prefixes, the provider might set a max-prefix limit of 20. If the customer suddenly starts announcing 20,000 routes (due to a leak or misconfiguration), the session is torn down immediately, containing the damage.

Max-prefix limits are a blunt but effective safeguard. They do not tell you which routes are bad — they simply detect that something has gone very wrong and cut the connection. Most BGP implementations support them natively, and they are recommended by MANRS (Mutually Agreed Norms for Routing Security) as a baseline practice.

Defense Layer 3: RPKI and Route Origin Validation

While RPKI ROV cannot directly detect route leaks (because the origin AS remains correct), it serves as a complementary defense:

• Max-length constraints — A ROA can specify a maximum prefix length, preventing deaggregation attacks where leaked routes are accompanied by more-specific announcements.
• Baseline validation — By ensuring origin AS correctness, RPKI eliminates one class of error that can accompany leaks (where the leaking network accidentally prepends or modifies the origin).
• Building block for ASPA — RPKI provides the certificate infrastructure that ASPA (described below) uses to authenticate provider relationships.

You can check the RPKI status of any prefix using the looking glass. Prefixes with valid ROAs show a green RPKI badge — but remember, a valid RPKI status does not guarantee the path is correct, only the origin.

Defense Layer 4: BGP Communities

BGP communities are tags attached to route announcements that carry metadata about how a route should be treated. Networks use communities to signal routing intent — for example, a customer might tag routes with a community meaning "do not announce to peers" or "announce with prepending to AS X."

Large transit providers define extensive community schemes that allow customers to control how their routes are propagated. However, communities are advisory — they depend on the receiving network honoring them. A misconfigured network that leaks routes may also strip or ignore community tags, undermining this defense.

Some standard community values defined in RFC 1997 and extended communities (RFC 4360) are widely recognized, but there is no universal standard for route-leak prevention communities. This is a policy coordination problem, not a protocol limitation.

Defense Layer 5: ASPA (Autonomous System Provider Authorization)

ASPA is an extension to RPKI that directly addresses route leaks. Where ROAs declare "AS X is authorized to originate prefix Y," ASPA objects declare "AS X has provider Z" — encoding the customer-provider relationship that the Gao-Rexford model relies on.

With ASPA, a network publishes a signed list of its authorized transit providers in the RPKI repository. When a receiving network validates a route, it can check whether each hop in the AS path represents a legitimate customer-to-provider or peer-to-peer transition. If a route's path violates the valley-free property — for example, going from a provider to a non-customer to another provider — the route can be classified as a leak and rejected.

ASPA is currently progressing through the IETF standardization process (draft-ietf-sidrops-aspa-verification). Several implementations already exist in routing software (OpenBGPd, BIRD, and others are adding support), and early deployers have begun publishing ASPA objects. ASPA is considered the most promising near-term solution for route leak prevention because it is lightweight (unlike BGPsec), incremental (each AS can deploy independently), and builds on the existing RPKI infrastructure.

How ASPA Differs from BGPsec

BGPsec was an earlier proposal to cryptographically sign every hop in the AS path. While technically rigorous, BGPsec requires every AS in the path to support it (it is not incrementally deployable), imposes significant computational overhead on routers, and breaks AS path prepending. These drawbacks have limited deployment to near zero.

ASPA takes a pragmatic approach: instead of signing paths, it verifies the relationship between adjacent ASes in the path. This is sufficient to detect valley-free violations — the defining characteristic of route leaks — without requiring universal deployment or per-update cryptographic operations.

Defense Layer 6: BGP Roles (RFC 9234)

RFC 9234, published in 2022, introduces the concept of BGP Roles — a way for two BGP neighbors to explicitly agree on their relationship when establishing a session. Each side declares its role (Provider, Customer, Peer, Route Server, or Route Server Client), and the roles must be compatible for the session to come up.

Once roles are established, RFC 9234 enables automatic route leak prevention through the Only to Customer (OTC) attribute. When a route is sent to a peer or provider, the OTC attribute is set with the AS number. If a downstream AS receives a route with OTC already set and tries to send it to a peer or provider, the route is automatically suppressed — because OTC indicates the route has already traversed a peer or provider link and should only flow toward customers.

Key properties of BGP Roles:

• Negotiated in BGP OPEN — Roles are exchanged during session establishment using a new capability. If the roles conflict (e.g., both sides claim to be Provider), the session is rejected.
• Automatic OTC marking — Routers automatically add the OTC attribute when sending routes to peers or providers, and reject routes with OTC when they would be re-announced to peers or providers.
• Incremental deployment — Each BGP session can independently adopt roles. You do not need universal deployment; each session that negotiates roles gets leak prevention for that link.
• No external database dependency — Unlike ASPA (which requires RPKI infrastructure) or IRR filtering (which requires database queries), BGP Roles work purely within the BGP protocol.

BGP Roles and ASPA are complementary. Roles prevent leaks at the source (the session where the leak would originate), while ASPA allows remote networks to detect leaks by validating the path. Together, they provide defense in depth.

Operational Best Practices

No single mechanism prevents all route leaks. Robust defense requires layering multiple approaches:

For Transit Providers

• Filter customer announcements — Build prefix filters from IRR data and RPKI ROAs. Never accept unfiltered routes from a customer.
• Set max-prefix limits — Configure per-session limits based on the customer's expected prefix count, with a reasonable margin (e.g., 2x).
• Perform RPKI ROV — Drop or deprioritize RPKI-invalid routes. This catches hijacks that may accompany leaks.
• Deploy BGP Roles — Negotiate roles on all customer and peer sessions to enable automatic OTC-based leak prevention.
• Monitor for anomalies — Use BGP monitoring tools to alert on sudden changes in prefix count, AS path patterns, or traffic volume on customer sessions.

For Network Operators (All Sizes)

• Maintain IRR objects — Keep your route/route6 and aut-num objects current in the appropriate IRR database.
• Publish ROAs — Create RPKI ROAs for all your prefixes with appropriate max-length settings.
• Publish ASPA objects — Declare your authorized transit providers in the RPKI repository.
• Implement strict export filters — Only announce your own prefixes and your customers' prefixes to transit providers and peers. Never re-announce routes learned from one provider to another.
• Join MANRS — The Mutually Agreed Norms for Routing Security initiative provides guidelines and tools for implementing routing security best practices.

For Monitoring and Detection

• BGP looking glasses — Use tools like this looking glass to verify your routes appear correctly from external vantage points.
• BGP stream analysis — Services like RIPE RIS, BGPStream, and Cloudflare Radar provide real-time visibility into routing changes.
• Alerting — Configure alerts for unexpected origin changes, new AS path elements, and RPKI validation state changes for your prefixes.

The Current State of Route Leak Prevention

As of 2026, the internet's defenses against route leaks are stronger than ever but remain incomplete:

• RPKI ROV adoption has reached critical mass, with most major transit providers and content networks performing validation. However, ROV alone does not prevent leaks — only origin hijacks.
• IRR filtering is widely practiced by large transit providers, though coverage and data quality vary significantly by region.
• Max-prefix limits are a baseline practice at well-run networks but are not universal.
• ASPA is in active deployment phase, with growing support in routing software and increasing publication of ASPA objects. Full effectiveness requires broader adoption.
• BGP Roles (RFC 9234) are supported in several major routing platforms and are being rolled out incrementally.

The trend is toward a layered defense model where no single mechanism is sufficient, but the combination of RPKI ROV, ASPA, BGP Roles, IRR filtering, and operational practices like max-prefix limits dramatically reduces the likelihood and impact of route leaks.

Investigate Routes Yourself

Understanding route leaks requires understanding how routes normally propagate. Use the BGP looking glass to examine real routing data — look at AS paths, check RPKI validation status, and explore how major networks are interconnected through peering and transit relationships.

• AS13335 — Cloudflare: heavily peered, a frequent target of route leaks
• AS3356 — Lumen (Level 3): a major Tier 1 transit provider whose filtering policies affect global routing
• AS701 — Verizon: involved in the 2019 route leak incident
• 1.1.1.1 — Check the AS path and RPKI status for Cloudflare's DNS
• 8.8.8.8 — Verify Google DNS routing from multiple vantage points