RPKI tools and deployment

▼ Recently, Cloudflare launched Is BGP safe yet?. And they immediately answer their own question: No.

What they're getting at is RPKI deployment. RPKI is a mechanism that lets the owner of a block of IP addresses specify which network gets to use those addresses. (Which AS gets to originate a prefix, in BGP speak.) RPKI protects to some forms of (mostly accidental) address hijacking. But for RPKI to work, the address owner needs to publish a "route origination authorization" (ROA) and networks around the globe need to filter based on these ROAs.

Five years ago, I wrote that RPKI is ready for real-world deployment. So where are we now? The US National Institute of Standards and Technology (NIST) has a very nice RPKI deployment monitor, showing the following graph:

So globally, for just about 20% of all prefixes (address blocks) RPKI checks out (valid). For a little less than a percent, the way the address block is routed is not in agreement with the ROA (invalid). For the remaining nearly 80% of prefixes, no ROA is published (not-found). However, these numbers are different in various parts of the world:

• North America: 9% valid, 0.3% invalid, 91% not-found
• Europe: 34% valid, 1% invalid, 64% not-found
• Asia-Pacific: 18% valid, 1% invalid, 81% not-found
• Latin America: 30% valid, 1% invalid, 69% not-found
• Africa: 5% valid, 0.5% invalid, 95% not-found

These numbers show how many address owners are publishing ROAs. This is very easy to do. Here in the RIPE region, it's just a few clicks in the LIR portal. The harder part is filtering based on RPKI. For this you need validator software, for which there are now several choices, and then you need to hook up the validator to your routers, explained here for Cisco and here for Juniper.

For some time, I feared networks would hesitate to filter out prefixes with the RPKI state "invalid", because there's still several thousand prefixes that are invalid. However, it now looks like there are enough big networks doing this that the onus of working around the resulting breakage is correctly put on the address owners / networks that cause the "invalid" state rather than the networks doing the filtering.

Is BGP safe yet? as well as a RIPE labs RPKI test tell you if your ISP is filtering RPKI invalid prefixes, with Cloudflare also naming and shaming the big ones that don't.

The RPKI Observatory has a list of prefixes that have the RPKI invalid state and are therefore unreachable with RPKI filtering enabled. The Route Views collector now also has RPKI, letting you check the state of individual prefixes (telnet route-views.oregon-ix.net). Or use the NLNOG RING looking glass.

Permalink - posted 2020-05-04

❝Beating BGP is harder than we thought❞

▼ In a paper for the HotNets'19, seven researchers admit that "beating BGP is harder than we thought". (Discovered through Aaron '0x88cc' Glenn.) The researchers looked at techniques used by big content delivery networks, including Google, Microsoft and Facebook, to deliver content to users as quickly as possible. This varies from using DNS redirects to PoPs (points of presence) close to the user, using BGP anycast to route requests to a PoP closeby and keeping data within the CDN's network as long as possible ("late exit" or "colt potato" routing).

Turns out, all this extra effort only manages to beat BGP as deployed on the public internet a small fraction of the time. So it's probably not really worth the effort. Also interesting: when BGP is worse, that's usually consistent over relatively long timescales, and when things deteriorate over one path, they tend to also get worse over alternative paths.

That seems strange, as the authors observe that "BGP, the Internet’s inter-domain routing protocol, is oblivious to performance and performance changes." However, BGP isn't deployed in a vacuum. People either install capacity where BGP is going to use it, or they tune BGP parameters to use capacity that's installed.

So having automated traffic management doesn't seem to help much—or does it? Maybe all paths deteriorate together because the automated traffic management solutions do their job and distribute the traffic equally over the available paths, keeping performance the same.

However, there are some cases when one of the options (regular BGP, anycast, late exit, DNS redirect) performs a lot poorer than the alternative(s). So it's probably more important to focus on avoiding really bad paths rather than trying to pick really good ones.

Also interesting: apparently ISPs rarely include the EDNS client subnet option, which DNS redirect really needs to work well. However, the Google and OpenDNS/Cisco public DNS services seem to do support it (but not CloudFlare), so if you're experiencing poor performance towards a CDN, you may want to try using the Google or OpenDNS DNS servers.

Download the paper here.

Permalink - posted 2019-12-30