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/ <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/ <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/
<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/
<https://www.ripe.net/membership/mail/mailman-3-migration/>
