Since the release of the Resource Public Key Infrastructure (RPKI) service, APNIC has supported the provisioning protocol service, so that APNIC account holders can operate self-hosted RPKI systems.
This service is outlined in RFC 6492, which defines a process that an authorized client can use to request a resource certificate from an RPKI Certificate Authority (CA). Currently, four National Internet Registries (NIRs) in the APNIC region operate RPKI in this way: JPNIC, CNNIC, TWNIC and IDNIC. Each of these NIRs operates a self-hosted engine, and publishes RPKI products using services that they operate and maintain themselves.
Learn more about Resource Public Key Infrastructure
This RFC 6492 service is how APNIC passes certificates and requests for certificates between the CA systems in a secure manner. It is fundamental to the signing process of the X509 Public Key Infrastructure (PKI) for resources. But, it is not the only protocol APNIC uses in RPKI.
What about RPKI publication?
As well as provisioning, there is also publication, which is about making signed objects available to relying parties. While self-hosted clients can publish RPKI products themselves, as the NIRs do, this makes the burden of running a self-hosted engine quite considerable, since it involves operating and maintaining globally-accessible public services. As an alternative, APNIC implemented a publication protocol service (see RFC 8181) in May 2018, that a self-hosted client can use to publish objects via APNIC’s existing systems. That way, the client avoids needing to run those publication-related services themselves.
At the time of that deployment, rpki.net was the only public RPKI CA software, and it only supported a pre-RFC version of the publication protocol, so that was the version for which we implemented support. Since that time, Krill has been released, and is proving very popular. Krill only supports the RFC version of the publication protocol, though, so it wasn’t possible to use it with our existing publication service.
Read: Moving RPKI beyond routing security
However, following recent upgrades, the APNIC RPKI publication service now supports the protocol as defined in the RFC. This means that it is possible for self-hosted clients using Krill to publish objects via APNIC’s publication service.
Can I convert over from the MyAPNIC-hosted RPKI?
If you currently host RPKI inside the MyAPNIC routing management system, the APNIC Helpdesk can help you run this in both APNIC’s service, and self-hosted as a transitional process. If you do not currently operate in the MyAPNIC-hosted mode, or are able to turn this off and start afresh, you can subscribe to self-hosted RPKI inside MyAPNIC.
Why ‘publish in parent’?
APNIC wants to promote the use of the ‘Publication service for self-hosted RPKI’’. This model of RPKI is one that limits the increase in distinct publication points inside the global RPKI framework. This reduces the number of places the worldwide relying parties have to connect to fetch the RPKI data, and so reduces the time to construct a complete model for the RPKI data.
Why self-hosted RPKI?
APNIC encourages all RPKI producers to think seriously about running a self-hosted RPKI system. This increases your ability to manage your Route Origin Authorization (ROA) state as a function of your delegated resources, and so is inherently more responsive to local network management needs. As your Border Gateway Protocol (BGP) intent changes, you can modify your ROA declarations inside your own network management systems, and script updates in the RPKI system you operate locally. If you manage resources held in multiple RIRs, self-hosted RPKI will permit you to make RPKI updates via a single interface. And, if you want to have complex ROA outcomes which may not be a good fit for the abstract routing model APNIC uses, then self-hosted RPKI will allow you more flexibility in that respect.
A second reason to run a self-hosted RPKI system is the ability to offer novel RPKI products such as ‘Resource Tagged Attestations‘ (RTA), which permit the use of RPKI products outside of the BGP. An example of where RTA could be used in the future is the increasing volume of ‘Bring Your Own IP’ (BYOIP) services, where you may be able to run a locally-operated RPKI system and produce a signed statement regarding your resources, to use privately in a Business-to-Business system for configuration.
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.