Resource certification is a security framework that proves the association between specific IP address blocks or AS numbers (Internet number resources) and the holders of those Internet number resources. The certificates are proof of the resource holder’s right of use of their Internet number resources and can be validated cryptographically. Resource certification uses a framework called Resource Public Key Infrastructure (RPKI), which is based on an X.509 certificate profile defined in RFC3779.
In RPKI, the certificate structure mirrors the way in which Internet number resources are distributed. That is, resources are initially distributed by the IANA to the Regional Internet Registries (RIRs), who in turn distribute them to National or Local Internet registries, who then distribute the resources to their customers.
APNIC acts as a trusted Certification Authority (CA) and issues certificates to resource holders - APNIC Members. Certificate Authorities attest that the public key in the generated certificate is the public key of the identified party.
APNIC’s RPKI repository includes a single ‘all resources’ certificate as a self-signed trust anchor. Underneath this trust anchor, APNIC has five sub-repositories with distinct subsets of the Internet number resources it manages. This reflects those resources for which administrative responsibility has been assigned to APNIC directly by IANA as described in the IANA registries, and those resources whose administrative role has been transferred to APNIC from each of the other four RIRs.
Certificate management services
APNIC resource holders can create and manage their resource certificates and associated objects (e.g. ROAs) via MyAPNIC
Alternatively, resource holders can operate their own locally managed RPKI system and communicate with the APNIC RPKI using the standard ‘RPKI Provisioning Protocol’ (RFC6492). This is typically only relevant to resource holders who need to automate/script their RPKI operations.
Benefits of resource certification
- Routing information corresponds to provably delegated IP address resources, giving resource holders proof that they hold certain resources and have the right to use an IP address
- Resource holders can attest to their resources when distributing them to customers/users
- Resource users can protect information related to their delegated resources with a digital signature. Any effort to alter that information results in the signature being invalidated
- Only resource holders with a properly delegated ‘right of use’ can generate a signature that associates Internet number resources with their signing
Secure inter-domain routing
Internet routing is largely based on trust. Each party trusts that routes used to transmit data are safe, or will not be maliciously altered to compromise data - for example, black holing, or impersonation of identity at an application level.
Previous security measures such as ‘bogon’ filtering and piecemeal routing policy databases are no longer reliable forms of defence against security vulnerabilities. Using a validation structure called Resource Public Key Infrastructure (RPKI), resource holders can confidently state that the information being transmitted is correct and corresponds to their intentions.
RPKI allows network operators to digitally encrypt and sign routing advertisements transmitted into the BGP by using a system of private and public keys. Information can be encrypted and signed with a private key and can only be decrypted, or have its signature verified, using the matching public key. Digitally signing information provides assurance that routing advertisements transmitted into the routing system can be verified and are authentic. Network operators are therefore creating cryptographically valid statements, or Route Origin Authorizations (ROAs), about the route announcements they authorize to be made with the prefixes they hold. In essence, ROAs state which AS is authorized to originate certain IP address prefixes.
Benefits of creating a ROA
- Verify whether an AS is authorized to announce a specific IP prefix
- Minimize common routing errors
- Prevent most accidental hijacks
What’s contained in a ROA
- The AS number you authorize
- The prefix that is being originated from it
- The most specific prefix (maximum length) that the AS may announce
A ROA might look like this for example,
“ISP 4 permits AS 65000 to originate a route for the prefix 18.104.22.168/24”
Create your ROA in MyAPNIC
It’s easy to create a ROA. Log in to your MyAPNIC account and follow the step-by-step guide or the video below. It will only take you about 5 minutes to complete.
Note, you can add in your ROAs individually or for identical items, add and clone them for convenience.
Higher-trust resource management
APNIC is investigating mechanisms to use RPKI to enhance trust in general Internet number resource management. A service model for signing assertions about resources is being designed, which will use the RPKI to provide signatures demonstrating the authority to act regarding specific number resources. Use cases include transit provisioning, resource transfer, and improvements to the Internet Routing Registry.
- Signed Letters of Authority (LOA) to enable provisioning for transit
- Signed requests for Expression of Interest in acquisition/transfer resources
- Signed Internet Routing Registry (IRR) objects involving resources from multiple RIRs
Single Trust Anchor
APNIC is in the process of transitioning from the current Resource Public Key Infrastructure (RPKI) trust anchor arrangement to a new configuration which has been agreed among the RIRs and announced by the NRO.
In this new configuration, each RIR will publish an 'all resources' global trust anchor, under which its own regional resources (IP addresses and ASNs) will be certified.
APNIC will no longer maintain the current set of five trust anchors (which represent resources received from IANA and the four other RIRs), but will instead certify those resource sets within its certification hierarchy, as further described below.
This page explains the implications of these changes, and actions which may be needed by APNIC Members and other relying parties.
What do I need to do?
If you are registering ROAs via MyAPNIC or the RPKI provisioning protocol, the process is unchanged and you do not need to make any changes. Existing ROAs will not be affected by the transition either.
If you are using relying-party software, such as the Dragon Research Labs RPKI Toolkit or RIPE’s RPKI Validator, you are advised to update your software’s configuration to use only the current APNIC IANA trust anchor, rather than the five APNIC TAs that are used currently, once stage 3 is complete on 30 October 2017.
Note: this update is not critical. However, if it is not done, the software will log or report warnings about being unable to retrieve the trust anchors that are no longer being used.
What will change
Currently, the APNIC RPKI has:
- Five trust anchors, one for resources APNIC receives directly from IANA and one for resources vested through other RIRs, with each containing the resources for which APNIC considers itself authoritative by way of delegation from that source.
- Five online Certificate Authorities (CAs), each signed by one of the trust anchors and having the same set of resources as its signing trust anchor.
- Member CAs, each signed by an online CA.
After the transition, there will be:
- An expanded trust anchor (including originally marked resources from IANA), containing 'all resources'.
- A new, online-intermediate CA (signed by the new single APNIC trust anchor), also containing 'all resources'.
- Five online CAs, each signed by the intermediate CA, with one for resources we hold directly from IANA and others for resources held through each other RIR, with each containing the resources for which we consider itself authoritative by way of delegation from that source.
- Member CAs, each signed by one of the five online CAs.
The transition process comprises four stages:
- Expand the existing trust anchor for resources from IANA, issue the new intermediate CA, and re-sign one of the existing online CAs under that intermediate CA.
- Re-sign the other online CAs under the new intermediate CA.
- Reduce the other trust anchors’ resources to AS0, to indicate that they are no longer in use.
- Remove the other trust anchors and their repositories.
See a visual representation of the transition.
|9 October – 12 October||Step through the transition in the test environment, with one stage happening on each day.|
|23 October||Complete stage 1 in production|
|25 October||Complete stage 2 in production|
|30 October||Complete stage 3 in production|
|5 February 2018||Complete stage 4 in production|
The first three stages here were previously scheduled for completion by the end of September. However, some new problems occurred during the public test environment transition that hadn’t been caught by earlier internal testing, necessitating that those stages be rescheduled in order to rectify those new problems.
Testing and validation
Visit the testbed for details on how to enrol in the test environment or validate the test environment repository.