[db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects

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 at 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://mailman.ripe.net/