Tree Hints for the Resource Public Key Infrastructure (RPKI)

Introduction In the RPKI, holders of IP address space can host their own repositories and act as their own CA. They have full control over that repository and any objects signed by their CA. They may, for example, sign one or more certificates that hold a subset of the resources from the parent certificate. These certificates may reference publication points in the same repository or different ones. These new certificates can, in turn, do the same, ad infinitum. The nested structure of CAs forms a tree structure. The root of these trees are defined by the Trust Anchor Locators (TALs) . RP software is assumed to walk this tree, visit every node, and retrieve all objects (e.g. Manifests , Route Origin Authorizations , Ghostbuster records , other certificates , etc.). RP software collects all information from the objects and processes it. It is important to note that RP software needs to visit every repository and consider every object CAs put on manifests. If it would exclude any repository or CA, then a BGP advertisement that should be valid can become invalid. For example, if a ROA for the prefix 2001:DB8::/32 and AS64496 is included, but the ROA for 2001:DB8:123::/48 and AS64497 (from another CA) is not, then a BGP speaker performing ROV validation may falsely reject the latter, more specific, announcement. For RP software to fully walk the tree, the tree needs to be finite and reasonably sized. However, the size of the tree can only be determined while traversing the tree - RP software cannot verify these properties in advance. A malicious CA could, for example, create its children in an ad-hoc fashion while RP software is discovering it, thereby violating the implicit assumption that the tree is finite. That specific behaviour can be countered by RP software by setting a maximum depth for a certificate chain. However, at 10 children per child, the number of repositories would already reach 1111111111 (10^0 + 10^1 + ... + 10^9) after a modest 10 levels. With other strategies, such as serving gigabytes of data and simulating a very low bandwidth, a malicious repository can violate our second assumption that the tree is reasonably sized. Using malicious repository content, any CA can cause the process to take so unreasonably long that RP software does not finish processing in a reasonable amount of time (possibly years). The size and structure of nodes in the RPKI tree varies. For example, a NIR may have a legitimate need for hundreds of child-CAs, while a regular CA under the same parent does not. This diversity makes heuristics unsuitable for detecting this issue adequately, only discarding the malicious repository and its children, without heavily restricting the freedom of the structure of RPKI or causing false positives capping future growth. Likewise, there may be valid reasons for splitting a prefix into many subprefixes, or authorising subprefixes for many autonomous system numbers (ASNs), but allowing any party to add limitless prefix-ASN pairs may overflow BGP Origin Validation tables. Setting a fixed limit may be problematic in these cases. The new certificate extensions, "maxDescendants" and "maxVrps", are added to mitigate this issue by providing RP software prior knowledge about the tree limits before walking the tree.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Scope The scope of "maxDescendants" and "maxVrps" is to provide guidance for RP software regarding the expected structure of the tree, as well as impose requirements on other aspects of the CA and its repository. Following the information in "maxDescendants" and "maxVrps" is RECOMMENDED. However, local policy MAY prevail.

Resource Certificate Extensions These extensions extend the already defined extensions for PKIX Resource Certificates as defined in RFC 6487 section 4.8 . Both maxDescendants and maxVrps SHOULD appear at least once in each certificate chain. If these extensions are absent on a certificate, it means that this certificate imposes no additional limits.

maxDescendants This extension is a non-critical extension that defines the maximum cumultative amount of descendants under this CA. BGPsec Router Certificates are not counted because they do not add child-objects to the validation tree. At a value of 0, an RP SHOULD NOT visit any of the child CAs listed on the manifest. At a value of N, an RP SHOULD at most visit N descendants of this CA. This does not affect the amount of EE certificates used for signing objects like manifests and ROAs - those are not affected by this limit. This does include children and children of children. If maxDescendants is defined at multiple levels in the certificate chain, then the strictest limit MUST prevail. The maxDescendants extension contains the maximum amount of children the CA may at most have. This number SHOULD be lower than the effective maxDescendants value for this CA. A value higher than or equal to the effective maxDescendants value will cause the children to have an effective maxDescendants value equal to the effective maxDescendants value of this CA minus one.

