[connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call

On 6 Jun 2024, at 04:52, Marco d'Itri <md at 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