Abuse Contact Policy Update (Draft 8) Archived

1. 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 is also contradictory with RSA, that states that information in databases must be accurate. This policy ensures that this can be automatically and periodically verified by AFRINIC, without entering in the operational details of how doing it. In fact there is an AFRINIC activity (https://afrinic.net/stats/contact-update) that aims for the verification of the contacts, however it has only reported for 2017.

Again, this proposal, ensures that this activity is done in an automated fashion (as much as possible), saving cost to the membership and the community.

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, for example, is now using the IRT, but since an equivalent proposal has been accepted, an automated “link” (alias or pointer) 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, it is an operational AFRINIC decision how to handle the transition. This policy just ensures that abuse-c and abuse-mailbox are available and verified periodically.

2. 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 members to update their abuse-c contacts.

3. Proposal

3.1 Amending 8.0 of the CPM, as follows:

Current	Proposed
8.1 Introduction This policy specifies a dedicated object that shall be used as the preferred place to publish abuse public contact information within the AFRINIC service region. The mentioned object can be referenced in the inetnum, inet6num and aut-num objects in the AFRINIC whois database. It provides a more accurate and efficient way for abuse reports to reach the correct network contact	8.1 Introduction This policy specifies a mandatory attribute (abuse-c) that must be used to publish abuse public contact information within the AFRINIC service region. The mentioned attribute must be referenced in the inetnum, inet6num and aut-num objects in the AFRINIC whois Database. It provides a more accurate and efficient way for abuse reports to reach the correct contact.
8.2 Policy details: To make available a new or use an already existing whois database object that implements the following properties: 1. A unique reference by inetnum, inet6num and aut-num 1. Contains 2 email attributes: 1. 1. "e-mail:" for personal communication 1. "abuse-mailbox:" for automatic report handling The object should be accessible through the whois protocol. AFRINIC to publish a Best Practice Paper that encourages all members actively to use the object for publishing abuse contact information.	8.2 Description of “abuse-c” and “abuse-mailbox” Resources allocated/assigned by AFRINIC must include a mandatory "abuse-c" contact attribute (abuse contact), pointing to a person or role, with at least one valid, monitored and actively managed email inbox (abuse-mailbox) intended for receiving reports regarding abusive behavior, security issues, and the like. The "abuse-mailbox" attribute must be available in an unrestricted way via whois, APIs and future techniques. Considering the hierarchical nature of IP address objects, child objects of those directly distributed by AFRINIC may be covered by parent objects or they may have their own "abuse-c" attribute. Following usual practices, other "e-mail" attributes may be included for other purposes.
8.3 Advantages and disadvantages of the policy 8.3.1 Advantages 1. Networks will be able to supply their own, direct contact information for abuse departments. 1. Abuse complaints will not be sent to the "wrong" contact anymore. 1. This permits greater administrative and operational flexibility, and faster abuse handling will be possible. 8.3.2 Disadvantages This object, like all other existing objects, will face the data accuracy problem. This policy aims to address the issue of a missing place for abuse contact information and will not improve data accuracy in the whois database. Nevertheless, it is suggested to AFRINIC to offer a way to receive reports about not working or not accurate objects.	8.3 About the "abuse-mailbox" Emails sent to "abuse-mailbox": * Require intervention by the recipient. * Must not require the reporter to complete a form. * Must guarantee that abuse reports and related logs, examples, or email headers are received.
	8.4 Objectives of "abuse-c"/"abuse-mailbox" validation The procedure, which will be developed by AFRINIC, must meet the following objectives: 1. A simple process that guarantees the abuse contact is able to fulfil its intended purpose. 1. Confirms that the resource holder: * has read the procedure and the policy * regularly monitor the abuse-mailbox * measures are taken * abuse reports receive a response. 1. Initial validation period of no longer than 15 days. 1. If validation fails, escalate to other LIR contacts and set a new validation period not to exceed 15 days.
	8.5 Validation of "abuse-c"/"abuse-mailbox" AFRINIC 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 6 months, and whenever AFRINIC sees fit.
	8.6 Escalation to AFRINIC Fraudulent behavior (for example, an "abuse-mailbox" that only replies to AFRINIC'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) can be reported to AFRINIC for a re-validation (as per section 8.5 above).
	8.7 Slow-start and progress follow-up The initial/escalation periods and the validation periodicity set by this policy can be amended yearly by AFRINIC, considering internal procedures, staffing needs and actual data, considering both, a slow-start and follow-up of the accuracy of the data. The reasons for the amendments shall be properly communicated to the community.

3.2 Additional information:

If this proposal reaches a consensus, to comply with it, AFRINIC must rename mnt-IRT to abuse-c. It is an operational AFRINIC decision if an alias (pointer, duplicated attribute, or any other alternative) to mnt-IRT is kept and for how much time (transition period) in order to facilitate the search in whois for the same information, regardless of looking for abuse-c or mnt-IRT. It is an operational AFRINIC decision to keep and for how much time the IRT or delete it and the rest of the actual information in the IRT. AFRINIC will also decide how to update the actual guidelines (membership-agreements.html) better or if they aren’t longer needed. This is done in order to assimilate the IRT to the majority of the RIRs where it is abuse-c.

As a matter of clarification, the “initial” and “escalation” validation periods may be modified by AFRINIC, if deemed appropriate, provided it informs the community of its motivation for doing so. For example, the periods could be extended in the implementation phase and adjusted as a higher percentage of contacts become accurate.

Similarly, the frequency of the periodic validation can be modified if AFRINIC deems this appropriate and informs the community of its reasons for doing so.

For example, a single validation might be done in the first year to facilitate adherence to the policy. The number of annual validations could increase over time, perhaps becoming quarterly, with the aim of improving the quality of the contacts.

This will facilitate AFRINIC for a “slow-start” to implement the policy and ensure that no additional staff is required in the initial implementation phases, as depending on the rate of failed contacts, they may need more time for the first passes thru all the membership. For example, it could be expected that the first pass takes 12-24 months and be done by different types of members (LIRs/end-users/others), with a batch each month or even holding the next batch in case of a very high failure rate, etc.

As in all the other policies, this one doesn’t set specific different conditions for legacy holders. This is a generic AFRINIC issue that should be tackled in a uniform way for all the policy manuals.

Similarly, the policy doesn’t state the consequences of lack of compliance, as this is generically stated in the RSA.

The policy doesn't define what is abuse because that definition doesn’t fall in any way in the actions from the AFRINIC perspective. Each Internet participant shall define what abuse for them is, and if others don’t respect that, they can use the abuse-c to contact them and in case of inaction to resolve the case, they should escalate the matter according to their own internal procedures, which in some cases, may also depend on their local regulations. All that is outside the scope of AFRINIC.

This policy has no additional GDPR impact, as this is already covered by all the existing AFRINIC regulations on that matter.

This proposal doesn't enforce any implementation timing, which is left to the operational practices, priorities and staffing needs of AFRINIC.

4. References

An equivalent proposal has been accepted in APNIC (already implemented) and LACNIC (under implementation). A new version is being worked out for RIPE and ARIN.

Revision History

Date	Details
12 August 2018	Version 1: AFPUB-2018-GEN-001-DRAFT01 * Initial Draft Posted to rpd
20 November 2018	Version 2: AFPUB-2018-GEN-001-DRAFT02 * Initial Draft Posted to rpd
5 June 2019	Version 3: AFPUB-2018-GEN-001-DRAFT03
2nd November 2019	Version 4: AFPUB-2018-GEN-001-DRAFT04 * Overall simplification of the text
21 November 2019	Version 5: AFPUB-2018-GEN-001-DRAFT05 * Further clarifications of the text
5 August 2020	Version 6: AFPUB-2018-GEN-001-DRAFT06 * Editorial improvements * Corrected typo in 'References' (2020/09/15)
17 May 2021	Version 7: AFPUB-2018-GEN-001-DRAFT07 * Further text clarifications based on the previous discussion and AI
15 May 2022	Version 8: AFPUB-2018-GEN-001-DRAFT08 * Version update without changes to extend the policy proposal validity to allow the Board ratification. However, the info in the references section has been updated so as to be consistent with the actual status in other RIRs.

AFRINIC Staff Assessment

(In Progress)