On Fri, Jan 03, 2020 at 01:40:41PM -0800, Ronald F. Guilmette wrote:
In message <20200103165918.GL72330@Space.Net>, Gert Doering <gert@space.net> wrote:
On Fri, Jan 03, 2020 at 04:14:07PM +0000, Suresh Ramasubramanian wrote:
So the RIR has absolutely no role in maintaining say IRR data? I agree validating LOAs and such for routing changes would be on providers. Though if the changes were to be made in IRR data who would validate it?
IRR data is authenticated by registry data in RIPE land, if the resource holder chooses so. Short story.
So, nobody can create routes for, say, my address space unless I authorize that.
Yes. Nowadays, the RIPE IRR is better in this respect than any other IRR that I am aware of.
I'd like to offer some additional datapoints, in this context I consider an IRR (either by a RIR or NIR) 'validated' if "route:" objects can only be created with the consent of the then-current resource holder. Current RIRs: * All RPKI ROAs (under all of the five RIRs) are validated * RIPE NCC's "RIPE" IRR source is validated (but "RIPE-NONAUTH" is not). * APNIC's IRR source "APNIC" is 100% validated * AFRINIC's IRR source "AFRINIC" is 100% validated Current NIRs: * NIC.BR's "whois" registry (which contains routing data) is validated * JPNIC (who manage 'JPIRR') validates all route objects on a regular interval There are more NIRs, but not all of them have IRRs, or in some cases the IRR function has been outsourced back to the RIR. Near Future: * LACNIC is working on a "RPKI to IRR" bridge, which will bring a new RIR managed IRR source to the ecosystem, but it will be 100% validated since it is based on RPKI. * ARIN is working on a validated IRR, I myself am involved in this project to help achieve the best possible outcomes. So in short: the RIPE IRR is very good. There are more IRRs like it already today. And the remaining RIR IRRs are moving to a more secure service execution model.
Don't even get me started about RADB! They don't check anything, and there are stale entires in there from 10+ years go for routes to bogons. As far as I can tell, there is zero quality control and zero maintenance, the result being that it has become one big playground for routing crooks.
As mentioned before, third party IRRs - through the IRRd 4 project - are working to address such shortcomings. Ronald as expressed some concern with the pace at which these projects are moving along, but I'm not sure things can be sped up - and I personally appreciate the positive direction in which things seem to be developing. Kind regards, Job