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 <[email protected]> wrote: > On Jun 06, "Mullally, Ronan via connect-wg" <[email protected]> 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 > [email protected] > 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 [email protected] 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
