Reclaim Functionality for Resource Holders

Introduction

This is an improvement to the RIPE Database update service to allow resource holders to delete any operational objects from the RIPE Database connected to their resources. This improvement automates the process which was previously handled manually by the RIPE NCC.

Background

The authentication system of the RIPE Database is quite complex. There are multiple levels and types of authentication. There are dedicated authentication types with fall back options with different meanings depending on the object type. Even experienced users of the RIPE Database can sometimes set up their data in ways that have undesirable consequences. This is reflected in the number of times the RIPE NCC is asked to manually intervene to recover control of objects or remove blocking objects for resource holders.

A common scenario is to give joint control over an object using the "mnt-by:". If you do this, both maintainers have equal authority. The other party can simply remove the resource holder from the object and control is lost. There was no way for a resource holder to recover from this without asking the RIPE NCC to intervene and override authorisation. This improvement automates the previously manual process.

Perhaps the most common issue is where a route object blocks the creation of a new exact matching route object. With this new functionality the resource holder can simply delete the blocking route object.

RFC 2725 (Routing Policy System Security) provides for a reclaim functionality. This was intended for resource holders to be able to delete more specific data. This functionality has been discussed many times by users but was never implemented.

The resource holder is responsible and accountable for the overall management of the resources allocated or assigned to them by the RIPE NCC. To fulfill these obligations the resource holder needs to have the 'capability' to manage their resources. This reclaim functionality was not implemented in the legacy RIPE Database software, but features like this are quite easy to add to the new software.

The RIPE RPSL (Routing Policy Specification Language) has evolved in many ways based on community needs rather than the original strict definition by the RFCs. This reclaim implementation is basically automating what the RIPE NCC has been doing manually for many years. It responds to the needs of the resource holders and will ease their day to day interaction with the RIPE Database.

Functionality

The functionality is called 'reclaim'. This implies to take back or re-gain control of a resource. Therefore only a delete option has been implemented. There is no option to modify objects or change authentication of existing objects. Only the resource holder has the authority to create objects within their networks. So when one or more objects are deleted, the resource holder has taken back control as only they can re-create those objects. The reclaimed objects are deleted by overriding the authentication on those objects. There are very strict rules about which objects can be reclaimed and whose authentication is allowed to override the object's authentication.

Usage

As mentioned before, the only difference this new functionality provides is to accept additional authorisation for delete requests in certain circumstances. This means there are no special tools or commands required to use this functionality. Resource holders can just append "delete: reason" to the more specific objects and submit them as a standard update with authorisation from the parent resource object.

Authentication to reclaim

Normally an object can only be deleted if the operation is authorised by one of the mntner objects in the "mnt-by:" attributes of the object to be deleted. With this new functionality, the software now also looks for the exact matching, encompassing or less specific address space object that was allocated or assigned by the RIPE NCC in the hierarchy of the object that is to be deleted.

All the mntner objects from the "mnt-by:" and "mnt-lower:" attributes of this allocated or assigned resource object are added to the list of mntner objects in the "mnt-by:" attributes of the object to be deleted. Any of these mntner objects can authorise the deletion.

So the "mnt-lower:" of an allocation, or the "mnt-by:" of a PI or anycast assignment, has the authority to reclaim any more specific or related primary object.

Example

In the example data shown below, the mntner object LIR-MNT can authorise the deletion of any of the objects shown, except for the allocation object itself. Although LIR-MNT is not listed directly on all these objects, based on the reclaim functionality business rules, as the legitimate resource holder it has the capability to delete these objects.

Note this functionality only applies to holders of resources issued by the RIPE NCC. So in this example the holder of the sub allocation does not have the authority to delete the end user assignment based on these new business rules. If the data was set up as shown in this example, the end user has exclusive control over the assignment object and reverse delegation. If the sub allocation holder wanted to override this they would need the assistance of the holder of the resource allocated by the RIPE NCC. In this example that is the holder of the ALLOCATED PA resource.

 ALLOCATED PA
inetnum: 10.128.0.0 - 10.128.255.255
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: LIR-MNT
mnt-routes: LIR-RT-MNT


SUB-ALLOCATED PA
inetnum: 10.128.0.0 - 10.128.127.255
mnt-by: SUB-MNT
mnt-lower: SUB-MNT

route: 10.128.0.0 - 10.128.127.255
origin: AS3333
mnt-by: AS3333-MNT


ASSIGNED PA
inetnum: 10.128.1.0 - 10.128.1.255
mnt-by: END-MNT

domain: 1.128.10.in-addr.arpa
mnt-by: END-MNT
 

Objects to be reclaimed

Not all object types can be reclaimed by a resource holder. The following primary object types are covered by this new functionality:

• inetnum
• inet6num
• route
• route6
• domain

For  inetnum and  inet6num object types, all objects more specific to an allocation made by the RIPE NCC are included, regardless of their status.The parent allocation object itself is not included as it is managed by the RIPE NCC. Objects related to PI assignments are included (as described below) but again the PI assignments themselves are not included as they are assigned by RIPE NCC. So it is not possible for a resource holder to accidentally delete their own resource object. Allocated and assigned resource objects can only be deleted by the RIPE NCC.

For  route and  route6 object types, any  route(6) with a prefix exactly matching or more specific to any resource allocated or assigned by the RIPE NCC are included. Multiple  route(6) objects with the same prefix, and different origins, are all included.

Reverse delegation  domain objects, ending with ip6.arpa or in-addr.arpa, with a prefix exactly matching or more specific to any resource allocated or assigned by the RIPE NCC are included. Enum  domain objects are not included.

AS Number objects are not included. These  aut-num objects represent the resources assigned by the RIPE NCC and can only be deleted by the RIPE NCC.

No secondary objects (for example  person and  role ) are included, even if they are directly referenced by any of the primary objects listed above and would be unreferenced after deleting the primary object. If they become unreferenced they will be deleted later by the automated cleanup process.