Ed Shryane

Cleaning Up Locked Person Objects in the RIPE Database

Ed Shryane

5 min read

0 You have liked this article 0 times.
0

Unmaintained person objects in the RIPE Database were locked by the RIPE NCC so they could not be used to hijack resources. Now we plan to set the correct user maintainer on those person objects.


Why are there locked person objects in the RIPE Database?

When the current iteration of the RIPE Database was created in April 2001, a maintainer was optional on person objects. This meant that anyone could modify unmaintained person objects, without any authentication. There was no control over the data and no clear indication of who was responsible for maintaining it.

In October 2010, a maintainer became mandatory on all person objects, following a recommendation by the RIPE Data Protection Task Force. An automated cleanup of unreferenced person objects was also introduced (any unreferenced person object is deleted after 90 days). However, no cleanup was done on referenced person objects, the mandatory maintainer rule was only enforced when the person was next updated. Most person objects were never updated.

Finally in April 2016, all remaining unmaintained person objects were locked by the RIPE NCC, as the personal data in these objects were susceptible to unauthorised changes. As these person objects were referenced as technical or administrative contacts on resources, there was also a risk of manipulating the data to facilitate resource hijacking.

Figure 1: 32% of all person objects in the RIPE Database were locked

It was not feasible to cleanup these objects at that time:

  • The RIPE NCC could not easily notify the affected persons. Only 25% had an email address, and it was not possible to verify if that address was accurate.
  • The RIPE NCC was not able to verify claims on unmaintained objects in the RIPE Database, and it was not possible to assist users to unlock those objects.
  • A substantial operational burden would suddenly be imposed on the RIPE NCC to respond to queries resulting from a mass notification.

Instead, users had to replace references to the locked person objects themselves, with a different person or role contact, and the unreferenced locked person would be automatically cleaned up (deleted) later. Unfortunately, most references were never updated, and so locked person objects were not cleaned up.

Why clean up locked person objects?

  • Locked person objects cannot be modified by the resource holder. Once the locked person objects have been updated with the correct maintainer, they can be reviewed and updated by the resource holder.
    • According to the IPv4 Address Allocation and Assignment policy (Section 4.0):
      • All assignments and allocations must be registered in the RIPE Database.
      • Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained).
  • The RIPE NCC must keep ensuring that it complies with the General Data Protection Regulation (GDPR) in relation to personal data held in the RIPE database.
    • Locked person objects appear to be maintained by the RIPE NCC, when in reality they are the responsibility of the resource holder.

How will locked person objects be cleaned up?

There is a manual process for resource holders to replace locked person objects, but the huge number remaining means that an automated process is now necessary to update them. 

We found that more than 90% of references to locked person objects are from IPv4 assignments, and 74% of those assignments are within allocations from 10 LIRs. 

Figure 2: Almost all locked person objects are related to IPv4 assignments (ASSIGNED PA)

To perform a cleanup, we will select locked person objects which are referenced by IPv4 allocations or assignments, and re-assign them to the resource maintainer (where we are certain of a link between them) or to the LIR's allocation maintainer.

We plan to announce this cleanup to the RIPE mailing lists beforehand. We will also directly notify the affected LIRs and assignment maintainers before and after we make any changes, including a list of updates.

We will also ask the affected maintainers to validate the correctness of the contact details on their resources. Once the person objects are unlocked they will be free to make changes themselves.

The remaining 10% of locked person objects, and locked role objects, not referenced from IPv4 assignments, will be cleaned up separately (at a later date).

 

When will this cleanup happen?

  • We will send an announcement to the RIPE community mailing lists in advance: ncc-announce, ncc-services-wg and db-wg.
  • We will notify a first group of affected LIRs by email, before the RIPE 80 meeting (12 - 14 May 2020).
  • A cleanup will be performed, one LIR at a time, after notifying them.
  • We will notify the LIRs again after the cleanup, asking them to review the contact details on their resources.
  • Any remaining LIRs will be notified after the RIPE meeting, before and after any cleanup.

 

For more background information, please also refer to the presentations at RIPE 78 Cleaning Up Locked Persons and at RIPE 79 Operational RIPE Database Update.

0 You have liked this article 0 times.
0

You may also like

View more

About the author

Ed Shryane Based in Amsterdam

I'm a Senior Technical Analyst with the RIPE NCC, working on the RIPE database.

Comments 0