Running Krill under APNIC

As you may know APNIC offers their members the option of running their own delegated RPKI CA instead of using the APNIC portal RPKI service. Moreover, APNIC also allows their members to make use of the APNIC managed RPKI repository infrastructure for publication of their RPKI objects. The latter is a truly great addition to this service as it reduces the costs and risks of running one's own delegated CA dramatically.

While using APNIC's web interface to manage Route Origin Authorizations (ROAs) is convenient for most, running Delegated RPKI with Krill Certification Authority (CA) software has several advantages:

• You can seamlessly manage multiple organizations in a single Krill instance, even across RIRs.
• You can configure named users with roles and permissions over specific resources and business units, also letting you delegate resources further down.
• Krill's Prometheus endpoint easily integrates monitoring and alerting with your existing tooling.
• And of course, as you will be the only holder of the private key of your resource certificate.

In this post we will explain by example how one can set up Krill under APNIC using these services.

Set up a Krill

The first step is to set up a production Krill instance for your CA. You can of course follow our comprehensive documentation, but if you want to have a look at how we set up our own Krill CA server, with multi-user logins and Let's Encrypt and NGINX for secure access, then please have a look at the section called "Production CA Server with Multi User Access Setup" in this blog post. Note that you can skip the first part about the set up of a Krill Publication Server, because you can (and should) use APNIC's Publication Server instead.

Configure an RPKI CA under APNIC

After installing and configuring the Krill server it's time to create your own new CA instance. In this post we will use a CA called "apnic-demo". It will receive private use IP addresses and AS numbers - since we (NLNet Labs) are not actually a member of APNIC.

In order to run your CA under APNIC you will have to exchange a total of four XML files which are used for the RFC 8183 exchange of identity keys between your CA, the APNIC parent CA and the APNIC Publication Server.

Provided that the RPKI portal is not enabled, you should see the following notice on the MyAPNIC portal:

A todo item to "Set up RPKI" is also shown under the Resource Manager and again under the "Resource certification" section in its "Resources" tab. After clicking the link we enter a set up dialogue, where we choose the option to "host my own certification authority":

After accepting the terms and conditions you will then see an option called "Create new Engine" where you can upload an Identity XML file:

The Identity XML file mentioned above is our Krill CA's RFC 8183 Child Request XML file which can be copied or downloaded under the "Parents" tab:

After uploading our XML file, the APNIC side of the RPKI will be initialised, and four different XML file options will be shown:

You just uploaded the "child request XML" - you won't need it again unless you want to replace your own CA or update its identity key. The latter is possible, but should not be needed.

We will get to the "publisher request" and "repository response" in a moment, but for now download the "parent response" XML file and upload it using the Krill UI.

For the parent name you can choose anything you like. Here we use 'apnic-testbed'. This name will be used to name this parent to users of krill, but it is not used in the actual communication with the parent system:

After adding the parent we still needed to configure the repository. So we downloaded the "Publisher Request" XML from the Repository tab on the Krill UI:

Then upload this "publisher request" XML file in the MyAPNIC portal. You can only do this after successfully submitting the "child request", because the APNIC system insists that the "handle" used in both requests match. As a user you won't need to worry about this in practice, but in case it would be relevant for communications with APNIC support it may help you to know that Krill will simply use your locally chosen CA name for this purpose.

Then download the "repository response" XML, and upload it in the Krill UI:

After uploading this response, Krill will notice that both a parent and a repository have been configured and it will show the ROA page. But usually you will be taken here just before Krill finishes successfully requesting its certificate from the APNIC parent:

The certificate is being requested in the background, but feel free to click the refresh link on the ROAs or Parents tabs. After refreshing you can check the Parents tab for the connection to the parent, and resources received:

On the "Repository" tab you can then see that Krill had publishes a manifest and CRL for the received certificate. No ROAs of course, because you did not configure any just yet:

Now you can start configuring ROAs. Or well, ROA configurations as Krill does not give the user direct control over the ROA RPKI Object as such. Instead Krill's philosophy is that operators declare which announcements should be authorized and then the system will take care of creating and renewing the actual RPKI ROA Objects for each authorization.

Krill uses information from RIS Whois, made available by RIPE NCC, to show operators known announcements to help them configure their ROAs.

In our demo instance's case we would not expect announcments for private prefixes to be shown - but it seems that a small number of RIS Route Collectors did see some announcements for private space:

Pressing "Analyse my ROAs" Krill suggested that we create ROAs for each 'not found' announcement. Note that even though Krill may suggest this, the choice is of course up to you and you should only select the announcements that should be authorized. In our case we were fine with selecting all of the suggestions shown:

After creating these ROAs they show up in our UI, with the status 'SEEN', which means that the announcement is seen in BGP, and it's authorized by at least one of your ROAs:

A thorough discussion on the Krill ROA management and suggestion goes somewhat beyond the scope of this post, but please have a read of our documentation if you want to know more about this.

That's it.. now Krill is running under the APNIC testbed. It will keep checking with the testbed that it's still entitled to the resources it received, an it will keep re-publishing a new manifest and CRL before they would expire. If we would not touch the configuration anymore at all, then it would also re-issue new ROA objects when the time comes. In short.. Krill will just keep doing its work, and all the operator needs to worry about is that it is configured to authorize the correct announcements.