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

I also support this proposal.

I've assisted some of the mentioned networks in the Original Post to
solve the overlapping AS-SETS and it has been a real operational pain.

It's clear that the actors that are doing this are motivated either by
amusement at causing networks downtime or pain, or as a way to
ransom the impacted networks.

While those actors could move to another RIR or non-authenticated
database to do this, I believe that solving this here would help shift
networks to using a more secure by default AS-SET convention, and
protect networks that have yet to move.

I see two ways out of this problem, RIPE comes up with a policy for
getting overlapping AS-SET objects removed from the database (that are
causing problems, either accidentally or in these cases deliberately)
or deprecate (as discussed in the OP) short AS-SETs.

On Mon, Nov 14, 2022 at 6:03 PM 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/