Every user of the RPKI system – whether they’re on the signing side, the validating side, or both – deserves to safely rely on our systems and must be able to trust that the data we publish is accurate and accessible.
In the global RPKI system, the five Regional Internet Registries serve as a Trust Anchor. This means that each of the RIRs have a self-signed root certificate. Below the root certificate, there are multiple layers of child certificates, for example from our members. These certificates, and all other RPKI objects are visible in a repository. This comes with a big responsibility for the RIRs. Users must be able to trust that our systems are safe, resilient and accurate.
At RIPE NCC, we are spending significant resources to ensure this trust and resiliency. After all, more and more operators rely on the RPKI system for their Internet routing.
In 2019 we started our “RPKI resiliency” project that included a variety of security assessments, implementation of thorough internal and external monitoring and scaling up our repositories to improve the availability.
In this process we learned that trust is built by being transparent and reliable. One of the things we started to do is to publish all our security and compliance reports on our website: https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/security-and-compliance This allows us to show our users what kind of assessments we do, who performed our assessment and which actions we took to mitigate the issues that were found.
One lesson that we learned is that we needed to improve our unit- and integration tests. This resulted in a dedicated QA engineer in the RPKI team.
We also believe in Open Source. When users can look at your code base, and see how the system works, it allows for a better understanding and improves trust. Different elements of our RPKI system have been published as Open Source for many years, last year we added our RPKI core and Trust Anchor software to GitHub. https://github.com/RIPE-NCC
We have received very positive comments from the community, and we will present on this process during the RIPE meeting in May.
In order to keep the RPKI community informed of our priorities, we publish a quarterly roadmap. This roadmap is open for feedback and we take into account any feature requests that we receive. With this effort, we hope to provide more clarity on the time lines of our projects.
Taking Compliance to the next level
One of the things we have to constantly ask ourselves is: Is what we are doing the right way of doing it? And is our Trust Anchor and Certificate Authority secure? What needs to improve and to what extent?
There are hundreds of audit frameworks out there, but none of them are an exact fit for RPKI. We needed a well-recognised audit framework that both encompasses all important IT security elements and can be tailored towards the design principals and RFCs of RPKI. For this purpose, we’ve chosen to team up with The British Standards Institution to develop an RPKI audit framework that can potentially also be used by other Trust Anchors.
This is now an ISAE3000/SOC 2 Type II audit framework. In 2021 we identified the controls and BSI performed a gap analysis.
We are now in the process of gathering evidence for our audit. In 2022, we will first start with an assessment of the framework by a third party.
Because ISAE3000/SOC 2 Type II frameworks are free-form by nature, we want to assure that we have the right controls and evidence in place.
Of course, we will keep the community informed of the process and outcome of this assessment.
Of Key Importance
The “K” in RPKI stands for “Key”. In our hosted RPKI system, we store the public and private keys for our members on our platform. Also, we must make sure that our own private key stays private. For the keys, we use multiple Hardware Security Modules. These HSMs must be of the highest quality and standards. Last year, we replaced our off-line HSMs, these HSMs store the private key of the Trust Anchor. We will soon publish a RIPE Labs article on how we handled this migration. Later this year, we will replace our on-line HSMs. This will be an even more challenging migration, as this involves all our member keys that use our hosted RPKI platform.
The RPKI Publication Service
When users prefer to host their own CA, they currently are automatically also responsible to publish their own RPKI objects. This is the current “Delegated RPKI” model. However, in practice, we see that these users often don’t have the capacity to facilitate highly available publication points. In the last year, APNIC and ARIN already released their publication service for users who want to operate their own CA. This year, RIPE NCC will also make this service available through our RPKI Dashboard.
And there is more….
In 2022, our focus continues to be on the resiliency and security of the RPKI system. Of course, we will have another penetration test on our software and we have also signed an agreement with a third party to have a Red Team test performed. We keep improving our RRDP and rsync publication infrastructure and we will improve our monitoring and alerting. These things never stop. But we also want to improve our RPKI dashboard in the future, by adding other RPKI objects that become standardized in the IETF and route/route6 functionality.
Together with the other RIRs, we promise that we will maintain a secure and resilient RPKI Trust Anchor.
