Skip to content

CONCEPT Cited by 1 source

Route leak

A route leak is a BGP advertisement propagated beyond its intended scope — formally defined in RFC 7908 as "the propagation of routing announcement(s) beyond their intended scope."

What "intended scope" means

Intended scope is set by pairwise business relationships between ASes:

  • In a customer→ provider relationship, the customer should advertise only its own routes and routes of its own customers.
  • In a peer↔peer relationship, each peer should advertise only its own routes and routes of its own customers.

A route leak violates one of these rules. Traffic still typically reaches its destination, but the path is unintended — often longer, slower, and saturating a network that wasn't sized for the carried transit volume.

Wrong-exit-off-highway analogy

Per the Cloudflare post: "BGP route leaks cause behavior similar to taking the wrong exit off of a highway. While you may still make it to your destination, the path may be slower and come with delays you wouldn't otherwise have traveling on a more direct route."

Types in RFC 7908

RFC 7908 enumerates six types. The canonical example and the one Cloudflare dissects is:

  • Type 1 — Hairpin leak between two providers by a customer. An AS takes routes from one of its providers and re-advertises them to its other provider, forming a "valley" in the AS path (customer → provider → ... → provider).

Usually accidental, sometimes attack

Most route leaks are the result of loose export policies that over-advertise routes learned from indirect sources. Cloudflare's 01-02 Venezuela event argument names the specific hygiene failure: an IRR-derived prefix list that matches the customer cone by prefix set but does not additionally require a customer BGP community tag — so routes that are in the prefix set but were learned indirectly via a provider slip through.

Leaks can also be malicious (traffic interception, MITM) but several forensic signals typically distinguish the two — see the alternative-explanation forensics pattern.

Mitigation

  • ROV doesn't help — Route Origin Validation only checks the originator of a prefix; route leaks have a legitimate originator and only the path is wrong.
  • ASPA (Autonomous System Provider Authorization) provides path validation — each AS publishes its authorized upstreams, and path validators can reject leak-shape paths.
  • RFC 9234 OTC adds BGP roles
  • an Only-To-Customer attribute enforced at session setup.
  • Peerlock / Peerlock-lite — simpler operator-side filters (e.g. "reject customer-learned routes containing a Tier-1 ASN in the path").

Seen in

Last updated · 200 distilled / 1,178 read