South African Internet Service Providers (ISPA) operates a take-down notice process on behalf of its members.
https://ispa.org.za/consumer-support/take-down-notices/how-to-lodge-a-take-down/ Regards. Le mar. 4 août 2026 à 12:56, Suresh Ramasubramanian <[email protected]> a écrit : > 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]> 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/
----- 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/
