On 6 Jun 2024, at 04:52, Marco d'Itri <md@Linux.IT> wrote:
At the moment of writing both the NTT and the RADB 'IRR mirror aggregators' support RPKI-based filtering for ROUTE/ROUTE6 objects. This is a fairly recent development and means that anyone using the bgpq3, bgpq4, or irrtoolset's peval utility will enjoy a view on the IRR that is informed by a cryptographically signed source of truth (the RPKI). It's only been 6 months since RADB deployed RPKI-filtering, have the effects of this been studied? We are aware of this, but it is not relevant because as you noted there are still ~50% of prefixes which are not protected by RPKI. As long as non-authoritative IRRs are used then it will be possible to hijack both allocated and unallocated IP space by creating bogus route/route6 objects. And if RPKI coverage were universal then we would not need IRRs (at least for route/route6 objects) and this would not matter anyway.
RPKI and Route Objects don’t prevent hijacks. Routing policies, filters and good practice prevent hijacks. An RPKI ROA will tell you how a given piece of IP space should be routed (origin ASN, prefix length), not from whom you should accept it. A route object will give a similar signal, the strength / validity of which may be seen to vary based on the IRR in which was published. But if a bad actor manages to masquerade as somebody else’s ASN, either directly or via ‘downstream’ routes then neither of the above help. If anything there is a risk that if we blindly consider a route that matches a route object / ROA to be beyond doubt we may be less able to identify such actions. -Ronan