The five Regional Internet Registries (RIRs) have been offering a hosted RPKI system since 2011. While this is a great solution to manage Route Origin Authorizations (ROAs) for most organizations, some need more flexibility and control. This is where delegated RPKI can be a solution, which APNIC also offers to its Members.
If you’re a member of more than one RIR and you manage IP address space and routes across them, delegated RPKI will allow you to manage ROAs seamlessly and transparently. Instead of having to rely on multiple web interfaces to manage ROAs, you can do it all from one place, running on your own systems.
Alternatively, it can be useful to run delegated RPKI if you want to be able to pass on RPKI management to certain business units or customers. Up to now, organizations were, in many cases, forced to manage everything on their customer’s behalf.
The prospect of running an RPKI Certificate Authority (CA) may leave you with the impression that running delegated RPKI comes with complicated cryptographic operations and expensive hardware such as Hardware Security Modules.
But with the RPKI publication services that APNIC offers and the usability of the latest release of Krill, the open-source RPKI CA software from NLnet Labs, running delegated RPKI has become a viable option for a broad audience. At this time, more than 550 organizations around the world are running delegated RPKI using Krill.
The moving parts
RPKI is a very modular system and so is Krill. Which parts you need to run delegated RPKI and how you fit them together depends on your situation. Before you begin, there are some basic concepts you should understand and some decisions you need to make.
With delegated RPKI there are two fundamental pieces at play. The first part is the Certificate Authority (CA), which takes care of all the cryptographic operations involved in RPKI. Secondly, there is the publication server, which makes your certificate and ROAs available to the world.
In almost all cases you will need to run the CA that Krill provides under a parent CA, usually your RIR or National Internet Registry (NIR). The communication between the parent and the child CA is initiated through the exchange of two XML files, which you need to handle manually: a child request XML and a parent response XML. This involves generating the request file, providing it to your parent, and giving the response file back to your CA.
After this initial exchange has been completed, all subsequent requests and responses are handled by the parent and child CA themselves. This includes the entitlement request and response that determines which resources you receive on your certificate, the certificate request and response, as well as the revoke request and response.
Whether you also run the Krill publication server depends on if you can or want to use one offered by a third party. For the general wellbeing of the RPKI ecosystem, we would always recommend to publish with your parent CA, if available. Setting this up is done in the same way as with the CA: exchanging a publisher request XML and a repository response XML.
Publishing with your parent
If you can use a publication server provided by your parent, the installation and configuration of Krill becomes extremely easy. After the installation has completed, you perform the XML exchange twice and you are done.
Krill is designed to run continuously, but there is no strict uptime requirement for the CA as long as the ROAs it generated are being served to the world. This means you can bring Krill down to perform maintenance or migration, as long as you bring it back up within eight hours to ensure your cryptographic objects are re-signed before they go stale.
At this time, only APNIC and the Brazilian NIR, NIC.br, offer a publication server for their Members. Several other RIRs have this functionality on their roadmap.
This is great news for APNIC Members, because running delegated RPKI now becomes extremely simple. Krill offers an intuitive user interface to set up the exchange with the parent CA and publication server.
Read: APNIC now supports RFC-aligned ‘publish in parent’ self-hosted RPKI
Publishing yourself
If you wish to publish your certificate and ROAs yourself, you will be faced with running a public service with all related responsibilities, such as uptime and DDoS protection.
In this scenario, you install Krill on a separate, highly available machine and simply don’t set up any CA. In addition, you will need to run Rsyncd and a web server of your choice to publish your certificate and ROAs.
System requirements
The system requirements for Krill are quite minimal. The cryptographic operations that need to be performed by the CA have a negligible performance and memory impact on any modern-day machine.
When you publish ROAs yourself using the Krill publication server in combination with Rsyncd and a web server of your choice, you will see traffic from several hundred relying party software tools querying every few minutes. The total amount of traffic is also negligible for any modern-day situation.
For reference, NLnet Labs runs Krill in production and serves ROAs to the world using a 2 CPU / 2GB RAM / 60GB disk virtual machine. Although we only serve four ROAs and our repository size is 16KB, the situation would not be different if we were serving 100 ROAs. We have also run Krill effortlessly on a Raspberry Pi with 2GB RAM.
Krill + APNIC RPKI pub server = RPKI for everyone
The fact that APNIC offers an RPKI publication server for Members running delegated RPKI is a game-changer because in combination with the minimal system requirements of Krill, it makes delegated RPKI available for everyone.
Read: How to: Creating RPKI ROAs in MyAPNIC
Please note that if you are already using the hosted RPKI service provided by APNIC and you would like to switch to delegated RPKI, there is currently no option for this to be enabled automatically within MyAPNIC. Please open a ticket with the APNIC Helpdesk to resolve this and include in your request that you wish to use APNIC’s publication server.
APNIC is able to support hosted, and delegated RPKI at the same time. It’s probably best if this is a transitional state because you will be publishing two sets of assertions over the same addresses from two different CA certificates under the APNIC trust anchor, which confuses some people. But, it is not technically ‘wrong’. This dual delegation helps assure you of some stability during the transitional stages, as no current ROA will be lost.
You can read more about Krill and RPKI technology in the documentation published at rpki.readthedocs.io. You can also follow Krill on Twitter, along with its buddy, the RPKI Relying Party software Routinator 3000.
Alex Band is the Director of Product Development at NLnet Labs.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.