Be gone, AS_SETs!

▼ As I was writing my RPKI path validation draft last week, I considered the issue of filtering BGP AS paths with AS_SETs in them.

For those of you who haven't read the BGP specification recently, the idea is that if a BGP router takes a bunch of prefixes and aggregates these into a single prefix, it then adds the AS numbers in the AS paths of the original prefixes to the AS path of the new prefix in the form of an AS_SET. The AS_SET has all the AS numbers in it so loops can be detected, but for the purposes of comparing the AS path length, the AS_SET counts as a single AS hop, regardless of the number of ASes in the AS_SET. (Or the router can leave out one or more ASes and then set the ATOMIC_AGGREGATE attribute instead.)

I think aggregation was added to BGP-4 as a way to start shrinking the BGP table while BGP-3 was still in use. BGP-4 added Classless Inter-Domain Routing (CIDR), allowing it to advertise (for instance) 16 class C networks to be advertised as a /20 prefix.

However, aggregation is the easy part, you also need to get rid of those original unaggregated prefixes (the 16 class C /24s in the above example). As these may also be advertised over other paths, that's very difficult. As such, there's really not much point to this type of aggregation, and thus, no point to using AS_SETs. In fact, I didn't even mention them in my book.

Turns out that I'm not the only one who feels AS_SETs are unnecessary: there's an RFC saying the exact same thing: RFC 6472.

Of course this being the internet, the fact that AS_SETs are of no use doesn't mean people don't use them. This is what I got from RouteViews just now:

>route-views>sh ip bgp | incl {
 *   5.28.128.0/20    203.181.248.168    0 7660 2516 3356 1299 12849 {12849} i
 *   5.28.144.0/22    203.181.248.168    0 7660 2516 3356 1299 12849 {12849} i
 *   5.39.176.0/21    203.181.248.168    0 7660 2516 3356 8530 {198753} i
...

There's currently 377 out of 803582 prefixes with AS_SETs in them in the global IPv4 routing table (0.046%), and 31 of 73138 in the IPv6 BGP table (0.042%).

Note that you can filter on an AS in an AS_SET with a Cisco BGP AS path regular expression like _8111_. The _ also matches the { and } that surround an AS_SET as well as the commas separating AS numbers in an AS_SET. However, if you filter a customer's AS path like this, as I always recommend:

^(65537_)+$

it won't work, as there is nothing to match the { in this regular expression. Which is fine, there's really no good reason to use AS_SETs.

Permalink - posted 2019-06-24

Path validation with RPKI draft

▼ Last week, I suggested it's time fix those BGP route leaks. I live by the words everybody complains about the weather, but nobody does anything about it, so as such I wrote an Internet-Draft with the protocol changes necessary:

draft-van-beijnum-sidrops-pathrpki-00

I think we can stop these route leaks with a relatively modest change to RPKI: by combining the ASes the origin trusts and the ASes the operator of an RPKI relying party server trusts, we have a list of all the ASes that may legitimately appear in the AS path as seen from this particular vantage point.

I believe deployment will be relatively easy, as it works for the two ASes at both ends even if ASes in the middle don't participate.

There is path filter example code in the appendix to show that this part is easy. 😀

You can see that filter code in action here:

http://bgpexpert.com/pathrpki/

I'm looking forward to hearing feedback. I've started discussions on the RIPE routing-wg mailinglist and the IETF sidrops working group mailinglist. Also feel free to mail me directly or talk to me on Twitter.

Permalink - posted 2019-06-20