Hi Cynthia
"Problems" is a wide definition.
We know that some ISPs have built filters using the malicious AS-AMAZON record
in RIPE DB, instead of the real record in RADB. This generates an empty
prefix-list, and therefor completely filtered the inbound routes from us to
that ISP. However, luckily in all of our cases, there has been enough capacity
on upstream links and therefor all traffic rerouted without end-user really
noticing, however the path is probably not the most optimal, diminishing the
value of peering (not good).
And since this is affecting our inbound-traffic, we have to spend significant
time vetting all of our interconnects currently to look for suspicious drops in
inbound-traffic, based upon heuristic models. The blatant trolling in the RIPE
db has forced us to craft alarms based upon this peculiar behavior, where
inbound flows moves around without any sensible explanation (such as linkdown,
port-errors, etc etc). We have hundreds of thousands of BGP-sessions in the
world so this is no small task.
I would like to point out though, that despite all of this, I think the other
affected companies, have had bigger outages, and I guess we are just waiting
for when that day comes to us, which is also why we are fairly invested in
fixing this.
In almost all cases "we" (as in the routing security community) have been able
to found the original creators of said objects (seems to all come from a
tunnelbroker discord server) and pulling the historic chatlogs when it was
created, it was all for fun & games, and most creators decided to just delete
them when people from the community reached out and explained that the risk
involved in this behavior, is probably larger than what most people believe,
given it's also potentially squatting on trademarks.
/FK
On 2022-11-25, 00:47, "Cynthia Revström" <m...@cynthia.re> 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 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 <m...@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
--
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
