[arin-ppml] Policy Proposal 2003-1: Required Performance of Abuse Contact

Michael Greenup michael.greenup at ionos.com
Fri Aug 29 15:02:27 EDT 2025


Hi Shawn,

Please allow me to clarify my position. I will happily look at any proposal
you submit but like the others I am wanting to help you understand the
complexities involved with this idea.

My company is, by your definition, already compliant: We issue a ticket
when we receive an abuse complaint and I can assure you I have personally
scoured our networks looking for abusive accounts and personally taken them
offline (even before we had an abuse complaint). However, I work for a
hosting provider and I can assure you, the additional overhead this will
cost my company will be incredibly high. We already have to deal with DMCA
requests, Better Business Bureau issues, and various other industry
complaints as a cost of doing business. We accept this because we want to
be good netizens. This does not mean we are perfect or that we could not
find areas in which we can improve, but we actively iterate on our
processes to ensure we are meeting or exceeding expectations where
possible.

At the same time, it seems you are not wanting to hear what others are
saying either. You have your point of view which I respect and empathize
with as it is both a real and expensive issue for every device, website,
server, etc. owner on the Internet. Being a role model for other RIRs does
not really work in practice or we would have adopted some of the policies
and database functionality of RIPE (as an example). If a policy like this
is to be implemented, it should really be implemented at a higher level
like the IETF or even ICANN so it can apply to all RIRs.

How many more employees should AWS, Google, or any of the other "compliant"
businesses actually hire to ensure this policy is fulfilled? I mean, if you
really want to know why this policy will meet resistance then understand
you are asking companies to reduce their bottom line by increasing OPEX,
increase their prices to cover the OPEX increase to ensure compliance thus
making their product look less attractive, or even getting legitimate
complaints missed because of all the malicious complaints received.

Believe me, the volume of spam our abuse@ email receives is ridiculous. I
know of at least one person who gets angry at us every so often and goes
and submits all our POC addresses to various mailing lists - and because we
are "subscribed" the spam filter doesn't pick them up and just fills up the
ticket queue. Again, the potential for maliciousness and abuse of such a
policy is high and then you want us to be able to lose resources because we
didn't respond with the correct answer to some malicious complaint? I
cannot imagine any resource holder agreeing to this policy no matter how
compliant they are.

Also a point of consideration is what will this look like from ARIN's side?
What "evidence" must a complainant provide to show a good faith attempt to
get the abuse resolved to open an investigation? What "evidence" will be
required by ARIN to ensure the abuse@ holder did everything necessary to
comply with the policy? Understand, gathering this information costs both
time and employee resources for ARIN and the abuse@ holder for very low
effort for the complainant. Any time you have a low effort bar for one side
which turns into a high effort bar for the other is going to breed
maliciousness (like a DNS reflection attack). How is your proposal going to
deal with this issue?

Again, I look forward to reading your proposal and I really hope you will
figure out how to get around these issues. Until I read your proposal
though, I cannot help but be opposed to the idea in principle.

Regards,

Michael

*The opinions and beliefs expressed in this email are mine alone and do not
reflect the opinions and beliefs of my employer.*


On Fri, Aug 29, 2025 at 12:56 PM Shawn Bakhtiar <shashaness at gmail.com>
wrote:

