While preparing the Internet Routing Security webinar, I stumbled upon RFC 7908, containing an excellent taxonomy of BGP route leaks. I never checked whether it covers every possible scenario¹, but I found it a handy resource when organizing my thoughts.

Let’s walk through the various leak types the authors identified using the following sample topology:

Hairpin turn: a customer lacks output filters and propagates routes between two service providers (example: Cust-AB propagates ISP-A routes to ISP-B). Depending on the upstream connectivity of the ISPs, the path through the customer AS might result in the shortest AS path. Even worse, many service providers prefer customer routes over peer routes regardless of AS path length²

Lateral leak: a service provider is leaking peer routes (example: ISP-B forwards ISP-A prefixes to ISP-C), and its peers usually accept them as best routes:

• AS path on a lateral leak is shorter than the paths going through the transit providers
• Nobody in their right mind would prefer transit routes (where they’re paying for traffic or bandwidth) over settlement-free peer routes.

Everyone involved in a lateral leak should be grateful that a kind soul provides free transit connectivity. Unfortunately, that kind soul usually forgets to provision its peer links accordingly, resulting in congestion and customer complaints.

Peer-transit leaks: a service provider is leaking peer routes to its upstream transit provider (or vice versa). In our topology, ISP-B would leak routes between ISP-A and Trans-2. The transit provider would often prefer leaked routes (coming from its customer), and the peer ISP would probably choose them due to the shorter AS path length.

As before, karma punishes the kind soul providing free transit with extra traffic charges, and everyone gets yelled at due to inevitable link congestion. Not exactly a fun day in the office.

Lack of routing policies (= filters) on EBGP sessions usually cause the abovementioned leaks. Now for some heavy hitters:

Prefix re-origination: an autonomous system advertises third-party prefixes as belonging to itself:

• When someone leaks hundreds of thousands of prefixes, we’re probably dealing with a two-way redistribution gone wrong.
• Dozens or hundreds of more-specific prefixes from different autonomous systems? Probably a gift from someone carelessly playing with prefix deaggregation.
• Just a few prefixes? “Temporary” static routes redistributed into BGP or a malicious hijack.

Please note that since the RFC 7908 was published we encountered another type of prefix deaggregation leak in the wild: a BGP optimizer running with insecure default settings advertises more-specific prefixes with unmodified AS-path.

Finally, there’s the accidental leak of internal- or more-specific prefixes, usually resulting from a missing route map in an IGP-to-BGP redistribution point. We’re probably dealing with this type of leak when someone³ announces an additional 20.000 routes and revokes them a few minutes later. Bonus points for style⁴ if those routes bring the size of the global BGP table over a hardware limit of core Internet routers.

In the next blog posts in this series we’ll discuss individual leak types and tools you can use to avoid them. In the meantime, read RFC 7908 and watch the Internet Routing Security webinar.

Revision History

2023-06-14

As pointed out by Doug Madory in a LinkedIn comment: The Allegheny Technologies leak was not prefix re-origination as the BGP optimizer causing the leak created more-specific prefixes with unmodified AS-path. Added another paragraph specifically pointing out this type of leak.