RIPE Database

Abuse Handling in the RIPE Database

Denis Walker

This article describes a technical design for the introduction of abuse contact details in the RIPE Database and streamlining the general approach to handling contact details.


In the original design of the RIPE Database an abuse handler was not considered as a contact. When it was considered, it was thought of as a special case and extra complexity was bolted on to the design. This was later tweeked several times as it was never 'quite right'. When the code is adapted and re-adapted several times the quality gets worse - sometimes it is better to take a step back and re-design a solution. For a new implementation we not only want to avoid adding even more complexity, but go back to basics and fully implement a generalised ROLE object that can be used for any type of contact information.

When reading this design document, try to look at it as if you are a new user of the RIPE Database who wants to know how to add contact information. Try to avoid thinking about the details of a transition from where we are now to where this will take us. We will cover that in more detail during the impact analysis.

Proposal to re-structure the data

An abuse handler is a contact related to an Internet resource who has a defined responsibility or role. In terms of RPSL Database structures, this is the same as an administrative contact, technical contact or DNS zone contact. So lets start with an "abuse-c:" attribute referencing abuse contact details. This fits the existing model of "admin-c:", "tech-c:" and "zone-c:" attributes. To make this new abuse contact reference work effectively as an abuse handler, three things need to be defined:

* what it points at
* where to put it
* how to find it

What it points at

An abuse handler has a defined role. So it makes sense to use the existing role object to hold the contact details. No need for new data objects.

Where to put it

To keep it simple we want to be able to put it in the least number of places with the most flexible options. So we make "abuse-c:" an optional attribute but business rules will require it in all the objects and situations as defined in the policy. For example in an INETNUM object with status 'ALLOCATED PA'. It is also optional in all other INET(6)NUM objects. This allows the flexibility to centralise all abuse handling at the LIR level, or distribute all or parts of it to customers in any combination.

How to find it

Finding the abuse contact for a resource with this structure is also simple. The basic logic is to start with an Internet resource. Then search the database in the following steps:

* does it contain an "abuse-c:" attribute? If so, that is the abuse handler.
* if not, search up the hierarchy (within preset boundaries) looking for an object that has an "abuse-c:" attribute. If one is found, that is the abuse handler.
* If no "abuse-c:" attribute is found, then this resource does not have a dedicated abuse handler defined.

Of course, all hierarchies are not always perfectly formed and they do have boundaries. By using the Abuse Finder tool provided for this purpose, known (and possible future) exceptions and limits can be built into the logic of the tool. This will provide more accurate information than directly querying the RIPE Database yourself and possibly making the wrong assumptions. For example, if the starting point is an IP address that is part of a PA assignment, the hierarchical search should stop at the encompassing PA allocation.  The Abuse Finder has a web interface for one-time users and also an API for power users.

We can adapt the '-b' query flag (currently used to search hierarchies for IRT object references) to also search for "abuse-c:" attributes. But we would encourage all users to use the Abuse Finder tool.

Generalised ROLE object

We propose to add a new attribute to the ROLE object:

 role-type:      [mandatory]  [multiple]     []

and allow this initially to take one of two values:

 STANDARD    All the current ROLE objects would fit with this type
ABUSE       For ROLE objects holding abuse contact data

All role based contact information can then be held in the one object type, ROLE. All references to contact details will be from the same type of attribute, "xxx-c:". The ROLE object will hold a superset of optional attributes needed for all role functions. Business rules will determine which optional attribute is required or allowed/not allowed for a specific role type. Webupdates can present templates for ROLE objects based on the role type, so it is not necessary to remember which optional attributes are required or allowed.

For example, "abuse-mailbox:" will be required in an ABUSE ROLE object, but not allowed in a STANDARD ROLE object.

Filtering and access control limits (ACL) could also apply differently to the different role types. For STANDARD ROLE objects, query filtering could apply to all attributes containing an email address (as it does now). ACL will apply to the number of objects of this role type a user queries. For ABUSE ROLE objects, filtering should only apply to database management attributes like "notify:" and "changed:". The operational specific attributes like "abuse-mailbox:" and "e-mail:" will not be filtered. Also no ACL will apply to queries for objects of this role type.

Authentication can be applied when adding references to ABUSE ROLE objects ("abuse-c:") as it currently does for references to IRT objects ("mnt-irt:"). This prevents anyone else directing their abuse complaints to you. But adding references to STANDARD ROLE objects ("admin-c:", "tech-c:") can still be done without needing any authentication.

