You can find our completed plans from previous quarters, along with requests from the community. We are updating this page at the end of each quarter.
Ιtem 1: Open source "rpki-monitoring"
We worked on open-sourcing our internal RPKI monitoring that (1) compares if multiple rsync/rrdp repositories are in sync and (2) if objects are far enough from expiry.
Completed in Q1 2024.
Ιtem 2: New online HSMs
We received new online Hardware Security Modules (HSMs). After the vendor completed the prerequisite work, we worked on migrating to these new HSMs.
Completed in Q1 2024.
Item 3: Support ASPA in Hosted RPKI
Autonomous System Provider Authorization (ASPA) API support was added to the pilot environment in Q4 2022 and was updated to the profile defined in version 16 of draft-ietf-sidrops-aspa-profile in Q4 2023. We plan to extend the RPKI Dashboard with ASPA support after the current work on the RPKI Dashboard improvements has finished.
Completed in Q1 2024.
Item 4: RPKI compliance project (ISAE3000)
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 want 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.
The tailored ISAE3000 control framework for RPKI was designed, and we completed a gap analysis against this framework. We have completed 90% of the relevant documentation, control implementation and evidence gathering for the first certification audit.
We have also engaged with known international audit firms and are planning the execution for the first half of 2024.
Status: In progress
Item 5: RPKI Dashboard improvements
We are working on the RPKI dashboard to improve its usability and make it possible to extend its functionality with new object types. We have performed a user study of the existing dashboard and have started the implementation of the new dashboard.
Status: In progress
Item 1: Implement "Publish in Parent" RFC 8181 support
ARIN and APNIC indicated they would offer this service to Delegated RPKI users. We worked on offering this service, too, as we believe this will help improve the resiliency of the RPKI ecosystem. Organisations which choose to run their own CA have the option to publish their RPKI objects in repositories provided by the RIPE NCC.
This feature was requested by Benno Overeinder in the Routing WG session of RIPE 82 as well as by Job Snijders on the routing-wg mailing list in September 2021. We recorded this request with reference RPKI-2021#03.
Completed in Q1 2023.
Item 2: Create multiple parallel internal test environments for RPKI
The RPKI team used to share one environment used for Quality Assurance. This shared environment led to longer release cycles as we could not independently evaluate multiple features in parallel. We set up multiple independent environments (with one environment per feature where possible). More environments allow us to evaluate features independently and improve our Q&A and release process.
Completed in Q1 2023.
Item 3: rsync repository capability
We were aware of the capacity limitations of our rsync repositories. The rsync repositories are mainly used as a fallback during issues with RRDP. We worked on increasing their capacity and resiliency.
Completed in Q3 2023.
Item 1: Scaling up the RPKI repositories
In preparation for the improved RPKI repository architecture, we implemented the distributed nature of the RRDP repository using containers and krill-sync that pulls data from the centralised on-premise repository. This greatly simplified smooth transitioning between publication servers without any downtime.
NOTE: We are not referring to cloud technologies here; we are simply referring to our internal deployment technologies.
Completed in Q1 2022.
Item 2: Create a public status page
We had been asked at the RIPE 82 presentation on RPKI to create a public status page for RPKI. We recorded this request with reference RPKI-2021#01.
Completed in Q2 2022.
Item 3: Support a Red Team security exercise
We performed a Red Team security exercise for RPKI. A Red Team assessment is an ultimate test by an external party trying to access our systems and data through different means, such as phishing or getting physical access to our data. The exact timeline for this exercise was confidential by nature and was an important step towards improving security for RPKI and the RIPE NCC.
Completed in Q4 2022.
Item 4: Improve the internal business logic on certifiable resources
The registry software dictated whether resources were eligible for certification, and the RPKI software followed the registry software. We have improved the registry software to allow atomic reads of the registry state and supported the registry software team with changes where needed.
Completed in Q3 2022.
Item 5: Pilot ASPA support
Autonomous System Provider Authorization (ASPA) is an active draft (a current proposal) in the IETF sidrops working group. ASPA objects describe the provider relations for an AS number. We will provide input to the discussion by producing some code on a testbed.
Completed in Q4 2022.
Community input RPKI-2021-#06: Move delegated CAs communication (“up-down”) to TLS out of precaution.
For more information, check the Routing WG mailing list archives. After further discussion, a decision has been made not to move ahead with this request.
Item 1: End of support for the RIPE NCC RPKI Validator
On 1 July 2021, we ended providing support for the RIPE NCC RPKI Validator. Our RPKI Validator is one of several Relying Party software that network operators can use to download and validate the global RPKI data set. This data is used to support their BGP decision-making process.
We also migrated the user interface of the rpki-validator.ripe.net from the RIPE NCC RPKI Validator 2 to Routinator.
More information has been shared on RIPE Labs and at our presentation at RIPE 81.
Completed in Q3 2021.
Item 2: SOC 2 Type II audit framework
We designed an RPKI audit framework that allows us to publish a transparent SOC 3 report of our findings. In Q1 2021, we worked with the British Standards Institution to identify missing controls, and we worked towards closing these gaps. We have collected all the evidence to fulfil the controls of the SOC 2 type 2 RPKI framework.
Completed in Q3 2021.
Item 3: Open sourcing the RPKI core
Radically Open Security (ROS) performed a code review of the RPKI Core. The goal of this review was to assess what parts of the code need to be updated before we could open source this code and make it available to the wider community. ROS identified eight issues that were resolved in Q4 2021. You can find more details in the published report.
Item 4: Penetration testing
We have asked ROS to perform a pen test on the LIR Portal, our RPKI Core, RPKI Commons and the RPKI Dashboard. ROS identified nine issues, which were resolved in Q4 2021. You can find more details in the published report.
Item 5: New Hardware Security Module (HSM)
We were using both online and offline HSMs for our Trust Anchor. The offline HSM was at the end-of-life and has been replaced.
Completed in Q4 2021.