| Internet-Draft | ROA-BCP | October 2025 |
| Zhang, et al. | Expires 16 April 2026 | [Page] |
This document specifies best current practices for Resource Public Key Infrastructure (RPKI) operators regarding Route Origin Authorizations (ROAs). It mandates that a parent Certification Authority (CA) MUST NOT issue ROAs for Internet number resources delegated to a child CA. RPKI certification authorities(CA software) and relying party software are required to enforce this restriction by rejecting or flagging invalid ROAs issued outside of resource allocations.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Resource Public Key Infrastructure (RPKI) [RFC6480] provides a framework to secure the Internet routing by associating IP address blocks with public key certificates. Route Origin Authorizations(ROAs) [RFC9582] 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, transferring exclusive 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) to specify that only the entity holding the resource certificate with effective authority for a prefix may issue ROAs for that prefix. Effective authority is transferred to the child CA upon delegation, and the parent CA MUST NOT issue ROAs for those resources.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
When a parent CA delegates resources to a child CA, authority over those resources is exclusively transferred. According to the RPKI architecture [RFC6480], the parent CA relinquishes operational control and MUST NOT issue ROAs for delegated resources. However, in practice, some RPKI systems permit this leading to the following issues:¶
Competing ROAs [RFC8211]: 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.¶
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.¶
To ensure consistency, security in the RPKI ecosystem, the following practices are RECOMMENDED:¶
Parent CAs MUST 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 MUST reject ROAs issued for resources outside the issuer's certified resources, defined as those resources in the CA's active certificate, excluding delegated portions.¶
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.¶
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.¶
This memo includes no request to IANA.¶
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.¶
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.¶
In some operational environments, organizations may delegate resources internally to subsidiaries or business units. In such cases, the parent organization may still need to issue ROAs that cover subsidiary resources. The recommended practice is to avoid using the parent/child CA model for this purpose. Instead, the parent and subsidiary should share a common CA certificate within the same administrative domain, and implement internal controls to ensure that ROAs are issued according to IP allocation rules. This prevents conflicts and ensures compliance with the principle of least authority within the global RPKI framework.¶