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

Based on what has been said in this thread so far, I cannot support
automatic clean-up of AS-SETs even if they are empty.
There is simply way too little to be gained compared to the issues it
could cause.
Also if there is someone who maliciously created a short AS-SET, they
could simply just add an ASN into it to exclude it from automatic
clean-up.

It might be complicated but I really think the better way to go about
it is to handle each of the individual cases in which this is an issue
as I suspect that there are not many and they are probably pretty
clear cases.
I know of AS-AMAZON but are we aware of any other potentially
problematic AS-SETs in the RIPE DB currently?
Also I don't even know if it is currently causing issues for amazon,
but maybe Fredrik could answer that?

-Cynthia

On Thu, Nov 24, 2022 at 4:14 PM Nick Hilliard via db-wg <db-wg at ripe.net> wrote:
>
> Niall O'Reilly via db-wg wrote on 23/11/2022 18:17:
> > What I have in mind is AS-NIALLSPECIAL, which I populate with a list of
> > AS numbers which I want to advertise to let others know that these
> > are to be handled in some special way, unlike those in AS-NIALLNORMAL.
> >
> > According to operational circumstances, there might be periods, even
> > long ones, with nothing special going on; AS-NIALLSPECIAL would then be
> > empty, but only for as long as this continued to be the case.
>
> this ^^^ is one of the failure modes.
>
> It would not be safe to assume that empty as-sets named in RPSL policies
> are unused. It would be less unsafe to assume that unreferenced as-sets
> are unused.  A reasonable middle ground might be - after the proposed
> new unqualified as-set block has been implemented - to check out all
> unreferenced as-sets older than a specific period of time and flag those
> for deletion.
>
> It would also be worthwhile inspecting rpsl in other IRRDBs to see if
> there are any references.  The reason for this is that lots of people
> use tools like bgpq3 / peval / etc, and query aggregate IRRDBs, e.g.
> RADB, NTT, etc.
>
> So if you have RPSL in another IRRDB and this references an empty as-set
> in the RIPE IRRDB, that definition may be picked up in preference to
> other as-set definitions.  I.e. by removing an as-set definition in the
> RIPE IRRDB, it could unexpectedly influence routing policies elsewhere.
>
> These are corner cases, but they should show why some care will be
> needed to figure out whether deleting these objects is a good idea.
>
> Nick
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/