<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Solution proposal<br>=================<br>I think the solution is to - GOING FORWARD - disallow creation of new<br>AS-SET objects which follow the 'short' naming style.</blockquote><div><br></div><div>I support this solution </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear DB-WG,<br>
<br>
Speaking in individual capacity.<br>
<br>
In RFC 2622 section 5 specifies the naming convention for AS-SET<br>
objects. <a href="https://www.rfc-editor.org/rfc/rfc2622#section-5.1" rel="noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc2622#section-5.1</a><br>
There basically are two styles:<br>
<br>
    * "short" (example: AS-SNIJDERS)<br>
    * "hierarchical" (example: AS15562:AS-SNIJDERS)<br>
<br>
Problem statement<br>
=================<br>
In recent weeks a number of hypergiant cloud providers have faced the<br>
thorny effects of adversarial AS-SET object naming collisions between<br>
IRR databases.<br>
<br>
An example of this phenomenon is the existence of AS-AMAZON in both RADB<br>
and RIPE. According to <a href="https://www.peeringdb.com/net/1418" rel="noreferrer" target="_blank">https://www.peeringdb.com/net/1418</a> the RADB copy<br>
of the object is the the correct one and populated with a number of<br>
members entries. The RIPE one is empty, and not under control of Amazon.<br>
<br>
The existence of the AS-AMAZON object in the RIPE database might cause<br>
some operators to inadvertently apply empty prefix-filters to EBGP<br>
sessions which in turn causes various problems.<br>
<br>
It seems Amazon has no recourse to get the AS-AMAZON object removed from<br>
the RIPE database; because the existence of that object in the RIPE<br>
database does not violate any policies (as far as I know). But perhaps,<br>
going forward, this community can do a little bit more to help prevent<br>
similar situations from happening to others.<br>
<br>
Solution proposal<br>
=================<br>
I think the solution is to - GOING FORWARD - disallow creation of new<br>
AS-SET objects which follow the 'short' naming style.<br>
<br>
The advantage of hierarchical naming is that the existing authorization<br>
rules as applied by the RIPE Whois Server database engine do a decent<br>
job of protecting/separating namespaces. 'Grandfathering' existing<br>
short-named objects ensures that implementation of this solution<br>
proposal causes minimal (if any) disruption to existing workflows.<br>
<br>
The RIPE database engine blocking creation of short-named AS-SETs might<br>
help nudge the industry towards making hierarchical naming the norm.<br>
<br>
Related work<br>
============<br>
Related work throughout the registry industry: IRRd version 4 forces new<br>
AS-SET objects to be structured hierarchically:<br>
<a href="https://github.com/irrdnet/irrd/issues/408" rel="noreferrer" target="_blank">https://github.com/irrdnet/irrd/issues/408</a><br>
<br>
Kind regards,<br>
<br>
Job<br>
<br>
-- <br>
<br>
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: <a href="https://mailman.ripe.net/" rel="noreferrer" target="_blank">https://mailman.ripe.net/</a><br>
</blockquote></div>