Best Current Practice for ROA Issuance Restrictions in RPKI

Introduction The Resource Public Key Infrastructure (RPKI) provides a framework to secure the Internet routing by associating IP address blocks with public key certificates. Route Origin Authorizations(ROAs) allow the holder of an IP prefix to authorize an Autonomous System (AS) to originate routes for that prefix. In the RPKI hierarchy, IP resources are delegated from a parent Certification Authority (CA) to a child CA. Upon delegation, the child CA typically gains effective operational authority over those resources. However, some RPKI implementations permit parent CAs to issue ROAs for delegated resources, leading to conflicts and undermining the RPKI trust model. This document establishes a Best Current Practice (BCP) that RECOMMENDS restrictions on ROA issuance by parent CAs for delegated resources, while providing flexible operational guidance to support legitimate BGP practices such as announcing covering prefixes alongside more-specific customer announcements.

Requirements Language 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.

Problem Statement When a parent CA delegates resources to a child CA, authority over those resources is generally expected transferred. However, parent CAs sometimes issue ROAs for those delegated resources. This can lead to the following issues:

Competing ROAs : Multiple ROAs may exist for the same IP prefix, issued by both parent and child CAs.
Validation ambiguity: Relying party (RP) software cannot prioritize between competing ROAs, including all valid ROAs in validated ROA payloads(VRPs). This may lead to routing decisions that conflict with the delegation model(e.g., a parent CA's ROA for 192.0.2.0/24 authorizing AS1, and a child CA's ROA for the same prefix authorizing AS2).
Security risk: A malicious or compromised parent CA could issue ROAs to hijack routes or disrupt legitimate routing. Note that this BCP primarily mitigates misconfigurations rather than providing complete protection against a fully malicious parent CA, which retains other powers (e.g., certificate revocation or resource modification)

These issues directly affect the security and stability of the Internet routing system, as RPKI data is used to validate route origins and influence routing decisions.

Best Current Practice To ensure consistency and security in the RPKI ecosystem, the following practices are RECOMMENDED:

Parent CAs SHOULD NOT issue ROAs for resources delegated to a child CA. If legacy ROAs exist, the parent CA SHOULD revoke them in coordination with the child CA to minimize disruption.
RPKI CA software SHOULD warn or reject ROAs issued for resources that have been delegated to a child CA (i.e., resources no longer within the issuer's effective authority due to delegation).
Relying party (RP) software SHOULD flag ROAs issued by a parent CA for resources delegated to a child CA, issuing warnings during validation. The detection rule is:verify if a parent CA's ROA prefix overlaps with resources delegated to a child CA.
It is RECOMMENDED that only leaf CAs(CAs that have not delegated resources further) issue ROAs. Restricting ROA issuance to leaf CAs clarifies authority, prevents overlapping or competing ROAs between parent and child CAs, and reduces risks of misconfiguration or misuse that could lead to routing incidents. If a non-leaf CA issues a ROA, RP software triggers an warning during validation. This recommendation is consistent with the above restriction on parent CAs and extends the principle by specifying that only CAs without further delegation (leaf CAs) should perform ROA issuance.
Operational Guidance for Covering Prefixes and Customer Delegations: When an ISP holds a covering prefix (e.g., a /16) and delegates a more-specific prefix (e.g., a /24) to a customer:
- If the delegation occurs within the same administrative domain or the ISP wishes to retain operational control, the shared CA model is RECOMMENDED. The ISP and customer operate under a common CA certificate. This allows the ISP to issue ROAs for both the covering prefix and the more-specific delegation, supporting common BGP practices such as announcing an aggregate alongside customer more-specifics. In such cases, creating a separate child CA is NOT RECOMMENDED and is often discouraged.
- If the customer requires full control (independent ROA management and announcement from a different origin AS), the parent/child CA model MAY be used. The child CA issues the ROA for the more-specific prefix, while the parent MAY retain a ROA for the covering prefix if needed for its own announcements. RP software SHOULD flag such overlapping ROAs for operator review but MUST NOT automatically invalidate them.
In cases where a parent CA, such as a Regional Internet Registry (RIR), operates its own network and needs to issue ROAs for the resources it directly holds (i.e., resources not delegated to child CAs), it is RECOMMENDED that the parent CA create a dedicated subordinate CA for those resources. ROAs should then be issued from this subordinate CA, maintaining clear separation between allocation and operational roles.
Operators of RPKI CAs SHOULD implement monitoring to detect ROA misconfigurations, with automated alerts for unauthorized issuance.
Regional Internet Registries (RIRs) and other certification authorities are encouraged to update their RPKI documentation and user interfaces to clearly communicate these restrictions to end users.

IANA Considerations This memo includes no request to IANA.

Security Considerations Failure to enforce ROA issuance restrictions can lead to serious security consequences, including:

Route hijacking: An compromised parent CA could issue ROAs to redirect traffic.
Routing blackhole: If a parent CA issues an ROA for a delegated prefix (e.g., 192.0.2.0/24 authorizing AS1) and the child CA, holding the same prefix, does not issue an ROA but announces via AS2, the route may be marked "Invalid" per [RFC6811], causing traffic to be dropped and resulting in a routing blackhole.
Erosion of trust: Ambibuities in ROA authority reduce confidence in RPKI.

This BCP primarily addresses misconfigurations and unintended authority overlaps. It does not prevent all possible actions by a malicious or compromised parent CA, which could still revoke child certificates, shrink resource sets, or re-delegate resources. Strict enforcement at both the CA and relying party levels is essential to maintaining the integrity of the global routing system. This document reinforces the principle of least authority within the RPKI hierarchy.

Special Considerations In operational environments, organizations may delegate resources internally to subsidiaries or to external customers while needing to announce covering prefixes themselves. When the more-specific prefix belongs to a different legal entity requiring independent control of its BGP announcements, the parent/child CA model may be necessary. This document does not invalidate such configurations, nor does it impact the validity of BGP announcements containing both covering prefixes and more-specifics. The focus is strictly on minimizing cryptographic authority conflicts to prevent validation ambiguity. Resources MAY appear on multiple CA certificates for legitimate purposes such as key rollovers and make-before-break transfers.