Dear group, I have good news related to two remarks about prioritization of IRRs On Tue, Jun 04, 2024 at 10:08:53AM -0700, Randy Bush wrote:
i would support preferring some irrs in case of duplication/conflict
This is nowadays possible, see below. Also replying to part of Marco's message: On Thu, Jun 06, 2024 at 05:52:50AM +0200, Marco d'Itri wrote:
On Jun 04, Job Snijders <job@sobornost.net> wrote:
It seems the proposal does not mention considerations on alternative approaches.
I do not think that it is plausible for us to propose to all IRR operators to implement something.
Yet, this 'BCOP' draft proposal is exactly that? :-) On Thu, Jun 06, 2024 at 05:52:50AM +0200, Marco d'Itri wrote:
Maybe it could be implemented in bgpq4 at the price of a lot more client-side processing, but since it would still allow hijacking unallocated space then I do not believe that this complexity would be justified.
In IRRd v4 a feature was implemented called "route object preference": https://irrd.readthedocs.io/en/stable/admins/route-object-preference/ This is part of a broader set of tools to help mitigate risk associated with non-cryptographically signed IRR databases (such as RIPE, ARIN, RADB) https://irrd.readthedocs.io/en/stable/admins/object-suppression/ Knowing that the software and tooling already today is out there to prioritize RIR databases over non-RIR databases, and knowing there also is RPKI-filtering on the route object level; what threats does this draft proposal address other than recommending to ignore potentially useful information? Did any of the authors actually try IRRd v4's route object preference feature and compared it with their own proposal? Kind regards, Job