Hi Dennis
I like this, thanks a lot. I think it would make sense to create a
better understanding of systematic abuse, because otherwise there will
be endless arguments about this.
I also think it makes sense to have a clear list of abuse types we deal
with, maybe with a clause to update this every year or so. Otherwise,
the EU/ENISA will determine this. I kind of like starting small, and
then expand. But if people are fine with this, no problem for me.
There probably needs a feedback mechanism to the org that filed the
complaint.
I still think we need, separate to this an abuse-c test. Back in the
day, when we started blocking (removing NS delegations) for malicious
CH-Domains, one provider didn't have a working abuse contact, so we
blocked. Once they learned about the issue they fixed this. This is my
point: If you have a big club like you prose, there will be a motivation
to get your house in order before you escalate.
As I said, lazy/negligent operators are not the same as criminal ones.
The former we can probably motivate to become better.
Best
Serge
On 04/08/2026 19:48, denis walker wrote:
Colleagues
One of the reasons LIRs do not process abuse reports is because RIPE
policy currently makes it entirely free to ignore them. We can only
fix this by creating a clear, contractual incentive where permitting
systemic abuse carries the risk of registry suspension or closure.
To bypass historical jurisdiction arguments regarding the definition
of "abuse," we can utilize the harmonized definitions established
under the EU Directive on Cybercrime (2013/40/EU) and ENISA metrics
(covering DDoS, phishing, and malware distribution) as a baseline.
Just as Address Policy limits sub-assignments under contract, we have
the same right to prevent abusive behaviors, using the same
contractual terms.
Nick's latest email correctly highlights the core existential and
scaling traps that have stalled this conversation for a decade. If a
policy targets individual subscriber-level botnets, it creates an
unworkable scaling failure. If a policy forces the RIPE NCC to act as
a judge or deploy the 'nuclear option' of total resource withdrawal,
it invites massive legal liability.
However, we can completely bypass these traps by separating low-level
consumer incidents from systemic infrastructure abuse, and by shifting
the sanction from resource closure to administrative quarantine.
I propose a simplified, three-article baseline framework for an
Anti-Abuse Policy under the Policy Development Process (PDP):
----------------------------------
Article 1:
1.1 For the purposes of RIPE Address Policy, "Network Abuse" is
defined, as a base line, by the technical threat classifications
maintained under the European Union Cybercrime framework (specifically
DDoS, malware hosting, phishing networks, and systemic spam botnet
distribution).
1.2 The following activities are also included:
- dictionary attacks
Article 2: RIPE allocated and assigned address space must not be
systematically utilized to facilitate Network Abuse as defined in
Article 1.
Article 3: When the RIPE NCC receives an authenticated notification of
systemic abuse involving RIPE allocated and assigned IP addresses, the
registry responsible for those addresses will be given 14 working days
notice to shut down the abuser or have their registry operation suspended.
----------------------------------
To address the valid operational and legal questions raised over the
weekend regarding implementation, "internet policing," and protecting
innocent downstream networks, the operational compliance workflow
would function across three objective, administrative steps:
1. Objective Identification (The Scaling Filter)
To eliminate the 'grandma's compromised router' scaling problem, the
policy trigger must rely exclusively on infrastructure-only,
architecture-level blocklists that explicitly exclude residential and
dynamic subscriber IP space (such as the Spamhaus DROP list). An IP
from a RIPE address allocation or assignment must appear on such a
list for a continuous period of 14 consecutive days. This removes
human bias and ensures only persistent, intentional,
infrastructure-level abuse triggers the process.
2. Administrative Accountability (The Registry Mail Relay)
Because the LIR is ignoring standard automated abuse-c: emails, an
affected network operator or a National CERT uploads the 14-day
continuous blocklist evidence to a dedicated RIPE NCC Compliance Portal.
The RIPE NCC does not act as a judge or evaluate the traffic. To
strictly protect member data privacy, the official contract address of
the LIR remains confidential. The RIPE NCC simply acts as an
administrative postal carrier. They look up the LIR’s private legal
contact details on file and forward a formal remediation notice via
Registered Mail to the physical legal address they are already
contractually required to maintain under their signed RIPE NCC
Standard Service Agreement. This applies uniformly to all LIRs across
the entire RIPE region, regardless of country, organizational
structure or legal jurisdiction.
The RIPE NCC already uses this exact contract address to send out
formal legal warnings for non-payment of fees or failure to pass
administrative audits (ARCs). They are simply utilizing an existing,
well-established legal pipe.
3. Non-Lethal Sanction (The RPKI CA Freeze)
The LIR is given a strict 14 business days from the confirmed date of
physical or electronic delivery to self-correct. If they quietly
terminate the abuser’s account, the traffic stops, the IP
automatically drops off the blocklist, the RIPE ticket closes, and no
penalty is applied.
If the 14 days pass, the IP remains blacklisted, and the LIR has
explicitly refused to respond to the paper trail sent by the RIR
registry, the RIPE NCC executes a boilerplate administrative sanction:
they freeze the LIR's RPKI CA management and append an administrative
status update to the continuous NRTM serial stream by updating the
LIR's ORGANISATION and ALLOCATION or ASSIGNMENT objects with a
'NON-COMPLIANCE' tag.
Operational Timeline and Liability Realities:
Nick is entirely correct that threatening to kill a business over a
few abusers is legally unworkable. That is why this proposal does not
withdraw resources or trigger a sudden, automated network shutdown
that instantly drops thousands of innocent downstream customers
offline. The RIPE NCC is completely insulated from legal liability.
Initially, all downstream traffic continues to flow normally. What we
are doing is cryptographically freezing the LIR's routing boundaries.
They cannot shift transits or alter routes to evade security tracking,
and their daily automated BGP filter rebuilds will signal their
non-compliance to the market.
Furthermore, if an LIR ignores over four weeks of automated warnings
and an explicit, paper-trailed legal notice from the RIR registry,
concealing that operational risk from its own downstream clients, the
liability for any subsequent routing disruption or upstream transit
disconnection rests squarely on the non-compliant LIR—not the RIPE
NCC. We completely bypass unmonitored email accounts. The RIPE NCC
handles the administrative notice delivery and holds the
authoritative, legally binding proof of receipt.
Nick asked for a concrete proposal to discuss rather than
generalities. This 3-step framework uses existing data and mechanisms,
protects data privacy, requires zero judicial filtering by RIPE NCC
staff, avoids legal liability by the RIPE NCC for any consequences and
protects innocent networks while finally holding non-responsive
resource holders contractually accountable.
Let's work together to end this 20 year impasse...
cheers
denis
On Tue, 4 Aug 2026 at 16:27, Nick Hilliard <[email protected]> wrote:
Serge Droz via Security-wg wrote on 04/08/2026 13:30:
> Nick: I'd appreciate if you could contribute more than just
reasons for
> why something doesn't work. Or is, what you are saying, that
LACNIC and
> APNIC just don't get it. I will now stop answering to your
objections,
> since this is not constructive.
Serge,
I replied to a suggestion that you made, and if I understand it
correctly, what LACNIC and APNIC are doing is substantially
different to
what you were suggesting in your email.
Possibly this is one of the problems with this (recurrent)
conversation
- different people are talking across each other about different
potential solutions to different problems in the same email thread.
Specifically what you suggested in your last email is fairly
fine-grained. Spam and residential proxies are a huge problem and a
noticeable percentage of subscriber accounts host compromised
equipment
- TVs, fridges, IOT, malware-ridden POS units, laptops, etc. If your
proposal is effectively for individual subscriber-level stuff to be
handled by or escalated in some way another to the RIPE NCC,
there's a
huge scaling problem right there. The RIPE NCC doesn't have the
scope or
scale to become a clearinghouse for abuse complaints at that level of
granularity.
At the point that an organisation was so substantially involved with
online abuse that complete resource withdrawal could be considered
justified by some measure, then I'd be thinking that that would be
already well within the jurisdiction of civil authorities to handle.
Also, the RIPE NCC isn't set up to make judgement calls about this
sort
of thing.
If you're talking about general abuse management, then the
suggestion of
deregistration of resources is a pretty severe sanction. Put simply,
it's the sort of thing that could kill a business, and given the RIPE
NCC's position as a regional monopoly of registration services, they
would need to be pretty careful about applying this sort of
sanction to
their members. Threatening to do something which would kill a
business
is the sort of thing that's going to be legally unworkable unless it
falls into either breach of boilerplate contract terms (e.g.
failure of
members to pay bills, bankruptcy, etc, i.e. stuff which is routine
and
well-established in law) or stuff which was immediately
identifiable as
critical to the continuity of the RIPE NCC's core mandate, which
is to
ensure the correct registration of resources, e.g. continued
failure of
ARC audits. These things are already in the standard service
agreement.
Overall, the remedies being proposed are too slow and too
coarse-grained
to deal with how resources are abused in real life, and too severe to
deal with anything other than systematically intentional abuse, in
which
case it's by definition a legal problem for someone else to handle
anyway.
You're right to ask for constructive ideas, but I genuinely don't see
any which involve the RIPE NCC that aren't fraught with serious
and in
many cases, existential problems. Maybe the way to deal with this
would
be to put a formal proposal together, as something that can be
discussed? Right now, there's nothing concrete to discuss.
Nick
-----
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/
-----
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/
