ripe-563: Improving Abuse Contact Information in the RIPE Database

The proposed approach

The aim of policy proposal 2011-06 , "Abuse Contact Management in the RIPE NCC Database", is to provide a mechanism for users to query resource information and to be able to get abuse contact information related to that resource, so in the case of abuse they can report it to the responsible party. The implementation details of the policy proposal are described in ripe-563 .

The most straightforward way to implement this would be to add an abuse contact field to each resource. Although in theory this is possible, in practice it would become unmanageable. At the time of publication, there are about 3.7 million individual Internet resource objects in the RIPE Database . Even using the hierarchical nature of IP addresses and assuming the parent holder is responsible for abuse contact management doesn't help much. It will reduce the number from millions to hundreds of thousands; however, that still means RIPE NCC members would have to work with us to provide accurate abuse contact information for a huge number of objects. As a side effect, working with this amount of data will decrease the data quality over time, because maintaining this amount of data is a very time consuming task for the maintainers.

There is another problem with that model. Internet resources do not necessarily represent physical entities. This means the Internet resource objects do not model any real world operation or unit in member organisations.

To address these issues and other practical limitations, the RIPE NCC proposes adding the abuse contact information to the organisation object. Each Internet resource in the RIPE Database is associated with an organisation object which is referenced by the resource, either directly or hierarchically. For allocations, or Provider Aggregatable (PA) resources, it is mandatory to have an organisation object linked to the resource. With policy proposal 2007-01 in place, for Provider Independent (PI) assignments and Autonomous System Numbers (ASNs), each resource is either linked to the member's organisation object or to an organisation object of a client of the member (if it is not, the resource object is not in accordance with current RIPE Policy and should be updated to accurately represent the resource information).

This means each resource object which is subject to, and in compliance with, RIPE Policy will inherit abuse contact information from its  organisation object. Each RIPE NCC member should maintain correct contact information representing their organisation, including the new abuse details, in the organisation object. To make the model more closely map real-world situations, the abuse contact in the organisation object will be a link to a role object, representing the organisation's abuse-handling contact or department. This role object needs to have an "abuse-mailbox:" attribute, which will be the email address for the abuse-handling role in the organisation.

The image below illustrates how an inetnum object would refer to an organisation object, which in turn would refer to a role object (you can enlarge the image by clicking on it).

Figure 1: Proposed relation between organisation and role object

Implementing this model would be simpler, more practical and require less maintenance by members to keep abuse contact information up to date. But at the same time, it raises two issues:

• The resource is not directly linked to an abuse contact role, but they are connected through the organisation object. This might make finding abuse contact information for a resource more complex and confusing for users if they were to search through the database manually. To address this issue, we propose implementing this as part of the standard resource query. For each resource query, our software will follow the references and will automatically show the abuse contact information along with the resource.

• Many resources will not have a direct reference to an organisation object. The reference will often be listed in a resource higher up in the hierarchy, for example in the resource's parent object. In that case, the RIPE Database software will return abuse contact information for that organisation object. In the simplest model with one organisation object reference at the root of a network, this might not be the correct contact for the more specific resource. In this situation, another organisation might be responsible for maintaining the resource and handling the abuse, without actually being listed or linked to the resource. This case requires some fine-tuning. The maintainers of the resource can create their own organisation object, using type 'other', with a reference to the correct abuse-handling role object. This organisation object is then referenced from their resource. This will address the issue and will improve the data quality in the RIPE Database at the same time.

Proposed tools

Tools for data entry

PA allocations are managed by RIPE NCC members through the LIR Portal . It will be possible to check if the member's organisation has a link to an abuse-handling role. If not, a warning will be presented to the user when logging in to the LIR Portal, and help offered on how to add a role to their organisation object. We are planning to provide a tool in the LIR Portal to help users create a new role object, or modify an existing one, with abuse contact details, and add this information to their organisation objects.

Members can also get an overview of the PI assignments they sponsor and ASNs in the LIR Portal. If the related organisation objects don't have an abuse contact listed, a warning will be displayed. We will also provide a tool in the Webupdates interface to facilitate adding an abuse role to organisation objects referenced by PI assignments and ASN objects to allow one data-entry point for maintainers of those objects.

Tools for searching

Abuse contact information will be available without any limits on the number of queries. To facilitate queries and searches for this information, we will include the abuse contact information in resource queries by default. Additionally, we will provide query flags that will give only abuse contact information for any given organisation or resource. These methods will be available through our web-based search tools, query API and also the port 43 whois facility.

Proposed timeline

We propose implementing this policy in three phases (including phase 0):

Phase 0: Tools

In this phase we will make the changes to the software to support the proposed business logic in the RIPE Database updates. We will also make the proposed tools available in the RIPE Database query code and the LIR Portal. We are planning to deliver this phase by end of Q1 2013.

Phase 1: Allocations

In this phase we will focus on allocations. These objects are maintained by RIPE NCC members. Each member can cover the address space allocated to them by providing abuse contact information for their organisation. This is done by referencing a role object, with an "abuse-mailbox:" attribute, in their organisation object's "abuse-c:" attribute. This will be facilitated through the LIR Portal.

We propose a six month period for executing this step. During these six months, members will be contacted and asked to log in to their LIR Portal account and add this information to their organisation information. We will send follow-up emails during these six months. We will also use any communication a member might have with the RIPE NCC to follow-up on this.

Phase 1 will be initiated in Q2 2013 and should be finished by the end of Q3 2013.

At the end of these six months, if a member has not supplied the required abuse contact, the RIPE NCC will automatically add the member's publicly-listed contact information - available in the RIPE NCC member list - as their organisation's abuse contact information in order to conclude this phase. Members can always edit this information though the LIR Portal if they want to change the details.

According to this planning, 77% of the total amount of address space (by size of resource blocks) given out by the RIPE NCC will be covered by policy proposal 2011-06 and will have an abuse contact by the end of Q3 2013. This represents about 40% of number resource blocks given out by the RIPE NCC.

Phase 2: Assignments and AS Number resources

In this phase, ASN and PI resource holders will be asked to make sure the organisation object referenced by their resources has a reference to a role object with an "abuse-c:" attribute. As with Phase 1, follow-up emails will be sent and resource holders will be requested to review registry information.

Due to the number and nature of assignments, we are planning to finish this phase in one year. We propose starting this phase immediately after Phase 1, in Q4 2013, and concluding it in Q3 2014.

At the end of this phase the RIPE NCC will automatically add abuse contact information from the sponsoring LIR's organisation object to the organisation object of resources which were not updated by their maintainers during this one-year phase. Maintainers of the organisation object linked to the resource will always be able to modify this data later.

At the end of this phase, all resources given out by the RIPE NCC which are subject to, and compliant with, RIPE Policy will have abuse contact information.

Figure 2: Proposed timeline of policy proposal 2011-06 implementation

As usual, the RIPE NCC will do regular quality checks to make sure resources given out to our members comply with RIPE Policy and we will help members to resolve any open issues. That will include having abuse contact information linked to resource holders' listed organisation objects.

If you have any feedback or suggestions, please discuss it on the RIPE Anti-Abuse Working Group Mailing List , where the initial announcement for implementation of this policy will be submitted. The RIPE Working Group Chairs will help us assess all feedback received for this implementation proposal.