RPKI Terminology

Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Introduction The Resource Public Key Infrastructure (RPKI) is defined in dozens of different RFCs. The terminology used by implementers and developers of RPKI protocols, and by operators of RPKI systems, can at times be inconsistent or imprecise, leading to confusion. An example of this sort of problem arises in the context of RPKI implementation models. The model where an address holder runs their own CA software deployment that communicates with the relevant registry is often referred to as "delegated RPKI", but at least some Regional Internet Registries (RIRs) instead use the term "self-hosted RPKI". In an effort to improve consistency and precision in this respect, this document provides a single location for definitions of commonly-used RPKI terms.

Basic Internet Number Resources (INRs): Autonomous System (AS) numbers, IPv4 addresses, and IPv6 addresses. Regional Internet Registry (RIR): An INR registry recognized by IANA as a regional authority for INR management. At the time of writing, these are AFRINIC, APNIC, ARIN, LACNIC, and RIPE NCC. See for more details. National Internet Registry (NIR): An INR registry that is primarily concerned with the delegation of resources within a specific economy, as opposed to the larger geographical regions covered by an RIR. Internet Service Provider (ISP): An organization that provides internet services to other organizations. An ISP will typically have an IP address or AS number delegation from an RIR or an NIR. Local Internet Registry (LIR): A term used in some regions as a synonym for ISP. Certification Authority (CA): Certification Authorities in the RPKI are entities that receive an RPKI CA certificate from an issuer. RPKI CA certificates bind a public key to INRs. CAs can use the corresponding private keys to sign verifiable statements pertaining to those INRs, such as CA certificates issued to a subordinate CA with INRs that are a subset of the INRs held by the CA, or ROAs, etc. Repository: The repository is the component responsible for storing and distributing RPKI-signed objects, such as Route Origination Authorizations (ROAs), Certificates, Certificate Revocation Lists (CRLs), and Manifest files. It acts as a centralized or distributed database that enables RPKI validators (relying parties) to fetch and validate routing security data. The key functions include storing RPKI objects issued by CAs, using protocols like RRDP (RPKI Repository Delta Protocol) or rsync to synchronize data with RPKI validators, and ensuring validators globally access the same authoritative data. Relying Party (RP): A Relying Party (RP) is an entity that utilizes validated RPKI data to enhance the security of Border Gateway Protocol (BGP) routing decisions. Key responsibilities include the retrieval of RPKI objects (CA certificates, CRLs, manifests and other signed objects) from RPKI repositories using protocols like rsync or RRDP. It will validate the certificate chain of trust from end-entity certificates up to trusted root CA certificates, and also ensure that additional signed object validation is performed as expected. RPs will typically generate validation results that users can review, and will often also operate as an RPKI-Router server. RP can sometimes be referred to as an "RPKI validator" and different definitions can be referenced interchangeably. Address space holder: An entity that has been delegated INRs by an RIR or other authorized body. Resource Allocation: Resource allocation refers to the authoritative process of assigning Internet number resources to entities through a hierarchical trust framework, including sub allocation processes. This process establishes cryptographic binding between resources and their legitimate holders, enabling secure route validation. Resource Revocation: Resource revocation refers to the process of invalidating compromised or deauthorized INRs or their associated digital certificates. This ensures unauthorized entities cannot misuse revoked resources for BGP route manipulation. In RPKI, resource delegation revocation involves cascading revocation of all sub certificates/objects.

