Route leak
termRe-announcing routes beyond their intended scope - typically passing routes learned from one transit provider or peer to another - so a network briefly claims to be a path to far more of the internet than it can carry.
Leaks are usually accidents and are responsible for a large share of the biggest routing outages on record: traffic for major services converges on a network with a fraction of the required capacity and simply drops. The distinction from a hijack is intent, not mechanism, and the defence is identical - prefix filtering by the upstream. The recurring lesson is that the failure is rarely the leaking network; it is the larger provider that accepted and propagated an announcement it should have discarded.
RFC 7908 (June 2016) defines a route leak as the propagation of routing announcements beyond their intended scope; the result can be traffic redirected through an unintended path, open to eavesdropping or traffic analysis, and sometimes overload or a black hole. RFC 9234 puts it in terms of relationships: prefixes propagated in violation of the assumptions of BGP topology relationships, usually through misconfigured or absent route filtering.
RFC 7908 sorts leaks into six types. Types 1 to 4 violate policy and differ in the roles of the ASes involved: a multihomed AS passing a route from one upstream to another (the hairpin turn), a lateral ISP-to-ISP-to-ISP leak, provider routes sent to a peer, and peer routes sent to a provider. Type 5 is re-origination with a data path to the legitimate origin; type 6 is an accidental leak of internal or more-specific prefixes, such as about 22,000 internal routes leaked by AS701 and AS705 in August 2014.
Origin validation does not catch a leak, because the origin is genuine: in Cloudflare's record of 27 June 2024, the leaked 1.1.1.0/24 was RPKI Valid while its path was invalid. RFC 9234 (May 2022) answers with roles agreed in the OPEN message and the Only to Customer (OTC) attribute: a route carrying OTC must not be propagated to providers, peers or route servers.
Also known as: as path leak, transit leak, reannouncement
Sources
- MANRS - Mutually Agreed Norms for Routing Security
- RFC 7908, Problem Definition and Classification of BGP Route Leaks, June 2016: sections 2 to 4 (read 2026-10-19)
- RFC 9234, Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages, May 2022: sections 1, 3.1, 4 and 5 (read 2026-10-19)
- Cloudflare Blog, Cloudflare 1.1.1.1 incident on June 27, 2024, 4 July 2024 (read 2026-10-19)