Testing .. 123 Delegated RPKI

By Ximon Eighteen

If you’re one of the many organisations that manage or are considering running your own delegated RPKI CA, NLnet Labs has something new to help you test before going for delegated RPKI for real.

Introducing testbed.rpki.nlnetlabs.nl

NLnet Labs is pleased to announce the launch of an open public RPKI testbed service for testing integration of your RPKI CA in an RPKI hierarchy. Anyone can register an RPKI CA as a child of the NLnet Labs RPKI Testbed and/or publish ROAs to its hosted repository, safely away from the real global RPKI hierarchy.

If you’re not familiar with RPKI or with Krill, learn all about it at Read the Docs.

Nothing new here…

If you hold resources in one or more RIR or NIR regions you may already be able to do something similar in an RPKI test environment via your member portal, so you might be wondering why this is needed.

Unless…

Maybe you don’t have access to the member portal, or to the RIR or NIR RPKI test environment, or for some reason you don’t want to use it, or you want to experiment with publishing resources other than those configured in your account, or you just want to test against another parent CA to double check everything is okay. There can be many reasons why you might want to test somewhere else and/or with different resources.

Why should NLnet Labs operate an RPKI testbed?

The NLnet Labs testbed is not related to any one RIR or NIR but rather permits anyone, without proof of ownership, to claim any resources in the test RPKI hierarchy, and so there’s no barrier to using it.

By lowering the barrier to use and increasing the diversity of options available we hope to increase adoption of and confidence in RPKI thereby contributing to a more secure and robust Internet.

We believe strongly in a healthy ecosystem, part of which is enabling the community to test different client implementations with different server implementations such as the new NLnet Labs RPKI Testbed service.

The testbed also acts as a showcase and proving ground, most importantly for Krill, our free open source RPKI CA and publication server daemon, but also for our one-click Krill in the cloud solution aka Krill Manager, which together power the NLnet Labs RPKI Testbed.

Finally, the testbed may also prove useful in our own testing of Krill without being dependent on access to, and availability and predictable operation of, a test RPKI hierarchy operated by a third party.

Disclaimer

The NLnet Labs RPKI Testbed is NOT intended to be a permanent parent for your CA or permanent repository for your published ROAs. Part of lowering the barrier to adoption of RPKI by making it open and easy to test is that it’s equally easy for anyone, in theory, to unregister your registered CA and/or publisher. We also make no guarantees about persisting your data, this is for testing, not production.

How the NLnet Labs RPKI Testbed works

The NLnet Labs RPKI Testbed works just like a root CA in the real RPKI hierarchy, but separate from and not connected to the real hierarchy.

The manner in which a child CA interacts with a parent CA in the RPKI is governed by Internet standards known as RFCs. One common way to register a child CA or publisher with a parent is via RFC-8183 XML messages. To register a CA with the NLnet Labs RPKI Testbed you must submit such XML messages via HTML web forms.

Once the parent child CA relationship is established and resources are issued to the child CA the child can then create Route Origin Authorizations (ROAs).

To test the effect of these ROAs they must be published in an RPKI repository in such a way that Relying Party software will find them and make them available to their router clients e.g. via the RPKI Router-To-Router (RTR) protocol. The NLnet Labs RPKI Testbed offers a hosted repository for test CAs to publish their ROAs in.

Every RP traverses the RPKI hierarchy by starting at well known roots called Trust Anchor Locators (TALs), usually those of the 5 RIRs. To use an RP with a test RPKI hierarchy such as the NLnet Labs RPKI Testbed the RP must be configured with the TAL of the testbed.

Demo time!

To test RPKI without impacting real Internet routing you’ll need at least an RPKI CA, and optionally an RP to show that ROA publication by your CA is working as expected. If you want to see the effect end-to-end on a router you’ll also need a test router (NOT a router that is participating in global Internet routing!). Note: testing with a router is beyond the scope of this article, we will show how to verify that an RP can retrieve the ROAs and assume that the router and RP software will do their job correctly after that.

Deploying an RPKI CA

To register with the testbed you’ll need to run your own RPKI CA. In late 2019 NLnet Labs launched Krill specifically to make it easy to run your own RPKI CA, and in early 2020 we launched Krill Manager to make it even easier. For this demo we will use Krill via Krill Manager.

