Dear SIG members,
The proposal "prop-125-v001: Validation of "abuse-mailbox" and other IRT emails" has been sent to the Policy SIG for review.
It will be presented at the Open Policy Meeting at APNIC 46 in
Noumea, New Caledonia on Thursday, 13 September 2018.
We invite you to review and comment on the proposal on the mailing list
before the meeting.
The comment period on the mailing list before an APNIC meeting is an
important part of the policy development process. We encourage you to
express your views on the proposal:
- Do you support or oppose this proposal?
- Does this proposal solve a problem you are experiencing? If so,
tell the community about your situation.
- Do you see any disadvantages in this proposal?
- Is there anything in the proposal that is not clear?
- What changes could be made to this proposal to make it more
effective?
Information about this proposal is available at:
http://www.apnic.net/policy/proposals/prop-125
Regards
Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs
https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt
----------------------------------------------------------------------
prop-125-v001: Validation of "abuse-mailbox" and other IRT emails
----------------------------------------------------------------------
Proposer: Jordi Palet Martínez - jordi.palet@theipv6company.com
Aftab Siddiqui - aftab.siddiqui@gmail.com
1. Problem Statement
--------------------
APNIC implemented mandatory IRT references on 8 November 2010. This means it is mandatory to register an Incident Response Team (IRT) object for each resource record in the APNIC Whois Database. The policy mandates IRT references for each inetnum, inet6num and aut-num objects, however in many cases, those contain out-of-date, inaccurate, non-existent or not actively monitored abuse-mailbox information.
In practice, this contact becomes ineffective to report abuses and generally gives rise to security issues and costs for the victims.
This proposal aims to solve the problem and ensure the existence of a proper abuse-mailbox contact and the process for its utilization.
2. Objective of policy change
-----------------------------
The Internet community is based on collaboration. In many cases, however, this is not enough and we all need to be able to contact those LIRs which may be experiencing a problem in their networks and may not be aware of the situation.
This proposal aims to solve this problem by means of a simple, periodic verification of IRT object emails, and establishes the basic rules for performing such verification and thus avoids unnecessary costs to third parties who 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 LIR whose client is causing the abuse (and 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 the courts, thus avoiding costs (lawyers, solicitors, etc.) and saving time for both parties.
3. Situation in other regions
-----------------------------
A similar proposal is being discussed in LACNIC and being prepared for AfriNIC and RIPE NCC.
Currently, ARIN conducts an annual POC (point of contact) validation and RIPE NCC validates the “abuse-mailbox:” attribute annually (ripe-705).
4. Proposed policy solution
---------------------------
1. About the "abuse-mailbox", “email”, “admin-c” and “tech-c”
Emails sent to "abuse-mailbox", “email”, “admin-c” and “tech-c” must require manual intervention by the recipient at some time, and may not be filtered, as in certain cases this might prevent the reception of the abuse reports, for example a case of spam, as it would include the spam message itself or URLs or content usually classified as spam.
The mailboxes may initially send an automatic reply, for example, assigning a ticket number, applying classification procedures, requesting further information, etc. However, it may not require the use of a form, as this would imply that each company that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each case, 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 by the those whose client causes the abuse (and from whom they obtain income).
By way of information, it is worth noting that it is reasonable for the person reporting the abuse to do so from the start and in that first report, sending the logs, or a copy of the spam message (attaching an example of the spam email or its full headers) or similar evidence proving the abuse. Likewise, it is reasonable to expect that the initial auto-reply email will specify that the claim will not be processed unless such evidence has been submitted, thus allowing the sender the opportunity to repeat the submission and include the pertinent evidence. This allows automatic reporting, for example, via fail2ban, SpamCop or others, keeping costs at a minimum for both parties involved.
2. Objectives of "abuse-mailbox", “email”, “admin-c” and “tech-c” validation
The procedure, which is to be developed by APNIC, 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 APNIC and not from third parties (which might involve security risks), avoiding, for example, a single "direct" URL for validation.
2) Avoid automated processing.
3) Confirm that the person performing the validation ensure that understands the procedure and the policy, that they regularly monitor the "abuse-mailbox", “email”, “admin-c” and “tech-c”, that measures are taken, and that the abuse report receives a response.
4) Validation period no longer than fifteen (15) days.
5) If validation fails, escalate to the LIR and set a new validation period not to exceed the fifteen (15) days.
(By way of example, a detailed procedure is included in this policy proposal under "Additional Information")
3. Validation of "abuse-mailbox", “email”, “admin-c” and “tech-c”
APNIC will validate compliance with the items above, both when the "abuse-mailbox", “email”, “admin-c” and/or “tech-c” attributes are created or updated, as well as periodically, not less than once every six months, and whenever APNIC sees fit.
At the discretion of APNIC, in general or in specific cases (for example, for confirmation in cases of escalation under 4., APNIC may use domains other than apnic.*, and even modify the subject and body of the message, in order to perform said validations more effectively.
Lack of compliance will imply a more exhaustive follow-up, in accordance with the relevant APNIC policies, procedures and membership agreement and a temporary lock of myapnic access, until resolved.
4. Escalation to APNIC
To avoid fraudulent behavior (for example, an "abuse-mailbox" that only replies to APNIC’s 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) and, therefore, to guarantee the quality of the services in the region with the resources allocated by APNIC, a mailbox will be available (for example, "escalation-abuse@apnic.net"), to escalate such situations, thus allowing for a re-validation (according to section 3. above) and even the intermediation by APNIC and, where appropriate, the application of the relevant policies/procedures, APNIC policies, procedures and membership agreement.
i) In case there is no response from all the email addresses associated with the IRT object, then mark that IRT object invalid and block access to myapnic and use other means to contact the member (e.g. via billing contact or corporate contact)
ii) if there is no response from some of the email address associated with the IRT object, then mark those attributes invalid and contact the member for the resolution. If the problem is not fixed after fifteen (15) days then block access to myapnic and use other means to contact the member (e.g. via billing contact or corporate contact).
5. Advantages / Disadvantages
-----------------------------
Advantages:
The purpose of creating IRT object in the APNIC whois database is to provide a more accurate and efficient way for abuse reports to reach the correct network contact. Fulfilling the objectives above indicated and ensuring that a real contact can be approached in case of abuse cases and effectively serve the purpose of creating IRT object.
This will improve the quality of the information and help to achieve the goal of handling network abuses.
Disadvantages:
None foreseen.
6. Impact on resource holders
-----------------------------
APNIC members have to verify and update (if required) their IRT objects periodically.
7. References
-------------
ADDITIONAL INFORMATION
a. Since this proposal is implemented, APNIC will publish the IRT also as abuse-c, in order to facilitate the search in whois, for the same information, regardless if looking for abuse-c or IRT. This is done in order to assimilate the IRT to the majority of the RIRs where it is abuse-c.
b. It is recommend that all NIRs implement a similar validation process within their own jurisdictions.
c. Example of the validation procedure.
1) APNIC initiates the validation automatically, sending TWO consecutive emails to each of the mailboxes.
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.apnic.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 each of the mailboxes 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 mailboxes, 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 fifteen days.
8) If the code is not entered within that time, the system will mark the IRT as "temporarily invalid” and will send a reminder with another unique code and alert APNIC staff, so 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 IRT 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 IRT will be marked as "valid"; otherwise it will be considered in breach of the policy.