Suggestions for Improving Abuse Contact Management

Overview

Note the following points:

• The policy provides for an "abuse-c:" attribute covering all resources
• General agreement that offering a simple default option is a good idea
• There is a need to maintain one simple means of representing the same information

Two issues have been identified:

• Partitioned subnets within one organisation
• Adding abuse contacts to more specifics for End Users

Regarding the first issue, users don't want to create copies of their organisation object to document different abuse contact details for different subnets. Currently there is no concept of groups within an organisation. So the implementation requires duplicated organisation data.

Regarding contacts for End Users, there has been some misunderstanding about the organisation objects created. This is not meant to be a copy of the LIR's organisation object. When the organisation object was introduced in 2004 the intention was that this will hold details of an organisation (or individual) who is responsible for some aspect of the management of Internet resources. If an End User is managing the abuse reporting for an Internet resource then the organisation object should represent that organisation (or individual). Since 2004, the RIPE Database has adopted an organisation-centric model. This maps well with reality where in most cases an organisation has Internet resources and human resources with contact details and the human resources manage the Internet resources.

A solution to the subnet issue

We want to maintain the one single structure within the RIPE Database for representing abuse contact details. That means an "abuse-c:" attribute is referenced only in an organisation object. For many users this one option works well. But we realise that this option does not fit all situations. How do we offer alternatives for the subnets without breaking the current single structure?

We would like to propose an extension to the current implementation using a construction similar to the "mnt-routes:" attribute. The principle that any organisation object referenced by a resource object must have a default "abuse-c:" covering all the resources held by that organisation remains. If a different abuse contact is needed for a subnet, add an additional "abuse-c" to the LIR's organisation object with a reference to the address(s) it relates to. For several subnets with different abuse teams, add several additional "abuse-c:" attributes with the address reference. So the organisation object may look like this:

 organisation:  ORG-LIRA-RIPE
 

 org-type:      LIR
 

 abuse-c:       AH9936-RIPE                 <--- default
 

 abuse-c:       AH9955-RIPE {10.0.0.0/16}   <--- an LIR subnet
 

 abuse-c:       AH8888-RIPE {fd30::1/64}    <--- another LIR subet

The option of adding a reference to a different organisation object with it's own default "abuse-c:" lower down in your network still exists. So if you make a sub-allocation to a different organisation you can mark that point with a new 'default' for the network they build from that point on. They can also add additional "abuse-c:" attributes to their organisation object for any of their subnets who handle their own abuse. The software tools developed by the RIPE NCC to search for abuse contact details will ensure that for any address only the most appropriate, single contact details are returned.

One major advantage of this construct is that it makes it easy for you to view and manage the list of subnets where abuse handling is different to the default. They are all grouped together in your organisation object.

A solution to the End User issue

The problem seems to occur when an End User who has been assigned a resource that is fully managed by the LIR now wants to manage the abuse handling themselves. There is no infrastructure set up in the RIPE Database for this End User. They need to have an organisation and role object and in the case of IPv6, maybe even an inet6num assignment object if their resource is currently part of an aggregated range of IP addresses. For an LIR with many End Users handling abuse, this is a lot of extra work creating all these objects in the RIPE Database.

The RIPE NCC proposes to provide a simple wizard that will take in some basic information and create all the necessary objects for an End User to handle abuse reporting. The wizard will also allow for the quick cancellation of the End User managing abuse handling and clean up any redundant objects created for this process.

This process will:

• Maintain the one, standard format for representing abuse contact data in the RIPE Database
• Preserve the integrity of the organisation centric model showing who (jointly) manages Internet resources
• Minimises the extra work load for LIRs to set up and remove End User abuse handling

Mockup

Below you can see four images showing a possible work flow for the simplest case of setting up an end user to handle abuse reporting (You can click on the images to enlarge them). A final design of this wizard will take care of many of the corner cases as well and provide for the clean up.

Management of data

Once you have set up many subnets and end users with their own abuse handling, it is not easy to get a complete overview of who handles abuse within your organisation's networks. As the RIPE Database develops by adding these complex features, all users, including the experienced power users, can rely on the RIPE NCC to provide the tools or API calls that will return 'interpreted information' to you. Digging into the RIPE Database yourself with (large numbers of) individual queries and either writing your own scripts to parse the output or looking at the results with the human eye becomes in-practical and error prone. In the case of abuse handling we can provide API calls that will return a full summary of all the abuse contacts you have set up based on all the resources your organisation holds, or per resource. Currently there are no simple database queries that will do this for you. If the community adopts this plan, we can build the tools which internally can make a lot of short cuts that will avoid the need for so many individual queries.