Colleagues The chairs discussed this issue over the weekend and agreed that we see a consensus to change the syntax rules for AS-SET object names in the RIPE Database. We also agreed that we believe this feature request can be managed through the Numbered Work Item process. We therefore ask the RIPE NCC to document 'NWI-19 Change to AS-SET object naming rules'. The problem statement is as specified by Job: -------------------------------------------------------- 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 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. -------------------------------------------------------- The solution proposal was also specified by Job with some clarification on the required syntax changes. -------------------------------------------------------- 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. The new syntax rules will follow these lines: -An AS-SET name must be hierarchical -There must be at least one colon (:) character in the name -The first element of the name must be an ASN -The second element of the name must be an AS-SET name starting with 'AS-' -Any further elements can be either ASNs or AS-SET names -Any other existing syntax rules that don't conflict with this change -These rules to only apply to creating new AS-SET objects -Existing non-hierarchical AS-SET objects can still be updated -------------------------------------------------------- One question to the community...do we want to disallow authorisation of new AS-SET objects from ASNs in RIPE-NONAUTH? The chairs would like the RIPE NCC to prepare an impact analysis. cheers denis and William co-chairs 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