Hi Job Interesting timing. I was about to make the same suggestion but for a different reason...accountability. Currently ANYONE can create a set object in the RIPE Database. You can be completely anonymous, not a member or LIR, hold no resources. All you need to do is create a ROLE, MNTNER and set object. I was going to ask this question: Although anyone CAN create a set object, who DOES create set objects? Ignoring the abuse situation you are referring to, is there any legitimate reason for anyone to create a (short named) set object who does not hold an ASN resource? Only if the answer is no, can we enforce hierarchical naming. cheers denis co-chair DB-WG On Mon, 14 Nov 2022 at 18:41, Job Snijders via db-wg <db-wg@ripe.net> 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 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 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
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