The Resource Public Key Infrastructure (RPKI) is a framework for certifying the holdership of Internet resources (IPv4, IPv6 and ASN). It uses an extended version of the X.509 standards to create and validate certificates containing resource holdership information. RPKI follows the allocation hierarchy from IANA to RIRs, from RIRs to LIRs and from LIRs to end-users. As such, the RPKI is an important component for interdomain routing security by enabling origin validation through cryptographically signed objects called ROAs (Route Origin Authorization). Basically, a ROA is a signed assertion by a prefix holder, authorising a specific AS number to advertise the prefix or a subset of it. The ROAs are then made public and validated by third parties and the validation results can be used to produce BGP filters to accept or deny ingress route announcements. Validation works by walking up the chain of trust, validating each certificate along the path up to the trust anchor (TA).
The TA is the topmost certificate of the PKI, it is self-signed and is supposed to contain all Internet resources. However, because there is currently no single TA managed by an apex body, the five RIRs including AFRINIC are currently managing their own TA. Each TA therefore contains resources allocated by IANA to the respective RIR and each RIR’s RPKI system operates independently from one another. In general, RIRs work collaboratively to make sure there is no overlap of resources in their respective TAs.
However, the situation can become challenging with resource transfers. ARIN, RIPE NCC and APNIC have inter-RIR transfer policies, and are therefore transferring resources between themselves. Suppose resource X is moving from ARIN to RIPE NCC, ARIN needs to remove resource X from its TA, and RIPE NCC needs to add X to it’s one. The issues that may arise with a resource transfer are: (1) it is a lengthy procedure as it involves regenerating the TA on both sides (2) there is always a risk that an RIR over-claims resources, and this would invalidate the tree beneath it.
By definition a TA is a static entity, usually valid for 10-20 years and will only change if there is a key rollover. Adding or removing resources in the TA means that an RIR will have to run the complex process of regenerating a TA every time resources are transferred. Additionally, each time there is change in resources, we need to have access to the private key of the TA for the certificate re-sign and this is inherently a bad practice.
RPKI is envisioned to be a 0% downtime system with 100% accuracy at all time and that is why it is important for RIRs to adopt the make-before-break principle. If resources have been transferred from RIRX to RIRY and RIRX has previously issued certificates with the transferred resources, the whole tree under this certificate will be invalidated as the parent does not contain the transferred resources anymore. This poses a real operational problem as routing depends on the validity of objects in the tree below. Having TAs with a unified set of all resources (for e.g. 0/0) mitigates the risk and alleviates the threat of having an RIR over-claiming resources.
AFRINIC currently operates its RPKI laid out as follows:
- A single Trust Anchor (TA), that covers AFRINIC’s primary Internet Number Resource (INR) holdings, as well as all smaller INR allocations where AFRINIC considers itself authoritative.
- Five (5) online Certificate Authorities (CAs): One for the large INR holdings allocated to AFRINIC directly from IANA, and one each for the other four RIRs, covering the resources for which AFRINIC is the authority for some minority of resources.
- Member CAs, each signed by the covering online CA.
After the transition to an all resources TA, the AFRINIC RPKI will then be as follows:
- An expanded single Trust Anchor, that covers “all resources”.
- The same five online CAs, as before, re-signed by the newly updated and expanded TA.
- Member CAs, each signed by the same covering online CA as before.
This means that during and after the change, there is no visible change to the online CA’s holdings, and no change at all to any member CAs. Therefore, no existing ROAs are affected, and the process for creating new or updated ROAs remains unchanged.
Likewise, if you run local relying-party tools, often referred to as a “validator”, it should continue to run as before, with no changes needed.
AFRINIC will go live with an “all resource” TA (trust anchor) on September 14, 2017. This change will not affect validation of existing certificates and ROAs.
This will be fully tested within an internal test environment prior to that date.