> I would agree with everything you are saying, save there is one problem....
>
> As much as I appreciate your thorough arguments, they fly in the face of
> reality.
>
> AWS, DigitalOcean, Datapacker, and many others are following the proposed
> policy and succeeding in reducing the abusive behavior. I use to do it and
> I'm a mom and pop shop.
>
> It sounds like you've already resigned yourself to defeat.
>
> I believe we can revive this policy in ARIN, set an example for the rest
> of RIRs, and make a huge dent in the amount of useless traffic generated on
> the internet.
>
> Everyone would benefit, and I have as of yet to hear a good argument
> against, given that all the arguments made so far (administratively
> prohibitive) are being proven wrong by all the providers that are doing it
> and being effective at it.
>
>
> On Aug 29, 2025, at 8:46 AM, Michael Greenup <michael.greenup at ionos.com>
> wrote:
>
> Hi Shawn,
>
> In a world where DMCA takedown requests are made based on a search of
> keywords (and not actual content to see if there is actually any
> infringement), this proposal creates some significant issues for ARIN
> resource holders.
>
> I agree, a response from abuse@ should have a timely response and
> resolution, but the problem is the resolution might not be what the abuse@
> sender is actually wanting. Just open port 22 to the Internet and watch all
> the brute force attacks against your device. Unfortunately, while I agree
> this is abuse, it is a normal reality we will face from all regions, not
> just the ARIN region. I could easily set up a script to record every IP and
> automatically send an email to every abuse@ address but that would
> essentially lead to my own email being spammed with responses. Honestly,
> nobody has time to go through all those responses to see if they are
> accomplishing what I want, which is that the abuse stops.
>
> Even worse, many DDoS vectors spoof an IP address in an attempt to get the
> spoofed source IP address flooded. Think of how a DNS reflection attack
> works. Currently, SHODAN shows some 90k open DNS resolvers on the Internet.
> All it takes is for a malicious source to spoof a source IP address and
> send requests to these servers to take your source IP offline. So if we
> follow the logic of the proposal and your view of it, ARIN should start
> policing DNS resolving and operators should have to prove their DNS cannot
> be maliciously used or forfeit their right to resolve DNS. This, however,
> is not the purpose of ARIN. ARIN provides resources according to
> established policy, but it does not dictate nor police how those IPs are to
> be used.
>
> The sad reality is, the Internet was never designed with security or
> safety in mind. Give everybody a useful tool and somebody will figure out a
> way to abuse it. While I resent the notion of "just through
> cpu/ram/money/whatever" at the problem, in some cases, we have to take on
> the role of sysadmin and figure out how best to protect ourselves against
> these malicious actors. The only thing this policy would do is create more
> issues for those responsible providers for doing what we are supposed to do
> because all it would take is one person who wrote abuse@ to make a claim
> to ARIN that we are not acting like a responsible provider. Multiply that
> by X malicious actors (something like that could be easily scripted and
> there are enough bot networks out there to flood ARIN) and you can see how
> this idea does not scale.
>
> Providers like spamhaus are also able to be exploited. All one needs do is
> talk to any email service provider to find out how quickly and easily it is
> to get added to any number of the spam lists out there but how difficult it
> is to get off the list. Something as simple as deciding I don't want to
> receive email from a list and reporting it to a spam list provider instead
> of clicking 'unsubscribe' happens unfortunately more than some like to
> admit.
>
> In other words, there is no perfect solution to this issue. I, therefore,
> join my fellow community members in opposing this policy.
>
> Regards,
>
> Michael
>
>
> *The opinions and beliefs expressed in this email are mine alone and do
> not reflect the opinions and beliefs of my employer.*
>
>
> On Fri, Aug 29, 2025 at 9:32 AM Shawn Bakhtiar <shashaness at gmail.com>
> wrote:
>
>> Good morning Scott, Paul,
>>
>> I'm not sure who Matt is, so far the only reasonable response I've
>> received have been from Bill, who's right about doing my homework on the
>> topic, and I truly appreciate his time and effort in leading me in a good
>> direction.
>>
>> You and Paul's suggestion, on the other hand, to simply block / report /
>> sue, I find completely lacking, and frankly sad.
>>
>> Your suggestions reeks of the those supposedly (edumicated) computer
>> engineers I see managing servers, who simply throw CPU and memory at a
>> problems instead of caring about or addressing the underlying root cause of
>> an issue. Do either of you run OSSEC on servers you manage?
>>
>> Your argument is tantamount to, I don't know what to do, so I'll just
>> kick the can down to a policing organization who actually has very little
>> skill or ability to meaningfully do anything about it. I've been there and
>> done that, it's all but pointless. After 40 years of government and private
>> work (long before the modern form of the internet was even a verb), I can
>> assure you, your suggestion is lacking at best, and.... well... let's just
>> leave it there, before I break the protocols of politeness :)
>>
>> it is a shirking of responsibility for an organization that claims as
>> part of it mission statement "...member-based organization that supports
>> the operation and growth of the Internet."
>>
>> I would argue that letting this behavior continue would neither be
>> supportive nor promote growth (unless we're taking about the growth of
>> Microsoft and others who abuse their size).
>>
>> I'm not talking about a few vulnerability scans done by Universities et
>> al, I'm taking about being hammered by 100s of popup-script-kiddie-servers
>> made popular by products like Kali Linux, and the fact that some providers
>> like AWS take it seriously while others like Microsoft completely ignore
>> emails sent to registered abuse emails.
>>
>> It perplexes me to no bounds to see Amazon AWS (of all people), Digital
>> Ocean, and many others, being a good netizen, and doing it (despite ARIN's
>> inability to define a very common sense policy,  responding to abuse
>> emails, assigning support tickets, and taking action on them, while
>> Microsoft (we all know who they are) does not, and I'm beginning to see
>> why.
>>
>> This I did not expect.
>>
>> You have quickly dismissed a real concern, without engaging in any
>> meaningful debate. If what you say is remotely true, than why does
>> Spanhuase exists? why does Abuse Radar exists? Why are their so many REAL
>> COMMUNITY BASED organizations forming to dealing with an very serious
>> issue, that law enforcement has no capabilities to deal with and apparently
>> ARIN (the very governing body of IP addresses) doesn't care to do anything
>> about, even though a very sound and reasonable policy was written, but
>> never adopted, probably due to naysayers like yourself and Paul.
>>
>> Lazy and bad. <-- period!
>>
>> Curious though, you and Paul have attempted to dismissing me quite
>> quickly and out of hand, but if I may, why not implement the policy, what
>> do you think is going to happen? Why would it be bad to hold abuse POCs
>> accountable for what their IP address is doing? What hardship do you think
>> this will cause the community, other than you personally not wanting to be
>> responsible for the IP addresses under your charge?
>>
>> Again, I'm not asking ARIN to police it, I'm asking them to govern it.
>> I'm not asking for people to be sent to jail or fined, I'm asking for the
>> governing body to take action in stopping the behavior (preferable without
>> the need for behemoth, slow, broadsword agencies like law enforcement
>> having to get involved, they have a whole lot of issues they need to fix
>> before they can even approach an issue like this).
>>
>> I've been a POC for more than my fare share of ranges, I don't recall
>> this ever being in issue, and I know I took my responsibility for the IP
>> addresses under my charge very seriously. I would create a ticket, follow
>> up with my end users, and if deemed inappropriate or against our policy,
>> their privileges would be revoked.
>>
>> Telling me that ARIN isn't the police is like telling me the sky is not
>> green. Obviously.
>>
>> However, it is the governing body, for the assignment of IP addresses. If
>> the idea behind the abuse email was NOT to have it used to take down bad
>> actors, then why even have it at all?
>>
>> Why are some organization voluntarily doing what you and Paul find so
>> offensive a policy, and why are you and Paul so much against it, other than
>> a blanket statement the ARIN is not the police (again this obvious).
>> However IT IS the governing body, and does bear responsibility for how the
>> community behaves.
>>
>> Honestly curious,
>> Shawn
>>
>>
>>
>> On Aug 28, 2025, at 5:14 PM, Scott Leibrand <scottleibrand at gmail.com>
>> wrote:
>>
>> Just block them, as Matt suggested. Or sue them, if they're harming your
>> business in some meaningful way that can't be trivially handled by blocking
>> their abusive subnets. Or contact law enforcement if there's actual
>> criminal trespass or some other law being broken.
>>
>> ARIN is not set up to be the Internet police, and I would oppose any
>> efforts to make it try to play that role. As Matt eloquently elucidated,
>> any requirements ARIN could enforce would likely make things worse for
>> everyone holding ARIN IP addresses for very little tangible social benefit.
>>
>> -Scott
>>
>> On Thu, Aug 28, 2025 at 4:57 PM Shawn Bakhtiar <shashaness at gmail.com>
>> wrote:
>>
>>> Thank You Bill!
>>>
>>> I really appreciate the input, and these are all great suggestions. I
>>> will certainly do my homework and reach out again to the group with more
>>> specific questions on the topic.
>>>
>>> As I said  in my email to Alison,
>>>
>>> AWS (of all people), auto responds to any email sent to the abuse email
>>> on record for a given IP segment. It includes a ticket number, and without
>>> me having to follow up (usually a few days later) an email back often
>>> having remediated the issue, or in the rare instances where the they did
>>> not remedy the issue, explaining why the behavior is not abuse or a
>>> violation of their policies.
>>>
>>> Digital Ocean does the same thing (without a ticket number). So do
>>> several midsize providers. Hit and miss with anything smaller than a /24.
>>>
>>> Microsoft (where the preponderance of abusive behaviors come from) and
>>> Google. Do nothing. Literally nothing. I have OSSEC notification logs in
>>> which a single IP address with a Microsoft abuse POC, continues to scan
>>> different customer's networks, looking for Wordpress vulnerabilities, and
>>> has done so for over a month, without any remediation.
>>>
>>> The aforementioned policy is a common sense one already being
>>> (voluntarily) done by a good number of the providers out there. I am very
>>> curious as to what objections anyone could have to it, and how we can
>>> address those concerns so we can put what seems like a very common sense
>>> policy into place. We need to bring accountability back to the internet.
>>>
>>> Again, thank you for the guidance, I look forward to any and all
>>> questions, comments, and or concerns.
>>>
>>> > On Aug 28, 2025, at 3:24 AM, William Herrin <bill at herrin.us> wrote:
>>> >
>>> > On Wed, Aug 27, 2025 at 11:45 AM Shawn Bakhtiar <shashaness at gmail.com>
>>> wrote:
>>> >> I would like to re-introduce the following Policy Proposal from 2003
>>> to hold abuse POCs accountable.
>>> >> https://www.arin.net/vault/participate/policy/drafts/2003/2003_1/
>>> >
>>> >>> Changes to ARIN’s policies may be made via submission of a policy
>>> proposal
>>> >>> via ARIN’s Policy Devcelopment Process - more details available here
>>> >>> - https://www.arin.net/participate/policy/pdp/
>>> >
>>> > Hi Shawn,
>>> >
>>> > I note that the practical question of "how do I submit a policy
>>> > proposal" is not answered in
>>> > https://www.arin.net/participate/policy/pdp/, or if it is, it's buried
>>> > so deeply I can't find it.
>>> >
>>> > What you probably want is the policy proposal template, which you can
>>> > find here: https://www.arin.net/participate/policy/pdp/appendix_b/
>>> >
>>> > You can also discuss policy changes here on the mailing list without
>>> > making a formal proposal. That would enable you to gather information
>>> > which could inform a formal proposal.
>>> >
>>> > I recommend you sift through the mailing list archives at
>>> > https://lists.arin.net/pipermail/arin-ppml/ and read the original
>>> > discussions around proposal 2003-1. This can help you understand what
>>> > defects in that proposal led to it failing to reach consensus.
>>> >
>>> > Finally, I note that there have been other off and on discussions
>>> > about the published POCs and their utility. It might be worth digging
>>> > into them as well. Try a Google search such as, "site:lists.arin.net
>>> > abuse poc"
>>> >
>>> > Regards,
>>> > Bill Herrin
>>> >
>>> >
>>> >
>>> > --
>>> > William Herrin
>>> > bill at herrin.us
>>> > https://bill.herrin.us/
>>>
>>> _______________________________________________
>>> ARIN-PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>>
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250829/2120ff03/attachment-0001.htm>


More information about the ARIN-PPML mailing list