<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="en-NL" link="blue" vlink="purple" style="word-wrap:break-word"> <div class="WordSection1"> I support the idea as well. <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Kind Regards<o:p></o:p> <o:p> </o:p> Stavros Konstantaras | Sr. Network Engineer | AMS-IX Frederiksplein 42, 1017 XN Amsterdam, The Netherlands M +31 (0) 620 89 51 04 <a href="http://ams-ix.net" title="http://ams-ix.net/">ams-ix.net</a><o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: db-wg <db-wg-bounces@ripe.net> on behalf of Emil Palm via db-wg <db-wg@ripe.net> Reply to: Emil Palm <emil@netnod.se> Date: Wednesday, 16 November 2022 at 13:07 To: "db-wg@ripe.net" <db-wg@ripe.net> Subject: Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects<o:p></o:p> </div> <div> <o:p> </o:p> </div> <div> <blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"> Solution proposal ================= I think the solution is to - GOING FORWARD - disallow creation of new AS-SET objects which follow the 'short' naming style.<o:p></o:p> </blockquote> <div> <o:p> </o:p> </div> <div> I support this solution <o:p></o:p> </div> </div> <o:p> </o:p> <div> <div> On Mon, 14 Nov 2022 at 18:41, Job Snijders via db-wg <<a href="mailto:db-wg@ripe.net">db-wg@ripe.net</a>> wrote:<o:p></o:p> </div> <blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"> Dear DB-WG, Speaking in individual capacity. In RFC 2622 section 5 specifies the naming convention for AS-SET objects. <a href="https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc2622%23section-5.1&data=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C0ae0271e70bf4ade6ae408dac7cb331e%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638041972795837229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BJKdbzxhekJUUBiprtS6%2B00dLK%2BsuSxv%2FxaCnWUFFpc%3D&reserved=0" target="_blank"> https://www.rfc-editor.org/rfc/rfc2622#section-5.1</a> There basically are two styles: * "short" (example: AS-SNIJDERS) * "hierarchical" (example: AS15562:AS-SNIJDERS) Problem statement ================= In recent weeks a number of hypergiant cloud providers have faced the thorny effects of adversarial AS-SET object naming collisions between IRR databases. An example of this phenomenon is the existence of AS-AMAZON in both RADB and RIPE. According to <a href="https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.peeringdb.com%2Fnet%2F1418&data=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C0ae0271e70bf4ade6ae408dac7cb331e%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638041972795837229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TslaSp8LfMPD%2Ba1z2Aauez8LLnpqc6tEQGPl1r%2B%2FrMM%3D&reserved=0" target="_blank"> https://www.peeringdb.com/net/1418</a> the RADB copy of the object is the the correct one and populated with a number of members entries. The RIPE one is empty, and not under control of Amazon. The existence of the AS-AMAZON object in the RIPE database might cause some operators to inadvertently apply empty prefix-filters to EBGP sessions which in turn causes various problems. It seems Amazon has no recourse to get the AS-AMAZON object removed from the RIPE database; because the existence of that object in the RIPE database does not violate any policies (as far as I know). But perhaps, going forward, this community can do a little bit more to help prevent similar situations from happening to others. Solution proposal ================= I think the solution is to - GOING FORWARD - disallow creation of new AS-SET objects which follow the 'short' naming style. The advantage of hierarchical naming is that the existing authorization rules as applied by the RIPE Whois Server database engine do a decent job of protecting/separating namespaces. 'Grandfathering' existing short-named objects ensures that implementation of this solution proposal causes minimal (if any) disruption to existing workflows. The RIPE database engine blocking creation of short-named AS-SETs might help nudge the industry towards making hierarchical naming the norm. Related work ============ Related work throughout the registry industry: IRRd version 4 forces new AS-SET objects to be structured hierarchically: <a href="https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Firrdnet%2Firrd%2Fissues%2F408&data=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C0ae0271e70bf4ade6ae408dac7cb331e%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638041972795837229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qoot5BPK95InIXGeQH9Hhp0ZcPM4I8dD95cpEE%2F9%2Bac%3D&reserved=0" target="_blank">https://github.com/irrdnet/irrd/issues/408</a> Kind regards, Job -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: <a href="https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fdb-wg&data=05%7C01%7Cstavros.konstantaras%40ams-ix.net%7C0ae0271e70bf4ade6ae408dac7cb331e%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638041972795837229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OCpNwUO8IhZ%2BGoO%2FO%2FIVQ5Z0Nk5imw%2Bh8NG9rW4jljU%3D&reserved=0" target="_blank"> https://mailman.ripe.net/</a><o:p></o:p> </blockquote> </div> </div> </body> </html>