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

Job, Ben

So while I 100% agree with the problem statement here. (if not clear by my email-address, I do work for Amazon, and me in particular has been fighting both RIPE and the adversaries about this illicit Entry) 

Ideally I don't want to maintain my data in more than one place (right now, that place is RADB). With this suggestion and the hieararchical "protected namespace" this would, if I understand this correctly, not be a problem? 

I have no problem in moving over to use AS16509:AS-AMAZON as my official AS-SET going forward, if this can't be recreated elsewhere and therefor create these problems, which has the potential of being fairly large if an ISP generates empty prefix lists for us. 

Another alternative we thought about was to be able to have "invisible" objects or "protected objects" or whatever you want to call them, so we can create for example AS-AMAZON in every IRR-source but have it be invisible to avoid maintaining it, to protect ourselves from automatic prefix-list generators that would use the RIPE-object (empty) infront of the RADB-object (millions of routes). We touch our IRR-data basically daily (RPKI data every minute...) so scaling out here is not very nice. 

And on this topic, we tried to get this object deleted through regular support, but it was not possible since there is technically nothing that stops anyone from registering anything and calling it whatever. So there is really no jurisdiction from a database point of view to address it. However one thing that IS interesting is that the name itself, is a registered and protected trademark in essentially every single country in the world, so that’s an avenue one could argue should carry some weight in database-cleanliness? 

Either way, before we torch IRR to the ground there is some incremental steps we could take to make it better it seems like

All for. 

 /FK

PS: Perhaps RIPE could charge me 8$/mo for a verified blue checkmark on our as-set objects? __ .DS 


On 2022-11-14, 19:30, "db-wg on behalf of Ben Cartwright-Cox via db-wg" <db-wg-bounces at ripe.net on behalf of db-wg at ripe.net> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    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/

    --

    To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/