Defining the Criticality of RIPE NCC Services
We’ve been brainstorming on a process to determine the criticality level of our services, and we’d now like to ask the community for input on how we should approach this effort moving forward.
Felipe Victolla Silveira
7
Articles
214
Likes on articles
I am the Chief Operations Officer of the RIPE NCC, responsible for the registry, member-related services and software development, including the RIPE Database, LIR Portal, and RPKI. I have joined the RIPE NCC in 2012 as a Software Engineer, and since then have worked in different roles across the organisation. I have a MSc in Computer Science.
RIPE NCC Cloud Strategy Framework
Our cloud strategy framework provides a starting point that we will use when developing cloud implementations in the future. It also forms a solid basis for discussions with the community on specific proposals relating to our services.
Using Third Parties to Automate Our Due Diligence
For the past year, we've been improving our due diligence procedures. Performing all of the necessary checks is complex work, and there’s a lot of it. For this reason, we'll be using trusted third-party expertise and automation in two key areas: sanctions screening and the validation of identificat…
RIPE NCC and the Cloud: Draft Principles, Requirements and Strategy Framework
Our draft cloud strategy framework is an attempt to bring everything together in a way that sets out some boundaries, identifies critical elements, and indicates where we need to be strict vs where we can afford to be a little more relaxed. This should hopefully support more clarity regarding how w…
RIPE NCC and the Cloud: Let’s Start Again
The community’s reaction to our cloud proposal at RIPE 82 was stronger than we expected. We think it’s worth re-starting this discussion, and the first step is to check that we’ve heard you correctly.
RPKI Repositories and the RIPE Database in the Cloud
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 …
RPKI: Past, Present and Future
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…
Showing 7 article(s)
“> 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)