Draft Policy ARIN-2019-5: Validation of POCs Referenced as Abuse Contacts [Archived]

Status : Abandoned

Advisory Council Shepherds : Owen DeLong, Amy Potter

Join the Public Policy Mailing List

History:

• Origin - ARIN-prop-264
• Draft Policy - 26 March 2019
• Abandoned - 20 August 2019

Revisions:

• 16 July 2019

ARIN Advisory Council Meetings:

• 21 March 2019
• 10 April 2019
• 16 May 2019
• 20 June 2019
• 18 July 2019
• 15 August 2019

Presented at:

• Not yet presented

Latest Version: 16 July 2019

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. If validation fails, escalate to the LIR for an additional 15 days.

5. 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.

##########

Earlier Version

##########

Version Date: 26 March 2019

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 availability 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 could be full or not actively monitored, or even responding only to ARIN emails.

In practice, this contact becomes ineffective to report abuse and generally gives rise to security issues and costs for the victims.

Furthermore, POCs are verified only every year and provides a too much relaxed response time (60 days).

Finally, the proposal is aiming to have a standard abuse-c/abuse-mailbox as a pointer to the actual abuse POC, in order to facilitate tools across regions.

This proposal aims to solve those issues and ensure the existence of a proper abuse-c POC and the process for its utilisation.

a. Arguments Supporting the Proposal

The Internet community is based on collaboration. However, in many cases this is not enough and we need to be able to contact those resource-holders (LIRs or end-users) that may be experiencing a problem in their networks and are unaware of the situation.

This proposal solves this problem by means of a simple, periodic verification, and establishes the basic rules for performing such verification and thus avoids unnecessary costs to third parties that need to contact the persons responsible for solving the abuses of a specific network.

The proposal guarantees that the cost of processing the abuse falls on the resource-holder causing the abuse (or its customers, from whom they receive financial compensation for the service), instead of falling on the victim, as would be the case if they had to resort to a legal claim in an extreme case, thus avoiding costs (investigation and in the worst-case lawyers, solicitors, etc.) and saving time for both parties.

Having an equivalent policy in different regions, has the advantage of improving overall response to abuse cases, reduces the cost for handling them, and facilitates the work for all the people involved in the operation of Internet.

b. Arguments Opposing the Proposal

ARIN members have to verify and update (if required) their abuse-c objects periodically.

Policy Statement:

Proposed

1.0 Abuse Contact Information

The “abuse-c:” will reference a role object holding abuse contact information. The positioning of the “abuse-c:” attributes will make use of the hierarchical nature of the resource data to minimize the workload on resource holders. Internet number resources need to have an “abuse-c:” attribute. The “abuse-c:” will be mandatory for all aut-nums. Due the hierarchical nature of IP address objects, at least every direct allocated inetnum and inet6num needs to have an “abuse-c:”. Inherited objects might have their own “abuse-c:” attribute or they will be covered by the higher-level objects. The role objects used for abuse contact information will be required to contain a single “abuse-mailbox:” attribute which is intended for receiving automatic and manual reports about abusive behavior originating in the resource holders’ networks. The “abuse-mailbox:” attribute must be available in an unrestricted way via whois, APIs and future techniques. ARIN will validate the “abuse-mailbox:” attribute at least every six months, as per the procedure stated in this policy. Where the attribute is deemed incorrect, it will follow up in compliance with relevant ARIN policies and procedures. As per current practice, other “e-mail:” attributes can be included for any other purposes.

2.0 About the “abuse-mailbox”

Emails sent to “abuse-mailbox” must require manual intervention by the recipient at some point, and may not be filtered, because in certain cases this might prevent receiving abuse reports, for example in a spam case where the abuse report could include the spam message itself or URLs or content usually classified as spam. The “abuse-mailbox” may initially send an automatic reply, for example assigning a ticket number, applying classification procedures, requesting further information, etc. However, it should not require that the abuse reporter fills a form, as this will imply that each entity that needs to report abuse cases (a task that is typically automated), would be forced to develop a specific interface for each resource-holder in the world that mandates filling forms, which is neither feasible nor logical, as it would place the cost of processing the abuse on those who submit the claim and are therefore victims of the abuse, instead of being paid for by those whose clients cause the abuse (and from whom they obtain income). By way of information, it is worth noting that it is reasonable to expect that the abuse reporting procedure sends, with the initial abuse report, the logs, a copy of the spam message (attaching an example of the spam email or its full headers), or equivalent evidence (depending on the abuse type). Likewise, it is reasonable to expect that the initial auto-reply email could specify that the claim will not be processed unless such evidence has been submitted, thus allowing the sender an opportunity to repeat the submission and include relevant evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or others, keeping costs at a minimum for both parties involved.

