Archived Plans

On this page, you can find our plans from previous quarters and requests from the community. We update this page at the end of each quarter.


Q4 2022 Plans and Community Input

Plans
Item Activity Description
1 Support a Red Team security exercise

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.

2 Create multiple parallel internal test environments for RPKI

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.

3

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.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#02

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.

RPKI-2021-#03

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.

RPKI-2021-#04

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.

RPKI-2021-#05

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.


Q3 2022 Plans and Community Input

Plans
Item Activity Description
1 Support a Red Team security exercise

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.

2 Implement "Publish in Parent" RFC 8181 support

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.

3 Create multiple parallel internal test environments for RPKI

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.

4 Improve the internal business logic on certifiable resources

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.

5

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.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

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

 
RPKI-2021-#03

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).

RPKI-2021-#04

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).

 
RPKI-2021-#05

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

 
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.


Q2 2022 Plans and Community Input

Plans
Item Activity Description
1 Support a Red Team security exercise

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.

2 Implement "Publish in Parent" RFC 8181 support

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.

3 Create multiple parallel internal test environments for RPKI

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.

4 Improve the internal business logic on certifiable resources

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.

5

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.

6

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

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#01 Request to add public status page (as referenced during RIPE 82 RPKI presentation) to the RPKI planning.

See item 6 in the table above.

Completed

RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

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

 
RPKI-2021-#03

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

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

See item 2 in the table above.
RPKI-2021-#04

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).

 
RPKI-2021-#05

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

 
RPKI-2021-#06

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

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

 

Q1 2022 Plans and Community Input

Plans
Item Activity Description
1 Support a Red Team security exercise

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.

2 Implement "Publish in Parent" RFC 8181 support

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.

3 Create multiple parallel internal test environments for RPKI

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.

4 Improve the internal business logic on certifiable resources

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.

5

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.

6 Scaling up the RPKI repositories

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.

7

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.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#01 Request to add public status page (as referenced during RIPE 82 RPKI presentation) to the RPKI planning.

See item 7 in the table above.

RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

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

 
RPKI-2021-#03

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

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

See item 2 in the table above.
RPKI-2021-#04

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).

 
RPKI-2021-#05

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

 
RPKI-2021-#06

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

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

 


Q4 2021 Plans and Community Input

Plans
Item Activity Description
1 Implement and publish findings of the penetration test report

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.

2 Implement findings of the source code review and open source the RPKI core

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.

3 New Hardware Security Module (HSM)

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.

4 Scaling up the RPKI repositories

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.

5

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.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#01 Request to add public status page (as referenced during RIPE 82 RPKI presentation) to the RPKI planning. See item 5 in the table above.
RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

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

 
RPKI-2021-#03

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

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

Added to our Q1 2022 planning.
RPKI-2021-#04

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).

 
RPKI-2021-#05

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

 

Q3 2021 Plans and Community Input

Plans
Item Activity Description
1 End of support for the RIPE NCC RPKI Validator

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.

2 SOC 2 Type II audit framework

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.

3 Open sourcing the RPKI core

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.

4 Penetration testing

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.

5

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.

6 New Hardware Security Module (HSM)

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.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#01 Request to add public status page (as referenced during RIPE 82 RPKI presentation) to the RPKI planning. Added to our Q4 2021 planning.

 

Please contact us if you need more information.

Stay up to date!

Follow the #RPKI hashtag on Twitter.