[arin-ppml] Policy Proposal 2003-1: Required Performance of Abuse Contact
Matthew Petach
mpetach at netflight.com
Fri Aug 29 16:59:12 EDT 2025
On Fri, Aug 29, 2025 at 12:45 PM Shawn Bakhtiar <shashaness at gmail.com>
wrote:
>
>
> On Aug 29, 2025, at 12:02 PM, Michael Greenup <michael.greenup at ionos.com>
> wrote:
>
>
>
>
> 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.
>
>
> I hear you. I appreciate everything you are saying, and more importantly
> doing to keep the internet safe for all of us.
>
> Question:
> You're doing it, AWS IS doing it (following the policy voluntarily),
> Digital Ocean is doing it, I use to do it, and many others are already
> voluntarily following the policy, which means it won't cost us anything, as
> you said we are compliant already.
>
Shawn,
Those of us who have been doing this for the better part of half a century
have lived through automated
"your network is ATTACKING me!!!!" abuse alert emails generated by
overly-excitable "firewall" software
that detects any inbound unrequested packet, looks up the purported source,
and emails the listed
contacts for the netblock. As BCP 38 is not yet universal, most of the
time there's nothing that can
be done about those automated abuse reports. It's a spoofed SYN, it hit
their firewall, they generated
an automated complaint. There's absolutely no action that can be taken on
those reports, and
ultimately, they resulted in the behaviour you see now, of ignoring most
inbound abuse reports.
You claim you are "compliant already" -- compliant with what? Having an
abuse email address that is
read by a human? What is your SLA for responses? What is the penalty if
you fail to meet that SLA?
If I start generating spoofed traffic purporting to be from your IP block
towards 50,000 destinations that
have poorly written software firewalls that generate automated abuse
reports to your abuse@ email
contact, how many can you respond to per hour? How long can you keep doing
that before you
fall out of compliance with your SLA? At what point do you need to start
either hiring more people
to answer all those emails, or do what everyone else does, and start
ignoring the abuse alerts coming
in?
It's easy to "be compliant" when things are going smoothly. When someone
decides they want
to force you out of compliance, it's trivially easy to do so. What teeth
do you really want to have
ARIN to be authorized to use against you when you inevitably fall out of
compliance?
Everybody says "There ought to be a law against that!" right up to the
point when they're
suddenly on the other side, and the realize *why* legislature is hard to
put in place--because
poorly thought out laws can end up doing more harm than good. The devil is
in the details.
Google is not and neither is Microsoft. Why do they get to not? Why do we
> have to deal with the extra burden of them not caring?
>
> This policy would simply level the playing field. That's it, and the only
> ones who would have to do more, are the ones who were not following the
> policy.
>
And how much more would you be requiring companies to do? As another
poster pointed out,
you're asking people to spend money, and change their potential viability
in the marketplace.
Would you still be in favor of this policy if it meant you had to hire
twice as many full time
employees to answer abuse email messages, *even if there was no actual
abuse taking
place*?
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.
>
>
Even if it's not subscription spam, even if it's quasi-legitimate "network
abuse" complaints, all it takes is one poorly
written auto-complaining firewall out there that generates a complaint for
every unwanted inbound packet that hits
their firewall, and your inbound abuse queue will be overwhelmed.
>
> 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.
>
>
> I appreciate your consideration, and I really thank everyone who has
> responded to me on this list. I am beginning to understand the viewpoint,
> even if I am not, as of yet, convinced of the validity of the arguments.
>
>
My older brothers told me over and over again to stay away from the
campfire; the metal grate over the fire would be hot, they said.
So, I waited until they had walked away before I put my hand on the metal
grating to see what they meant.
After screaming my lungs out for several minutes while my older brother
held my hand in a bucket of ice water to stop the burning,
I did tearfully admit that maybe they had a point and I should have really
listened to them.
Every generation needs to learn that you don't touch hot items, and they
all seem to need to learn it the same way,
by disbelieving those who came before who said "we each got burned--why
don't you avoid pain and suffering, and
not touch the hot item?"
It's OK if you need to touch the hot stove to discover why it shouldn't be
done.
Just please don't ask the rest of us to join you in touching the stove;
we've already been there, and have the scars to show for it. ^_^;
Thanks!
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250829/f1f20fe4/attachment-0001.htm>
More information about the ARIN-PPML
mailing list