Late last year, we explained how we would implement a policy proposal that instructed us to validate abuse contact information in the RIPE Database. At the time, we only shared the first half of our approach – which was a fully-automated process of first checking abuse contacts and then sending validation links and reminder emails to get resource holders to either confirm that their existing abuse contact is valid or update it to a working one.

The part of the process we were still working on was the manual element – what to do when an abuse contact has not been validated or updated after our final reminder email has been sent. This part will require our staff intervening directly to make sure this information is updated. The challenge was to identify an approach that would allow us to fulfill the spirit of the policy while not creating too much of a burden on our operations or those of our members.

This figure illustrates how abuse contacts are referenced in the RIPE Database

Test results and considerations

Our last article mentioned some of the guiding principles behind our implementation planning. Essentially, the goal is to make sure we have accurate information in the RIPE Database – not to close down our members or create unnecessary disruption. We also want to avoid having to staff an entire “Abuse-c Department” simply to deal with this information.

In late 2018, we tested our automated process on the abuse contacts referenced in 900 LIR organisation objects. We used our tool to check 300 emails at a time over three consecutive nights. This resulted in 187 tickets (meaning around 21% of these emails were either invalid or false-positives). Our system then sent out the validation links and email reminders as we have described previously.

Four weeks from this point (one week after our last reminder), 106 tickets had been resolved without any intervention by our staff. This still left 81 cases where we needed to follow-up manually – which is 43% of the invalid emails or 9% of the 900 abuse contacts in total.

We decided to test our process on abuse contacts for LIR organisation objects because we expect these will be the easiest to resolve. Our members are used to hearing from us and are obligated to respond, as they can eventually be closed for unresponsiveness or for not following RIPE policies (though it is important to note that this is a long process with plenty of time to comply).

The results of this test indicate that our staff will need to intervene manually for a significant portion of abuse contacts. Even for this “easy” category, a large amount of work was needed to follow-up with LIR contacts. In many cases, this involved multiple email and phone reminders – which is labour-intensive when we consider scaling this up to deal with the approximately 70,000 abuse contacts in the RIPE Database.

We expect that abuse contacts for End User resources and LIR resource objects will be more difficult. Not only will we need to get through to the LIR, but they will often need to contact their customers or End Users to update this information. If even a relatively small percentage of these people are unresponsive, this could create unwanted disruption in terms of members being closed or resources being de-registered.

Taking this into consideration, our board has decided on an approach that is in line with the spirit of the policy and is not overly disruptive. It also minimises the impact on our workload and staff levels.

Our approach

We will be validating abuse contacts in a particular order, according to the type of database object they are referenced in:

1.  LIR organisation objects
2. LIR resource objects
3. End User (sponsored) objects

We will start with an automated process that is unchanged from what we described last year. We will then use a manual approach to follow up directly with LIRs that still have invalid abuse contacts at the end of this process.

Automated process

As our earlier article explains in more detail, we start with a verification tool that checks whether an abuse contact email is valid and can accept mail. Abuse contacts that pass this initial check will be marked as valid and the process ends there. The next step is to email contacts that have been marked as invalid to explain what we are doing and ask them to update their contact. If our tool has got it wrong and their email is working, they can simply click on a link to confirm it is valid and close the ticket.

Obviously, resource holders won’t see this initial email if their abuse contact cannot accept email. For this reason, we will also email all listed LIR contacts to ask if they were able to find the validation email in their abuse-mailbox, or otherwise ask them to update this with a working email address. If they do update their abuse contact, we will validate this before we close the ticket.

Resource holders can respond to these emails if they have any questions or need assistance (such as getting LIR Portal or maintainer access). We will send two further reminders at one-week intervals for a total of two weeks from the start of the process.

Manual approach

Our manual approach begins one week after the final reminder has been sent. If an abuse contact has not been validated/updated by this point, our staff will take over the ticket and begin to intervene directly.

Once our staff become involved, we will attempt to contact the LIR in other ways. We might call their main office or look for alternative contacts. If we are unable to establish contact with the LIR, we will further escalate the process. What happens next depends on which category the abuse contact falls under.

LIR ORGANISATION objects

When dealing with abuse contacts for LIR organisation objects, we will send a final notification that we would like to update the abuse contact ourselves, by inserting the public email address of the LIR (or another one if it seems more appropriate). However, we will only make this update if we receive consent from the LIR to do so.

If the LIR refuses to cooperate or is unresponsive, we will escalate the ticket according to our existing processes for unresponsiveness or failure to comply with RIPE policies. This may ultimately lead to the closure of the member and de-registration of the Internet number resources. Again, it is worth highlighting that this is not an outcome we will be aiming for. Once we have started the closure process, the LIR will have a further three months to update their abuse contact before their membership is terminated.

For LIR resource objects / End User objects

For abuse contacts referenced in LIR resource objects or End User objects, we will use a slightly different approach. As before, once our automated process has run its course, we will send a final notification to the LIR that we would like to update the abuse contact ourselves, inserting an appropriate email. Again, we will only make this update if we receive consent from the LIR to do so.

However, the key difference here is that we will not terminate the membership (or the End User sponsorship agreement) if we do not receive a positive response from the LIR. Instead, we will update the RIPE Database to include a comment that the abuse contact has failed our validation, along with a link that directs users to the LIR with responsibility for the database object.

We believe that the approach we will be using strikes an appropriate balance between fulfilling the intent of the policy while remaining realistic in terms of the impact on our workload and potential disruption for resource holders. We think this is further supported by the statement in the policy: “Due [to] 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.”

It is also worth noting that we will not simply be “giving up” in terms of having a validated abuse contact in place for these objects in the RIPE Database. When we perform future validations, these contacts will again return as invalid and we will attempt to resolve the issue with the LIR again. Our Registration Services department will also look at resolving these cases through other means (such as when conducting Assisted Registry Checks in the future).

Next steps

We have already used our tool to check all LIR organisation object abuse contacts. On Wednesday 20 February, our automated process will begin sending emails in batches to the 6,000 abuse contacts that failed this initial validation.

Only once we have resolved these tickets will we move on to the abuse contacts for LIR resource objects and finally for End User objects.

We will provide an update with some statistics as we make further progress with our validation of LIR organisation object abuse contacts.