BCOP for the use of IRR DBs in IXP RS - Last call
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
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
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<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://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<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://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<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://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<https://datatracker.ietf.org/doc/html/draft-snijders-constraining-rpki-trust-anchors> 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<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://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<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://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<https://lists.ripe.net/mailman/listinfo/connect-wg>
On Jun 04, Job Snijders <job@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 .
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
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.) 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
On 6 Jun 2024, at 04:52, Marco d'Itri <md@Linux.IT> wrote:
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.
RPKI and Route Objects don’t prevent hijacks. Routing policies, filters and good practice prevent hijacks. An RPKI ROA will tell you how a given piece of IP space should be routed (origin ASN, prefix length), not from whom you should accept it. A route object will give a similar signal, the strength / validity of which may be seen to vary based on the IRR in which was published. But if a bad actor manages to masquerade as somebody else’s ASN, either directly or via ‘downstream’ routes then neither of the above help. If anything there is a risk that if we blindly consider a route that matches a route object / ROA to be beyond doubt we may be less able to identify such actions. -Ronan
But if a bad actor manages to masquerade as somebody else’s ASN, either directly or via ‘downstream’ routes then neither of the above help. If anything there is a risk that if we blindly consider a route that matches a route object / ROA to be beyond doubt we may be less able to identify such actions. Of course, this is obvious. But we are trying to solve only one aspect of the problem: by not using anymore the unauthenticated IRRs we will have removed a whole class of
On Jun 06, "Mullally, Ronan via connect-wg" <connect-wg@ripe.net> wrote: possibile hijackings. For the others indeed other technologies will be needed. -- ciao, Marco
Hi
But we are trying to solve only one aspect of the problem: by not using anymore the unauthenticated IRRs we will have removed a whole class of possibile hijackings.
And also you might invalidate a lot of valid objects causing issues for the networks using the RS in the IX. Let me make a few comments. I agree with some of the concerns raised here. IMO I do not think that is a good idea to just ignore some of the IRR databases, instead you could use something similar to what we have proposed on the MANRS for Cloud/CDN providers. I think it is a good balance to use a variety of IRR DBs: ---> Standard AS-SET expansion process: 1. If a peer-AS has downstream customer ASNs (customer cone ASNs), they are to be gathered through the “as-set” object. The “as-set” (or AS-SETs) will be picked up from PeeringDB, “IRR as-set/route-set” field. The syntax of the name should be IRR-NAME::ASX:AS-SET-NAME, where ASX is the ASN of the peer-AS. If no AS-SET is provided, only the ASN of the peer-AS will be used in the following steps. 2. All the IRRs mirrored by RADB will be consulted to collect all “route” objects with the “origin:” field matching the ASNs collected in step 1 3. If the collection of data results in conflicting objects, the following rules apply in the following order until all conflicts are resolved: 4. The primary IRR specified by IRR-NAME has the priority 5. AFRINIC, APNIC, ARIN, LACNIC, RIPE have the priority 6. The most recently updated object has the priority 7. If further tie breaking is needed, could select the object based on lexicographic order of the IRR DB names Source: https://manrs.org/cdn-cloud-providers/actions/ ---> Also, it is true that this is meant to be applied on European IXs, but as Nick mentioned, regulators et al. might take this as the BOCP for everyone (even no IXs.) Believe it or not, this document might have a lot of influential power and you should be careful on what you propose, because it might have some unintended repercussions. Finally, on a practical note, for organizations that have to maintain a few thousands of IRR objects, doing it manually is not an option, so we need to rely on APIs. The less the better, and the more the same, the better. Unfortunately not all RIRs support API calls to manage IRRs objects, and for the ones that they do I think they are different. So, it is much easier to use RADB or other single DB. Regards as On Thu, Jun 6, 2024 at 11:54 AM Marco d'Itri <md@linux.it> wrote:
On Jun 06, "Mullally, Ronan via connect-wg" <connect-wg@ripe.net> wrote:
But if a bad actor manages to masquerade as somebody else’s ASN, either directly or via ‘downstream’ routes then neither of the above help. If anything there is a risk that if we blindly consider a route that matches a route object / ROA to be beyond doubt we may be less able to identify such actions. Of course, this is obvious. But we are trying to solve only one aspect of the problem: by not using anymore the unauthenticated IRRs we will have removed a whole class of possibile hijackings. For the others indeed other technologies will be needed.
-- ciao, Marco _______________________________________________ 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
Hi Arturo, Great to see you participating in this discussion, thank’s a lot for your feedback. To the best of my knowledge, EU regulators go for the big fish. Look at the example of the Czech Government who announced their services will be IPv6 only by 2032. Based on the current IPv6 adoption, the diff between the IPv6 RADB records and the IPv6 RIPE DB records is only 0.65%. Such a move means that the organization not only will benefit from an almost perfect 1-to-1 sync between IRR data and PRKI data but could consider relying fully on RPKI system and exclude the IRR one. Once this effort becomes successful, will open the appetite for EU regulators to push massively into this direction. Moreover, your very last sentence can be translated into “Prioritizing convenience over routing security”, which -in my eyes- is very sad. I think you miss the point that If we help our customers convert all those objects from “ RPKI unknown” to “RPKI valid”, big CDN networks who perform ROV will benefit out of that as well. Thus, I would expect more of a reaction that includes a mentality like “Please help us create a common API between IRRs to ease operations” rather than “don’t do it all”. Kind Regards Stavros From: connect-wg <connect-wg-bounces@ripe.net> on behalf of Arturo Servin via connect-wg <connect-wg@ripe.net> Date: Thursday, 6 June 2024 at 13:14 To: Connect-WG <connect-wg@ripe.net> Subject: Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call Hi
But we are trying to solve only one aspect of the problem: by not using anymore the unauthenticated IRRs we will have removed a whole class of possibile hijackings.
But if a bad actor manages to masquerade as somebody else’s ASN, either directly or via ‘downstream’ routes then neither of the above help. If anything there is a risk that if we blindly consider a route that matches a route object / ROA to be beyond doubt we may be less able to identify such actions. Of course, this is obvious. But we are trying to solve only one aspect of the problem: by not using anymore the unauthenticated IRRs we will have removed a whole class of
And also you might invalidate a lot of valid objects causing issues for the networks using the RS in the IX. Let me make a few comments. I agree with some of the concerns raised here. IMO I do not think that is a good idea to just ignore some of the IRR databases, instead you could use something similar to what we have proposed on the MANRS for Cloud/CDN providers. I think it is a good balance to use a variety of IRR DBs: ---> Standard AS-SET expansion process: 1. If a peer-AS has downstream customer ASNs (customer cone ASNs), they are to be gathered through the “as-set” object. The “as-set” (or AS-SETs) will be picked up from PeeringDB, “IRR as-set/route-set” field. The syntax of the name should be IRR-NAME::ASX:AS-SET-NAME, where ASX is the ASN of the peer-AS. If no AS-SET is provided, only the ASN of the peer-AS will be used in the following steps. 2. All the IRRs mirrored by RADB will be consulted to collect all “route” objects with the “origin:” field matching the ASNs collected in step 1 3. If the collection of data results in conflicting objects, the following rules apply in the following order until all conflicts are resolved: 4. The primary IRR specified by IRR-NAME has the priority 5. AFRINIC, APNIC, ARIN, LACNIC, RIPE have the priority 6. The most recently updated object has the priority 7. If further tie breaking is needed, could select the object based on lexicographic order of the IRR DB names Source: https://manrs.org/cdn-cloud-providers/actions/ ---> Also, it is true that this is meant to be applied on European IXs, but as Nick mentioned, regulators et al. might take this as the BOCP for everyone (even no IXs.) Believe it or not, this document might have a lot of influential power and you should be careful on what you propose, because it might have some unintended repercussions. Finally, on a practical note, for organizations that have to maintain a few thousands of IRR objects, doing it manually is not an option, so we need to rely on APIs. The less the better, and the more the same, the better. Unfortunately not all RIRs support API calls to manage IRRs objects, and for the ones that they do I think they are different. So, it is much easier to use RADB or other single DB. Regards as On Thu, Jun 6, 2024 at 11:54 AM Marco d'Itri <md@linux.it<mailto:md@linux.it>> wrote: On Jun 06, "Mullally, Ronan via connect-wg" <connect-wg@ripe.net<mailto:connect-wg@ripe.net>> wrote: possibile hijackings. For the others indeed other technologies will be needed. -- ciao, Marco _______________________________________________ connect-wg mailing list connect-wg@ripe.net<mailto: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
On Thu, Jun 06, 2024 at 05:52:50AM +0200, Marco d'Itri wrote:
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.
Yes, I'm sure that NTT, and myself, and you, all agree we want improve Internet routing security. However working towards this common goal is very different from RIPE as a community recommending a specific set of IRRDBs to be used or not to be used. NTT arguably has invested lots of resources to improve the status quo: deployment of RPKI ROV, kickstarting the IRRd v4 project, harmonizing RPKI filtering for IRR, ability to priotize one IRRDB over another, and always very conservative about which new IRRDBs to mirror. I'm trust most people would agree that each IXP operator has to make a conscious decision which IRRDBs to use or not to use, at the very least as a matter of local policy. Support for reduction of poorly managed IRRDBs (either by deploying more IRRd v4 or turning them off) and support for hygiene in the global routing system, probably do not equate support for this specific proposal in its current form. Kind regards, Job
On Thu, Jun 06, 2024 at 05:52:50AM +0200, Marco d'Itri wrote:
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.
It's amusing RPKI deployment never is enough. When we were at 5% people said it wasn't relevant, when we were at 10% it wasn't relevant, now we are at 50% (with 70% of IP traffic being forwarded to RPKI-valid destinations!) and its still not relevant?
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.
For allocated: you can simply use IRRDv4's route object preference feature. And, for both allocated and unallocated IP space: if neither the RPKI nor the RIR-managed IRRDBs contain any information about a given prefix, the non-RIR managed database could be the right information. This is the case especially for legacy space.
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.
Well, the draft proposal starts with a whole paragraph about IANA managing all IP space; and I think one can easily challenge this specific characterization of the current state of affairs. Kind regards, Job
Hi all, Marco d'Itri wrote on 06/06/2024 04:52:
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.
I think you're referring to the Euro-IX Route Server Workshop held recently in Rome? If so, let me start by saying it was a great workshop and very useful for route server operators - kudos to all who organised including Stavros. Regrettably, it was also the first of these workshops I was able to attend, and so I was unfamiliar with the rules of consensus, what was required to agree on a plan, and what had transpired at previous workshops. This BCOP plan felt like it came with plenty of prior work that I missed, so I was hesitant to be overly vocal as a newbie. I'm not sure to what extent it can be asserted that the plan was agreed by IXP operators (and I appreciate it's not clear what is meant by that above) but I'd like to state that my being present at the workshop does not convey agreement with this plan. One comment I did make was that it was paradoxical, on one hand, to bemoan the depeering of large network(s) from route servers and discuss how IXPs could engage to bring them back while, on the other hand, trying to implement a practice which would dictate how and where they should register their routing objects. Others have already noted that a BCOP should reflect established /current/ operating practices, and I think this proposal fails that test. I’d emphasise that, like everyone else here, I am passionately pro-improved routing security, and there are important roles for IXP operators here. Including proposals like this which, regardless of whether they succeed or fail, help remind us all of the potential problems with the status quo. - Barry
On Thu, Jun 6, 2024 at 11:21 PM Barry O'Donovan (Open Solutions) < barry@opensolutions.ie> wrote:
Hi all,
One comment I did make was that it was paradoxical, on one hand, to bemoan the depeering of large network(s) from route servers and discuss how IXPs could engage to bring them back while, on the other hand, trying to implement a practice which would dictate how and where they should register their routing objects.
And this will definitely won't help to bring them back (and probably nothing will but we can try ... ) As I mentioned in my previous email, as stated in the MARNS for CDN/Cloud providers their approach for the same problem is different and possibly incompatible. In a perfect world where all RIR support and have the same APIs to manage IRR objects, this could have an opportunity, but in the current state of affairs for IRR management in RIRs, I think it is difficult. Regards as
Difficult but not impossible, right? Maybe a reasonable counter-proposal would be to delay the removal of RADB for an extra year until a common API is adopted or a proxy tool is developed ? Technical solutions exist, is a matter of willingness and I would love to see initiatives into that direction rather seeing ourselves rely on convenient solutions. Kind Regards Stavros From: connect-wg <connect-wg-bounces@ripe.net> on behalf of Arturo Servin via connect-wg <connect-wg@ripe.net> Date: Friday, 7 June 2024 at 09:51 To: Barry O'Donovan (Open Solutions) <barry@opensolutions.ie> Cc: Connect-WG <connect-wg@ripe.net> Subject: Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call On Thu, Jun 6, 2024 at 11:21 PM Barry O'Donovan (Open Solutions) <barry@opensolutions.ie<mailto:barry@opensolutions.ie>> wrote: Hi all, One comment I did make was that it was paradoxical, on one hand, to bemoan the depeering of large network(s) from route servers and discuss how IXPs could engage to bring them back while, on the other hand, trying to implement a practice which would dictate how and where they should register their routing objects. And this will definitely won't help to bring them back (and probably nothing will but we can try ... ) As I mentioned in my previous email, as stated in the MARNS for CDN/Cloud providers their approach for the same problem is different and possibly incompatible. In a perfect world where all RIR support and have the same APIs to manage IRR objects, this could have an opportunity, but in the current state of affairs for IRR management in RIRs, I think it is difficult. Regards as
Please correct me if I'm wrong about my logic and naive about my proposal here: If this BCOP is implemented by an IXP, then the IXP would have to tell all their peers to create route(6) objects in their RIR if they do not have it. At the same time, those peers would have to tell their customers to create objects in their RIR and so on. The time of that process in the BCP first draft is calculated as a grace period of 12 months (of course it can be reviewed). So, there is an effort on the IXPs and on the peers to educate customers that can be used to educate them in signing ROAs. These users would have to login in their RIRs anyway. If I were a lazy AS administrator, I would rather create an ROA with 3 or 4 clicks than learn RPSL. On Sun, Jun 9, 2024 at 1:20 PM Stavros Konstantaras < stavros.konstantaras@ams-ix.net> wrote:
Difficult but not impossible, right?
Maybe a reasonable counter-proposal would be to delay the removal of RADB for an extra year until a common API is adopted or a proxy tool is developed ?
Technical solutions exist, is a matter of willingness and I would love to see initiatives into that direction rather seeing ourselves rely on convenient solutions.
Kind Regards
Stavros
*From: *connect-wg <connect-wg-bounces@ripe.net> on behalf of Arturo Servin via connect-wg <connect-wg@ripe.net> *Date: *Friday, 7 June 2024 at 09:51 *To: *Barry O'Donovan (Open Solutions) <barry@opensolutions.ie> *Cc: *Connect-WG <connect-wg@ripe.net> *Subject: *Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call
On Thu, Jun 6, 2024 at 11:21 PM Barry O'Donovan (Open Solutions) < barry@opensolutions.ie> wrote:
Hi all,
One comment I did make was that it was paradoxical, on one hand, to bemoan the depeering of large network(s) from route servers and discuss how IXPs could engage to bring them back while, on the other hand, trying to implement a practice which would dictate how and where they should register their routing objects.
And this will definitely won't help to bring them back (and probably nothing will but we can try ... )
As I mentioned in my previous email, as stated in the MARNS for CDN/Cloud providers their approach for the same problem is different and possibly incompatible.
In a perfect world where all RIR support and have the same APIs to manage IRR objects, this could have an opportunity, but in the current state of affairs for IRR management in RIRs, I think it is difficult.
Regards
as
_______________________________________________ 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
Hi Tomas, There is nothing to correct on that, that is exactly what we are planning to do. I was in talks with the DECIX colleagues to create a strategy on how to approach our members/customers together, educate them and measure progress in a monthly basis. Obviously the 12-month soft-deadline is subject on the performance of our actions. Indeed, when our customers realized how easy is for them to use the RIPE, ARIN or APNIC WEB portal to create ROAS, we saw prefixes being transition from unknown to valid. I think the above plan and its benefits is heavily overlooked from our community ☹ Kind Regards Stavros From: connect-wg <connect-wg-bounces@ripe.net> on behalf of Tomas Lynch <tomas.lynch@gmail.com> Date: Monday, 10 June 2024 at 00:21 To: Connect-WG <connect-wg@ripe.net> Subject: Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call Please correct me if I'm wrong about my logic and naive about my proposal here: If this BCOP is implemented by an IXP, then the IXP would have to tell all their peers to create route(6) objects in their RIR if they do not have it. At the same time, those peers would have to tell their customers to create objects in their RIR and so on. The time of that process in the BCP first draft is calculated as a grace period of 12 months (of course it can be reviewed). So, there is an effort on the IXPs and on the peers to educate customers that can be used to educate them in signing ROAs. These users would have to login in their RIRs anyway. If I were a lazy AS administrator, I would rather create an ROA with 3 or 4 clicks than learn RPSL. On Sun, Jun 9, 2024 at 1:20 PM Stavros Konstantaras <stavros.konstantaras@ams-ix.net<mailto:stavros.konstantaras@ams-ix.net>> wrote: Difficult but not impossible, right? Maybe a reasonable counter-proposal would be to delay the removal of RADB for an extra year until a common API is adopted or a proxy tool is developed ? Technical solutions exist, is a matter of willingness and I would love to see initiatives into that direction rather seeing ourselves rely on convenient solutions. Kind Regards Stavros From: connect-wg <connect-wg-bounces@ripe.net<mailto:connect-wg-bounces@ripe.net>> on behalf of Arturo Servin via connect-wg <connect-wg@ripe.net<mailto:connect-wg@ripe.net>> Date: Friday, 7 June 2024 at 09:51 To: Barry O'Donovan (Open Solutions) <barry@opensolutions.ie<mailto:barry@opensolutions.ie>> Cc: Connect-WG <connect-wg@ripe.net<mailto:connect-wg@ripe.net>> Subject: Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call On Thu, Jun 6, 2024 at 11:21 PM Barry O'Donovan (Open Solutions) <barry@opensolutions.ie<mailto:barry@opensolutions.ie>> wrote: Hi all, One comment I did make was that it was paradoxical, on one hand, to bemoan the depeering of large network(s) from route servers and discuss how IXPs could engage to bring them back while, on the other hand, trying to implement a practice which would dictate how and where they should register their routing objects. And this will definitely won't help to bring them back (and probably nothing will but we can try ... ) As I mentioned in my previous email, as stated in the MARNS for CDN/Cloud providers their approach for the same problem is different and possibly incompatible. In a perfect world where all RIR support and have the same APIs to manage IRR objects, this could have an opportunity, but in the current state of affairs for IRR management in RIRs, I think it is difficult. Regards as _______________________________________________ connect-wg mailing list connect-wg@ripe.net<mailto: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
Maybe I did not explain myself correctly. The BCP talks about relying only on RIRs IRRs for route(6) objects and it doesn't mention RPKI at all. My question is why use the effort of educating parties about RPSL, creating objects, etc. when all that effort can be used to teach them how to create ROAs (or pointing them to the nice videos de RIRs have) and simplify this BCP to "IXPs will only accept valid ROAs". Thanks. On Mon, Jun 10, 2024 at 11:00 AM Stavros Konstantaras < stavros.konstantaras@ams-ix.net> wrote:
Hi Tomas,
There is nothing to correct on that, that is exactly what we are planning to do. I was in talks with the DECIX colleagues to create a strategy on how to approach our members/customers together, educate them and measure progress in a monthly basis. Obviously the 12-month soft-deadline is subject on the performance of our actions.
Indeed, when our customers realized how easy is for them to use the RIPE, ARIN or APNIC WEB portal to create ROAS, we saw prefixes being transition from unknown to valid. I think the above plan and its benefits is heavily overlooked from our community ☹
Kind Regards
Stavros
*From: *connect-wg <connect-wg-bounces@ripe.net> on behalf of Tomas Lynch <tomas.lynch@gmail.com> *Date: *Monday, 10 June 2024 at 00:21 *To: *Connect-WG <connect-wg@ripe.net> *Subject: *Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call
Please correct me if I'm wrong about my logic and naive about my proposal here:
If this BCOP is implemented by an IXP, then the IXP would have to tell all their peers to create route(6) objects in their RIR if they do not have it. At the same time, those peers would have to tell their customers to create objects in their RIR and so on. The time of that process in the BCP first draft is calculated as a grace period of 12 months (of course it can be reviewed).
So, there is an effort on the IXPs and on the peers to educate customers that can be used to educate them in signing ROAs. These users would have to login in their RIRs anyway. If I were a lazy AS administrator, I would rather create an ROA with 3 or 4 clicks than learn RPSL.
On Sun, Jun 9, 2024 at 1:20 PM Stavros Konstantaras < stavros.konstantaras@ams-ix.net> wrote:
Difficult but not impossible, right?
Maybe a reasonable counter-proposal would be to delay the removal of RADB for an extra year until a common API is adopted or a proxy tool is developed ?
Technical solutions exist, is a matter of willingness and I would love to see initiatives into that direction rather seeing ourselves rely on convenient solutions.
Kind Regards
Stavros
*From: *connect-wg <connect-wg-bounces@ripe.net> on behalf of Arturo Servin via connect-wg <connect-wg@ripe.net> *Date: *Friday, 7 June 2024 at 09:51 *To: *Barry O'Donovan (Open Solutions) <barry@opensolutions.ie> *Cc: *Connect-WG <connect-wg@ripe.net> *Subject: *Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call
On Thu, Jun 6, 2024 at 11:21 PM Barry O'Donovan (Open Solutions) < barry@opensolutions.ie> wrote:
Hi all,
One comment I did make was that it was paradoxical, on one hand, to bemoan the depeering of large network(s) from route servers and discuss how IXPs could engage to bring them back while, on the other hand, trying to implement a practice which would dictate how and where they should register their routing objects.
And this will definitely won't help to bring them back (and probably nothing will but we can try ... )
As I mentioned in my previous email, as stated in the MARNS for CDN/Cloud providers their approach for the same problem is different and possibly incompatible.
In a perfect world where all RIR support and have the same APIs to manage IRR objects, this could have an opportunity, but in the current state of affairs for IRR management in RIRs, I think it is difficult.
Regards
as
_______________________________________________ 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
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. I think you're referring to the Euro-IX Route Server Workshop held recently in Rome? No, I am referring to private discussions that me and Stavros had over
On Jun 06, "Barry O'Donovan (Open Solutions)" <barry@opensolutions.ie> wrote: the past year with other IX operators.
Others have already noted that a BCOP should reflect established /current/ operating practices, and I think this proposal fails that test. Yes, this is clear now.
-- ciao, Marco
Hi Barry, It was a pleasure to have you at the workshop and would love to see you again in the next one. I can assure you that with your presence at the workshop we didn’t assume agreement on this plan, we were just seeking for fruitful feedback and different opinions from our participants. 😊 As I already mentioned to a previous message, some of us already use a restricted pool of IRR DBs to create prefix lists. Indeed, it lacks massive adoption, but is not far away from reality and there is a good list of early adopters that expressed interest and would love to work on that direction. Do you mean you would like to see a number like 10-20 EU IXPs adopting this practice before it becomes a RIPE doc? And although the two proposals you mentioned sound paradoxical, if you re-think about it they are not. This current BCOP targets to enhance routing security while the second one combines it with common Traffic Engineering rules and other best practices. For the good friends in Akamai, perhaps both proposals will have little to zero impact. For the good friends in Google, both proposals are out of interest as they are de-peering with the Route Servers. For the good friends in META, Microsoft etc we need to examine it more thoroughly but the paradox is that Microsoft is already creating a pool of trustworthy Route Server deployments across IXPs via the MAPS program (not sure if they came to INEX though). Finally, I am super aligned with your last paragraph: regardless of the outcome of this proposal, it is a good crash-test to check the status-quo of this community regarding this hot topic. Kind Regards Stavros From: connect-wg <connect-wg-bounces@ripe.net> on behalf of Barry O'Donovan (Open Solutions) <barry@opensolutions.ie> Date: Thursday, 6 June 2024 at 23:21 To: Connect-WG <connect-wg@ripe.net> Subject: Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call Hi all, Marco d'Itri wrote on 06/06/2024 04:52:
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.
I think you're referring to the Euro-IX Route Server Workshop held recently in Rome? If so, let me start by saying it was a great workshop and very useful for route server operators - kudos to all who organised including Stavros. Regrettably, it was also the first of these workshops I was able to attend, and so I was unfamiliar with the rules of consensus, what was required to agree on a plan, and what had transpired at previous workshops. This BCOP plan felt like it came with plenty of prior work that I missed, so I was hesitant to be overly vocal as a newbie. I'm not sure to what extent it can be asserted that the plan was agreed by IXP operators (and I appreciate it's not clear what is meant by that above) but I'd like to state that my being present at the workshop does not convey agreement with this plan. One comment I did make was that it was paradoxical, on one hand, to bemoan the depeering of large network(s) from route servers and discuss how IXPs could engage to bring them back while, on the other hand, trying to implement a practice which would dictate how and where they should register their routing objects. Others have already noted that a BCOP should reflect established /current/ operating practices, and I think this proposal fails that test. I’d emphasise that, like everyone else here, I am passionately pro-improved routing security, and there are important roles for IXP operators here. Including proposals like this which, regardless of whether they succeed or fail, help remind us all of the potential problems with the status quo. - Barry _______________________________________________ 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%7C832fb580d06c42c8b2bd08dc866e9a80%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638533056808449838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hQC1YPT7FHBIcU4NaK2NBQC2Ewk%2FlzOBtcmIF4SeMGk%3D&reserved=0<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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fconnect-wg&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C832fb580d06c42c8b2bd08dc866e9a80%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638533056808462755%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Ky6ZZSuw%2B5r%2BZ0dhyAQk9atCF9vQJHRX7%2FzywWg5u2A%3D&reserved=0<https://lists.ripe.net/mailman/listinfo/connect-wg>
thanks for the work it could use an executive/tldr summary up front and i do not support adoption as a bcop. concentration of authority and power, just what we're trying not to do these years. invalidating the irrs of ntt, level3, et alia is destructive, not productive. similar for other non-rir irrs. i would support preferring some irrs in case of duplication/conflict randy
Hi Randy Thank you very much for your quick response. I noted down your feedback, but can you please elaborate a bit more regarding your concern on the concentration of authority? Let me ask you quickly a question: Aren’t we doing this already with RPKI system? Last time I checked my routinator installation, it had 5 root TALs only (apart from the experimental ones) and the recommendation from the RPKI promoters is to keep it as is and not create more root TALs. Did anything change recently, and we missed it? Nevertheless, this BCOP is targeting a very specific use-case and has neither global applicability nor a policy-enforcement nature. Other network operators perhaps will still find uses cases to operate their networks on RADB/NTT/Level3 etc etc Kind Regards Stavros From: Randy Bush <randy@psg.com> Date: Tuesday, 4 June 2024 at 19:09 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 thanks for the work it could use an executive/tldr summary up front and i do not support adoption as a bcop. concentration of authority and power, just what we're trying not to do these years. invalidating the irrs of ntt, level3, et alia is destructive, not productive. similar for other non-rir irrs. i would support preferring some irrs in case of duplication/conflict randy
On Wed, 5 Jun 2024, Stavros Konstantaras wrote: (snip)
Other network operators perhaps will still find uses cases to operate their networks on RADB/NTT/Level3 etc etc (snip)
Maybe those network operators should be writing a BCOP as well, so they can enlighten us about the reasons why they need to use non-RIR IRRs. Best Regards, Carlos ps: Thanks for this work Stavros.
stravos: first: sorry i try not not to do walls of text. i also tend not to read them. life is short.
can you please elaborate a bit more regarding your concern on the concentration of authority? Let me ask you quickly a question: Aren’t we doing this already with RPKI system?
somewhat over twenty years ago, when we were designing rpki and its initial uses, i pushed strongly on this issue. unfortunately, non- hierarchic trust research lagged, and still lags, hierarchic by decades. so much for web of trust. the ip resource alocation administrative *authority* is hierarchic, iana, rirs, lirs, ... the irr authority is not necessarily a hierarchy. i trust NTT because they have proven to be a trustworthy peer, not because APNIC says to. and lastly, the rpki does provide for and encourage CA distribution. unfortunately hierarchic, see above.
it had 5 root TALs only
it was designed to have one, iana randy
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
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@ripe.net> on behalf of Job Snijders <job@sobornost.net> Date: Thursday, 6 June 2024 at 13:22 To: connect-wg@ripe.net <connect-wg@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@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@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://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://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://lists.ripe.net/mailman/listinfo/connect-wg>
On Sun, Jun 09, 2024 at 05:13:18PM +0000, Stavros Konstantaras wrote:
* 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 .
I do not follow the above argumentation. Every run of bgpq3/bgpq4/peval get their data from IRRD v4 instances. The software already has been written, now we just need to start making use of it! :)
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.
OK. How does it make this 'workaround' 'not a good one'? Outright deleting databases seems to be a workaround to me.
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”
I think your perspective is clear, but multiple people have pointed out concerns that the other databases also contain useful information; thus logically, by using a priority preference model you get the best of both worlds?
But RADB will always prioritize their objects with SOURCE RADB over the official ones (which makes sense as they make money)
Do you know that for sure? Kind regards, Job
Hi Stavros / authors, I don't think connect-wg should adopt this document as a BCOP, at least not for the moment. Apart from the concerns raised by Job, Randy and also Arnold's comments at the mic during the connect-wg meeting, there are a couple of reasons for this which I'd like to add. The first, and main one, is that this isn't current operational practice across a lot of IXPs. It might happen one day that it'll be adopted widely across IXPs, but as far as I'm aware, we're not at that point yet. When we're sure that it's reasonable and widely-deployed current operational practice, then that would be the point at which it might be appropriate to starting thinking of designating it as best current operational practice. But it would be premature to make the leap from our current position to BCOP status, without several years of widespread deployment. The second concern I have is that routing security is a hot topic in regulatory circles right now. As an industry, we need to be very careful about what is published with the stamp of approval from industry groups and quasi-SDOs, because regulatory authorities adopt documents of this sort as mandatory national or supra-national requirement lists and sometimes do so without a full understanding of the downstream consequences. The lifetime of regulatory standards is measured in years / decades, and if it turns out that there are unforeseen issues with the proposals in this doc, then it will be difficult to unscramble the egg. From this point of view alone, i.e. separate to the issue of whether the positions stated in the document are technically advisable or not, the language in this document needs serious work before it would be suitable for publication. The current text is very prescriptive and this is not a good thing for a technical policy document. In the case of routing security, there are still difficulties for organisations who have ASNs, as-sets and route lists which span different RIRs, and for whom third party IRRDBs provide a reasonable and responsible mechanism for expressing their intended routing policies. Cutting these organisations off is not going to help routing security overall - they'll simply bypass route servers and then the industry will be back to unfiltered bgp sessions again. In terms of object conflicts, there are certainly issues. I think it would be good to address these issues and to try to get common processes in place to remove conflicts when it's obvious that non-canonical IRRDBs are maintaining stale information. The RIPE NCC continually addresses this in RIPE-NONAUTH and there is no reason that other IRRDBs couldn't do similar things. Nick Stavros Konstantaras wrote on 04/06/2024 12:16:
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
The first, and main one, is that this isn't current operational practice across a lot of IXPs. It might happen one day that it'll be adopted widely across IXPs, but as far as I'm aware, we're not at that point yet. When We are not at that point because our plan was to first publish a document with a timeline of future actions. If we have totally misunderstood the process of publishing a RIPE BCOP
On Jun 06, "Nick Hilliard (INEX)" <nick@inex.ie> wrote: then we can just move on with the plan and come back in a couple of years to publish the document (if anybody will still care to do the work when ~everybody in Europe will already have adopted it).
In the case of routing security, there are still difficulties for organisations who have ASNs, as-sets and route lists which span different RIRs, and for whom third party IRRDBs provide a reasonable and responsible mechanism for expressing their intended routing policies. Cutting these I do not believe that this is a real issue: while it may be slightly more convenient for some networks to just dump all route objects in RADB instead of using the appropriate IRR which is authoritative for each prefix, I think that at this point it is a fact that filters are generated as the union of the results from multiple IRRs. So I do not believe that allowing this is worth the troubles which come from using non-authoritative IRRs.
organisations off is not going to help routing security overall - they'll simply bypass route servers and then the industry will be back to unfiltered bgp sessions again. The proposal does not specify any actions for non-RS BGP filters, so I am not sure that I understand your point.
-- ciao, Marco
"The main interest of the task force is that current operational practice are captured and documents are published." - it's in the BCOP description. First implement, then we document it. Not the other way around. Paul.
If we have totally misunderstood the process of publishing a RIPE BCOP then we can just move on with the plan and come back in a couple of years to publish the document (if anybody will still care to do the work when ~everybody in Europe will already have adopted it).
Hi Paul, At AMS-IX infra, we already use the 5 + 4 DBs that are proposed in the document since last year with great success. Same result can be achieved at DECIX network as well as per recent analysis. I think Marco and Will use even less databases in their infrastructures. Moreover, I had the chance last year to attend the BGP security course of RIPE NCC, where the colleagues over there teach exactly the same content as we have in the BCOP. Hence, this document not only depicts RIPE NCC’s position but also is accompanied with real life examples and analysis. That said, isn’t this proposal a type of documentation of above activities? Kind Regards Stavros From: connect-wg <connect-wg-bounces@ripe.net> on behalf of Paul Hoogsteder <paul@meanie.nl> Date: Thursday, 6 June 2024 at 10:28 To: Marco d'Itri <md@Linux.IT> Cc: Connect-WG <connect-wg@ripe.net> Subject: Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call "The main interest of the task force is that current operational practice are captured and documents are published." - it's in the BCOP description. First implement, then we document it. Not the other way around. Paul.
If we have totally misunderstood the process of publishing a RIPE BCOP then we can just move on with the plan and come back in a couple of years to publish the document (if anybody will still care to do the work when ~everybody in Europe will already have adopted it).
_______________________________________________ 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%7C68e652e29b054cf788bd08dc8602a0d8%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638532593049955839%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=wU4j5W3DcLx7faH9HOECAOtnHDsvmIYwejCTHnbAkhY%3D&reserved=0<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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fconnect-wg&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C68e652e29b054cf788bd08dc8602a0d8%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638532593049964328%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=usAzRYv7jV2yHpT6b%2Fplp8NF%2F1meMs2XwAuLw4oO3W0%3D&reserved=0<https://lists.ripe.net/mailman/listinfo/connect-wg>
Best practice: An idea that has no evidence to support its merits and that probably doesn't work, but that you can attribute to someone else when things go horribly, horribly wrong. -- https://www.w3.org/2006/WSC/wiki/Glossary
Hi Nick, Thank you very much for participating in this discussion, much appreciated. I agree with Marco’s replies on your feedback, and I would like to add 1-2 short comments: * I do believe the second argument of yours is not that strong. This doc is just a BCOP in the RIPE region with a narrow scope, is not even a policy that is enforced from RIPE NCC. Actually, I would be more concerned about the ongoing Cyber Resilience Act that could send the route servers to the graveyard and eliminate similar future discussions. * If an organization has such a size that holds resources in multiple RIRs and those resources are being updated so frequently, I believe would not be an issue to put some development resources to adopt a few REST APIs which I expect to be similar (due to the adoption of IRRDv4). I know that so far RIPE, ARIN, APNIC and LACNIC offer REST APIs to manage resources in the databases. Here in AMS-IX (which is a small organization) we do have it in our 2024 pipeline to adopt those APIs. If however the tooling is the obstacle, then I would be happy to see how can I contribute in this aspect. Kind Regards Stavros From: Nick Hilliard (INEX) <nick@inex.ie> Date: Thursday, 6 June 2024 at 00:04 To: Stavros Konstantaras <stavros.konstantaras@ams-ix.net> Cc: Connect-WG <connect-wg@ripe.net> Subject: Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call Hi Stavros / authors, I don't think connect-wg should adopt this document as a BCOP, at least not for the moment. Apart from the concerns raised by Job, Randy and also Arnold's comments at the mic during the connect-wg meeting, there are a couple of reasons for this which I'd like to add. The first, and main one, is that this isn't current operational practice across a lot of IXPs. It might happen one day that it'll be adopted widely across IXPs, but as far as I'm aware, we're not at that point yet. When we're sure that it's reasonable and widely-deployed current operational practice, then that would be the point at which it might be appropriate to starting thinking of designating it as best current operational practice. But it would be premature to make the leap from our current position to BCOP status, without several years of widespread deployment. The second concern I have is that routing security is a hot topic in regulatory circles right now. As an industry, we need to be very careful about what is published with the stamp of approval from industry groups and quasi-SDOs, because regulatory authorities adopt documents of this sort as mandatory national or supra-national requirement lists and sometimes do so without a full understanding of the downstream consequences. The lifetime of regulatory standards is measured in years / decades, and if it turns out that there are unforeseen issues with the proposals in this doc, then it will be difficult to unscramble the egg. From this point of view alone, i.e. separate to the issue of whether the positions stated in the document are technically advisable or not, the language in this document needs serious work before it would be suitable for publication. The current text is very prescriptive and this is not a good thing for a technical policy document. In the case of routing security, there are still difficulties for organisations who have ASNs, as-sets and route lists which span different RIRs, and for whom third party IRRDBs provide a reasonable and responsible mechanism for expressing their intended routing policies. Cutting these organisations off is not going to help routing security overall - they'll simply bypass route servers and then the industry will be back to unfiltered bgp sessions again. In terms of object conflicts, there are certainly issues. I think it would be good to address these issues and to try to get common processes in place to remove conflicts when it's obvious that non-canonical IRRDBs are maintaining stale information. The RIPE NCC continually addresses this in RIPE-NONAUTH and there is no reason that other IRRDBs couldn't do similar things. Nick Stavros Konstantaras wrote on 04/06/2024 12:16: 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<mailto: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
participants (12)
-
Arturo Servin -
Barry O'Donovan (Open Solutions) -
Carlos Friaças -
Job Snijders -
Marco d'Itri -
Marco d'Itri
-
Mullally, Ronan -
Nick Hilliard (INEX) -
Paul Hoogsteder -
Randy Bush -
Stavros Konstantaras -
Tomas Lynch