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