I think we are dealing with two different problems here:
1. Orgs that just are opportunistic, i.e. they ignore abuse complaints
because it's cheaper and there is no penalty for ignoring complaints.
These you can catch by the LACNIC approach I mailed earlier
The second case is orgs whose business case rests on abuse, likely
intentionally. There the LACNIC approach might have an impact, in that
it increases costs for the orgs, but probably not much.
I assume that the second case would require some different action.
I don't think we should mix them up too much.
Best
Serge
On 04/08/2026 09:47, Jeroen Massar via Security-wg wrote:
On 4 Aug 2026, at 06:22, Hank Nussbacher <[email protected]> wrote:
On 03/08/2026 16:56, Jeroen Massar via Security-wg wrote:
IMHO the ship of abuse reporting simply has completely sailed. Some years ago
one could still report and action would be taken, now that will happen if you
know the people directly and otherwise even with an intro it often just gets
ignored (many people are also to busy with too many fires though).
And as the subject of this thread is:
- Abuse mailboxes are increasingly no longer monitored
- are being replaced by (bad) forms
I think we just need to accept that
All that is missing now is an xkcd cartoon.
:) -- briefly checked, no existing one there... yet.
Thus maybe better would be a little write-up with some new ideas and
self-counter points to exclude those already :)
TLDR:
- ISPs need to work together to resolve this
- RIRs could verify LIR details better (but hard problem with the state of the
world)
# A) Bad-actors getting new resources
Bad-actors can easily create a 'company' anywhere around the world, even outside of the
RIRs service area, with valid paperwork and apply to become a LIR and request resources
(be that ASN, IPv4 or IPv6) and use those. Their claim is "we are a company in
Panama, we'll use the prefix in Netherlands", and they might even have hardware in a
colocation to back that up.
RIR cannot check if the person behind the anonymous corporation is the same or
a fake person, as identities can be stolen, officials bribed etc. Thus for them
finding out if the same actors are behind it, a bad actor will find a way.
# B) Reporting Abuse only works when the LIR/ISP wants to really be a good
netizen
While telling a RIR "this LIR does not handle abuse" is an option, the RIR
currently has no mandate to do much with it. And even then, lets say there is a mandate
to close, the bad actor will go to A
# C) Whitelists / Trusted ISPs
Instead of blacklists and marking all the bad networks, one could make a list
of GOOD networks, as that scoring does not change too often.
Networks (ASN / LIR level) one knows that do report to abuse handling and are
good netizens (and yes, bad apples can slip in over time, companies get bought
out, thus one need to account for that).
The ideal version would be multiple separate entities keeping a "good ASN /
LIR" list.
An ISP can then consume those lists and go 'two out of three trust that ASN"
and now at least know that abuse reports get handled. New entrants, would need to
find a way to get on it.
The legal complications that might be associated with such a list for "you did not
put me in the whitelist" are fun, at least the model of multiple and scoring based
on that would help with redundancy.
In the end though, as history has shown, either there will be one working list,
list will be commercialized, or run by the same people in the backend ;)
Anything not on the whitelist is something one can then ratelimit in pps or
requests/sec etc.
Will it give something worthwhile.... a split in the Internet if implemented
(and we are going there already with hyperscalers being the center and the ones
that decides things), not sure it can even work out. Trust networks tend to
only work in smaller scales where people still now eachother, the Internet is
rather large.
We have one semi-known 'good list' btw: MANRS... https://manrs.org
<https://manrs.org/> but how many ISPs actively properly implement it? At least
for routing that covers it, does not cover abuse (spam/ddos/etc).
# D) Misconfigurations happen and persist
Bad-actors and misconfigurations can ask for transit from an ISP, who happily
announces it:
https://www.cidr-report.org/#Bogons
We know that these prefixes are not supposed to be there (unallocated space,
thus no RIR involvement) but as long as transits pass them on without
consequence... does it matter?
And that discounts option C: there will be good ISPs having misconfigs and not
acting to remove clearly obviously fully backed unallocated blocks. Go through
the above list, and the IPv6 one, and check the prefixes. You will find transit
ASNs that you know and love, and who do not do their due diligence, but would
end up on any 'good'' list. AS421005xxx being in that list is a good example of
this.
ISPs that do not want to see these can implement unallocated checks (but long
list and resource heavy to verify that it is okay to route that prefix). It
would be so much better done at the edge of networks who accept these prefixes.
Or they can at least verify with RPKI ROV or ASPA checks that those are
permitted prefixes.
both need ISPs to change something to make their Internet better.
And not everything on the Internet has a ROA let alone ASPA. And one needs
BGPsec at one point too to make it a full solution.
So above a few ideas, but also their counter arguments. As long as there is no
accountability for an ISP to pass on unallocated space/ASN as the simplest
example little will change with the offenders of spam, ddos etc, as there are
easier low hanging fruits that are not addressed either.
And yes, effectively, that would require an internet police to resolve, and
with international law, that will not easily happen, till some large enough
government just puts their foot down...
Those unallocated spaces are inexcusable, but now go find an ARF format where
that complaint fits in while every ISP worth their salt has seen the CIDR
Report for many many years already.
Regards,
Jeroen
-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
--
Dr. Serge Droz
Director, Forum of Incident Response and Security Teams (FIRST)
[email protected] | https://www.first.org
-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/security-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