By allowing "role-type:" to be a multiple attribute, one ROLE object can take on more than one role, but with the caveat that the least restrictive rules for the included role types will apply. So for a small company with only one set of people who do everything, one ROLE object can be defined as both STANDARD and ABUSE. The business rules will be a combination of these two role types. No ACL will apply to queries for this ROLE object as it is an ABUSE role type, even though it is also a STANDARD role type. It becomes the user's choice to decide between the convenience of using a single ROLE object or having more control by creating separate ROLE objects.

To summarise, one object type can be used to define any type of contact role. We currently have a need for two types. Any new type can be added in the future by defining a new type value. Business rules can define the arrangement of attributes per type from a superset of attributes, including any new ones added later. All contacts should be referenced by attributes of the format "xxx-c:" and again business rules can restrict the type of role these attributes can reference.

For example, it may be decided later to replace the IRT object with an IRT role type and reference it with an "irt-c:" attribute. Business rules can require IRT ROLE objects to include the "signature:" and "encryption:" attributes and need authentication to add the "irt-c:" attribute. This perfectly fits the new model for role based contact details.


In our first example, we have a team of two people (AA1-RIPE, BC2-RIPE) who handle administrative and technical issues for this LIR's resources. They have been grouped together in a STANDARD ROLE object which is referenced as the "admin-c:" and "tech-c:" for their resources.

This LIR has a second team of two people (SD21-RIPE, PP321-RIPE) who handle abuse issues. They have been grouped together in an ABUSE ROLE object which is referenced as the "abuse-c:" for their resources.

The STANDARD ROLE object LIR2-RIPE is subject to filtering and access control limits apply to queries of this object. No authentication is required to reference it.

The ABUSE ROLE object AB141-RIPE is subject to reduced filtering and no access control limits apply. Authentication is required to reference it in an "abuse-c:" attribute.

 inetnum: - 
admin-c:       LIR2-RIPE 
tech-c:        LIR2-RIPE 
abuse-c:       AB141-RIPE 
status:        ALLOCATED PA 

role:          LIR Admin 
admin-c:       AA1-RIPE 
admin-c:       BC2-RIPE 
 nic-hdl:       LIR2-RIPE 
role-type:     STANDARD
remarks:       admin and tech contact for LIR

role:          LIR Abuse handler 
admin-c:       SD21-RIPE 
admin-c:       PP321-RIPE 
 nic-hdl:       AB141-RIPE 
role-type:     ABUSE
remarks:       abuse handler for LIR

Example 1: Different people have different tasks and roles

In the second example, we have a team of just one person (TS15-RIPE) who handles everything for this small LIR's resources. (S)he is represented in a STANDARD ROLE object which is referenced as the "admin-c:" and "tech-c:" for their resources.

This same ROLE object is also the ABUSE ROLE which is referenced as the "abuse-c:" for their resources.

As it is an ABUSE ROLE object, LIR36-RIPE is subject to reduced filtering and no access control limits apply to queries of this object. Even though it is also a STANDARD ROLE object. Authentication is required to reference it in an "abuse-c:" attribute, but not when referenced in an "admin-c:" or "tech-c:" attribute. The "abuse-mailbox:" attribute is required as it is an ABUSE ROLE object.

 inetnum: - 
admin-c:       LIR36-RIPE 
tech-c:        LIR36-RIPE 
abuse-c:       LIR36-RIPE 
status:        ALLOCATED PA 

role:          Small LIR contact 
admin-c:       TS15-RIPE 
nic-hdl:       LIR36-RIPE 
role-type:     STANDARD
role-type:     ABUSE
remarks:       admin, tech and abuse contact for small LIR

Example 2: One person handles everything

(For the examples we picked random letters and numbers for NIC Handles. Apologies if we have used your NIC Handle.)

This issue is currently being discussed on the Anti Abuse Working Group mailing list . Please direct any comments to the list.


You may also like

View more

About the author

From 2001 to 2015 I was a developer and then the business analyst for the RIPE Database with the RIPE NCC. During this time I have been involved in every aspect of it's design and development of the software, web services and infrastructure, it's philosophy, legal, political and policy aspects, documentation, testing and future planning and specifying of new features

Comments 4