Krill Manager isn’t for everyone as it runs in the public cloud and operators understandably want complete control over their own systems and networks. However, even if you wouldn’t want to run Krill in the cloud, Krill Manager can be a very quick and easy way to take Krill for a test drive, and now with the NLnet Labs RPKI Testbed you also have something to test it with!

For this demo you’ll need the right to create records in a DNS subdomain and you’ll need an account with DigitalOcean or Amazon Web Services.

Note: you do NOT need a cloud account to use Krill, this is only required if you wish to use Krill Manager.

Click here or here to get started immediately with Krill Manager in whichever cloud suits you best. Follow the cloud marketplace instructions to launch a Krill Manager virtual machine. The process is very simple as shown in the 6 minute video below. For further guidance consult the Krill Manager manual.

When asked if you want to publish with a 3rd party say YES as we will be publishing into the NLnet Labs RPKI Testbed repository.

Once Krill is deployed you should be able to login by browsing to your chosen domain name and using the token that you chose during installation:

Registering as a publisher

Upon initial login to Krill you are provided immediately with the RFC-8183 <publisher_request...> XML that is needed to register with the NLnet Labs RPKI Testbed repository:

Registering as a publisher with the NLnet Labs RPKI Testbed involves an exchange of XML messages:

1. Copy the <publisher_request...> XML to your clipboard, paste it into the NLnet Labs RPKI Testbed “Register Publisher” form then press the “Register publisher” button.
2. You should now see the RFC-8183 <repository_response...> XML from the testbed. Copy the XML to your clipboard.
3. Paste the <repository_response...> XML into the Krill management UI and press “Confirm”:

That’s it! The Krill management UI should at this point jump to the “Parents” tab reflecting the fact that the publisher relationship has been established.

Registering as a child CA

The process for registering as a child CA is almost the same as registering as a publisher. The RFC-8183 XMLs have slightly different names and you must also choose the resources that should be delegated to the child CA.

1. Copy the <child_request...> XML to your clipboard, paste it into the NLnet Labs RPKI Testbed “Register CA” form, enter the desired resources in the other fields then press the “Register child CA” button.
2. You should now see the RFC-8183 <parent_response...> XML from the testbed. Copy the XML to your clipboard.
3. Paste the <parent_response...> XML into the Krill management UI and press “Confirm”.

That’s it. Your resources should now be visible in the Krill child CA management UI:

Now, any ROAs that you create in your child CA should be published in the NLnet Labs RPKI Testbed repository and thus become visible in its Rsync and RRDP repositories.

Using Routinator to fetch your test ROAs

Before you can fetch ROAs you must first create them. Be sure to add at least one ROA to your child CA before continuing.

To fetch the ROAs using a Relying Party you must first download and configure the RP to use the NLnet Labs RPKI Testbed TAL. In this example we will use the Dockerised release of NLnet Labs Routinator 3000:

First, create a Docker volume to store the TAL file for Routinator to use:
(note: depending on your Docker setup you might need to prefix the following commands with sudo )

$ docker volume create tals

Next, download and store the NLnet Labs RPKI Testbed TAL in the new Docker volume:

$ docker run --rm -v tals:/mnt alpine wget -qO/mnt/krill.tal https://testbed.rpki.nlnetlabs.nl/testbed.tal

Now we are ready to run Routinator and have it walk our test RPKI hierarchy and print the ROAs/VPRs that it finds:

$ docker run --rm -v tals:/home/routinator/.rpki-cache/tals nlnetlabs/routinator vrps
ASN,IP Prefix,Max Length,Trust Anchor
AS1,10.0.0.1/32,32,krill

Notice that we didn’t give Routinator anything more than the testbed TAL, from there it was able to fetch the ROAs that we published!

Behind the clouds

By using Krill Manager to power the NLnet Labs RPKI Testbed we were able to easily deploy the CA and Rsync and RRDP repository services needed. Starting with a single VM we can easily scale out horizontally, integrate with Prometheus and Grafana monitoring instances, and push diagnostic logs to cloud storage for later analysis.

We didn’t have to make anything new to do all of this, Krill Manager already gives us everything we need for the NLnet Labs RPKI Testbed. Maybe Krill Manager could give you everything you need for delegated RPKI too? Deploy it today and register it with the new NLnet Labs RPKI Testbed!

Or if you want to know more about how Krill Manager leverages Docker Swarm and the Gluster replicated filesystem to offer RPKI CA and repository services at scale check out its documentation at Read The Docs.