Hi Job,

Thank you for taking the time to submit this long text of comments. Going through them feels like you missed some background info, aren’t you?

Most of your concerns have been noted by the authors and have been either presented or discussed during the past RIPE meetings. Nevertheless, I will try to answer your questions/comments but in a more condensed way to avoid making all the audience go away when reading such a huge text.

Regarding the missing content for the impact analysis, we intentionally kept that away from the document. After discussions with RIPE NCC colleagues we prefer to publish the BCOP short, clean and easy-to-read for quick reference. However, for the concerned colleagues who would like to see some numbers or perhaps missed the past RIPE meetings, we will create a RIPE article where we discuss prons and cons of this BCOP and share some analysis data from 1-2 example IXPs (perhaps AMS-IX and someone else).  Moreover, another reason to keep those data decoupled from the draft is the fact that -as you correctly mentioned- not every IXP will have the same impact when adopting. As we have spoken with some colleagues from other IXPs, due to their smaller size they have a much cleaner dataset to query, and they are ready even to go on phase-2. For some bigger ones it will take a bit of extra effort, but in any case, we advise colleagues to make their own impact analysis and draw their own results.

Regarding the point (2), we are aware from the fact the RADB and NTT filter out ROUTE/ROUTE6 objects in case they were detected as RPKI invalids, however is that enough? What about AS-SETs?   What about the users who create fake accounts in unauthorized BDs and consequently create RPSL objects? It feels like yesterday when RIPE NCC enforced the creation of hierarchical AS-SETs to avoid object conflicts and enhance trust.  Indeed, RPKI has approximately 50% coverage but what about the other 50% and all those RPKI unknowns? Shouldn’t become valid at some point? It is true that some of them are sourced from the problematic legacy space (we have seen it and mentioned it already) but there is also a good portion of it that is unknown simply because the RPSL data are not hosted in a non- authoritative RIR. In AMS-IX we partially support this BCOP already and experience in the daily Ops proved to us that when we motivate customers to insource their data back to authoritative IRRs, ROAs for those sources are being created as well and RPKI adoption is boosted. This action not only help us to deliver quality and verifiable prefixes but also help third-party IRR DBs to invalidate and stop delivering false data. We also spoke with the people of AMPRnet and they are aware of their situation, they will make efforts to use RIPE’s policy in order to bring the space in RIPE DB and thus, create valid IRR data and ROAs.

For the point (3) perhaps is better to not go into deep details but in short we are aware of the good old Jon Postel days where people received “/8” allocations like fresh warm stroopwafels and numbers were registered in a notebook under the desk. Which later lead to the “inaccuracies” that you described below. It is true that we don’t have answers for all those issues, especially the problem with the ARIN legacy allocations have been analysed thoroughly. But we will document this in an RIPE article and we would like to work on those with a step-by-step approach.

Leaving aside the comment on the “multiple roots” as it is questionable why should we trust them, I do agree that this is a very deep rabbit hole and we also discover more and more of those weird cases.  The slight drift of data beteen RIR and RPKI is out of concern as this probably occurs from the movement of IP allocations between RIRs and the slow processes. There will be future improvements over there for sure.

To the point (4), we will mention alternative approaches on the separate public article. But regarding your example, since the operator has valid RIR resources and access to RIPE DB, why shouldn’t have the route/route6 and as-set objects created in RIPE DB but rather in a non-authoritattive IRR DB? As authors we did our research around and asked several people in the industry but so far the only true and valid reason that we could find is the ARIN legacy space. All other reasones that where mentioned from colleagues in other networks (even the ones in NTT) are (one way or another) solvable. Even the EU-based legacy space can be easily imported and validated into RIPE by using the framework “RIPE NCC Services to Legacy Internet Resource Holders”.

In contrary, those type of developments are very much required as motivate operators to adopt RPKI while enhances the trust to non-cryptographic verifiable data with the target to eventually make those two pools in sync (as much as possible). That way, we prepare the way for ASPA adoption and can make the switchover to RPKI-only system much smoother.

Conclusion, this BCOP will definitely help into data cleanup and enhancing routing security as we have condluded during the past RIPE meeting. However, we see security and trust in a more holistic approach:

•⁠ ⁠Operators go to RIPE NCC, ARIN etc to request resources or register their existing ones;

•⁠ ⁠RIRs make their due diligence, assign unique resources to the person or entity requesting them and register those in the database.  There is also a legal contract covering those allocations or assignments;

•⁠ ⁠RIRs create a unique maintenaner object for this operator which can be used for aut-num/as-set/route(6) objects. Consequently this mnt object is used to create or update RPSL objects;

•⁠ ⁠Accounts on RIRs are MFA enabled and RIRs make periodic checks  to verify the validity of the resource holders, if they still exist, and so on.

Hence, by design there is an inherited top-to-bottom trust combined with good security practises that can boost the quality of the data and make other operators trust them. Avoiding situations where anyone with a credit card can go in a public/unauthorized DB and create whatever they want, hence leading to dangerous object conflicts.