Signature Objects and Associated Trust Data RPKI signed object: A cryptographically-secured data structure that has been signed by an RPKI End-Entity (EE) resource certificate. Currently, RPKI signed objects include six categories: Route Origination Authorization, Manifest, Ghostbusters, Autonomous System Provider Authorization, Trust Anchor Key, Signed Checklist. See for more details. Route Origination Authorization (ROA): A type of RPKI signed object that can be issued by an IP address holder in order to authorize an AS to originate routes to one or more of the holder's prefixes. See for more details. A ROA includes an authorised origin AS and a set of IP prefixes, each of them with an optional max length, which represents the maximum length of the IP prefix that the origin AS is authorised to advertise. Manifest: A type of RPKI signed object that provides a complete list of all the signed objects that an authority has published to a given repository publication point. The manifest includes the hashes of each file as well. The list of files and hashes helps RPs to detect unauthorized changes or deletions. See for more details. Ghostbusters record: A type of RPKI signed object for providing contact details for a given RPKI repository publication point. See for more details. Autonomous System Provider Authorization (ASPA): A type of RPKI signed object that can be issued by an AS holder as a statement about the ASes that operate as providers (upstreams) for the holder's AS. ASPA is used for route leakage protection. See and for more details. Trust Anchor (TA) Key: A type of RPKI signed object that can be issued by a TA key holder as a statement about the current public key for the TA, as well as the successor public key for the TA, in order to facilitate the transition of RPs to that successor key. See for more details. RPKI Signed Checklist (RSC): A type of RPKI signed object that can be issued by an INR holder over an arbitrary set of files. See for more details. Resource Certificate: Resource certificates are X.509 certificates that bind the holdership or "right-of-use" assertions of Internet Number Resources (INR) (i.e., IP Addresses and Autonomous System (AS) numbers) to a public key in the RPKI hierarchy. Allowing the entity that holds the corresponding private key to sign attestations pertaining to a non-strict subset of the INRs contained on the Resource Certificate. The CA and EE certificates, as well as the BGPsec router certificates in the RPKI system, are referred to as resource certificates and are profiled in and . End-Entity (EE) Certificate: EE Certificates are certificates for which the private key cannot be used to sign subordinate certificates. There are two types of EE certificates used by the RPKI: Embedded EE Certificates and BGPsec Router Certificates. Embedded EE Certificate: Embedded EE Certificiates are issued by resource holder CAs to delegate the authority attested by their allocation certificates . RPKI Signed Objects , such as ROAs and Manifests, use an embedded EE certificate. When issuing an RPKI signed object, the private key of the EE certificate is used to sign its content. A strict one-to-one exclusive mapping exists between the EE certificate and the signed object. This non reusable setting can reduce the attack surface. BGPsec Router Certificates: The BGPsec router certificate in RPKI is an X.509 end entity (EE) certificate, which is used for authenticating the AS path in the BGPsec protocol, indicating that the router or routers holding the corresponding private key have the authority to send secure route announcements (BGPsec UPDATEs) on behalf of the AS specified in the certificate.The BGPsec router certificate is stored in the repository of the issuing CA. Compared to other parts of RPKI, BGPsec uses different algorithms, key formats, and signature formats, BGPsec RP needs to support the algorithms used to validate BGPsec signatures in , as well as the algorithms in for validating signatures on BGPsec certificates, RPKI CA certificates, and RPKI CRLs. Trust Anchor (TA): A self-signed X.509 certificate representing the apex of trust in the RPKI hierarchy. It attests holdership of Internet number resources and delegates authority to subordinate CAs. TA is the ultimate arbiter of the RPKI trust chain, and RPs must configure trust anchors to initialize RPKI validation. Trust Anchor Locator (TAL): A TAL is used by relying parties (RPs) to retrieve and validate a trust anchor (TA) certification authority certificate used in RPKI validation, with its data format containing the TA URI and the public key corresponding to the referenced object. During validation, the RP fetches the TA via the URI and verifies the matching of the public key. It provides a secure bootstrap mechanism for the RPKI trust hierarchy without requiring pre-distribution of TA certificates. See for more details. Certificate Revocation List (CRL): A digitally signed list issued by a certificate authority (CA) in the RPKI system, enumerating the serial numbers of resource certificates that have been revoked before their scheduled expiration date. CRLs provide a real-time mechanism to invalidate compromised or erroneous certificates within the RPKI trust hierarchy. RPs can verify the revocation status of certificates during RPKI verification using CRL. Chain of Trust: Resource Certificates in the RPKI are validated by way of an hierarchical chain of trust. At the top level a Trust Anchor (TA) certificates is used for which trust is assumed by a Relying Party through a configured TAL. The private key of the TA certificate can be used to sign subordinate CA certificates that associate a public key with a non-strict subset of the INRs found in the TA. Trust in this association is derived by RPs through the assumed trust in the TA and the verification of signatures. The private keys of CA certificates can be used to sign further subordinate CA certificates. This resulting in an RPKI tree of TA and CA certificates.

RPKI Repository Repository Publication Point: RPKI TA and CA certificates contain Subject Information Access fields with rsync and RRDP related URIs that can be used by RPs to retrieve files signed by the private key pertaining to this certificate. The 'id-ad-caRepository' entry is the Repository Publication Point for the certficate. It refers to an rsync directory that contains the current certificates issued under this CA certificate, the most recent CRL, the current manifest, and all other current signed objects that can be verified using an EE certificate issued under this CA certifcate. See and for more details. Repository Instance: A host comprising one or more repository publication points. Repository Object (or Object): A terminal object in a repository publication point. Repository Directory: Synonymous with Repository Publication Point. RPKI Repository Name Scheme: The RPKI Repository Name Scheme defines the filename extensions format for RPKI repository objects. Specifically, it includes:

Filename extension	RPKI Object	Reference
.asa	Autonomous System Provider Authorization
.cer	Certificate
.crl	Certificate Revocation List
.gbr	Ghostbusters Record
.mft	Manifest
.roa	Route Origination Authorization
.sig	Signed Checklist
.tak	Trust Anchor Key

