There is this notice and takedown framework the Dutch put in place.

https://www.i3d.net/legal/dutch-notice-and-takedown-procedure/

There is always a way when there is a will - particularly with legislation as 
enabling as this one reads, besides generally robust safe harbor protections

Now, developing that will is the next step.

From: denis walker <[email protected]>
Date: Tuesday, 4 August 2026 at 11:18 PM
To: Nick Hilliard <[email protected]>
Cc: Serge Droz <[email protected]>; [email protected] 
<[email protected]>
Subject: [Security-wg] Re: Abuse mailboxes are increasingly no longer monitored 
and are being replaced by (bad) forms

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]<mailto:[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/

Reply via email to