Lastly, for the unsolved issue of ARIN legacy space which finds shelter on unauthorised DBs, we are open to examine possible workarounds.

Kind Regards

Stavros

From: Job Snijders <job@sobornost.net>
Date: Tuesday, 4 June 2024 at 14:29
To: Stavros Konstantaras <stavros.konstantaras@ams-ix.net>
Cc: Connect-WG <connect-wg@ripe.net>, Andrei Dinu <andrei.dinu@digitalit.ro>, Marco d'Itri <md@linux.it>, Will van Gulik <will@van.gulik.ch>
Subject: Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call

Dear working group,

As some of you may know improving Internet routing security is a topic
dear to my heart, so I read this proposal with much interest. I have
some concerns I'd like to share related to impact analysis, existing
deployed mitigations, alternative approaches, and potential
inaccuracies.

TL;DR - I do not think this draft proposal is ready for publication as
RIPE document.

1. Impact analysis
==================

I have some experience helping operate the NTT IRR mirror (rr.ntt.net),
and throughout my tenure I've both been part of the decision group
concerned with adding new and deprecating IRR database mirrors (both RIR
and third party databases). Part of the onboarding and offboarding
process would be to run simulations to understand how many BGP best
paths, not-best-but-elegible paths, and currently ineligible paths would
change status; additionally attempts were made to understand potential
for traffic swings.

I think some numbers were shared in previous Connect WG meetings, but
the proposal at hand does not include a thorough impact analysis from
the perspective of the IX operations affiliated with the authors. I'm
also not sure whether previously shared information contained impact
analysis broken out into RPSL object classes (for example, is the juice
worth the squeeze for just ROUTE/ROUTE6 objects, or is most of the
friction in AS-SETs, or in ROUTE-SETs, or some other type?).

I suspect impact will differ from IX operation to IX operation, for
example I can imagine that a Netherlands-specific IX is unlikely to
benefit much from using Canada's CANARIE IRR, but speaking from the
perspective of YYCIX (Calgary, Canada), there seems little to be gained
and some to be lost by dropping CANARIE.

The proposal correctly observes out that because there is a multitude of
information sources, those sources could be in conflict with each other
(simply by virtue of there existing multiple sources). What is perhaps
less understood is whether the information in the RIR database is the
correct one or the information in the third-party databases is more
aligned with the resource holder's intentions. In other words, yes,
conflicting information exists, but it doesn't automatically follow that
the 'wrong' information is in the non-RIR databases.

2. Existing deployed mitigations / threat model
===============================================

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?

This touches upon threat modeling, because the above means that
third-party databases no longer are a useful vector to inject
information which conflicts with the RPKI. With RPKI ROAs nowadays
covering over 50% of routes and over 70% of IP traffic flowing towards
RPKI-ROV-valid destinations, what threats are mitigated exactly with
this draft proposal?

