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/
