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

Hi Job,


  *   This BCOP proposal is not for all IXPs. First of all, it targets to be a RIPE document and thus, have validity in the EU/RIPE region. Unless another RIR decides to adopt it or publish a similar one, we don’t expect to become a global operational document. It is more of a strong recommendation rather than an enforced policy. Policies have major impact to anyone involved, BCOPs are optional recommendations.
Do you believe the introduction or the scope is misleading and needs rephrasing?

  *   The IRRdv4 workaround is not a good one. Initially, not everyone can afford having an IRRDv4 instance in its infrastructure to use its features or can fit with the operational model .
In AMS-IX infrastructure we do use IRRdv4 to mirror other IRR DBs and I have bumped into the "route object preference" feature.
But we incorporated it into our operations last year. Moreover, as Sasha mentions in the document: “IRRd will act as if the object was deleted, but it may become visible again later.” due to creations/deletions.

I consider the following approach a more feasible one for most of the users: “bgpq4 -4 -A -b -h my-whois.domain.net -S RIPE,LACNIC,APNIC,ARIN,AFRINIC,RADB AS-FOOBAR”

But RADB will always prioritize their objects with SOURCE RADB over the official ones (which makes sense as they make money), and AS-TWITTER is a great example:
There are 2 objects of AS-TWITTER in RADB, one from RIPE and one from RADB. If you select to prioritize the RIPE one instead of the RADB one, then you get nothing. That said, I can go tomorrow in RADB and create an AS-SET called “AS-AKAMAI” with no members, thus guess what will happen to all the folks who simply run “bgpq4 -A -h whois.radb.net AS-AKAMAI”

And this is just one example, but this BCOP is not about setting priorities on IRR DBs, it is a bit more ambitious. A small community of operators try to achieve a much broader goal (hopefully).


Kind Regards
Stavros

From: connect-wg <connect-wg-bounces at ripe.net> on behalf of Job Snijders <job at sobornost.net>
Date: Thursday, 6 June 2024 at 13:22
To: connect-wg at ripe.net <connect-wg at ripe.net>
Subject: Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call
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 at 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Firrd.readthedocs.io%2Fen%2Fstable%2Fadmins%2Froute-object-preference%2F&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C7489528349ec40bd3b7508dc861aefc5%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638532697446749115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=JHr8hq%2FeZjW%2FLRGptngGi5Oo%2BzuluAeTIxJVQJozTpA%3D&reserved=0<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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Firrd.readthedocs.io%2Fen%2Fstable%2Fadmins%2Fobject-suppression%2F&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C7489528349ec40bd3b7508dc861aefc5%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638532697446763652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=uG0%2BsEMySqMPz92LYRjlnLNzmNj39buWVU3u6O40jL8%3D&reserved=0<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

_______________________________________________
connect-wg mailing list
connect-wg at ripe.net
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fconnect-wg&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C7489528349ec40bd3b7508dc861aefc5%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638532697446775809%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=5u9KDQxvy9HRrZbpdsjNiX32adhj6YW7d3rrRSRP3MU%3D&reserved=0<https://mailman.ripe.net/>

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fconnect-wg&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C7489528349ec40bd3b7508dc861aefc5%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638532697446785253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PD9orcSuklaqfWVoDm6c4fwZT7j6cYzeT6uz4NsHLYQ%3D&reserved=0<https://mailman.ripe.net/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/connect-wg/attachments/20240609/f49304d1/attachment-0001.html>