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

I have just been informed that AS-AMAZON in the RIPE DB is indeed
causing issues for Amazon currently, so please disregard that
question.

-Cynthia

On Fri, Nov 25, 2022 at 12:20 AM Cynthia Revström <me at cynthia.re> wrote:
>
> 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/