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.
• 6 min read
RIPE Atlas and Routing Information Service (RIS) are highly valued services provided by the RIPE NCC to our members and overall community. Due to the very large amounts of data we collect and store, it is imperative that these services are built on a cost-effective platform, allowing us to provide …
• 4 min read
Over the past few months, the RIPE NCC has been working on enhancing the security of RIPE NCC Access, the Single Sign-On (SSO) system for accessing our key services. In this article, I explain the recent enhancements we've implemented and provide an overview of forthcoming developments you can anti…
• 7 min read
The RIPE NCC's new Chief Technology Officer, Felipe Victolla Silveira, provides an update on our technical services and tools and gives readers a heads up about what they can expect in 2024.
• 6 min read
Our cloud strategy framework provides the principles and requirements for the cloud architecture of the RIPE NCC services. To determine these requirements, it uses the service criticality framework, more specifically its availability component rating.
• 5 min read
We have implemented a temporary feature for any members and other resource holders concerned that they might be forced to transfer their IP addresses to another party due to threats or coercion. This article explains how this feature works, what it does and does not prevent, and who can activate it.
• 6 min read
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.
• 7 min read
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.
• 5 min read
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…
• 11 min read
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…
• 8 min read
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.
“> 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)