Archived Plans

Work started in Q1 2022 and was completed in Q1 2023.

Currently, the RPKI team shares one environment used for Quality Assurance. This shared environment leads to longer release cycles as we can not independently evaluate multiple features in parallel. We will set up multiple independent environments (with one environment per feature if possible). Having more environments available will allow us to evaluate features independently and improve our Q&A and release process.

Request to implement "Publish in Parent" RFC 8181 support.

Work started in Q1 2022 and was completed in Q1 2023.

ARIN and APNIC have already indicated that they would offer this service to Delegated RPKI users. We are now working on offering this service too. Organisations that choose to run their own CA will have the option to publish their RPKI objects in repositories provided by the RIPE NCC. We believe this will help improve the resiliency of the RPKI ecosystem.

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 are currently doing an "open beta trial", and the full launch will be in mid-January 2023.

We have marked this with reference RPKI-2021-#3 in the table below

RPKI compliance project (ISAE3000)

Work started in Q1 2023.

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.

We are now in the process of gathering evidence for our audit. In 2023, 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 ensure that we have the right controls and evidence in place.

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

We are investigating possibilities here and add a reaction when ready.

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

Completed

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

We are investigating possibilities here and add a reaction when ready.

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

We are waiting for an internal SSO project to be completed, and we will add a reaction when ready.

Work started in Q1 2022 and was completed in Q4 2022.

In 2022, we will perform 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 is confidential by nature, but this is an important step towards improving security for RPKI and the RIPE NCC.

Work started in Q1 2022.

Currently, the RPKI team shares one environment used for Quality Assurance. This shared environment leads to longer release cycles as we can not independently evaluate multiple features in parallel. We will set up multiple independent environments (with one environment per feature if possible). Having more environments available will allow us to evaluate features independently and improve our Q&A and release process.

Pilot ASPA support

Work started in Q1 2022 and was completed in Q4 2022.

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.

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

We are investigating possibilities here and add a reaction when ready.

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

The activity was on hold and will launch in mid-January 2023.

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

We are investigating possibilities here and add a reaction when ready.

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

We are waiting for an internal SSO project to be completed, and we will add a reaction when ready.

Work started in Q1 2022.

In 2022, we will perform 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 is confidential by nature, but this is an important step towards improving security for RPKI and the RIPE NCC.

Work started in Q1 2022 and was placed on due to pending approval of new terms and conditions and further technical work.

ARIN and APNIC have already indicated that they would offer this service to Delegated RPKI users. We are now working on offering this service too. Organisations that choose to run their own CA will have the option to publish their RPKI objects in repositories provided by the RIPE NCC. We believe this will help improve the resiliency of the RPKI ecosystem.

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 have marked this with reference RPKI-2021-#3 in the table below.

Work started in Q1 2022.

Currently, the RPKI team shares one environment used for Quality Assurance. This shared environment leads to longer release cycles as we can not independently evaluate multiple features in parallel. We will set up multiple independent environments (with one environment per feature if possible). Having more environments available will allow us to evaluate features independently and improve our Q&A and release process.

Work started in Q1 2022.

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 registry state and will support the registry software team with changes where needed.

Pilot ASPA support

Work started in Q1 2022.

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.

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

Currently on hold due to pending approval of new terms and conditions and further technical work (item 2 above).

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

Move delegated CAs communication (“up-down”) to TLS out of precaution.

For more information, check the Routing WG mailing list archives.

Work started in Q1 2022.

In 2022, we will perform 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 is confidential by nature, but this is an important step towards improving security for RPKI and the RIPE NCC.

Work started in Q1 2022 and was placed on due to pending approval of new terms and conditions and further technical work.

ARIN and APNIC have already indicated that they would offer this service to Delegated RPKI users. We are now working on offering this service too. Organisations that choose to run their own CA will have the option to publish their RPKI objects in repositories provided by the RIPE NCC. We believe this will help improve the resiliency of the RPKI ecosystem.

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 have marked this with reference RPKI-2021-#3 in the table below.

Work started in Q1 2022.

Currently, the RPKI team shares one environment used for Quality Assurance. This shared environment leads to longer release cycles as we can not independently evaluate multiple features in parallel. We will set up multiple independent environments (with one environment per feature if possible). Having more environments available will allow us to evaluate features independently and improve our Q&A and release process.