My intuition is that the third-party IRR databases nowadays at best
contain information that is not present in the RPKI (legacy space,
AMPRnet, or information about IP networks where the resource holder for
one reason or another didn't create RPKI ROAs), and at worst... well
they no longer present information that's in conflict with RPKI ROAs. So
what problem is solved? It seems to articulate what exactly the harm is
in third-party databases while it is easier to point at potential
benefits.

3. Potential inaccuracies
=========================

The proposal starts with "The root of the Internet Number Registry
System is the IANA, the Internet Assigned Numbers Authority, which
manages the complete pool of all possible IP addresses and AS numbers."
but historically that's not been the case entirely. Prior to IANA
numbers were managed by Jon Postel, and later on both IANA, InterNIC,
and the RIRs played a role. Throughout the years authorities came and
went, or were subsumed in other authories, or later on relieved (to some
degree) from duties.

A good example of inaccuracy in IANA 'managed' data is this registry:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fas-numbers%2Fas-numbers.xml&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C80e23ada40d64e8ae27808dc8492036d%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638531009861470112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=VXskGqEGrXp4vXRMtuRRkG0u2xsXu1SPW5KMb0FY6FY%3D&reserved=0
is an incomplete registry, where only 'new' ASN assignments are listed.
In the past this registry used to list all ASNs, but then later on the
RIRs asked IANA to revert to being less detailed...

Another IANA registry which is not very precise (read: inaccurate) is:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fipv4-address-space%2Fipv4-address-space.xhtml&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C80e23ada40d64e8ae27808dc8492036d%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638531009861480470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=YmoG0oEbWFJo%2B3HiNIkbD3Tt%2BwfPb2hcmkfDrVWL0j0%3D&reserved=0
It only contains high-level information about /8s, but a number of those
/8s are in reality managed by multiple RIRs, or are part RIR-managed
part legacy space.

A registry report that's more accurate than IANA's in relationship to
RIR-managed space is available via the NRO collaboration:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fftp.ripe.net%2Fpub%2Fstats%2Fripencc%2Fnro-stats%2Flatest%2Fnro-delegated-stats&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C80e23ada40d64e8ae27808dc8492036d%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638531009861485390%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fHYWlUaOTHgyIhs%2FqG8iIadyGBnBJ%2B19bsZNa3cdeiM%3D&reserved=0
However, this NRO data is only accurate for RIR-managed space, and there
still is non-RIR-managed IP space and ASNs.

Perhaps a more practical viewpoint would be to consider that there are
multiple 'roots' for the management of IP addresses and AS numbers, each
with their own scope. Taking such a perspective would lead to the
conclusion that not all Internet Number Resources are managed by either
IANA or the RIRs, begging the question whether a 100% RIR-centric
approach for IRR mirroring is helpful at this point in time.

As a sidenote: the RIR IRR and RPKI systems from time to time are in
slight conflict with each other. As part of the 'constraining RPKI Trust
Anchors'-project I've uncovered a number of inconsistencies between RIRs
in terms of what they claim authority for:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-snijders-constraining-rpki-trust-anchors&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C80e23ada40d64e8ae27808dc8492036d%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638531009861490045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kBDsjUoGw0v2X8a%2BgNM0byy%2FUN8i1nvKzrTwcnz77gE%3D&reserved=0
Despite everyone's best intentions, the rabbit hole is deep :-)

I'd like to emphasize we should view the data in context of higher and
lower sources of truth, with cryptographically verifyable data
superseding non-cryptographic information, and in doing so removing the
(potential) stinger out of non-RIR data.

4. Alternative approaches?
==========================

It seems the proposal does not mention considerations on alternative
approaches. For example, instead of wholesale dropping third-party
databases, one could argue that IRRd software should take into
consideration information from the 'nro-delegated-stats' file, and
either filter or mark differently information found in non-RIR IRR
databases that covers IRR information in RIR-managed databases. For
example, if IP address block ABC is managed by RIPE, but the RIPE
database doesn't contain any route/route6 information for ABC, and a
third-party database *does* contain information for ABC; then IRR should
not filter out the third-party information about ABC. Especially when
ABC is not in conflict with ROAs, especially when ABC is not covered by
ROAs.

Related to section 2 of this email, the proposal mentions dropping
RIPE-NONAUTH, but only a few years ago through a RIPE policy update
(https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fpublications%2Fdocs%2Fripe-731%2F&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C80e23ada40d64e8ae27808dc8492036d%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638531009861495106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=qusO28%2FtjZrViVhUuZTxwzqimkO8hsE2zWn8ZUNRNhU%3D&reserved=0) the community came
to consensus that imposing RPKI filtering on the RIPE-NONAUTH data would
be a sufficiently effective sunsetting strategy to over the years to
come purge more and more information, all the while retaining
routing information for which there is no better authority.

Or, perhaps such development work is not needed at all taking a long
view: every day more and more RPKI ROAs are being created, and as
industry we'd do well to let the brunt of the work be done by resource
holders creating ROAs for their IP address space? It may well be that
patience is all that's needed (again, depends on the threat model!).

5. Conclusion
=============

I'd prefer to see data cleanup and migration proposals which are softer
in nature: rather than dropping a database in its entirety merely
because it is not managed by an RIR, instead seek to develop strategy
and tooling to continue to extract benefit from such databases, while at
the same time strengthening the position of data stored in 'more
authoritative' sources.

Dropping one or more sources of routing information in their entirety is
is probably the crudest form of data source harmonization, instead I
think there is precedent to harmonize data such as was done in IRRd v4's
RPKI integration and through RIPE-731. Perhaps it is time to now see if
a similar approach can be done based on the NRO provided data? And once
that's done, see what treatment the remaining data needs ... if any.

Kind regards,

Job

On Tue, Jun 04, 2024 at 11:16:18AM +0000, Stavros Konstantaras wrote:
> Hi folks,
>
> We are discussing this subject since RIPE86 and we have presented our progress in both RIPE87 and RIPE88. Every time we bring this subject, we receive strong support from the community, both during the presentations and in personal discussions. We thank you all for that as it provides us fuel and motivation to continue our work.
>
> I have discussed the process with RIPE NCC employees and they are happy to adopt it as an official RIPE BCP/document, as long as the support is documented in this mailing list.
>
> Thus, we would like to make a call for adoption for this working item. Please find attached the latest version of the draft and feel free to submit your comments in case you find mistakes (e.g. typos, grammar, etc etc).
>
>
>
> Kind Regards
>
> Stavros, Marco, Will, Andrei


> _______________________________________________
> connect-wg mailing list
> connect-wg@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%7C80e23ada40d64e8ae27808dc8492036d%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638531009861500029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=p9yAuZDZrfZaalMbPWZQgv4tBFWe61lm3dciyaQiK2U%3D&reserved=0
>
> 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%7C80e23ada40d64e8ae27808dc8492036d%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638531009861504705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=HziLcR9dWV1rO9KjYvCIsCxu38OuI5yH7p9WzGo24Zw%3D&reserved=0