BCP 185 is a ‘must do’ 

BCP 185 is a composite set of recommendations from RFC 7115 and RFC 9319. 

The most impactful ‘should do’ in BCP 185 is requesting transit providers use Resource Public Key Infrastructure (RPKI) validation on all eBGP sessions. All sessions, meaning their upstream providers (if they have any), their peering sessions, and, of course, all customer BGP sessions.

This immediately creates critical dependencies on the integrity of the global RPKI database. 

While RFC 7115 avoids speaking to timing and availability of endpoints, there is strong SHOULD-DO language on how to set up maximum prefix lengths. That strong advice is extended to limiting the publishing of Route Origin Authorizations (ROAs) for only address space present in the global BGP routing table. 

Of course, Randy Bush (the author of RFC 7115) points out that Route Origin Validation (ROV) does not fix or mitigate many issues with routing security, nor does it deal with invalid origin routes in a provider routing policy that accepts and lowers the preference of invalids. 

But what about data integrity? 

This was the subject of my presentation (PDF) at SANOG 40 in Colombo, Sri Lanka recently. There are significant ‘holes’ in the currently signed routes for many providers in South Asia. 

Those holes are signed ROAs for routes not existing in the global BGP routing table. It’s troubling that these signed ROAs, expanded by MaxLength, numbered 184,392 on 26 September 2023 (as captured from rpki-client and Route Views), yet in the routing table, only 26,001 routed prefixes match those ROAs. 

This is where RFC 9319, the other part of BCP 185, comes into play.

Job Snijders and co-authors describe the “forged-origin sub-prefix” hijack. An example is detailed and demonstrates the methodology. To hijack ROA-signed routes, the attacker must impersonate the Autonomous System Number (ASN) and the longer prefix. Combine this with the ‘un-routed’ prefix data, and there is potential for a hijack that will pass ROV filters as valid and capture traffic very successfully for the attacker as the network operator has no route in the global BGP table for the prefix. 

The typical response to attacks is de-aggregation. Section 5.2 of RFC 9319 describes the de-aggregation of more than the attacker. Realistically, with proper ROAs signed, ROV would detect the longer prefix as INVALID and stop the route making its way across the globe in BGP updates. 

More importantly, for ROAs with advertised prefixes and maximum lengths matching only fully advertised subnets, there is preventative protection.

In essence, Snijders and the co-authors make it plain that the best possible deployment of ROAs is to match carefully what the operator expects to see in the global routing table. 

I made the case for this recommendation to be a ‘MUST DO’ for operators in South Asia at SANOG 40. Watch the recording.

Adapted from the original post that first appeared on the APNIC Blog.

Terry Sweetser is APNIC’s Training Delivery Manager (South Asia and Oceania). He has 30+ years of ITEE/Telco experience and is well-known in peering and governance forums.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of the Internet Society.