<div dir="ltr"><div>On Sat, Jun 3, 2017 at 7:27 PM, <<a href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a>> wrote:</div><div>> If enforcement of SWIP would result in the elimination of network abuse, I would not speak against it. However, even with valid contacts in SWIP, abuse reports are ignored. </div><div>> Contacting the ARIN allocation holder also often goes unanswered as well, and this is not dependent on SWIP. In addition to enforcement of valid contacts in Whois and SWIP, there </div><div>> needs to be a corresponding required response to reports of network abuse by those using ARIN resources. I find that the presence or absence of SWIP records have little to do </div><div>> with if a given allocation holder acts on abuse.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Albert,</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think it is worth dissecting this a bit more. </div><div class="gmail_extra">If an organization is trying in good faith, to follow ARIN rules, then they will try to keep SWIP information</div><div class="gmail_extra">for their networks accurate, as well as for their down stream customers.</div><div class="gmail_extra"><br></div><div class="gmail_extra">There is no ARIN requirement that a provider need to process or respond to abuse complaints on their </div><div class="gmail_extra">network space, nor that they take action on downstream customers who fail to process abuse complaints.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In some cases their are particular legal rules in particular countries that some types of abuse complaints </div><div class="gmail_extra">are required to be processed, for example legal take down requests. I suspect you will find very high </div><div class="gmail_extra">compliance in processing these types of abuse complaints.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In other cases there are unwritten standards of conduct that when violated results in a TOS agreement </div><div class="gmail_extra">violation leading to loss of service. I suspect you will find a wide mix in terms of what is permitted under</div><div class="gmail_extra">various TOS (although generally it is expected that the requirements are at least as strict for down stream</div><div class="gmail_extra">customers) as well as a wide mix on level of compliance in processing TOS abuse complaints.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In yet other cases, media agreements will contractually require DMCA violations to be processed. These </div><div class="gmail_extra">are often completed by a pre-defined process and not through abuse@ email contact. These will also </div><div class="gmail_extra">have a wide range of compliance directly proportional to the strength of the contract and importance of </div><div class="gmail_extra">the media agreement.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In yet other cases there is an unwritten standard of conduct that when violated results in being published</div><div class="gmail_extra">on a black list. This also has a wide mix in terms of what is needed to be added and removed from the </div><div class="gmail_extra">blacklist. Furthermore there is a wide mix of corresponding behavior by blacklisted organizations from </div><div class="gmail_extra">aggressively cleaning up black listed space and maintain a positive reputation (and usable IP space for </div><div class="gmail_extra">its customers), to organizations that do not engage black listers. Often times innocent customers are </div><div class="gmail_extra">caught in the middle, and network abusers move on to new IP space often with newly stolen credentials,</div><div class="gmail_extra">with very little that well meaning providers can do to prevent re-occurrence. </div><div class="gmail_extra"><br></div><div class="gmail_extra">My point is:</div><div class="gmail_extra">1. compliance tends to be very good when it is either required, or beneficial to the organization.</div><div class="gmail_extra">2. the data needs to be accurate to enable the first.</div><div class="gmail_extra"><br></div><div class="gmail_extra">__Jason</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 3, 2017 at 7:27 PM, <span dir="ltr"><<a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If enforcement of SWIP would result in the elimination of network abuse, I would not speak against it. However, even with valid contacts in SWIP, abuse reports are ignored. Contacting the ARIN allocation holder also often goes unanswered as well, and this is not dependent on SWIP. In addition to enforcement of valid contacts in Whois and SWIP, there needs to be a corresponding required response to reports of network abuse by those using ARIN resources. I find that the presence or absence of SWIP records have little to do with if a given allocation holder acts on abuse.<br>
<br>
The networks that you cite are examples of networks that deserve to be on a worldwide blacklist. From my point of view, most of my network abuse comes from addresses outside of the ARIN Region, mostly APNIC and RIPE. People hammer daily on my servers trying to get in with dictionary attacks. In the case of a couple of comment boards that I run, I ended up blacklisting from posting the entire APNIC and RIPE IPv4 space at the /8 level, as well as selected portions of ARIN in my apache configuration, as the intended audience is US based. The comment spam is very bad, and reports to the responsible contacts, even in the ARIN region go unanswered in most cases. Ditto with the Dictionary attacks.<br>
<br>
Those receiving allocations from ARIN need to be held responsible for actually answering reports of network abuse. I think this is vastly more important for enforcement than providing a SWIP record containing customer contacts which goes unanswered. Those with ARIN allocations should always be responsible for acting on reports of abuse, especially if no downstream SWIP records are provided, or the contacts in that record fail to act.<br>
<br>
Maybe the RSA should make the number resources subject to revocation if someone receiving space from ARIN regularly fails to respond and act on valid reports of network abuse. Maybe it already does, but it does not appear to be enforced.<br>
<br>
However, I do not think ARIN or any other RIR should required to become the "Internet Police". The purpose of ARIN is in 1.1 of the policy manual, which is uniqueness, contacts, transparency and assist in ip allocation studies. While having customers who abuse cannot always be prevented, failure to act on valid, repeated reports of abuse by those customers is wrong and should subject the Allocation to revocation. This is one of the few sticks that ARIN has in regard with "bad" members. The carrots do not seem to work.<span class="gmail-im gmail-HOEnZb"><br>
<br>
Albert Erdmann<br>
Network Administrator<br>
Paradise On Line Inc.<br>
<br></span><div class="gmail-HOEnZb"><div class="gmail-h5">
On Sat, 3 Jun 2017, Ronald F. Guilmette wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In message <<a href="mailto:551ebd1d-517e-5fb2-e379-0c45674b1f9d@linuxmagic.com" target="_blank">551ebd1d-517e-5fb2-e379-0c456<wbr>74b1f9d@linuxmagic.com</a>>,<br>
Michael Peddemors <<a href="mailto:michael@linuxmagic.com" target="_blank">michael@linuxmagic.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
.. and given the<br>
large increase in nefarious actors on the internet, it is important to<br>
have accurate information on the responsible party for that part of the<br>
internet.<br>
<br>
I for one want to see ARIN do more, and be given a mandate to enforce<br>
the given requirements already in place.<br>
</blockquote>
<br>
As should be evident to anybody who has been paying attention, I<br>
agree completely. And it isn't just me. Not by a long shot. It<br>
should be self-evident also that essentially every member of the<br>
law enforcement community, at all levels, would also like to see,<br>
if anything, the existing SWIP rules strengthened, rather than<br>
diluted, and, more importantly, would like to see them actually<br>
enforced someday.<br>
<br>
Unfortunately, as the examples I gave, of <a href="http://69.162.115.240/28" rel="noreferrer" target="_blank">69.162.115.240/28</a> and<br>
<a href="http://69.162.77.192/29" rel="noreferrer" target="_blank">69.162.77.192/29</a>, vividly illustrate, not only are the existing<br>
rules being openly flouted, but they are even being *brazenly*<br>
flouted, by at least some crooked providers... in this case<br>
Limestone Networks... who, for all I know, are selling identity<br>
protection services to criminals, as would appear to be the<br>
case here. (If anyone wants all of the particulars about the<br>
specific bad actors that are hiding out within the two blocks<br>
in question, and/or their direct links to an active and ongoing<br>
malware distribution operation, you can contact me off list and<br>
I will provide details.)<br>
<br>
Of course, Limestone Networks and its clearly non-residential<br>
"residential customer" are far from the only example I could<br>
cite here. It just happens to be among the most brazen and<br>
obvious. A fuller listing of all of the active identity<br>
concealment services that are, as we speak, being provided<br>
by entities holding direct ARIN allocations (and to various<br>
flavors of bad actors / criminals) would be so lengthy that<br>
I'm sure nobody here would bother to read it.<br>
<br>
In my more idealistic moments, I like to believe that we all have<br>
a shared and common interest in the security of the Internet as<br>
a whole. Few of us find the ongoing presence of spammers,<br>
hackers, and malware distributors to be directly beneficial.<br>
But clearly there are exceptions. Some holders of direct ARIN<br>
allocations are provably and unambiguously profiting from<br>
ignoring even the minimal and ineffectual SWIP rules that are<br>
currently on the books, and are doing so consciously, and in<br>
clear cooperation with bad actors, as a paid "service" to protect<br>
the true identities of these bad actors.<br>
<br>
Apparently, this is all exactly how the ARIN community wants things<br>
to be... nevermind the obviously negative effects to the security of<br>
all of us, and nevermind the general disrepute that these few "bad<br>
apple" providers bring to the ARIN community as a whole. The<br>
community makes sure that nobody, least of all the bad apple providers,<br>
will ever have to do or document anything that they don't much feel<br>
like doing or documenting, and the bad apple providers then, in turn,<br>
drive their proverbial trucks through the gaping loopholes in the<br>
rules and/or their enforcement, and thus profit handsomely by selling<br>
identity protection services to snowshoe spammers and malware distribtion<br>
operations, presumably for some additional premium, addded on top of<br>
the price for the usual and customary provision of non-cloaked services.<br>
<br>
I like to think that someday the vast majority of law-abiding and<br>
rule-following members of the ARIN community are going to wake up<br>
and realize that a small minority (<5%) of ARIN direct allocation<br>
holders are responsible for the vast majority (>95%) of all of the<br>
problems on the Internet, and that at some point the majority will<br>
at last conclude that enough is enough, and that all of these clever<br>
"hide the ball" games and shenanigans should finally, seriously, be<br>
ended. But I'm realistic enough to know that that day is not today.<br>
<br>
As with most problems faced by mankind... including global warming...<br>
things are going to have to get much much worse before they get any<br>
better, and the only thing that has been shown, over time, to reliably<br>
motivate homo sapiens to get up and out of their comfortable barcoloungers<br>
is a crisis that can no longer be ignored.<br>
<br>
I wish for once that we humans could be smart enough to act to solve at<br>
least this one evident problem early, i.e. -before- things reach crisis<br>
proportions, but in this case that doesn't seem at all likely.<br>
<br>
Would that it were otherwise.<br>
<br>
<br>
Regards,.<br>
rfg<br>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
</blockquote>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div></div>