Lifecycle of the RIPE NCC RPKI Validator

In an earlier article of mine, I talked about how we are constantly working on improving all aspects of RPKI at the RIPE NCC. This work includes the software development lifecycle, and in the last six months we took a closer look at all the different elements of the software development lifecycle for the RIPE NCC RPKI Validator. This article shares some important updates and timelines and explains the decisions we made. 

The Past

But first, I would like to take you back a decade. To a time where RPKI was just implemented by the RIRs and the RPKI Validator landscape was quite rural. After a lot of testing and building, we launched the RIPE NCC Validator 2.0 on 13 December 2011.

While there were other Validators out already, ours came with an intuitive web-based interface and a BGP Preview option that allowed operators to see in a UI how BGP announcements would be impacted by Route Origin Validation. Our initial Validator was built in Scala and over time we decided to move to Java as our main programming language. This meant that our RPKI Validator was rewritten and, during the Open Source Working Group at RIPE 76, we announced the beta-release of RPKI Validator 3.0, written in Java.

Version 3.0 was supposed to fix the high memory consumption of the RPKI Validator 2, but we soon discovered that the initial version 3.0 still had very bad performance in terms of memory consumption. After a complete overhaul of the code (see the presentation from Mikhail Puzanov at RIPE 79) we launched version 3.1 in July 2019. 

The Present

An RPKI Validator is a very complex bit of security software and while all RPKI Validators on the market today are Open Source, we don’t receive many pull requests from external contributors. At the moment, we hold around 28% “market share”. We see around 450 active instances of our Validator.

There is currently a lot of work being done in the SIDROPS Working Group on standardising the behaviour of the different Validators, while in other RIRs there are new Trust Anchors added to comply with the AS 0 policies in their respective region.

This means that RPKI Relying Party software developers have to spend significant resources on testing and maintaining their software. At the RIPE NCC, we have decided to strengthen our focus on maintaining a secure, stable and resilient RPKI Certificate Authority instead.

Please note that, at present, we are still actively working on the RIPE NCC RPKI Validator.

The Future 

This brings me to the last, but most important segment of this article - the future of the RIPE NCC RPKI Validator. We have had many internal discussions, during which we of course took into account opinions expressed by our members and the wider community. Based on this, we have decided to stop active development of our RPKI Validator in due time. Taking into account potential annual end-of-year leave and network freezes operators might face, we decided on the following timeline:

• 1 January 2021: Stop accepting and building new features
• 1 March 2021: Stop implementing new RFCs and RIR policies
• 1 July 2021: Stop overall maintenance and archive the RIPE NCC RPKI Validator

Of course we will continue to implement security fixes until 1 July 2021.

We realise we have to do a lot of outreach to our users, helping them point to alternatives. And we'll also be updating our training material. By following this timeline, we aim to provide a smooth transition and we are confident there are good alternatives on the market today.

I'll also present this decision in the Open Source Working Group at RIPE 81, and if you have any comments or questions I’ll gladly answer them there.