[routing-wg] Routing Reg. mess [was: Re: [anti-abuse-wg] Fwd: Hijack...]

Dear colleagues,

A few observations:

- RIPE NCC has operated RIPE IRR as an open IRR based on community requirements for years. In my opinion, a very productive first step towards better data quality and maintenance of RIPE IRR is for the community to provide RIPE NCC with an operations policy for RIPE IRR.
At the moment there is no policy governing RIPE IRR, so even in case of clearly fraudulent route objects -specially for resources outside of RIPE Region- RIPE NCC has no guidance on how to proceed and the records ultimately stay there. Having some policy, no matter how lightweight it is, will have great effect on improving things. 
This was brought up in Routing-WG session in London and echoed in RIPE Database-WG as well and I strongly suggest the community to take action in that regard. Here at RIPE NCC we are keen to provide any help required in that regard.

- Now, into the issue of open IRRs. For RIPE Region resources, the process has enough clarity and there is authentication/authorisation in place. Although that can be improved -as it was suggested by RIPE NCC and a few members on different occasions- the data quality for out of the region objects are much lower and there is basically no auth. present. Current model, as it has always been, is a first-come first-served model where you can basically register any out of region resources in the public IRR and the objects will stay there, locking others who might want to change things.

- 4 out of 5 RIRs run IRRs. A simple solution would be to limit each IRR to RIR’s managed resources. However this solution has a few flaws and might have a negative impact:

	* Many operators only look into RIPE IRR and/or RADb and ask their users to register their routes in one of these databases before they can serve them, no matter in which region they are located. This might not be the best practice but it is the reality. Looking at IRR query load, RIPE Database IRR by far surpasses other RIRs routing databases. This means, restricting RIPE IRR might have a negative effect on documentation of routing data: I expect instead of changing process, operators might drop the requirement.

	* In many cases the ASN comes from one region and IP Prefix comes from another. Requirement from some IRRs (including RIPE’s) to include auth. for both ASN and IP Prefix only makes things more complex, specially if there are more restrictions.

	* Routes for many early registration and legacy resources from different regions are only documented in RIPE IRR. This includes critical information like route objects for most of Root DNS operators.

These points should be considered when thinking about a solution.

- The idea of having a single repository has been brought up a few times. Although it might be possible (very complex though, specially for users, because of different policies of each region) I personally don’t see the benefit in that. RIPE Database for example, already has a complete and consistent view of global registration and routing data, presented as GRS. So, if a user desires, they can query only RIPE database to get information about any resources. New technologies like RDAP (which is implemented by all RIRs) also address this issue as a user can query any RIR registry and get information in a single, well defined format.

- There are many technical possibilities to improve things and we have many smart people in our community who have already proposed solutions to fix issues. One thing to keep in mind is most of these solutions are transitional solutions and each of them can incrementally improve things. It is possible to interlink RIR auth. systems, it is possible to interlink RPKI and IRR, it is possible to mark resources with an auth. quality indicator, etc. The main question then becomes effectiveness, as almost all IRR data users with automated processes rely on IRRtoolset which doesn’t consider any of this new changes or many of documented RPSL features. So, solutions should either rely on improving quality of inserted data AND consider the enduser toolset capabilities and improvements.

Have a nice weekend,
Kaveh.

---
Kaveh Ranjbar,
Chief Information Officer, RIPE NCC.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.ripe.net/ripe/mail/archives/routing-wg/attachments/20141114/40b91c9b/attachment.sig>