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

Hi All,

On Fri, Nov 06, 2015 at 12:55:40PM +0100, denis wrote:
> I don't claim this will solve all the problems of the universe, but it
> does satisfy an immediate goal to have all ROUTE objects in the RIPE
> Database created with the knowledge and approval of the related
> resource holders. 

Already today, the RIPE database offers very strong guarantee for RIPE
managed IP space. As most in this group know: you cannot, without
approval of the holder of the RIPE managed IP space, create a
route-object in the RIPE database. Any network operator can take
advantage of this characteristic and ignore 'rogue' objects already
today. A possible implementation of this strategy is called "IRR
Lockdown" which I presented about last RIPE meeting. One can wonder why
not many operators have implemented filtering strategies to exploit
the strong guarantees, is this something operators should solve or
should it be forced upon them from the database/data source perspective?
Because of the seeming lack of traction in the operator community for
which we do not know the exact reasons, I urge caution in radical
changes on the database side.

Another generic point I'd like to raise is that this proposal aims
towards _enabling_ foreign route-objects to exist in the RIPE IRR
database, while a lot of thought in the last 12 months has been spend on
... NOT enabling foreign objects in the RIPE IRR, or alternatively
clearly mark those objects as "source: FOREIGN" or an equivalent of
that. (See Nick Hilliard's proposal earlier this year). 

So the working groups needs to think about:

    A - do we want the RIPE IRR to ONLY contain route-objects covering
        space administrated by the RIPE NCC.

    OR

    B - do we want the end-game to be that the RIPE IRR can be host to
        any object from any RIR (and preferably be authenticated in some
        form).

I feel that making a decision on the above choice will help us guide any
subsequent choices.

One example of action taken towards choice A is the "IRR Homing" effort
that was set in motion at the last RIPE meeting. As we speak RIPE and
AfriNIC are jointly working on a project to move all route-objects which
cover AfriNIC space to the AfriNIC IRR and then delete them from the
RIPE database at some point. Part of the proposal (which is under
development) will be to reject creation of route-objects covering
AfriNIC space in the RIPE IRR and guide the user with an error message
to the appropiate RIR. If the AfriNIC IRR Homing is a success, I imagine
that APNIC space is a likely candidate after that. 

In any regard, I think we are in agreement that what's currently in
place with regard to route-objects covering foreign space in the RIPE
IRR can be improved upon.

> And I believe it could be implemented in a relatively short space of
> time giving immediate benefits.

RIPE NCC can comment on implementation timelines, I will not make any
assumptions on their behalf.

I've taken the liberty to summarize your proposed steps to improve
readability of my reply. Hope you don't mind.

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

Can the RIPE Whois software perform a programmatic check that with 100%
certainty will conclude whether space is globally
unassigned/non-allocated? Do all RIRs expose facilities today to do such
a lookup? What about pre-RIR / legacy space? (would especially
appreciate comments from RIPE NCC staff)

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

Are we able to programmatically retrieve email addresses for which we
have a high degree of certainty that they are the actual holders of the
IP space? (again, comments from RIPE NCC staff welcome). 

Intuitively it would appear that RIPE NCC would have to strike a deal
with the other 4 RIRs to be allowed to retrieve those email addresses,
as some RIRs hide / rate-limit email addresses because of abuse/privacy
concerns.

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

What if a registration moves from RIR to another RIR (transfers), or due
to software issues the registration temporary appears to be not there?
Permanently deleting a resource in RIPE IRR because of a transient issue
might be too strong of a reaction.

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

I have trouble overseeing the exact ramifications in doing so. I'd
personally prefer a more lenient mechanism so we are sure to not inflict
far going damage in the routing system, alternative options could be to
"freeze" existing objects covering foreign resources rather then delete
them. The "freeze" wouldn't need to be entirely without mutability:
should people want to change them or delete them, "step 2" could be
invoked.

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

Same comments as for "step 2" apply.

> AUT-NUM copies: delete foreign autnum copies

I am all in favor of a method to get rid of duplicate autnum objects
(duplicate in that they also exist in another RIR's IRR), this aligns
with another concept under discussion in the db-wg community: relaxing
the authorisation rules for foreign objects in such a way that the
duplicate autnum is no longer required to be present in the RIPE IRR.
Again I am hesitant to flat out delete existing information, and prefer
a grandfathering mechanism as described in my response to "step 4".

Denis, thank you bringing this to the group.

Kind regards,

Job