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@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@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://lists.ripe.net/mailman/listinfo/db-wg