Articles
Likes on articles
I am the Chief Technology Officer (CTO) of the RIPE NCC, overseeing IT engineering, DNS, Internet measurement services—including RIPEstat, RIS and Atlas—and software development, which encompasses the RIPE Database, LIR Portal, and RPKI. I joined the RIPE NCC in 2012 as a Software Engineer and have since held various roles within the organization. I hold an MSc in Computer Science.
• 8 min read
The RIPE NCC provides mission critical services to the Internet community which require a solid technical foundation. This article explains how we plan to use cloud infrastructure as a means to that end. We outline some of the risks that must be accounted for, and describe the target architectures …
• 8 min read
With RPKI experiencing a huge growth in its deployment and becoming a key part in the operations of the Internet, we have been investing a significant amount of resources in making its infrastructure resilient, secure, and highly available. Recent outages have raised concerns about the maturity lev…
“> For next year, we aim to scale up our RRDP repository in AWS as well, following the same architecture as Rsync. I know it's been asked before... 😐 This line mentions only AWS for the time being. "Multi-cloud"... any specific single reason to only stick with AWS as the "cloud" solution for redundancy. And not consider other cloud providers as a backup, depending on the local regions where AWAS might not yet be well represented/connected?”
Hi Chriztoffer, thank you for your comment. It is a very important point as indeed we don't want to be dependent on a single provider. We are currently working under the assumption that there will be multiple independent redundant infrastructures, for instance AWS + our current data-centres in Amsterdam. We are in the process of discussing this architecture with our engineering teams and I am planning to report on the agreed solution in a separated Labs article later this year. I will be very happy to hear your input and comments by then.
“I'm glad to see that the DNS root infrastructure is taken as an example of the kind of robustness that RPKI should have. I'm also glad to read that you recognize that "if this trust is broken, the entire system is compromised". However, in this last aspect, a hierarchical PKI will always fail to provide the needed redundancy and fault tolerance, because it's a centralized infrastructure with the root CA as its single point of failure. In other words, in addition to building an infrastructure where the risk of the root CA being compromised or unavailable is extremely low, you should also plan about what to do *when* the root CA will be compromised. If we don't consider that, we're not taking PKI seriously. Let's think about the long term: in the perfect world where everybody has ROAs and everybody does ROV in real time and filters routes for prefixes that are in *unknown* state, what's the plan in case the root CA's keys are compromised or unavailable? Personally, I believe that we should think of ways to move away from this centralized hierarchical model. Delegated RPKIs are a step in the right direction, but do not really remove the SPoF. Cross-signing of ROAs between the five RIRs could be another way to increase the redundancy of the system and avoid "breaking the internet" in case one RIR is compromised.”
Thanks for your comment Marco, you do raise some very important points. A contingency plan in the event our root CA gets compromised is part of the work we are doing in the RPKI resiliency project. Yet the main goal of the project is to prevent this to happen in the first place, we do acknowledge that having such a plan is very important. In the worst case scenario, a TA key-roll would be needed, which would require all RPKI validators to update the RIPE NCC TAL. We believe cross-signing ROAs between RIRs could be a potential solution but would add lots of complexity to the system, which is a threat in itself. However, we fully support using a more decentralised model for RPKI. Krill (developed by NLnet Labs) is a solution for non-hosted CA, and we believe is a good step forward in this direction.
Showing 2 comment(s)