[arin-ppml] Draft Policy ARIN-2021-7: Make Abuse Contact Useful

Wed Oct 27 17:07:33 EDT 2021

To make it short and focus a bit …

I agree that whatever we do there should be a transition path
I agree that if there is a better IETF standard way than email, even using forms (if they can be automated) is good
However, right now 2 above doesn’t exist and instead if we keep using email but making a policy that enforces a transition to X-ARF/RFC5965/RFC6650, resolves the problems for spam into abuse mailboxes (because it is automatically processed and the spams get rejected by the system), facilitates the transition (a period of time where plain emails and X-ARF/RFC5965/RFC6650 are accepted, then only X-ARF/RFC5965/RFC6650).
In parallel we can look for the proper/better way to standardize something equivalent that doesn’t require email, but we know that this is a slow path.

If anyone else is willing to work on that, via paralell work in RIR proposals for enforcing the usage of X-ARF/RFC5965/RFC6650 and work in IETF for a future way that probably can re-use X-ARF/RFC5965/RFC6650 but not based in email, that will be very useful and probably easier than a single person work. We should notice that this is not a few months effort …

I guess m3aawg will be also interested in that effort.

Regards,

Jordi

@jordipalet

El 27/10/21 21:47, "Owen DeLong" <owen at delong.com> escribió:

On Oct 27, 2021, at 01:12 , JORDI PALET MARTINEZ via ARIN-PPML <arin-ppml at arin.net> wrote:

Hi Owen, all,

Responding in-line as [Jordi]

I will once again urge you to get an MUA that works correctly.

On Oct 26, 2021, at 15:17 , JORDI PALET MARTINEZ via ARIN-PPML <arin-ppml at arin.net> wrote:

Hi,

Unless I misunderstood this proposal, I believe this is the wrong way to go.

Is this proposal suggesting that the abuse email must not be used anymore and instead a URL for abuse reports enforced?

You are making the same mistake as the previous poster. You are assuming that a URL is a website locator. It is not. It can be an email, a website,

a phone number, a file download, or any of a number of other resource types.

[Jordi] What I’m saying is that IT MUST BE an email. It is impossible if *every* resource holder can decide a different way, it is impossible to automate the reporting systems. Also changing from the actual system to a “mailto” URL means that the existing apps need to be modified, as those are, in many cases, taking the abuse-mailbox field “as is”.

Sorry, but no. The world has moved on from email only and it’s time for abuse reporting policies to recognize and adapt to that fact.

Providers should not be forced to accept the negative aspects of email abuse reporting if they don’t want to. Allowing providers to have a more flexible way to specify how they want to receive abuse reports is the necessary first step towards more effective abuse handling IMHO.

As I read the proposal, the effect would be that administrators receive additional flexibility in how they want to receive abuse reports by being able to

express that desire in terms of a URL.

[Jordi] If we want additional flexibility and not impact on existing systems/apps, we should a) keep the existing abuse-mailbox as mandatory (just a plain email) and b) ADD other fields (as optional), or a single “multifunctional URL field”, etc.

I disagree… There should be a migration period, but there must be a date certain when providers are allowed to discontinue support for email-based abuse reporting and all the problems it causes.

If we force them to maintain the existing system, there’s no motivation for innovation or advancement as it is simply an increased cost. The goal here is to allow for better systems to be developed and one of the best incentives for that is an ability to reduce the costs imposed by trying to handle email at scale. The simple reality is that most abuse email contacts for organizations of any scale are effectively nonexistent because they simply get queued indefinitely unless the email is on one of the whitelists that allows validations to be passed.

If you are currently using an abuse POC of abuse at example.com then you would be able to switch to mailto:abuse at example.com and continue as before.

Arguably, staff should automatically convert all ABUSE POC records accordingly as part of the implementation process…

Possible process (just spitballing here as this is operational and not part of the policy):

[Jordi] Yes agree this is a very easy to implement thing for the staff, but who will pay for the job of changing existing apps in THE REST OF THE WORLD? Changes in this affect every possible abuse reporter that has automated it, not just resource holders in a given region. This is totally against what the other 4 RIRs have been doing for many years. Yes, it can be done, differently in every RIR, but it is going against the rest of the worldwide community.