RPKI CA Deployment Models Hosted model: An operating model where the issuing registry (typically an RIR) manages the RPKI objects and associated repository on behalf of the resource holder. Resource holders use an interface provided by the registry to create and manage their RPKI objects, which are then hosted by the registry. This is sometimes referred to in a registry-specific sense, e.g. "APNIC-hosted RPKI". Delegated model: An operating model where the address holder runs an independent RPKI CA instance as a child CA of the issuing registry's parent CA. The address holder's CA typically relies on the provisioning protocol in order to communicate with the registry's CA. This is sometimes referred to as "self-hosted RPKI". Hybrid model: An operating model where the address holder runs an independent RPKI CA instance as a child of the issuing registry's parent CA (like in the Delegated model) and uses the publication service provided by the issuing registry, who will take care of the 24/7 availability of the repository. Currently, some RIRs and NIRs offer the hybrid model.

Inter-CA and Publication Server communication Parent CA: An entity that operates a CA that issues one or more CA subordintate certifates to child CAs. Child CA: An entity that operates a CA that received on or more CA certificates from a parent. Note that an entity can be a child to its parent, but also be a parent to its own child CAs. Provisioning Protocol: A protocol used by RPKI CAs to manage certificates issued by their parent CAs. See for more details. Publication Protocol: A protocol used by RPKI CAs to send their RPKI objects to a server, with that server then handling the distribution of those objects to RPs via rsync and other protocols. See for more details. Business PKI (BPKI): A PKI used in the RPKI out-of-band (OOB) protocol in order to establish and secure subsequent interactions via the provisioning protocol and the publication protocol . Publication engine/publication server: The server providing the publication protocol service. Publisher: An entity acting as a client of a publication server.

RPKI Repository and the Relying Party Communication Rsync: Rsync is a file synchronization and transfer tool designed to minimize data transfer time and bandwidth usage by copying only the differences between source and destination files. It allows relying parties to synchronize a local copy of the RPKI repository used for validation with the corresponding remote repositories. RPKI Repository Delta Protocol (RRDP): Data synchronization protocol between repositories and the relying parties . It aims to replace rsync in the RPKI context, providing a more reliable, scalable, and HTTPS-based incremental data synchronization mechanism, and ensuring that RPKI validators can quickly obtain the latest RPKI data. Update Notification File: A type of file in RRDP that acts as a directory pointing to the latest snapshot and delta files. This file allows relying parties to discover any changes between the repository state and the relying party's cache. Snapshot File: A type of file in RRDP that provides a complete copy of all RPKI objects (certificates, CRLs, manifests and other signed objects) in a repository at a specific moment. Delta File: A type of file in RRDP that contains incremental changes (additions, modifications, deletions) to the relevant repository's RPKI data. Same-Origin Policy (SOP): The Same-Origin Policy is a web security mechanism that restricts how resources from one origin (domain, protocol, and port) can interact with resources from another origin. Used in RRDP to reduce problems associated with inadvertent or malicious repository data. See for details.

Communication between RPKI and Routers RPKI-Router Protocol (RTR): A protocol designed to securely distribute validated routing information from RPKI validators to BGP routers. It enables routers to enforce Route Origin Validation (ROV) by dynamically receiving and applying authorized prefix-to-AS mappings. See and for details. Protocol Data Unit (PDU): A discrete protocol message in the RPKI-Router protocol. Payload PDU: An RPKI-Router PDU that contains data for use by the router (e.g. the IPv4 Prefix PDU), as opposed to the PDUs for the control mechanisms of the protocol (e.g. the End of Data PDU).

Using of signed objects Route Origin Validation (ROV): A security mechanism designed to prevent route hijacking and misorigination in BGP by verifying whether a given AS is authorized to announce specific IP address prefixes. Also known as Prefix Origin Validation. Validated ROA Payload (VRP): A data structure containing an origin ASN, a prefix, and the max-length for the prefix, derived from a validated ROA. VRPs are typically produced by RPs as the the base output format for ROA data. Route Origin ASN: The origin AS number derived from a BGP route as follows, see for details:

the rightmost AS in the final segment of the AS_PATH attribute in the route if that segment is of type AS_SEQUENCE; or
the BGP speaker's own AS number if that segment is of type AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty; or
the distinguished value "NONE" if the final segment of the AS_PATH attribute is of any other type.

Covered: An IP address prefix 'covers' another prefix if the second prefix is a non-strict subset of the first prefix. ROV states: There are three validation states in ROV: Valid, Invalid, and Unknown (or Not Found). See for details. ASPA validation states: When using ASPA to validate the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes, ASPA defines distinct verification algorithms and procedures for scenarios such as upstream paths and downstream paths, and establishes three possible validation outcomes.

Valid: The AS_PATH fully complies with ASPA authorization rules.
Invalid: The AS_PATH violates at least one ASPA authorization constraint.
Unknown: Inconclusive result due to missing ASPA data in RPKI repositories.

Acknowledgments To be determined.