3.0 Objectives of “abuse-mailbox” validation

The procedure, which will be developed by the ARIN, must meet the following objectives: 1. A simple process that guarantees its functionality and allows the helpdesks that deal with abuse reports to verify that validation requests actually come from the ARIN and not from third parties (which might involve security risks), avoiding, for example, a single “direct” URL for validation. 2. Avoid exclusively automated processing. 3. Confirm that the person performing the validation understands the procedure and the policy, that they regularly monitor the “abuse-mailbox”, that measures are taken, and that the abuse report receives a response. 4. Validation period of no longer than 15 days. 5. If validation fails, escalate to the LIR and set a new validation period not to exceed 15 days. The “initial” and “escalation” validation periods may be modified by the ARIN, if deemed appropriate, informing the community about the motivation. For example, it could be longer for the first validation, once this policy is implemented, and shortened afterwards once the percentage of failures decreases, so the quality of the contacts increases and consequently a decrease in the average abuse response times could be expected. (By way of example, a detailed procedure is included in this policy proposal under “Comments/Example of the validation procedure”) 4.0 Validation of “abuse-mailbox”

ARIN will validate compliance with the items above, both when the “abuse-c:” and/or “abuse-mailbox:” attributes are created or updated, as well as periodically, not less than once every six months, and whenever ARIN sees fit. At the discretion of ARIN, in general or in specific cases (for example, for confirmation in cases of escalation under 5.), ARIN may use domains other than arin., and even modify the subject and body of the message, in order to perform said validations more effectively. Lack of compliance will initially lead to the blocking of that account’s access to the invalid resources at ARIN Online, except for the abuse-c/abuse-mailbox update and payments. The account blocking will be released upon re-validation of the abuse-c/ abuse-mailbox, triggered automatically by the update of the abuse-c/abuse-mailbox. During the blocking of that account to the invalid resources, each time is accessed, will show a warning message including this policy text, and to continue it will be necessary to confirm by means of a check-box, that the message has been read in full. ARIN will do a more exhaustive follow-up, in accordance with the relevant ARIN policies, procedures or contractual requirements. The frequency of the periodic validation could be modified if ARIN deems this appropriate and informs the community of its reasons. For example, a single validation could be done in the first year, to facilitate adherence to the policy, and then the number of annual validations could progressively increase, reaching even quarterly ones, with the aim of improving the quality of the contacts.

5.0 Escalation to ARIN

To avoid fraudulent behavior (for example, an “abuse-mailbox” that only replies to ARIN emails or to messages with a specific subject or content), or failure to comply with the remaining aspects of this policy (incorrect or lack of response to cases of abuse), a mailbox will be available (for example, “escalation-abuse@arin.net”), to escalate such situations. This would allow for a re-validation (according to section 4. above) and even intervention by ARIN and, where appropriate, the application of the relevant policies, procedures or contractual requirements.

Comments:

Timetable for implementation: Immediate

Anything Else

Situation in other regions:

A similar proposal has been accepted in APNIC (being implemented) and is under discussion in the LACNIC and AFRINIC regions. It has also been submitted to RIPE (still not published).

Example of the validation procedure.

1. ARIN initiates the validation automatically, sending TWO consecutive emails to the “abuse-mailbox”.

2. These emails will be sent containing plain text only.

3. The first email will contain the URL where the validation is to be performed (“validation.arin.net”) and may contain information about the procedure, a brief summary of this policy, etc.

4. The second email will contain a unique alphanumeric validation code.

5. The person in charge of the “abuse-mailbox” must go to the URL and paste the code received in the second email in the form.

6. This URL must be designed in such a way that it prevents the use of an automated process (for example, “captcha”). In addition, it must contain a text that confirms that the person performing the validation understands the procedure and the policy, that they regularly monitor the “abuse-mailbox”, that measures are taken to solve reported cases of abuse, and that the abuse report receives a response, with a “checkbox” that must be accepted in order to proceed.

7. The alphanumeric code will only be valid for a maximum of 15 working days.

8. If the code is not entered within that time, the system will mark the “abuse-c” as “temporarily invalid” and will alert ARIN staff so that they can initiate a personalized follow-up with the LIR.

9. If no reply is received confirming that the situation has been corrected, after an additional period of three business days, the “abuse-c” will be permanently marked as “invalid”.

10. Once the issue has been resolved, the validation process will be repeated automatically (items 1 to 7 above). If satisfactory, the “abuse-c” will be marked as “valid”; otherwise it will be considered in breach of the policy.