This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[anti-abuse-wg] About "consensus" and "voting"...
- Previous message (by thread): [anti-abuse-wg] About "consensus" and "voting"...
- Next message (by thread): [anti-abuse-wg] About "consensus" and "voting"...
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Suresh Ramasubramanian
ops.lists at gmail.com
Mon May 11 18:00:15 CEST 2020
Due diligence can be legally problematic but the consequences, sooner or later, of not performing such due diligence are likely to be worse sooner or later. A decade or so back, the discussion here was about handing out multiple /15s to various LIRs who were populating them entirely with snowshoe spam. More than one person here back then was assuring me “oh that’s not a problem, IPv6 is here to stay and v4 is getting exhausted anyway”. About your question as to whether this is going to help mitigate internet abuse because the shady outfit will just register a fresh shell company, apply for LIR status and resume their activities. In security, you never let your adversaries entrench themselves in positions of strength, so chase them off ISPs, registrars and such on a regular enough basis and they’re left busy rebuilding their infrastructure – too busy to distribute malware or phish, never mind just spam. Keep them moving often enough and their efficiency is reduced. Take down a bunch of domains and suspend registrar accounts along with the IP addresses and the damage takes much longer for them to repair. Besides if these are coordinated with arrests and equipment seizure coordinated with law enforcement, it takes much longer for them to bounce back. The shutdown of Intercage / Atrivo back in 2008 was an early example. A brief but extremely sharp dip in spam levels worldwide, so that various botmasters had to scramble to set up new hosting. http://voices.washingtonpost.com/securityfix/2008/10/spam_volumes_plummet_after_atr.html From: Nick Hilliard <nick at foobar.org> Date: Monday, 11 May 2020 at 8:15 PM To: Suresh Ramasubramanian <ops.lists at gmail.com> Cc: anti-abuse-wg at ripe.net <anti-abuse-wg at ripe.net> Subject: Re: [anti-abuse-wg] About "consensus" and "voting"... Suresh Ramasubramanian wrote on 11/05/2020 13:20: > I am not entirely sure the discussion has moved all that much in the > past decade beyond this exact point - how to pressure ripe to deal with > shady actors getting themselves LIR status or appropriating large legacy > netblocks belonging to defunct companies. Fraudulent appropriation of network blocks is a direct violation of the SSA, and is already actionable. From what I understand, the RIPE NCC already deals with abuse of this form on a regular basis. Refusing to grant LIR status to "shady actors" is legally difficult. So is revocation of resource holdership on the grounds that the number resources were used for specific purposes which may be illegal in some or all of the RIPE NCC service region. Acting outside the terms of legal proportionality is also problematic. Many policy proposals have foundered on this issue. Also, there are open questions as to whether deregistration of IP addressing resources will have a real impact on abuse management, or whether the abusers would just spin up another legal vehicle to conduct their abuse. Overall, this is a fraught area. This is at least part of the reason that it's been difficult to reach consensus on a good number of these proposals. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/anti-abuse-wg/attachments/20200511/7617fc64/attachment.html>
- Previous message (by thread): [anti-abuse-wg] About "consensus" and "voting"...
- Next message (by thread): [anti-abuse-wg] About "consensus" and "voting"...
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]