maxVrps This extension is a non-critical extension that defines the maximum cumultative amount of Validated ROA Payloads (VRPs) under this CA. At a value of 0, an RP SHOULD NOT accept any of the ROAs under this CA. At a value of N, an RP SHOULD create most accept N VRPs based on data from this CA and its descendants. This means that at a limit of 25, one can create five ROAs with different ASNs with each five prefixes, or one ROA with 25 prefixes, or any combination that ensures the VRP count stays less or equal to maxVrps. This includes data from ROAs at children and children of children. If maxDescendants is defined at multiple levels in the certificate chain, then the strictest limit MUST prevail.

Validation In order to validate the limits, RP software constructs the chain of certificates from the current certificate up to the root. For each limit, RP software should check for each certificate in this chain whether that certificate defines a limit. Then the most strict limit of all limits present in the chain should be used as limit. During evaluation the RP software checks whether any limits have been violated, and if so, stops processing below the violating branch of the tree. If a limit is absent from the entire chain, a reasonable default SHOULD be used. Root CAs SHOULD define all limits on certificates for third-parties.

IANA Considerations This document registers the following RPKI extensions:

Name: maxDescendants
OID: xxx
Reference: [RFCxxxx] (this document)

Name: maxVrps
OID: xxx
Reference: [RFCxxxx] (this document)

Security Considerations This document contains security enhancements for the tree discovery process in the RPKI protocol. maxDescendants and maxVrps can help prevent a number of denial of service attacks against RP instances. There may be maxDescendants and maxVrps extensions published at the root level with very large allowances, thereby effectively negating the protections offered. The same precautions described in apply here as well. CAs should be careful with setting their maxDescendants limits. If the maxDescendants value times the amount of children of a CA is higher than the effective maxDescendants value of that CA, then one or more children may cause the maximum amount of children to be exceeded, even if none act malicious. This may cause routing data to not be retrieved. For example, take a CA A with three children: AA, AB, and AC. A has an effective maxDescendants of 10, and sets its maxDescendants value to 5, which thus applies to AA, AB, and AC. If both AA and AB decide to fully use their five children, for example by creating AAA, AAB, AAC, AACA, AACB, ABA, ABAA, ABAAA, ABAAAA, and ABAAAAA, then RP software may no longer check AC, as AA and AB together already hit the effective maxDescendants of A. Note that the retrieval order is not defined, thus different RP software may decide to first retrieve AA, AB, and AC, and exclude a different CA, for example ABAAAAA. This also applies to maxVrps. This may lead to RP software not retrieving data from certain CAs, which can lead to partial data. The threat that comes with partial data is that, for example, a BGP advertisement that should be valid, may become invalid, as the ROA for the advertisement is missing, and the less-specific prefix does have a ROA that was retrieved. When choosing limits, careful consideration must be taken to ensure that malicious actors cannot disrupt RPKI, whilst the data from valid actors is still retrieved.

References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A Profile for Resource Certificate Repository Structure This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK] A Profile for Route Origin Authorizations (ROAs) This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK] Manifests for the Resource Public Key Infrastructure (RPKI) This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. [STANDARDS-TRACK] A Profile for X.509 PKIX Resource Certificates This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK] The Resource Public Key Infrastructure (RPKI) Ghostbusters Record In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard. [STANDARDS- TRACK] BGP Prefix Origin Validation To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK] A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this document updates the RPKI Resource Certificates Profile (RFC 6487). Resource Public Key Infrastructure (RPKI) Trust Anchor Locator This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) Certification Authority (CA) certificate from one or more locations and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys but can allow these TAs to change the content of their CA certificate. In particular, it allows TAs to change the set of IP Address Delegations and/or Autonomous System Identifier Delegations included in the extension(s) (RFC 3779) of their certificate. This document obsoletes the previous definition of the TAL as provided in RFC 7730 by adding support for Uniform Resource Identifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC 7230) as the scheme.

Example Resource Certificate The following is the example resource certificate from RFC 6487 adapted with maxDescendants and maxVrps.