[db-wg] IRRd re-write

Denis,

I am very surprised by your statements. To be honest your email seems
quite detached from reality so it is somewhat hard to formulate a
coherent response.

I'll try to explain this as simple as possible: the users of IRRd (you
clearly are not one of them) have come to realise that the 20-ish year
old codebase (https://github.com/irrdnet/irrd) is no longer meeting
today's requirements in terms of maintainability and extendability. To
address this concern a full rewrite is underway (https://github.com/irrdnet/irrd4).
In the spirit of the original IRRd, this is work is open source and
published under a very liberal license, you're welcome!

Statements such as "This is being done without the decades of
experience, knowledge and understanding that has gone into developing
the RIPE Database software on which all 4 IRRs are based that are
operated by the RIRs." are not only false but also insulting and
discouraging. It actually may be you who lacks decades of experience on
how to operate a network and generate high quality BGP filters and what
the role of IRRd instances are.

I had the feeling that some people in this working group thought that
the third party IRRs are making zero attempt to increase the security of
their offering, so I hoped to illustate that people actually are putting
thought, money, and time into improving that situation.

This IRRd rewrite will ultimately result in the possiblity for operators
of "third party" IRRs to provide more secure, higher quality services.

Kind regards,

Job

On Mon, Jun 18, 2018 at 12:43:22PM +0000, denis walker via db-wg wrote:
> During the current discussion on out-of-region ROUTE objects, Job
> announced that IRRd is being re-written and will have some
> 'potentially' fantastic features including 'possibly' authentication
> against the RIRs number registries. The alternative/commercial IRRs
> have also been heavily promoted at many points in this discussion as
> 'the answer' to the current problems. I personally, and some others,
> have some issues with this. So I thought it appropriate to open a
> discussion on this issue as it does impact on, or is influenced by,
> the operation of the RIPE Database.
>
> Firstly it is unfortunate that all the RIRs that operate an IRR may
> not be in a position to accomodate all routing requirements that are
> currently provided for by the designed security hole in the RIPE
> Database at the time this security hole will be closed. To push
> operators to switch to commercial services as the answer simply
> monetarises routing which, as Randy pointed out, may affect smaller
> operators more, as perhaps the IPv4 market has done.
> 
> I looked at the github details of this new IRRd. I get the feeling
> that this is simply trying to re-invent the RIPE Database software in
> yet another language. This is being done without the decades of
> experience, knowledge and understanding that has gone into developing
> the RIPE Database software on which all 4 IRRs are based that are
> operated by the RIRs.
> 
> Job also pointed out that "One of the possible (and desired)
> extensions is an authorisation link to the authoritative RIR." This
> suggests some form of cross registry authorisation with/between the
> RIRs. During the years of debate about these out of region ROUTE
> objects this has been discussed and virtually dismissed on several
> occasions.
> 
> If the RIRs, and certainly the RIPE NCC, are going to devote time,
> effort and members money to develop some form of authorisation system
> for a remote IRR to connect to each of the 5 RIR number registries to
> authorise ROUTE creation, then I personally would prefer to see the
> development of a single, global IRR operated by the RIRs. This cross
> registry authorisation is probably the main element of having a single
> IRR.
> 
> Currently 4 of the 5 RIRs operate an IRR and they are all based on a
> version of the RIPE Database software. So we already have a common IRR
> database format. Add in this cross registry authorisation and we have
> a global IRR. I don't see the point of putting in the effort to
> develop a multitude of alternative/commercial IRRs when we can go the
> other way and have a single, authoritative, free IRR service. We have
> one internet, one DNS, why not one IRR?
> 
> I know the first comment is probably going to be, "we already have
> this with RPKI". But for whatever reason, not all operators use, or
> want to use, RPKI. That is a reality, just as much as everyone
> switching to IPv6...not. Since RPKI is not the complete answer, we
> still need an IRR where the ROUTE objects are validated and trusted. I
> think the RIRs are in the best position to each develop a trusted IRR
> linked to their own number registry, then take the leap to create a
> single IRR. I personally think this is the better way to go than
> develop secure authorisation modules for IRRd.
> 
> cheers denis co-chair DB-WG
>