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://www.iana.org/assignments/as-numbers/as-numbers.xml 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://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml 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://ftp.ripe.net/pub/stats/ripencc/nro-stats/latest/nro-delegated-stats 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://datatracker.ietf.org/doc/html/draft-snijders-constraining-rpki-trust... 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://www.ripe.net/publications/docs/ripe-731/) 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://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