This is a proposal to introduce a new contact attribute named "abuse-c:", which can be included in inetnum, inet6num and aut-num objects.

Summary of proposal:

This is a proposal to introduce a new contact attribute named "abuse-c:", which can be included in inetnum, inet6num and aut-num objects.

This proposal is explicitly not about data accuracy. If the RIPE community wishes, the data accuracy issue will be tackled in a separate policy proposal.

It provides a more efficient way for maintainers to organize their provided information and helps to increase accuracy and efficiency in routing abuse reports to the correct network contact. In addition, it helps all kinds of institutions to find the correct abuse contact information more easily.

Currently within the RIPE region, it is an issue for maintainers to determine the best place to publish abuse contact information (irt, "abuse-mailbox:", "remark-fields:", and in which object they should be published). As a consequence, it is an issue for all kinds of institutions to find the correct abuse contact.

The proposal intends to improve the abuse reporting value of the RIPE database at a high level. It does not intend to specify the technical details of the implementation or the procedures for the transition from the current system of abuse contact to the prospect one. Such details will be presented in the Review Phase of the PDP after the initial community discussion.

Policy text:

New policy text

[Following text will result in a new RIPE Policy Document “Abuse Contact Management in the RIPE NCC Database“]

Abstract

This policy originated from the work of the Abuse Contact Management Task Force. The task force examined the collection and maintenance of resource registration information in the RIPE NCC Registry Database, including potential areas for improvement and alternative approaches.

This policy introduces a new contact attribute named "abuse-c:", that can be included in inetnum, inetnum, inet6num and aut-num objects.

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

The "abuse-c:" will be mandatory for all aut-nums. 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.

As per current practice, other "e-mail:" attributes can be included for any other purposes.

2.0 Attribution

This document is compiled from policies developed by the RIPE community.

The following people actively contributed by making proposals through the RIPE Policy Development Process:

Tobias Knecht

Rationale

a. Arguments supporting the proposal

It provides a more efficient way for maintainers to organize their provided information and helps to increase accuracy and efficiency in routing abuse reports to the correct network contact. In addition, it helps all kinds of institutions to find the correct abuse contact information more easily.

Unlike existing email contacts in RIPE database, the new "abuse-c:" will have the advantage of being available with no restrictions to bulk access, which facilitates automated abuse reporting processes.

b. Arguments opposing the proposal

As this RIPE policy proposal does not describe in detail the process and procedure of the policy implementation, it will be necessary to clarify these details.

In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented.

A. The RIPE NCC's Understanding of the Proposed Policy

A new attribute, "abuse-c:", will be introduced in the inetnum, inet6num and aut-num objects. From the time of implementation of the policy, every new aut-num object needs to have the new "abuse-c:" attribute present or, in the case of an update to an existing object, the attribute should be added to the object before a successful update can go through.

In the case of the inetnum and inet6num objects, the "abuse-c:" attribute references will have the hierarchical behavior. So, from the time of implementation of the policy, creation or update of inetnum or inet6num objects will be dependent on the "abuse-c:" attribute being present in the new or updated object or one of its parents in the hierarchy.

The "abuse-c:" attribute must reference a role object and the referenced role object must have an "abuse-mailbox:" attribute. Presence of an "abuse-mailbox:" attribute in the referenced role object will be protected. During further updates to the referenced role object, the "abuse-mailbox:" attribute cannot be removed from the role object while the role object is referenced by an "abuse-c:" attribute in any inetnum, inet6num or aut-num object.

B. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

Fragmentation/Aggregation:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

C. Impact of Policy on RIPE NCC Operations/Services

Registration Services:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

Billing/Finance Department:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.

RIPE Database:
The RIPE NCC’s Database Department foresees the need to implement the policy in two phases.

Phase one: Implementing the policy.
In this phase, the rules will be enforced on creation of all new inetnum, inet6num and aut-num objects as well as on updates to existing objects. The existing objects that are not updated will remain as they are in the RIPE Database.

Phase Two: Data quality improvement and clean up.
Holders of resources with no reference to an abuse contact will be regularly contacted by the RIPE NCC and requested to fill in this information. Any further interaction between the resource holders and the RIPE NCC will depend on the availability of the abuse contact information on all the resources held by the resource holder.

In order to clean up existing data, the RIPE NCC will notify the users and convert "abuse-mailbox:" attributes into "remarks:" in any object other than role objects.

The RIPE NCC will also plan to decommission irt objects and all references to them in this phase because they overlap with the new "abuse-c:" attribute and basically perform the same function.

The "abuse-mailbox:" attributes will not be added to resource blocks held by the RIPE NCC and represented in the RIPE Database for administrative and authentication purposes. Nor will they be added to any placeholder objects representing other RIR resources included in the RIPE Database. These are all administrative resources and do not represent real user networks. In order to be able to manage these placeholder objects, the RIPE NCC needs to be able to update these objects without being required to add an "abuse-c:" attribute.

As a solution, the RIPE NCC proposes adding the new status value ”ADMINISTRATIVE” to be used on all address blocks held by the RIPE NCC and on placeholder objects representing other RIR resources in inetnum and inet6num objects. There would be no requirement to add an "abuse-c:" attribute when updating any inetnum or inet6num object with the status “ADMINISTRATIVE”.

The RIPE NCC proposes a six-month gap between the implementation of Phase one and Phase two. For Phase two, the start date will be incorporated into the RIPE NCC's operational practices.

Business Applications:
The Introduction of a mandatory “abuse-c:” attribute to aut-num, inetnum and inet6num has significant impact on all the RIPE NCC’s software and services.

Updates to RIPE NCC software to include the new attribute will represent changes to the IP Analyser, LIR Portal, the Request Form within the LIR Portal and the email robot.

D. Legal Impact of Policy

Data protection issues
The proposal is introducing a new contact attribute (the attribute “abuse-c:”) that could be filled in with personal data. In particular, the email contacts that the proposed attribute would include are meant to be available “with no restrictions to bulk access” in order to facilitate automated abuse reporting processes. Accordingly, these email contacts will not be filtered when the RIPE Database information is made available in a bulk way (e.g., through NRTM, proxy services, etc.).

In general, it is the responsibility of maintainers to obtain the informed consent of the individuals whose personal data will be published in the RIPE Database. If this proposal becomes a policy and maintainers wish to fill in the “abuse-c:” attribute with email contacts that could be considered as personal data, then these maintainers would also have to inform the relevant individuals of the fact that their email contacts will be processed in a bulk way and obtain their consent on the use of their data.

Data accuracy issues
All data registered in the RIPE Database, including contact information, is expected to be correct at all times (see IPv4 address allocation and assignment policies, section 4.0 -Registration requirements https://www.ripe.net/ripe/docs/ripe-530#----registration-requirements Link: /docs/ripe-530#----registration-requirements ). The proposal explicitly mentions that data accuracy issues are not within its scope and that “if the RIPE community wishes, the data accuracy issue will be tackled in an separate policy proposal”.

Consequently, the proposal, if it becomes a policy, would not have any impact on the current registration requirements. Data accuracy requirements would apply by default to any contact information corresponding to the “abuse-c:” attribute.