On 6 Jun 2024, at 04:52, Marco d'Itri <m...@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 _______________________________________________ connect-wg mailing list connect-wg@ripe.net https://lists.ripe.net/mailman/listinfo/connect-wg To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/connect-wg
