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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
