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

Hi,

I am not going to outright support this proposal as I think that this
is not really the way we should be dealing with it.
The main reason for this is because I think it is quite pointless
unless every common IRR database does it. (all RIRs + RADB, ALTDB,
etc...).
Also there is no way to really do this in the non-authenticated IRRs
(RADB, ALTDB, etc.) so I think it is something that will only work if
we abandon the non-RIR IRRs.

I think Fredrik's idea of allowing certain names to be blocked is good
along with putting in a procedure for these names to be removed.
This would still have the same problems as this proposal but it feels
like a more minor thing as I do think this is a pretty minor issue in
terms of the number of entities that are likely to have this happen to
them.
Those entities might very well also have worldwide trademarks and it
seems sensible to have a policy of letting companies with trademarks
have an as-set using that trademark removed, especially when it is
clearly not being used for a legitimate purpose.
Disallowing something like AS-SNIJDERS just seems like it is doing
more than is really justified for how little I imagine would change.
It also comes with the added potential issue if some org has an as-set
with a name that was previously allowed and if they for some reason
accidentally delete it and are then unable to recreate it.
I am not sure how likely that is to be an issue but it seems like it
could very well be an issue that might occur.

<rant>
I will also reiterate what I said on routing-wg regarding essentially
the same issue: IRR is not good and there is no way we can really make
it good and especially not while people are still relying on
non-authenticated IRRs (like RADB, ALTDB, etc.).
For as long as we use non-authenticated IRRs, the system will be
broken. Maybe a good first step to try to prevent this would be for
the big companies getting impacted by these issues to switch to
authenticated IRRs hosted by RIRs.
Not placing blame on these companies for getting impacted, but the
fact that RADB and other non-authenticated IRRs are still used is part
of why this problem will be difficult to fix.
In the long run we just need to fully replace IRR though.
</rant>

Finally I want to say that I am willing to support this proposal if
everyone else thinks that is the best way to "solve" this issue but I
would like you to also consider my suggestions as a potential
alternative.

-Cynthia

On Mon, Nov 14, 2022 at 10:35 PM Korsbaeck, Fredrik via db-wg
<db-wg at ripe.net> wrote:
>
> 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/
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/