Fat-thumbed a BGP entry? Relax, now your pain has a name
RFC gives route leaks names, to help netops explain why traffic goes missing
Users are familiar with those occasional events in which a sysadmin fat-thumb results in traffic getting deep-sixed – like, for example, this week's huge Telia outage.
It's a problem that plagues the Internet and has done for years: the foundational Border Gateway Protocol (BGP) was designed in an era long-gone where sysadmins knew each other by name and learned to trust the route advertisements they handed around.
It exercises the minds of the Druids of the Internet, the IETF, and as a first step towards defining the problem that needs to be fixed, a group of authors (in their own names, but employed by the National Institute of Science and Technology – NIST – and Verisign) have put together a taxonomy of different ways in which route leaks can occur.
The reason for RFC 7908, they say, is that while many events get lumped together under the heading “route leaks”, they're not identical.
“In order to pursue solutions to 'the route-leak problem' it is important to first provide a clear, technical definition of the problem and enumerate its most common forms”.
(They ought to know: one of the authors, Brian Dickson, has put forward at least three RFCs in the past to try and cure the Internet of route leaks.)
“A common form of route leak occurs when a multihomed customer AS (such as AS3 in Figure 1) learns a prefix update from one transit provider (ISP1) and leaks the update to another transit provider (ISP2) in violation of intended routing policies, and further, the second transit provider does not detect the leak and propagates the leaked update to its customers, peers, and transit ISPs”, the document states.
Easy, right? No: because as the rest of the RFC documents, there are plenty of wrinkles that make one route leak different from another.
There are “hairpin turn” leaks (a network – AS, for autonomous system – learns a route from one ISP and “turns it around” to propagate upstream to another ISP); or “lateral” leaks (in which the route leak propagates between peer networks).
The other types enumerated in the RFC (for space, we'll skip the full descriptions given) are:
- Type 3: Leak of Transit-Provider Prefixes to Peer;
- Type 4: Leak of Peer Prefixes to Transit Provider;
- Type 5: Prefix Re-origination with Data Path to Legitimate Origin; and
- Type 6: Accidental Leak of Internal Prefixes and More-Specific Prefixes.
In spite of the often sky-is-falling rhetoric surrounding BGP, The Register notes that the last kind of leak, according to the RFC, happen “multiple times in a week”.
And, of course, next time a big route leak occurs, hacks like yours truly will be able to ask network owners whether the outage was a hairpin bend or a lateral leak. ®