[arin-ppml] Revised/Retitled - Draft Policy ARIN-2019-5: Validation of POCs Referenced as Abuse Contacts

Tue Jul 16 17:58:31 EDT 2019

> On Jul 16, 2019, at 6:05 PM, JORDI PALET MARTINEZ via ARIN-PPML <arin-ppml at arin.net> wrote:
> 
> Hi Scott,
>  
> I guess there is some misunderstanding in that part of the text. May be “ultimately” is not doing the intended “work”. The idea is “last resort”.
>  
> The idea is not that messages are processed only by humans. If it can be automatically processed that’s fine and perfect. The goal is that if “that doesn’t work” then somebody need to take care of it.

A lot of mail sent to an abuse alias is just spam, or other sorts of mail that's entirely unrelated to the abuse desk or the network it's in charge of.

Automation for that mail stream isn't like automation for, say, ARF reports or DMCA boilerplates - it cannot reliably distinguish between that spam and some sorts of legitimate email.

So if the message "Hey, is anyone reading this abuse alias?" is sent to an abuse alias I'm not sure it could be reliably separated out from the flow of spam by typical automation.

If that email absolutely must be processed by humans, then so must a large fraction of the flow of spam sent directly to the abuse desk. What's the intent here for that sort of case?

Cheers,
  Steve

>  
> See 3.6.6.3:
> 2. Avoids exclusively automated processing.
>  
>  
> Regards,
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
>  
> El 16/7/19 18:39, "ARIN-PPML en nombre de Scott Leibrand" <arin-ppml-bounces at arin.net en nombre de scottleibrand at gmail.com> escribió:
>  
> Strongly opposed as written.
>  
> This policy would require that all "abuse reports receive a response" from "a human processor who evaluates each message received", which constitutes an inappropriate interference in the business operations of ISPs, and presents a denial of service vector.  There are many entirely appropriate automated actions that well-run ISPs take in response to abuse reports that don't involve "a human processor who evaluates each message received", and don't necessarily require a response to the original reporter.  The first project I undertook at my first job was writing a mostly-automated abuse processing system that properly dealt with all incoming abuse@ email, but would not be compliant with this policy language as written because it took fully automated action when appropriate.
>  
> If you want to impose such onerous requirements on ISPs, the appropriate method to do so is via legislation (as was done for the DMCA), not by ARIN number resource administration policy.
>  
> -Scott
>  
> On Tue, Jul 16, 2019 at 8:29 AM ARIN <info at arin.net> wrote:
>> The following has been revised and retitled:
>> 
>> * Draft Policy ARIN-2019-5: Validation of POCs Referenced as Abuse Contacts
>> 
>> Formerly:
>> 
>> * Draft Policy ARIN-2019-5: Validation of Abuse-mailbox
>> 
>> Revised text is below and can be found at:
>> https://www.arin.net/participate/policy/drafts/2019_5/
>> 
>> You are encouraged to discuss all Draft Policies on PPML. The AC will 
>> evaluate the discussion in order to assess the conformance of this draft 
>> policy with ARIN's Principles of Internet number resource policy as 
>> stated in the Policy Development Process (PDP). Specifically, these 
>> principles are:
>> 
>> * Enabling Fair and Impartial Number Resource Administration
>> * Technically Sound
>> * Supported by the Community
>> 
>> The PDP can be found at:
>> https://www.arin.net/participate/policy/pdp/
>> 
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/participate/policy/drafts/
>> 
>> Regards,
>> 
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> 
>> Draft Policy ARIN-2019-5: Validation of POCs Referenced as Abuse Contacts
>> 
>> Problem Statement:
>> 
>> The current policy, “3.6. Annual Validation of ARIN’s Public Whois Point 
>> of Contact Data” does not provide sufficient validation of the actual 
>> availablility of the abuse mailbox.
>> 
>> As a result, some resource-holders (LIRs and end-users) might not keep 
>> this contact information up to date, or might use a non-responsive 
>> mailbox which may be full or not actively monitored. Some may even 
>> respond only to ARIN emails.
>> 
>> In practice, this contact becomes ineffective for reporting abuse and 
>> generally gives rise to security issues and costs for the victims.
>> 
>> Furthermore, POCs are verified only every year and provide a very 
>> relaxed response time (60 days).
>> 
>> Finally, the proposal seeks to standardize the abuse-c/abuse-mailbox as 
>> a pointer to an actual abuse POC in order to facilitate development of 
>> tools that can work across regions.
>> 
>> Proposed Policy Statement:
>> 
>> Add to section 3.6 of the NRPM as follows:
>> 
>> 3.6.6 Policies specific to Abuse Contacts
>> 
>> 3.6.6.1 Abuse Contact Information
>> 
>> The Abuse Contact will reference a POC object holding Abuse contact 
>> information. Each org must have an Abuse Contact. Optionally, resource 
>> records may point directly to an Abuse Contact as an override to the 
>> corresponding organizational Abuse Contact specific to that resource.
>> 
>> 3.6.6.2 Email Addresses in POCs used as Abuse Contacts
>> 
>> Emails sent to this address must ultimately reach a human processor who 
>> evaluates each message received.
>> 
>> Messages cannot be automatically filtered because legitimate abuse 
>> reports may include contents which would trigger such filters.
>> 
>> Reports to this mailbox may undergo initial automatic processing for the 
>> following purposes:
>> 
>> * An automated reply assigning a ticket number, applying classification 
>> procedures, etc.
>> * An indication of the required information for an abuse report to be 
>> processed, such as pertinent logs, copy of the spam message with full 
>> headers, or any other relevant evidence of abuse.
>> * The intent is to facilitate automated abuse reporting in consistent 
>> formats lowering cost for both victims and those processing legitimate 
>> abuse reports.
>> 
>> 3.6.6.3 Abuse Contact Validation Objectives Staff must develop a 
>> validation procedure which accomplishes all of the following objectives:
>> 
>> 1. A simple process which allows POCs to validate that the validation 
>> request is actually from ARIN.
>> 2. Avoids exclusively automated processing.
>> 3. Confirms that the person performing the validation understands the 
>> procedure and relevant policies. That the mailbox is regularly monitored 
>> and that abuse reports receive a response.
>> 4. Maximum validation period is 15 days.
>> 5. If validation fails, escalate to the LIR for an additional 15 days.
>> 
>> The initial and escalation validation periods may be modified by ARIN 
>> staff, if deemed appropriate. In such a case, the community shall be 
>> notified at least 5 days prior to implementation of the change (at least 
>> via arin-announce and arin-ppml) including the rationale for the change.
>> 
>> 3.6.6.4 Validation of Abuse Contacts
>> 
>> ARIN will validate that the email listed in each POC referenced as an 
>> abuse contact for one or more ORG or Resource records under any of the 
>> following circumstances:
>> 
>> * When the POC record is created or first referenced as an Abuse POC.
>> * When a referenced POC record is updated.
>> * No less than every 6 months
>> * At any other time ARIN staff deems necessary
>> 
>> 3.6.6.5 Escalation to ARIN
>> 
>> To avoid fraudulent behavior (for example an email address that responds 
>> only to ARIN emails or emails with a specific subject or content), or 
>> failure to comply with other aspects of this policy, ARIN designates to 
>> receive reports and to escalate any such situations. This will allow for 
>> re-validation (per section 3.6.6.4) and even intervention by ARIN and, 
>> where appropriate the application of the relevant policies, procedures, 
>> or contractual requirements.
>> _______________________________________________
>> 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. 
> 
> **********************************************
> 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.
> 
> _______________________________________________
> 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.