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

HI Tim

Thanks for the review. I have added a few comments below.

cheers
denis

On 11/11/2015 10:41, Tim Bruijnzeels wrote:
> 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.

Someone made a comment about legacy space. Is this now shown in the 
extended delegated stats? Can we determine if it is legacy space and who 
is authoritative for it? Or do we need a separate rule for legacy space 
ROUTE objects?

>
>> 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).

Agreed

>
>> 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).

Agreed with a caveat that as a one of action the authoritative contacts 
should be notified that a ROUTE object exists in the RIPE Database 
relating to their resource. If it was maliciously or accidentally 
created the authoritative registrants may not be aware of it's existence.

>
>> (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

Agreed

>
>> 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

Agreed

>
>
> 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.

 From what I understood from Gert and Randy's comments it is a user's 
choice where to put a ROUTE object and there seem to be some reasons why 
they sometimes choose to put it in the RIPE Database. Is there some 
specific policy now that prohibits ROUTE objects in the RIPE Database 
for AFRINIC resources?

>
> 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
>