Guess what… The abuse reporters have been externalizing this cost to the report recipients for decades… now it’s their turn to pay.

                T+0         Policy is ratified by BoT

                T+120 days ARIN Staff has the software and training changes ready to go and the final schedule and process are documented and distributed

                                arin-announce, nanog, other usual suspects…

                T+120 days ARIN begins accepting ABUSE-URLs as an additional field in WHOIS ORG and RESOURCE records.

                T+150 days ARIN Sends out warning that ABUSE-C will be removed from WHOIS at T+180 days

                T+165 days ARIN sends out second warning

                T+175 days ARIN sends out third warning

                T+178 days ARIN sends out fourth warning

                T+179 days ARIN sends out final warning

                T+180 days, ARIN converts all ABUSE-C items in records that lack an ABUSE-URL entry to ABUSE-URL: mailto:<former abuse-c content>

                                ARIN then removes all remaining ABUSE-C fields from WHOIS

If you look at all the other 4 RIRs, this is totally contrary to the practical experience.

Only if you stick to your above erroneous assumption that an email address expressed in URL form is somehow less valid than an email address in an ABUSE-C field.

If you enforce abuse to use a form, because each ISP can implement a totally different form format, this disallows automating the abuse reporting process, which is the only way it can be actually useful.

This depends on your definition of useful. From a reporter perspective, perhaps automating the abuse reporting process to minimize the effort required to report abuse is most useful.

[Jordi] Yes, but you’re missing the point on who must pay for the cost of abuse cases. Who is getting the profit from a customer? If you’re an ISP or university, and from your network you’re abusing my customers/my network, why I should bear the cost of reporting beyond a very simple and inexpensive way (that already exist in both open source and commercial systems)? Exactly the same in the other way around. If my customer is abusing your network/your customers,  why you should pay for the cost of reporting the abuse beyond automated systems that already exists? Why any of us should invest in human filling or automatically filling the forms that *are* different for every resource holder in the world?

Let’s look at it from the other side… I’ve been on the receiving side of abuse mailboxes… It tends to be about 80% spam, 15% complaints about non-abuse just because the person reporting doesn’t understand what abuse actually is, and 5% or less legitimate complaints of which about 5% (0.25% overall) is actually actionable because most reports received via email are deficient in some way and of those, the vast majority use from addresses that cannot be (effectively) replied for various reasons (fake address, postmaster@ which is rerouted to /dev/null, etc.).

Email is a terrible way to receive abuse complaints and it’s allowed whiners^wabuse complaint publishers to externalize cost to the point of being effectively a denial of service attack on some businesses.

If you’re so determined that automated support needs to exist for all these email reporters, feel free to implement an email->new form gateway that will take peoples emailed reports and sort it out on their behalf.

>From a dealing with the abuse and solving the problem perspective, however, there is some amount of value in having a standardized format for receiving the reports and an ability to insist upon collecting the data needed to actually act on the report.

Allowing resource holders to choose how they wish to receive abuse reports, therefore, may have some utility.

The problem is not that the abuse mailbox is not useful because it can get spam or something else, the problem is when it is not correctly processed, updated with the right contact, etc., so it must be periodically validated to become useful.

There are multiple problems. Spam and other useless email flooding an abuse mailbox is, in fact, a real problem, so you can’t say that the problem is not that. You may say that’s not the problem that bothers you the most, but that’s a different statement entirely.

There are also situations where incorrect processing is a problem. In many of those cases, it may well be because the needed information is not provided in the emailed report and many such emailed reports do not provide a functional way to request the additional information. There are, of course, other causes for this issue as well.

Certainly stale data in WHOIS is a chronic problem and validation helps, but I don’t see URL validation as being significantly worse than email validation.

Alternatively, reporting could be done using via email and standard formats such as X-ARF/RFC5965/RFC6650.

That wouldn’t hurt, but even with standardized email formats, there are going to be bad implementations, errors, etc. that result in non-actionable reports.

[Jordi] The we should improve it, but X-ARF and so on, allow using simple email for reporting any kind of abuse. There are already open source and commercial tools that handle it. It is just a matter of a) policy in each RIR to mandate it, b) parallel work (if needed) in IETF to make it better.

But there’s no way for the recipient of the abuse complaints to enforce any of those formats on the reporter. If I take the abuse complaint via a web form or some other interactive or API mechanism, then I have a guaranteed way to provide feedback to the submitter telling them:

                1)            Their abuse report was rejected

                2)            Why it was rejected

                3)            How to fix it and get it accepted

With email, to the extent that exists (which is very limited), it isn’t at all reliable and there’s absolutely nothing to say it’s at all likely to reach the original abuse report submitter.

