[db-wg] [routing-wg] Solving the issue of rogue ROUTE objects in the RIPE Database

Dear working groups,

At RIPE 70 the RIPE Database Working group asked the RIPE NCC to work together with Afrinic on an implementation proposal to migrate Afrinic route(6) objects to the new Afrinic IRR as part of the IRR Homing project. We are planning to present a proposal at the Database Working Group session at RIPE 71.

Initially we will focus on the clear cases where Afrinic is the RIR for both the inet(6)num and aut-num (roughly 34k object). In the meantime we are also seeking technical alignment with Afrinic and the other RIRs on how cross-RIR authorisation for route(6) objects can be improved, so that we can also put forward an implementation plan for the remaining objects (e.g. roughly 6k objects with an Afrinic inetnum and RIPE aut-num).

Experience with the migration of Afrinic route objects can serve as a basis to similar migrations in the future. And while the RIPE NCC and RIPE working groups cannot set the priorities for other RIRs, they are following these developments with interest.

All that said it is clear that the current situation is problematic and an intermediate solution may be desired. In general the RIPE NCC also likes the proposal for this put forward by Denis. But we have some comments, much in line with comments made by Job. We would propose the following:

> STEP 1: reject creation of route-objects if they cover foreign non-allocated / non-assigned space

This should be doable. The past few years the RIRs have been working hard on cleaning up overlaps, and therefore we can now be certain which RIR is authoritative for which resources and check this programatically.

> STEP 2: email confirmation link to admin-c/tech-c equivalent as listed in the foreign RIR database to confirm creation of the route-object in RIPE's IRR database.

Indeed as Job pointed out we may have to make a special arrangement with other RIRs, but we are confident that we can work with them on this.

> STEP 3: continiously check if the block is allocated in the foreign RIR database, if no longer, delete the route-object from RIPE's IRR db.

We share concerns raised by Job. We believe this adds a lot of complexity to the implementation, and introduces an unacceptable risk of deleting the wrong objects. Furthermore we believe that this step is not necessary if we implement step 5 (below).

> STEP 4: one-off cleanup: confirm with all out-of-region objects whether the object belongs in RIPE IRR db or not, if no confirmation is received: delete the object.

We would also echo the concerns raised by Job. And similar concerns with complexity and risk apply as with step 3. Furthermore we believe that this step is not necessary if we implement step 5 (below).

> (Possible) STEP 5: confirm with admin-c/tech-c equivalent as listed in the foreign database when a 'delete' request is received.

If we implement this, step 3 and 4 are not needed. Rather than trying to determine automatically if an object is still valid - and risking getting it wrong, this leaves both the empowerment and responsibility to maintain this data with the current resource holders.

We would propose that out-of-region resource holders can delete route(6) objects in the RIPE Database in a two step process:
1) try to delete the object without authorisation
     - We can detect that it's an out-of-region object and send a link to the holder similar to step 2
2) the holder can click the confirmation link

> AUT-NUM copies: delete foreign autnum copies

From our perspective we agree that we do not technically need foreign aut-num objects if we have a different authorisation model, and it would be better if such duplicates did not exist.

As for the clean-up we could:
= disallow new out-of-region aut-num objects
= warn (email) respective holders in the authoritative database
= and delete them as a later step


So, with the caveat about automated deletion of objects that we do have concerns with, we think we could implement the above as an intermediate solution. We would also like to point out that we can build on this step by step. E.g. we can start disallowing route objects for Afrinic resources and direct people to the Afrinic IRR, while still applying the above strategy for resources from other regions.

It will obviously require work. Very rough initial estimates indicate it can take up to a few months. We can refine these estimates if and when we have a clear consensus on a go-ahead.


Kind regards,

Tim Bruijnzeels
Assistant Manager Software Engineering
RIPE NCC Database Group