Work started in Q1 2022.

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 registry state and will support the registry software team with changes where needed.

Pilot ASPA support

Work started in Q1 2022.

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.

Create a public status page

Work started in Q3 2021.

We have been asked at the RIPE 82 presentation on RPKI to create a public status page for RPKI.

The page has been published and is available at:

https://status.ripe.net

See item 6 in the table above.

Completed

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

Move delegated CAs communication (“up-down”) to TLS out of precaution.

For more information, check the Routing WG mailing list archives.

Work started in Q1 2022.

In 2022, we will perform 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 is confidential by nature, but this is an important step towards improving security for RPKI and the RIPE NCC.

Work started in Q1 2022.

ARIN and APNIC have already indicated that they would offer this service to Delegated RPKI users. We are now working on offering this service too. Organisations which choose to run their own CA will have the option to publish their RPKI objects in repositories provided by the RIPE NCC. We believe this will help improve the resiliency of the RPKI ecosystem.

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 have marked this with reference RPKI-2021-#3 in the table below.

Work started in Q1 2022.

Currently, the RPKI team shares one environment used for Quality Assurance. This shared environment leads to longer release cycles as we can not independently evaluate multiple features in parallel. We will set up multiple independent environments (with one environment per feature if possible). Having more environments available will allow us to evaluate features independently and improve our Q&A and release process.

Work started in Q1 2022.

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 registry state and will support the registry software team with changes where needed.

Pilot ASPA support

Work started in Q1 2022.

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.

Work was completed in Q1 2022.

As part of our improvements to the RPKI repository infrastructure, the RRDP publication server will be deployed on-premise. This greatly simplifies transitioning between instances of the publication server without any
downtime. The infrastructure is now in place, but we still need to finalise some
technical work to serve the data hosted on premise.

Note: We are not referring to cloud technologies here, just to our internal
deployment technologies.

Create a public status page

Work was completed in Q2 2022.

We have been asked at the RIPE 82 presentation on RPKI to create a public status page for RPKI.

See item 7 in the table above.

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

Move delegated CAs communication (“up-down”) to TLS out of precaution.

For more information, check the Routing WG mailing list archives.

Work was completed in Q4 2021.

Radically Open Security (ROS) performed a penetration test of the LIR Portal and the RPKI infrastructure. ROS identified nine issues which we resolved in Q4 2021.

You can find more details in the published report.

Work was completed in Q4 2021.

Radically Open Security (ROS) performed a source code review in preparation to open source the RPKI core. The goal of this review was to assess what parts of the code needed 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.

Work took place from Q3 2021 until Q4 2021.

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.

Work took place from Q3 2021 until Q1 2022.

As part of our improvements to the RPKI repository infrastructure, the RRDP publication server will be deployed on-premise. This greatly simplifies transitioning between instances of the publication server without any downtime. The infrastructure is now in place, but we still need to finalise some technical work to serve the data hosted on premise.

Note: We are not referring to cloud technologies here, just to our internal deployment technologies.

Create a public status page

Work was completed in Q2 2022.

We had been asked at the RIPE 82 presentation on RPKI to create a public status page for RPKI.

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

Work was completed in Q3 2021.

On 1 July 2021, we ended offering 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.

Work was completed in Q3 2021.

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 fulfill the controls of the SOC 2 type 2 RPKI framework. The audit will take place in Q2 2022.

Work was completed in Q3 2021.

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 can Open Source this code, and make it available to the wider community.

The report was delivered on 19 July 2021.

Work was completed in Q3 2021.

We have asked ROS to perform a pen test on our RPKI Core, RPKI Commons and the RPKI Dashboard.

The report was delivered on 26 July 2021.

Scaling up the RPKI repositories

Work took place from Q3 2021 until Q1 2022.

In preparation for the improved RPKI repository architecture, the distributed nature of the RRDP repository is going to be implemented using containers and krill-sync that pulls data from the centralised on-premise repository. This greatly simplifies smooth transitioning between publication servers without any downtime.

NOTE: We are not referring to cloud technologies here, just to our internal deployment technologies.

Work took place from Q3 2021 until Q4 2021.

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.