APNIC and LACNIC have already implemented my abuse-c policy proposal that enforces the validation of the abuse-mailbox, and the results are awesome.

I’ve heard mixed reviews, but glad you’re happy.

[Jordi] The info that I’ve (top of my head, not precise data) is that the validation in APNIC for 90% of the abuse contacts took about 18 months, while in LACNIC only took 6 months for 85%. I’ve already noticed, reporting (mainly automatically) about 1.000-1.500 cases per day, that the number of bounces from those two regions decreased very quickly. As a consequence, the RIRs are also getting less reports themselves because now the reports are reaching the actual resource holder. I call it a success.

That’s not a measure of how well it’s working, just a measure of how well validation went.

How many of those 1,000-1,500 abuse cases per day that are being reported are actually getting acted upon in a meaningful or useful way?

What I’ve heard is probably on the order of 20-50, if that. Admittedly, also top of my head, not precise data.

However, actual action on useful reports is the true metric of effectiveness. The numbers you’ve quoted measure nothing useful.

It reached consensus also in AFRINIC but there is a pending appeal.

It seems anything that happens in AFRINIC these days gets appealed. I wonder if the appeal committee will ever stop churning long enough to actually review any of the appeals that have been stacking up.

[Jordi] Following the PDP, this appeal has already failed (because there are several procedural mistakes in the appeal itself – some missing steps according to the PDP that invalidate it), so the policy should be implemented (it will take anyway 3-6 months probably), but we need to wait for the AC to say that.

This assumes the AC ever starts actually functioning again and that it continues to function without the board resetting it again long enough to actually say anything.

Of course, now that the board has chosen to ensure that the appeal committee can’t possibly be independent or fair and is just an extension of the board, I’m not sure what the point is, just let the board ratify or not as the appeal committee has been rejiggered to ensure that they will do whatever the board wants anyway. The level of corruption and disdain for the community and the multistakeholder process displayed by the current AFRINIC board is truly outrageous. Hopefully the next election will see a great deal of new blood seated.

[Jordi] While I don’t agree in many things with the board, and I expressed it publicly, regardless of what AC is there, the PDP has not been followed in order to make the appeal valid (and the time to re-appeal has passed). Anyway, this is a different discussion.

Following the PDP and/or the bylaws or CPM would be a novel approach for AFRINIC these days. As such, I have little hope in any form of predictable process, though I suspect the result is highly predictable, and in favor of a vocal minority segment of the community that seems to have taken effective control of the AFRINIC board and thus since the board appears to feel unconstrained by process, policy, or even the bylaws or the companies act, by extension, AFRINIC itself.

In the case of RIPE NCC, there is already a validation policy in place. I tried to improve it, but didn’t reached consensus (yet).

Certainly all of the abuse problems in Europe have been completely solved by this, right?

[Jordi] Not all, however, it is clear that we have less than before and that’s why I think the policy should be improved, and I will keep working on that. Most of my abuse cases was coming at some point from France, Brasil, China and US. Not in any specific order. However now I get less and less from France, Brasil and China, and more and more from US (which often is never resolved, so we need to block US IP ranges and more and more people is doing that). This proposal will not improve that, in the other way around!

If there is less abuse than before coming out of Europe, it is not to a measurable degree from my perspective.

We can agree to disagree. This proposal, by enabling providers to force interaction even if it is API interaction, can allow them to ensure that the abuse reports they accept are actionable and contain the necessary information to be properly processed and allow them to implement automated mechanisms to reduce the potential for artificial reports as a DOS attack on their abuse reporting system. By doing so, it will enable them to automate the process of providing only the useful and valid reports to humans for action and, thus, improve

the ability to act on abuse reports in a meaningful way.

Merely proving that a huge volume of abuse reports can be dumped into a mailbox is hardly a measure of actual success here, contrary to what you express above.

Owen

IPv4 is over
Are you ready for the new Internet ?

It’s not new any more… I’ve been on the IPv6 internet for decades.

Tragically, I’m still tethered to the IPv4 internet as well by those who have failed to move forward.

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Dude… You posted it to a mailing list. It’s public information and you’ve inherently authorized wide disclosure by posting it to a public list.

Your legal disclaimer is meaningless and won’t hold up in any rational court under the circumstances.

It’s one thing when peons at $RANDOM_COMPANY have these ridiculous signatures, but I know you own your own company, so this act of legal self-gratification is entirely your decision.

Owen

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20211027/ef639e03/attachment.htm>