Creating and Finding Abuse Contacts in the RIPE Database (Update on Implementing ripe-563)
The RIPE community decided to improve the quality of the abuse contacts in the RIPE Database by making an "abuse-c:" attribute for Internet resources mandatory. In ripe-563: Improving Abuse Contact Information in the RIPE Database the overall strategy of implementing the policy ripe-563 is described. In this document we explain some of the finer points about the implementation and the next steps.
RIPE Database structure
In the simplest case a RIPE NCC member manages the abuse reports for all customers using networks within the member's allocation. In the real world this member organisation has one or more Internet resources and within the organisation there is a function (or role) to handle abuse complaints. This is illustrated in the image below:
This maps exactly to the new RIPE Database model:
INET(6)NUM member abuse
objects ROLE object
For some members, some of their customers handle abuse reports for the address space they use themselves. These customers take on responsibility for part of the management of that Internet resource. The structure of the customer's organisation is the same as that of the member, but maybe on a different scale. So the customer has an organisation, partly managing Internet resource(s), and within their organisation there is a function (or role) to handle abuse complaints.
As far as the RIPE Database is concerned, the model for the customer is identical to that of the member. This model can be replicated at any point in the network where a customer is (partly) responsible for managing some aspect of an Internet resource:
INET(6)NUM member abuse
objects ROLE object
/ \ customer ORGANISATION
/ \ object (org-type:OTHER)
/ \ / \
/ \ / \
other customer customer abuse
customers INET(6)NUM ROLE object
In the first setup phase we will focus on IPv4 and IPv6 allocations. These are registerd in the INETNUM and INET6NUM objects created by the RIPE NCC for the member's resources. The timeline in the implementation plan indicates that all these resources will have abuse contacts referenced within the next six months.
How to create a top-level abuse reference
For a RIPE NCC member to create their top level abuse contact, the process is very straight forward. First you need a ROLE object with an "abuse-mailbox:" attribute. This attribute will contain the email address to send all abuse reports to. You can use any existing ROLE object and simply add an "abuse-mailbox:" attribute. Or you can create a new ROLE object just for this function. This is illustrated in Figure 1 of ripe-563: Improving Abuse Contact Information in the RIPE Database.
We have made the "admin-c:" and "tech-c:" attributes optional in this ROLE object so it does not need to reference any PERSON objects. The purpose of such ROLE object is to specifically record abuse contact details. This is considered to be business data, not personal or private data. There will be no restrictions on queries for ROLE objects containing an "abuse-mailbox:" attribute. So NOT having any directly referenced PERSON objects on these abuse ROLE objects may be preferred. In reality someone reporting abuse wants to contact a help desk who can sort out their problems. They are not usually interested in knowing who sits behind that desk as long as they can contact it and their problems are resolved.
All RIPE NCC members already have an ORGANISATION object with org-type:LIR. This is already referenced by the "org:" attribute of all INET(6)NUM allocation resources held by the LIR. You can use the LIR Portal ORGANISATION object editor and add an "abuse-c:" attribute to the ORGANISATION object. This must reference the ROLE object with the "abuse-mailbox:" attribute. (For more details on using the LIR Portal object editor see below.)
For the simplest case that is all that needs to be done.
How to create delegated abuse handling
If you have delegated responsibility for handling abuse to a customer for the part of your network they use, they need a similar set up to yours. Either you can set this up for them, if you maintain all the RIPE Database objects, or they can (partly) set it up themselves. In most cases the INET(6)NUM assignment objects will be maintained by the RIPE NCC members, so you will have to add the ORGANISATION reference to these objects.
You first need a ROLE object for the customer and it must contain an "abuse-mailbox:" attribute. If the customer already has one you can use that one or create a new one. This ROLE object does not need to reference any PERSON objects. It will be public with no query limits, so all information it containes is assumed to be business data, not personal or private data.
You then need an ORGANISATION object for the customer with "org-type: OTHER". Again you can use an existing one or create a new one. This object must reference the ROLE object with the "abuse-mailbox:" attribute.
Finally reference this ORGANISATION object in the customer's assignment object(s). Any query for the customer's IP address(es) will now return their abuse contact details instead of the contact details you set up for the parent allocation.
The RIPE NCC's abuse finding tools work from the bottom up looking for "abuse-c:" references in ORGANISATION objects linked from the INET(6)NUM objects. The first one found is returned. If any "abuse-c:" reference is found, only that will be returned. None of the legacy "abuse-mailbox:" attributes used in various object types will be considered. So when setting up your new abuse contact information you need to work from the bottom up. That is, to set up any "abuse-c:" details for your customers first, then set up your required, default "abuse-c:" in your LIR's ORGANISATION object. If you set up yours first, any request for abuse contacts for your customers will only return your details until you set up the customer's new "abuse-c:" details.
Finding Abuse Contacts
RIPE NCC tools
The preferred way of finding abuse contact details for any resource registered in the RIPE Database is to use one of the RIPE NCC's abuse finding tools. These tools take account of defined rules for documenting abuse contact details and also know what email addresses are NOT abuse contacts. If no abuse contact is found no email address will be returned. Users should resist querying the RIPE Database directly and sending abuse complaints to any or all email addresses found. Many of these email addresses are for functions that have nothing to do with abuse handling. Mass mailing every contact found in the RIPE Database that is linked to the IP address in question is actually making the problem worse rather than solving it.
The RIPE Database Abuse Finder tool
The Abuse Finder tool takes an IP address or AS Number as input. If the given resource has a related "abuse-c:" attribute, the "abuse-mailbox:" listed the ROLE object will be returned as the abuse contact. It may be that in some cases no abuse contact is returned. This can happen if the maintainers of the resource have not defined any email address as an abuse contact in an "abuse-mailbox:" attribute. The implementation plan for "abuse-c:" takes this into account and puts strict timelines on setting up abuse contact data. The RIPE Database Abuse Finder is described in more details in Find Abuse Handler Details Using the Abuse Finder.
The RIPEstat Abuse Contact Finder widget
The RIPEstat Abuse Contact Finder widget also provides an interface to find abuse contact data. It is based on the RIPE Database abuse finder tool desribed above, but provides potential abuse contacts found elsewhere and rates the likelihood of it being the correct contact. The RIPEstat abuse finder widget is described in more details in Finding Abuse Contact Information with RIPEstat.
Querying the RIPE Database directly
If you are not familiar with the RIPE Database and what the different data sets mean, or you are only looking for abuse contact details, you should use the tools described above. If you are familiar with the RIPE Database and are looking for additional information then querying the RIPE Database for Internet resource objects, by any means, will return an abuse contact by default, if one is registered. This will be shown in the query output as a comment before the resource object. This output is shown below:
% This is the RIPE Database query service.
% The objects are in RPSL format.
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Abuse contact for '192.168.100.0 - 192.168.100.255' is 'firstname.lastname@example.org'
inetnum: 192.168.100.0 - 192.168.100.255
descr: /24 assigned
status: ASSIGNED PA
changed: email@example.com 20020101
% This query was served by the RIPE Database Query Service version 1.52.8 (UNDEFINED)
The RIPE Database software works on the address hierarchy to find the most appropriate details for a given address. This may be an abuse contact registered diretly for the given address, or it may be from a parent address object. When a contact is registered for a parent it will always be shown for any more specific address queried, unless a contact has been defined lower down in the hierarchy. So the closest details are provided to any address queried, when searching up the address hierarchy.
Heuristics of Abuse Finder
The Abuse Finder tool used to trawl through the RIPE Database looking for 'possible' contacts for a given resource. But, before the introduction of "abuse-c:", the "abuse-mailbox:" could have been put in any of five different object types. These could have been objects directly referenced by the resource, or 'some distance away from' the resource. There were no rules enforced by the software. Not even any guidelines on the 'best' place to put it. Many maintainers of resources even put the abuse contact details in the "remarks:" attribute which are impossible to accurately parse by software. As a consequence the Abuse Finder tool could only give a 'best effort suggestion' of the appropriate abuse contact details. This proved to be unreliable and contentious.
The RIPE NCC will drop this old behaviour of the Abuse Finder tool. It will then only return accurate and reliable data from the "abuse-c:".
After adding an "abuse-c:" attribute to the ORGANISATION object, it would help to keep the RIPE Database clean if you can remove any old "abuse-mailbox:" attributes and "remarks:" referencing abuse contacts from other objects. Also any IRT references, if the IRT object was only used for abuse handling. There will be a data cleanup project when the "abuse-c:" attribute has been fully setup. But according to the time line that is over a year away. The full timeline cn be found in Figure 2 of ripe-563: Improving Abuse Contact Information in the RIPE Database.
Using the LIR Portal Object Editor
All RIPE NCC members have an account with the LIR Portal. This allows members to change parts of their allocation objects, which are maintained by the RIPE NCC Registration Services. The screen shot below shows the ORGANISATION object editor in the LIR Portal.
To get to this you select 'Object Editors' from the 'Resources' menu, then select 'Organisation Object Editor' from the list presented. In section 1 you will see a list of your ORGANISATION objects. Select the one(s) you want to add an "abuse-c:" to.
In section 2 select the "abuse-c:" attribute from the drop down menu. Insert the Nic Hdl of the ROLE object in section 3 and click the '+' button to register this value. Clicking the 'Add' button in section 4 adds the "abuse-c:" attribute to the end of the ORGANISATION object.
The Preview in section 5 shows the object and if you scroll down to the bottom you will see the new attribute. Finally click 'Submit Changes' in section 6 and the update will be sent to the database. Scrolling to the top of the page shows the results of the update.
An announcement was sent out by the RIPE NCC to the Anti Abuse Working Group mailing list. If you have any comments or feedback, please focus the discussion on this mailing list.