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 that is 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?
Those holes are signed ROAs for routes that do not exist 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 there are only 26,001 routed prefixes matching 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 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 a 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 now.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.