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-boun...@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. 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 <m...@linux.it<mailto:m...@linux.it>> wrote: On Jun 06, "Mullally, Ronan via connect-wg" <connect-wg@ripe.net<mailto: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<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
_______________________________________________ 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
