Validating RPKI Validators

Editor's note: Please also see the results of the first RPKI Deployathon organised by the RIPE NCC and this report published by the Network Startup Resource Center (NSRC) about the RPKI Deployathon at APRICOT 2020.

Last year I attended an APNIC workshop on how to deploy the Resource Public Key Infrastructure (RPKI).

Although it provided me with a really solid grounding about the technology, I still had some lingering questions that needed answering before deploying it in our network, specifically surrounding the use of RPKI validators. This is why I signed up to attend the RPKI Deployathon at APRICOT 2020.

In this post, I will share my experience with RPKI and maybe where there could be some improvements from my perspective.

As a note, I’ve used my EVE-NG environment as the testbed for the examples in this blog post. It is worth noting that I am not biased towards any validator and the words and thoughts in this blog are my own. I’m running EVE-NG PRO with 24Gb RAM on an Intel Corei7 CPU.

Testing the validators and routers

During the labs component of the deployathon, we installed the following four validators and used these in our lab set up, running on Ubuntu18 Desktop images as well, as seen on the left hand of the topology (Figure 1):

• RIPE NCC’s RPKI Validator 3 & RTR Server bundle
• Cloudflare’s OctoRPKI & GoRTR bundle
• NLnetLabs’ Routinator 3000
• LACNIC and NIC.MX’s FORT Validator

On the right you see that I am using four routers from three vendors:

• Juniper vMX 14.1
• Cisco XRv 5.3.0
• Cisco IOS-XE 16.03.02
• The VyOS Project’s VyOS 1.3

While installing the validators I made some notes on points that I thought were awesome. I’ve installed all but Routinator 300 using the deb packages.

• Routinator was by far the simplest to install and hit the ground running. The documentation and installation instructions were straightforward, and the package was small enough. It was great that I didn’t have to download the ARIN Trust Anchor Locator (TAL) separately; I could just include the ‘–accept-arin-rpa’ argument.

• RIPE NCC RPKI Validator 3 wasn’t too much of a hassle either. I recall that we used Ubuntu 16 server images during the deployathon and those proved to have had some issues with certain packages not upgradable and were really a hassle; this was one of the reasons I opted for Ubuntu 18 from the start. Using the deb packages made it super easy and straight forward. We had some documentation discrepancies around finding the best and most correct information during the deployathon, but it seems to be addressed now if I look at the installation.

• OctoRPKI and GoRTR was easy as well. Using Ubuntu I had to go and figure out where the files were installed as you have to point it to certain folders with arguments or start the daemon whilst inside a specific folder to make it work. The one problem I found was that OctoRPKI and GoRTR both want to start a daemon process on the same port, which is a bit silly and therefore I have to start the daemon by setting the ‘–metrics.addr’ argument to another port just so that it starts up. Perhaps the intention wasn’t to have both daemons on the same server….who knows?

• FORT installation was easy but I found it seems to be very sensitive with the wrong date and time configured on the host. Whilst the daemon started, it seemed to have had a lot of complaints in the logs and the routers didn’t get any updates about prefixes at all. When I changed the time zone on the host and restarted the daemon, then it seemed to be happier and fewer errors were sent out to the logs. 

With the four validators up and running using the default config (apart from changing the localhost variables and ports) I went about configuring RPKI validation on the routers, which, as expected, went through without issue.

It is worth mentioning that the Cisco and Juniper routers happily accepted all four validator prefixes while VyOS seems to prefer only one validator active at a time.

Within a short time, all four routers synced up with the validators and, strangely enough, they reported different ROA counts:

• Routinator and RIPE NCC reported the same number of ROAs. At the time of checking this was 114,961/19,307
• OctoRPKI had ~1,200 fewer ROAs than the first two at 113,756/18,807
• FORT had one fewer ROAs than the first two at 114,959/19,306

Below are some screenshots of my configurations and outputs.

Figure 2: Cisco and Juniper shows the same ROAs

Figure 3: VyOS output

Armed with this information and proof of concept in my little lab environment, I’m happy to say that we at AS17473 will be using Routinator and OctoRPKI+GoRTR to drop invalids at the borders of our network.

Drikus Brits loves playing around with IoT, Python, and is a Cisco and Juniper fundi, chicory instant coffee lover and father of two boys.

This article was originally published on the APNIC blog.