I support the idea as well.


Kind Regards

Stavros Konstantaras | Sr. Network Engineer | AMS-IX
Frederiksplein 42, 1017 XN Amsterdam, The Netherlands
M +31 (0) 620 89 51 04
ams-ix.net<http://ams-ix.net>


From: db-wg <[email protected]> on behalf of Emil Palm via db-wg 
<[email protected]>
Reply to: Emil Palm <[email protected]>
Date: Wednesday, 16 November 2022 at 13:07
To: "[email protected]" <[email protected]>
Subject: Re: [db-wg] proposal: disallow creation of new non-hierarchically 
named AS-SET objects

Solution proposal
=================
I think the solution is to - GOING FORWARD - disallow creation of new
AS-SET objects which follow the 'short' naming style.

I support this solution

On Mon, 14 Nov 2022 at 18:41, Job Snijders via db-wg 
<[email protected]<mailto:[email protected]>> wrote:
Dear DB-WG,

Speaking in individual capacity.

In RFC 2622 section 5 specifies the naming convention for AS-SET
objects. 
https://www.rfc-editor.org/rfc/rfc2622#section-5.1<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>
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 
https://www.peeringdb.com/net/1418<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>
 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:
https://github.com/irrdnet/irrd/issues/408<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>

Kind regards,

Job

--

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/db-wg<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>
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/db-wg

Reply via email to