RPKI

Resource certification is a security framework that proves the association between specific IP address blocks or AS numbers and the custodians of those Internet number resources (INRs). It does this through the production of public-private cryptography certificates known as PKI (for Public Key Infrastructure).

The certificates provide proof and authority to use given IPv4, IPv6 and ASN resources and can be validated cryptographically.

What is RPKI?

Resource certification uses a framework called Resource Public Key Infrastructure (RPKI), which is based on X.509 PKI certificate standards. Using a validation structure called 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 in Border Gateway Protocol (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 seen in the routing system can be verified and are authentic.

RPKI works by adding INR information to X.509 PKI certificates issued to resource holders. This represents custodianship and other status information regarding a particular INR. When RPKI certificates are used, the INRs are associated with the digital signature. Proving the signature can, therefore, attest the INRs relate to what has been signed. You cannot sign correctly referring to INRs that are not contained in your certificate.

RPKI works by forming hierarchies of certificates signing over each other. A ‘root’ certificate signs over child certificates, which sign over their child certificates and so on. The act of signing a certificate makes you a certificate authority or CA. RPKI assigns CA status to the agencies that delegate INRs, so the delegation role aligns with the CA role. Regional Internet Registries (RIR) sign certificates for direct Members and for National Internet Registries (NIRs), both of whom may sign certificates and other RPKI products regarding the resources in their certificates.

In addition to certificates signing other certificates (the CA role), certificates can be used to sign other digital objects. This is called an end-entity or EE certificate: it does not sign other CA certificates, it only signs non-certificate objects. In RPKI, EE certificates are used to sign manifests (catalogues of signed objects) and to sign routing and other digital objects. The primary signed object in routing is the Route Origin Authorization or ROA.

RPKI applications

These are two current applications of RPKI:

Route Origin Validation (ROV) performed by ROAs to make BGP routing decisions. (This is the primary function of RPKI).
Resource Tagged Attestation (RTA), which allows an arbitrary digital object to be signed by the holder of the IP address/ASN mentioned in the digital object (this is a work in progress).

Benefits of RPKI

Much safer than manually checking the APNIC Whois Database or the IRR database.
Secure origin of the prefix or origin-as is the first step to preventing many attacks on BGP integrity.
Instruction/information from the resource custodian can be cryptographically verified (for example, Letter of Authority signing).

APNIC’s RPKI

RPKIs publish all their products in a repository. All PKIs depend on a trust anchor. This is typically fetched as a self-signed certificate but actually is defined by the key. You MUST fetch your trust anchor independently of any other PKI products you will be validating.

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 INRs 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.

See APNIC’s RPKI Trust Anchor Locator

Find out how APNIC has implemented RPKI

Find out how APNIC has implemented a Single Trust Anchor

Certificate management services

APNIC resource holders can create and manage their resource certificates and associated objects (for example, ROAs) via MyAPNIC. The service embedded in MyAPNIC is a child CA specific to the resource holder, operated on their behalf inside APNIC services but run distinctly from the APNIC CA, which is bound to the registry. APNIC holds your private keys, and at all times the products you sign are your products, signed with your keys.

Alternatively, resource holders can operate their own locally managed RPKI system and communicate with the APNIC RPKI using the standard ‘RPKI Provisioning Protocol’ RFC 6492. This is typically only relevant to resource holders who need to automate/script their RPKI operations. This model is also used by the NIR to provide services hosted in their economy, for their direct membership. This form of operation is often called “self hosted”. It is possible to run both MyAPNIC and self-hosted RPKI, for transition purposes. Currently, subscription to self-hosted RPKI along with MyAPNIC hosted services requires manual intervention. Contact helpdesk@apnic.net for assistance.

ROV and ROA

BGP route assertions have an origin AS and a series of AS forming the path. Route Origin Validation (ROV) is the application of RPKI to validating the origin AS.

The main and most widely known application of RPKI is Route Origin Validation (ROV).

ROV is performed using a Route Origin Authorization (ROA). A ROA lists the prefixes that an ASN is authorized to announced. ROAs therefore state which AS is authorized to originate certain IP address prefixes. Once validated, a ROA can be used to generate route filters.

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 192.2.200.0/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.

RTA

Resource Tagged Attestation

Another potential application of RPKI is Resource Tagged Attestation (RTA), which allows RPKI certificates to be used to sign an arbitrary object, such as a cryptographic verifiable ‘Letter of Authority’ (LOA) as a PDF file, or word document.

Current practice uses an informal scanned/signed PDF under company letterhead, which is unverifiable without more information. Forging a LOA is a risk that cannot easily be detected as-is.

RTA generates a ‘detached signature’ using RPKI. The signing certificate contains the IP address range listed in the LOA document. The signed object contains the specific IP resources relevant to the signing, identifies the certificate that proves the resource holder has control, and a digital signature of the object being signed. This is now a cryptographically verifiable object (for instance a LOA) and can be automated.

The exact intent of the resources included is not specified: it depends entirely on the meaning of the signed object. So, a LOA should continue to state conclusively which INRs it relates to.

APNIC is developing RTA and will release services in due course.

Trust Anchor Locator

APNIC operates the RPKI system under a single trust anchor. This has been chosen to cover ‘all resources’ across IPv4, IPv6 and ASNs in line with a decision made by the NRO.

The single trust anchor is represented by a file called a ‘Trust Anchor Locator’ or TAL. It is very important that relying parties, who consume the products of the APNIC RPKI system have this TAL configured into their validator.

The current APNIC TAL as of YYYY-MM-DD is shown below, in two formats:

1. RIPE NCC Validator format:


ca.name = APNIC RPKI Root
certificate.location = rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer
public.key.info = MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9RWSL61YAAYumEiU8z8qH2ETV
IL01ilxZlzIL9JYSORMN5Cmtf8V2JblIealSqgOTGjvSjEsiV73s67zYQI7C/iSOb96uf3/s86NqbxDiFQGN8qG7
RNcdgVuUlAidl8WxvLNI8VhqbAB5uSg/MrLeSOvXRja041VptAxIhcGzDMvlAJRwkrYK/Mo8P4E2rSQgwqCgae0e
bY1CsJ3Cjfi67C1nw7oXqJJovvXJ4apGmEv8az23OLC6Ki54Ul/E6xk227BFttqFV3YMtKx42HcCcDVZZy01n7Jj
zvO8ccaXmHIgR7utnqhBRNNq5Xc5ZhbkrUsNtiJmrZzVlgU6Ou0wIDAQAB
prefetch.uris = rsync://rpki.apnic.net/member_repository/

2. Routinator and RPKI.Net format:

 
rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9RWSL61YAAYumEiU8z8
qH2ETVIL01ilxZlzIL9JYSORMN5Cmtf8V2JblIealSqgOTGjvSjEsiV73s67zYQI
7C/iSOb96uf3/s86NqbxDiFQGN8qG7RNcdgVuUlAidl8WxvLNI8VhqbAB5uSg/Mr
LeSOvXRja041VptAxIhcGzDMvlAJRwkrYK/Mo8P4E2rSQgwqCgae0ebY1CsJ3Cjf
i67C1nw7oXqJJovvXJ4apGmEv8az23OLC6Ki54Ul/E6xk227BFttqFV3YMtKx42H
cCcDVZZy01n7JjzvO8ccaXmHIgR7utnqhBRNNq5Xc5ZhbkrUsNtiJmrZzVlgU6Ou
0wIDAQAB

One of these two formats should be used to write the TAL as a configured element of your validator.

Should APNIC change the TAL, this will be communicated widely, and software should update. The TAL can always be verified by referring to these web pages.

Under this single TAL, APNIC operates a number of subsidiary RPKI CAs to represent the states of Internet number resources we receive from IANA directly, and from other RIRs via transfers. This logistical separation means we can clearly identify transfers in from resources delegated down.

Previously, APNIC operated five distinct TALs, one for each of these cases (the four other RIRs and IANA). A transition plan was enacted which completed in February 2018 and is documented on the Single Trust Anchor transition webpage.

Additional TAL for AS0

The Implementation of Prop132 (AS0 ROA for bogons) necessitates the use of an additional TAL, because we operate this service discretely, separated from the main service TAL.

3. AS0 TAL in RIPE NCC Validator format:


ca.name = APNIC AS0 Root
certificate.location = rsync://registry-testbed.apnic.net/as0-test/ta/ta.cer
public.key.info = MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvo8wLXUFnUjXyX
hy11VpFWiDZy7Hs9TAIfymiKwCbOz3ZMp8iWgWoxI5IJzO0cIz/KaRgBbzVeXRFttp3nzh5Up+EQ
XnL3ixWh3gAjSD0mTOLchLtS4pSuuHxLfdqTreCRLVK2Fbq09jUUPf76C6TazIQouMp6epGOJZvS
fmBMK3TQphlXC/iREbiMtDL7gPhexidllhuNbk4PXXBhXxoUjOEG4YdVUC/MV3dXZ72IOtl1HQ9J
3tky/bgaDVykD4j4wqHyrzhiXQ45KIrY7JGT95Z++L00OrjxlLwZoKi5vxh9U4rDtNUhPKESzpqu
t1+cO4WX+Z6L2DR80abh1DOQIDAQAB

4. AS0 TAL in Routinator and RPKI.net format:


rsync://registry-testbed.apnic.net/as0-test/ta/ta.cer
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvo8wLXUFnUjXyXhy11VpFWiDZy7Hs9TA
IfymiKwCbOz3ZMp8iWgWoxI5IJzO0cIz/KaRgBbzVeXRFttp3nzh5Up+EQXnL3ixWh3gAjSD0mTO
LchLtS4pSuuHxLfdqTreCRLVK2Fbq09jUUPf76C6TazIQouMp6epGOJZvSfmBMK3TQphlXC/iREb
iMtDL7gPhexidllhuNbk4PXXBhXxoUjOEG4YdVUC/MV3dXZ72IOtl1HQ9J3tky/bgaDVykD4j4wq
HyrzhiXQ45KIrY7JGT95Z++L00OrjxlLwZoKi5vxh9U4rDtNUhPKESzpqut1+cO4WX+Z6L2DR80a
bh1DOQIDAQAB