Proposal

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, in 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 a 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 on 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: 

3.2 Additional information:

If this proposal reaches 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 if 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, as well as the rest of the actual information in the IRT. AFRINIC will also decide how to better update the actual guidelines (https://www.afrinic.net/library/membership765-abuse-policy-bcp) 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, in the implementation phase, the periods could be extended, 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.

 4. References            

An equivalent proposal has been accepted in APNIC (already implemented) and LACNIC (under implementation) and is under discussion in the RIPE.

Revision History

Revision History

AFRINIC Policy Impact Assessment

AFRINIC Staff Assessment

1. Staff Interpretation & Understanding of the proposal

This policy proposal requests AFRINIC to implement proper abuse-c contact and abuse-mailbox. It updates Section 8.0 of the Consolidated Policy Manual. At the moment, AFRINIC WHOIS objects - aut-num, inetnum and inet6num do not contain the abuse-c attribute

A - The abuse-c :-

• must be used to publish abuse public contact information within the AFRINIC service region. 
• are verified automatically and periodically with the use of automation, where possible by AFRINIC in order to facilitate in/cross-region abuse reporting.
• does not replace the data included in the IRT object on the AFRINIC whois database implemented at the moment
• is mandatory in resource objects “aut-num”, "inetnum" and "inet6num" in resources allocated/assigned by AFRINIC as well as other resources that may be used in the future
• present in child objects of those directly distributed by AfriNIC (Assignments, sub-allocations) can be either be new or inherited from the parent resources delegated by AFRINIC
• shall have at least one valid and actively monitored abuse-mailbox attribute
• shall pointing to a person or role, with at least one valid, monitored and actively managed email inbox (abuse-mailbox)
• The "abuse-mailbox" attribute must be available in an unrestricted way via whois, APIs and future techniques.

B - Abuse-c/abuse-mailbox validation

AFRINIC shall develop the procedure for abuse-c/abuse-mailbox validation that meets the following objectives:-

1. A simple process that guarantees the abuse contact is able to fulfil its intended purpose.
2. 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.
3. Initial validation period of no longer than 15 days.
4. If validation fails, escalate to other LIR contacts and set a new validation period not to exceed 15 days.

Frequency of validation conducted by AFRINIC:-

1. At the time abuse-c/abuse-mailbox are created 
2. At the time abuse-c/abuse-mailbox are updated
3. Periodically - not less than once every 6 months
4. Whenever AFRINIC sees fit.

C. Escalation to AFRINIC

AFRINIC shall ensure that reporters can escalate and report fraudulent behaviour such as:-

1. Unresponsive abuse-mailbox
2. Abuse-mailbox that only replies to AFRINIC's emails, or to messages with a specific subject or content)
3. Failure to comply with the remaining aspects of this policy (incorrect or lack of response to cases of abuse)

Such cases when reported will trigger revalidation of the abuse-c contact.

D. AFRINIC shall:-

1. confirm if the proposal can be implemented in 90 days as written, or; 
2. provide a reasonable time frame to allow both the staff to develop the tool and the members to update their abuse-c contacts.

The initial policy compliance enforcement period is not specified and hence implied alignment with the 6 months validation period is assumed

Benefit to AFRINIC

The accuracy of the whois database in terms of abuse contacts will increase as its members adopt and implement an abuse contact in compliance with this policy.

Impact on members

In addition to the existing person/role objects that serve as administrative and technical contacts, members shall:-

1. provide an abuse-c contact to AFRINIC that is valid, monitored and actively managed
2. ensure that emails sent to the abuse-mailbox in the abuse-c contact
   • Require their intervention
   • Must not require the reporter to complete a form.
   • Must guarantee that abuse reports and related logs, examples, or email headers are received.
3. Ensure that their internal abuse handling procedures reflect the above in order to comply with the policy.
4. Service support (inclusive of help desk/resource applications) for existing members shall be offered only if compliance with this policy is observed
5. Ensure that they keep their contact information, inclusive of abuse-c accurate at all times so as to be in compliance with this policy and the RSA

2.0 AFRINIC Staff Comments on the clarity of policy

None

3.0 AFRINIC Staff Clarification Requests

AFRINIC is assuming that the abuse-c will not be mandatory for inetnum and aut-num that hold legacy status. Clear guidance from the author is required on this matter.

4.0 Staff Comments on Areas of Impact

4.1 Impact on Registry Functions

1. If this proposed policy reaches consensus, an improvement on the accuracy and currency of registry data is expected, as the “abuse-mailbox:” attributes are expected to be current and correct. This will also reduce the number of abuse emails that are directed to AFRINIC queues due to lack of abuse contacts currently.

2. MS procedures will require updates as follows:-

New procedure/sub-process to be developed for the validation of the abuse-c/abuse-mailbox.

3. WHOIS

• The abuse-c shall be a person/role object on the WHOIS database. abuse-mailbox is already an attribute of the person/role object.
• The abuse-c attribute shall be added on the WHOIS database as an attribute to inetnum, inet6num and aut-num objects
• Deprecate IRT object
• Remove mnt-irt attributes from inetnum, inet6num and aut-num objects.
• Add validation rules to force abuse-mailbox on person and role objects which are referenced via the abuse-c attribute.
• A WHOIS query of the inetnum, inet6num and aut-num shall provide the abuse contact in the response.

4. MyAFRINIC

1. Coding will be required to ensure creation/updates/import of abuse contacts
2. Abuse contacts shall not have login credentials on MyAFRINIC unless if it is being used in another role as well and hence will be maintained by admin/tech contacts
3. Update of the resource issuance/update business rules to make abuse-c mandatory(all or excl legacy TBC)
4. Updates of the sub-allocation and assignment forms with business rule around abuse-c
5. A tool to validate the mailboxes as mandated by this policy proposal will have to be implemented and abuse contacts flagged as valid/invalid
6. A tool to enable members to implement the abuse-c will be developed.

5. NMRP

Since the abuse-c will become mandatory, changes will be needed on NMRP as well where the applicant should provide the abuse-mailbox email to be added to the resources if the request is approved.

4.2 Impact on Member Services Operations

Breakdown:

Member organisations: 28 Out of a total of 1857 resource members have adopted the current abuse contact policy and 27 IRT objects (out of 42 IRT objects created in the whois db) are referenced in their resources on the whois database.

1. The AFRINIC Database contains around 7,000 distinct aut-nums and first-level (directly allocated by AFRINIC) inet(6)nums and only 27 distinct IRT objects are being referenced. This implies a significantly high workload on the MS department during the initial validation to have all members to comply with the policy. This activity may require a phased approach to ensure the workload is manageable. While the process will be automated as much as possible, a considerable amount of support to members shall be rendered by Member Services.
2. Member documentation on AFRINIC website will be improved with guidelines around the abuse contact policy
3. The initial policy compliance enforcement is likely to require more than 6 months validation period for staff to provide the necessary support to all members. This will increase the workload on the Member Services Department if the initial policy compliance enforcement period is aligned with the 6 months validation period. The department will require additional staff to ensure all members are given the required support within the 6 months.
   Alternatively, a period of 12 months would be feasible to conduct the initial policy enforcement, and if aligned to the validation period, this will easily blend with another internal activity where member information verification will be done at a cycle time of 12 months.

5.0 Legal

In case this policy reaches consensus, non-compliance with this policy by an AFRINIC member will be considered a breach of the RSA clause and the member will be encouraged to remedy the breach. Persistent non-compliance may entail revocation of the RSA as per the clause.

6.0 Finance

Recruitment of additional support staff to cater for the increase in tickets that the implementation of the policy will generate.

7.0 Implementation Timeline

Due to the significant amount of systems impacted and coding required to onboard the AFRINIC members into adopting the abuse-c contact, 90 days for implementation cannot be met. The AFRINIC team can implement the policy within the 6 months from the Last Call as mandated by the CPM on its systems and 12 months to get the members to comply with the policy.