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) Trust Anchors (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.

Route Origin Authorization

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

Validation

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. This is usually due to there being a ROA for the prefix for some other ASN.
• Not Found: No ROA exists for the prefix for any ASN, so the announcement’s 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.

Autonomous System Provider Authorization

ASPA validation is slightly different from ROV, in that there are two algorithms: One when the recipient is upstream of the sender, and one when the recipient is downstream of the sender.

Upstream algorithm

Validators compare BGP announcements against the ASPAs and classify each route as:

• Valid: The announcement’s path segments each represent a customer-to-provider relationship.
• Invalid: One or more of the path segments have a relationship other than customer-to-provider.
• Unknown: One or more of the path segments have an unknown relationship.

Downstream algorithm

Validators compare BGP announcements against the ASPAs and classify each route as:

• Valid: The announcement’s path is not a route leak.
• Invalid: The announcement’s path is a route leak.
• Unknown: It is not possible to determine whether the announcement’s path is a route leak.

Why this matters

ROAs and ASPAs work together to improve routing security.

ROAs help answer the question: “Is this ASN authorized to originate this prefix?”

ASPAs help answer the next question: “Does the path this route has taken make sense?”

Together, they provide stronger protection against routing incidents by helping network operators verify both the origin and the path of BGP route announcements.

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.

To take full advantage of RPKI:

• Ensure your ROAs and ASPAs match your actual Border Gateway Protocol (BGP) announcements. When making changes in the MyAPNIC portal, you will be alerted if a proposed change would lead to an announcement becoming invalid under ROV or ASPA validation. These alerts reduce the risk of misconfiguration.
• Avoid overly broad maxLength values, which can unintentionally authorize sub-prefix hijacks.
• Regularly review and update your objects to reflect changes in your routing configuration.
• Implement ROV and ASPA validation 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.