Proposal

1.0 Summary of the problem being addressed by this proposal

The current policy doesn’t imply the obligation to register an abuse contact and specifies a format for personal communication and for “automatic reporting”, which compared to other RIRs becomes confusing, as a single email will be more efficient, as at the end, reports get copied to both emails.

As a result, some resource-holders may not have this contact information registered and up to date for their resources. In fact, there are even cases of non-existent mailbox or one that is not actively monitored.

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 this problem and ensure the existence of a proper abuse-c contact and the process for its utilization, which is more uniform across all the RIRs, in order to facilitate cross-region abuse reporting. 

Existing policy references to a “Best Practice Paper”, which is not deemed as mandatory and in fact, is not being used by the community. This proposal doesn’t change the scope of that document, and in fact, a link between the few existing IRT objects and the new one, should be automatically established.

At this way, AfriNIC abuse contact will be in line with other RIRs. APNIC is now using the IRT, but since an equivalent proposal has been accepted, an automated “link” (alias) to the pre-existing IRT will be created, so abuse-c and abuse-mailbox prevail.

There is no need to delete the other optional data today included in the IRT. This policy just ensures that the abuse-mailbox is available and verified periodically.

2.0 Summary of how this proposal addresses the problem

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

This proposal creates a new section in the Policy Manual to solve 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 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.

For this, the abuse-c attribute becomes mandatory in the “aut-num”, "inetnum" and "inet6num" objects, as well as in any others that may be used in the future. This attribute is an abuse contact, which must contain at least the "abuse-mailbox" attribute.

The proposal is expected to be implemented in 90 days, to be confirmed by AfriNIC, a reasonable time frame to allow both the staff to develop the tool and the LIRs to update their abuse-c contacts.

3. Proposal 

3.1 Amending 8.0 of the CPM, as follows:

3.2 Additional information:

Since this proposal is implemented, AFRINIC will publish the IRT as an alias to the abuse-c, in order to facilitate the search in whois for the same information, regardless if looking for abuse-c or IRT. The rest of the actual information in the IRT, can be kept as per the actual guidelines (which will need to be updated AFRINIC). This is done in order to assimilate the IRT to the majority of the RIRs where it is abuse-c. 

Example of the validation procedure. 

1. AFRINIC initiates the validation automatically, sending TWO consecutive emails to the "abuse-mailbox". 

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

3. At the discretion of AFRINIC, in general or in specific cases (for example, for confirmation in cases of escalation under 8.6), AFRINIC may use domains other than afrinic.*, and even modify the subject and body of the message, in order to perform said validations more effectively.

4. The first email will contain the URL where the validation is to be performed ("validacion.afrinic.net") and may contain information about the procedure, a brief summary of this policy, etc.

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

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

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

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

9. If the code is not entered within that time, the system will mark the "abuse-c" as "temporarily invalid” and will alert AFRINIC staff so that they can initiate a personalized follow-up with the resource-holder.

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

11. AFRINIC must ensure that all possible means of “warning” the resource-holder are put in place, such as periodic emails to other email boxes, alert pop-ups, etc. All those must contain the policy text and reminders about consequences in case of continued policy violation. Means of blocking access to certain services should be also considered.

12. The validation process will be repeated automatically (items 1 to 8 above). If satisfactory, the "abuse-c" will be marked as "valid"; otherwise it will be considered in breach of the policy. 

13. There must be tools such as a form, mailbox (for example, a mailbox such as "abuse-escalation@afrinic.net"), or others in the future, to escalate lack of compliance with this policy and even the intermediation by AFRINIC and, where appropriate, the application of the relevant policies/procedures, especially those related to revocation of resources.

References

An equivalent proposal has been accepted in APNIC and is under discussion in the ARIN, LACNIC and RIPE regions.

Staff Assessment

PDF Version

1.0 Staff Understanding of the Proposal

1. Replacement policy text to current CPM 8.0 (Abuse Contact Information) - [sec 8.1]
2. Introduces a mandatory "abuse-c" attribute in inetnum, inet6num and aut-num whois database objects. The value of this attribute is an e-mail address (abuse-mailbox), to which all abuse related information shall be sent. The abuse-mailbox is optional in child objects of parent direct allocations or assignments issued by AFRINIC - [sec 8.2]
3. The abuse-mailbox must be valid and actively monitored through period verification - [sec 8.2]
4. Email sent to the abuse-mailbox must need manual intervention by the recipient at some point- [sec 8.3]
5. AFRINIC must provision a system to validate the abuse-mailbox. The actual process is left to AFRINIC staff discretion, but could follow an example procedure in sec 3.2 of the policy proposal, with a recommended minimum validation interval of at least once every 6 months - [sec 8.4]
6. Abuse-c mailboxes that fail validation tests will lead to eventual blocking of certain services, at AFRINIC discretion (and in accordance with the relevant policies/procedures) - [sec 8.5]
7. An escalation mechanism to AFRINIC must be provided where any concerns with the validation process can be reported by community and/or members. This can also help with manual re-validations. - [sec 8.6]

2.0 Staff Comments

1. There is already an existing solution through the IRT object, which is currently optional - (and which seems to address the intent of the proposal) - which can be made mandatory for directly issued resource objects by AFRINIC. An added advantage of using the IRT is that it can hold more information than just an e-mail address, such as physical address, phone numbers and PGP keys for secure communication. 
2. During the AFRINIC30 Public Policy Meeting, the author clarified that the IRT can be an 'alias' of the abuse-c. We note however that it is confusing to use IRT as an alias to the abuse-c and the other way round -  we would not know how to implement such a requirement unless the author guides with detailed specifications through the policy proposal or through the (DBWG) database working group.
3. In proposed 8.5 where abuse-c mailboxes that fail validation tests will lead to eventual blocking of certain services, at AFRINIC discretion (and in accordance with the relevant policies/procedures). The policy proposal needs to be clear on what specific services shall be blocked. However, it's important to note that without this clause in the first place, a breach of the policy (such as lack of valid abuse-c if this proposal were to pass) amounts a breach of the RSA, which can lead to eventual revocation of the same RSA and associated services.

3.0 Legal Observations 

None

• Implementation:
• Timeline & Impact: About 6 months of software development work.
• Implementation Requirements: Modifications to WHOIS codebase depending on the solution that will eventually be ratified.

Revision History

Revision History