Re: [db-wg] IRRd re-write
Colleagues My suggestion about the IRR(s) yesterday didn't seem to go down too well, so I will try again. I will start with a question. Why do people believe that having many, many independent/commercial IRRs, mostly containing unverified operational data and lots of personal data, where they all have to be mirrored to access the full data set is preferable to having multiple instances of a single data set containing fully verified and trusted operational data and no personal data? I agree it is always good to re-write old, unmanageable code. But without a cross registry authorisation link to all 5 RIRs number registries, the new IRRd is the same product. The data in all these third party IRRs using the new IRRd is still unverified. You are correct Job that I have zero experience of operating networks or generating anything to do with BGP. My understanding is that is what you do using the data you take out of an IRR database. I am only thinking about the structure and management of a public database containing high quality, trusted data for global resources, not what you do with that data. This is something I do have decades of experience of. cheers denis co-chair DB-WG
Re: [db-wg] IRRd re-write
please note that the rirs are a small minority of the irr instances. i do not have time to deal with putting more lipstick on the poor pig. randy
Re: [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 +, 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 >
Re: [db-wg] IRRd re-write
On Mon, Jun 18, 2018 at 12:43:22PM +, denis walker via db-wg wrote: 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? A single IRR is a single point of failure and a single point of attack. Much preferrable would be if all IRRs mirrored the authorisation data from all other (RIR?) IRRs. Am I correct in thinking that this is now done for RPKI data in order to address the SPOF problem? rgds, Sascha Luck
[db-wg] IRRd re-write
Colleagues 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
