On Jun 04, Job Snijders <j...@sobornost.net> wrote: > 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. Actually I have been doing something like that for the past year: I took dumps from european route servers and checked which routes are legacy and would be filtered accordingly to the last stage of this proposal. The filtered routes are then divided among categories like "Cogent", "AMPR", "traffic scrubbing", etc... My scripts and the results are available at https://www.bofh.it/~md/legacy.tgz .
And DE-CIX checked how much traffic would be lost from the route servers. I believe that their methodology was flawed because it does not take into account the prefixes which are currently not, but actually can, and reasonably will be, registered in the official IRRs. But it is still useful because it gives an upper bound of how much traffic would move. (Spoiler: not much.) > 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 We did these analysis, but indeed they should have accompanied the proposed document. > 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?). as-sets are not relevant for this proposal because their content is not authenticated and so can be trivially replicated in the official IRRs. Does any IXP actually use route-sets to generate filters? But anyway the same principle would apply to these too, since their content is not authenticated. > 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. Sorry, looks like a major detail was left out from the proposal because we have been thinking of it among ourselves as obvious for all this time: this is a proposed best practice for EUROPEAN route servers. We are well aware that IXPs in other continents may have different needs and we are not taking a position about them at this time. > 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. This is correct, but in the end it does not matter in our view: the plan agreed by the IXP operators also contemplates educating their members to move (or at least replicate) the correct data to the authoritative IRRs. > 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. BTW, the proposal has also been discussed with the managers of the NTT IRR database. I will not speak for them, but I believe that I can say that they broadly agreed with our goals. > 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. I am aware of this, but our goal was to discuss the current situation and not writing an history of the RIRs system. You point out some issues with the IANA official registries, but I am not sure why this would be relevant. My analysis only used networks.csv from ARIN to determine which networks are "ARIN legacy", which is what matters here: networks which CANNOT be registered in an authoritative IRR. > 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. I do not think that it is plausible for us to propose to all IRR operators to implement something. 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. > 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. Maybe you are right: since no new objects can be created in RIPE-NONAUTH then it is safe enough. I would probably not be opposed to continue using it, but none of the IXP operators that support our plan asked for this. -- ciao, Marco
signature.asc
Description: PGP signature
_______________________________________________ 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
