RPKI

How does RPKI work?

RPKI operates by issuing cryptographic certificates that bind Internet number resources (INRs) — such as IP address blocks and Autonomous System Numbers (ASNs) — to public keys held by the resource holder. These certificates are part of a hierarchical trust model, beginning with Regional Internet Registry (RIRs, like APNIC) TAs and extending to individual members. Each entity that issues a certificate acts as a Certification Authority (CA), and the structure ensures that only authorized holders can make attestations about their resources.

To validate RPKI data, entities known as relying parties — typically network operators or service providers — run RPKI validators. These validators use a configuration file called a Trust Anchor Locator (TAL) to locate and verify the root certificate of a TA, usually operated by an RIR. The TAL contains the public key and URL of the TA’s certificate repository, forming the basis of trust for all subordinate certificates and signed objects.

The most common use of these certificates is to create Route Origin Authorizations (ROAs). A ROA is a digitally signed object that specifies which ASN is permitted to originate a route for a given IP prefix. ROAs contain:

• The AS number being authorized.
• The IP prefix being originated.
• The maximum length of the prefix that may be announced (maxLength).

For example, a ROA might state: “ISP 4 permits AS 65000 to originate a route for the prefix 192.2.200.0/24.”

Validators compare Border Gateway Protocol (BGP) announcements against the ROAs and classify each route as:

• Valid: The ASN in the BGP announcement is authorized to originate the prefix, according to a matching ROA.
• Invalid: The ASN is not authorized to originate the prefix, even though a ROA exists for it.
• Not Found: No ROA exists for the prefix, so its legitimacy cannot be verified.

This process is known as Route Origin Validation (ROV). When implemented in routers, ROV enables operators to take action based on these classifications. This typically means rejecting invalid routes.

How can I take advantage of RPKI?

If you’re an APNIC Member, you can start using RPKI by creating and managing Route Origin Authorizations (ROAs) through the MyAPNIC portal. This allows you to specify which Autonomous Systems are authorized to originate routes for your IP prefixes, helping protect your network from accidental misconfigurations and malicious hijacks.

APNIC provides certificate management services through MyAPNIC. Each resource holder is assigned a child Certification Authority (CA), operated on their behalf within APNIC’s infrastructure. APNIC generates private keys on your behalf and signs products, such as ROAs, with those private keys.

You can choose between two deployment models:

• Hosted Mode: APNIC manages the certificate and publication infrastructure. This is the recommended option for most Members and requires minimal setup.
• Self-Hosted Mode: This mode is also referred to as the ‘delegated’ mode. You operate your own Certification Authority and publication point, or use APNIC’s publication point, and communicate with APNIC’s RPKI system using the standard RPKI Provisioning Protocol (RFC 6492). This model is typically used by resource holders who need custom functionality that can only be supported through a standalone CA, or who want a single CA to manage resources from multiple Regional Internet Registries (RIRs). You can also run both MyAPNIC and self-hosted RPKI in parallel during transitions. When using hosted mode, the APNIC Registry API can also be used to manage ROAs.

To take full advantage of RPKI:

• Ensure your ROAs match your actual Border Gateway Protocol (BGP) announcements. When making ROA changes in the MyAPNIC portal, you will be alerted if a proposed change would lead to an announcement becoming RPKI-invalid. These alerts reduce the risk of misconfiguration.
• Avoid overly broad maxLength values, which can unintentionally authorize sub-prefix hijacks.
• Regularly review and update your ROAs to reflect changes in your routing configuration.
• Implement ROV in your routers to act on the validation status of incoming routes.
• Use an RPKI validator.
• Learn from RPKI best practices and resources available through the APNIC Academy.

By following these steps, you can strengthen your network’s routing security and contribute to a more trustworthy Internet.

APNIC and RPKI

This section provides direct access to APNIC’s key resources for understanding, deploying, and managing RPKI. Each link includes a description of its purpose, how it’s used, and who it’s most relevant to.

• Trust Anchor Locator (TAL) archive: Offers archived TAL files in multiple formats (RFC 6490, RFC 7730, RIPE Validator) for both APNIC’s main Trust Anchor and the AS0 Trust Anchor. This supports validator configuration, compatibility testing, and historical reference. Relevant to engineers, researchers, and operators needing legacy or alternative TAL formats.
• Certification Practice Statement (CPS): Outlines APNIC’s formal operating procedures for its RPKI Certification Authority. It describes how certificates are issued, managed, and revoked, and aligns with the Certificate Policy defined in RFC 6484. Important for relying parties, compliance teams, and anyone auditing APNIC’s RPKI operations.
• Historical Certification Practice Statements (CPS): Provides archived versions of APNIC’s CPS documents, allowing users to track changes in operational practices over time. Useful for audits, research, and understanding the evolution of APNIC’s RPKI implementation. Relevant to researchers, auditors, and policy analysts.
• Notes on the use of APNIC RPKI: Explains APNIC’s legal disclaimers regarding its RPKI services. It clarifies that APNIC is not liable for damages resulting from use of RPKI data, except in cases of wilful misconduct. Important for legal teams, service providers, and anyone relying on RPKI data.
• Important notes on the APNIC AS0 ROA: Expands on APNIC’s liability disclaimers and provides guidance on responsible use of RPKI data, including AS0 ROAs. Emphasizes user responsibility and the importance of using current repository data. Relevant to operators deploying AS0 ROAs and legal/compliance teams.
• Single Trust Anchor transition (completed 2018): Describes the final stage of APNIC’s move to five TAs to a single TA. Useful for historical purposes.
• RPKI I-ROV Filtering World Map: APNIC Labs provides a map showing the level of RPKI origin validation that occurs in different economies and regions.