| Internet-Draft | ROAs for Unique Origin Anycast | September 2025 |
| Poulopoulos, et al. | Expires 7 March 2026 | [Page] |
This document describes a set of best practices for the management of Route Origin Authorizations (ROAs) used to certify globally anycasted services with unique origin autonomous system numbers (ASNs) per node. It identifies key risk areas related to anycast-based ROA publication and how to mitigate technical risk for RPKI operations.¶
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 7 March 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.¶
Anycasting, the origination of a prefix from multiple nodes, is an internet design pattern for improving the performance, stability and resiliency of global networks and is commonly implemented by DNS, CDN and DDoS protection service operators. This approach can result in lower latency and can simplify fail-over. An anycast node can be easily taken offline via withdrawl of its BGP route, causing traffic to automatically shift to other available nodes.¶
Anycast services originating from unique origin ASNs per node [RFC6382], originate a single prefix from multiple distinct ASNs. The approach allows for more precise monitoring and troubleshooting of routing anomalies or hijacks. The primary benefit is enhanced observability of anycasted services, especially when a large number of nodes are in operation.¶
This design (distinct origin ASNs) calls for specific considerations when publishing Route Origin Authorizations (ROA). Certifying origins of a Multiple Origin Autonomous System (MOAS) prefix implies the existence of a set of ROAs to certify all origins of the prefix. Given the exclusive nature of route origin validation (ROV), partial ROA coverage of MOAS prefixes MUST be avoided, as it would result in "INVALID" prefix/origin pairs for non-covered origins. In this instance, absence of coverage is preferable over partial coverage as it would make all prefix/origin pairs resolve to RPKI "UNKNOWN".¶
This document presents a set of recommendations meant to avoid partial ROA coverage of MOAS prefixes, by ensuring shared fate among the set of ROAs covering them.¶
The terms "MOAS Service" and "MOAS Prefix" are used throughout this document as a convenience shorthand for the more verbose "Globally Anycasted Service with Unique Origin Autonomous System Numbers per Node".¶
The terms "covering", "covered", when used to describe the effect of a ROA on a prefix/origin pair, are to be interpreted in the intuitive sense of "certified by". They are not to be interpreted in the more restrictive sense employed by other writings, where "covering" only applies to the prefix of a prefix/origin pair [RFC6811] [RFC6483].¶
They key words "VALID", "INVALID" and "UNKNOWN", are to be interpreted as RPKI validity states as described in [RFC6483] when, and only when, they appear in all capitals, as shown here. ç 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.¶
Separate ROAs SHOULD be published for each prefix/origin-AS pair of the MOAS prefix. This entails that these ROAs should contain a single prefix and the maximal length should be equal to the prefix length, i.e., be minimal ROAs [RFC9319].¶
Doing so, ensures that routes of a MOAS prefix do not share fate with unrelated resources.¶
A set of ROAs covering origins of a MOAS prefix SHOULD be signed using the same End-Entity (EE) certificate (a.k.a. "sequential use" EE certificate [RFC6487]).¶
This guarantees a common validity period among all origins of the prefix, avoiding partial expiry or partial revocation within the ROA set.¶
Moreover, using a single EE certificate for all ROAs covering a MOAS prefix avoids unnecessary CRL bloating.¶
A set of ROAs covering origins of a MOAS prefix SHOULD present the same CMS signing time attribute.¶
This practice may also have positive consequences if the publication point uses the CMS signing time as a reference to override filesystem timestamps [RFC9589] [I-D.ietf-sidrops-publication-server-bcp].¶
Signing, publication and withdrawal of ROAs covering origins of a MOAS prefix SHOULD be synchronous to ensure shared fate among them and avoid partial coverage.¶
In the context of the RPKI publication protocol [RFC8181], clients SHOULD request publication or withdrawal of all ROAs related to the MOAS prefix as part of a single publication query message, preferably avoiding operations on resources unrelated to the MOAS prefix. Reciprocally, publication servers SHOULD honor atomicity of transactions requested as part of a single query message.¶
When creating ROAs as the consequence of the addition of new origin node to a MOAS service, ROAs covering existing nodes of the prefix SHOULD be renewed at the same time to preserve common signing and validity times among all origins of the prefix.¶
More broadly, any modification to a ROA covering a MOAS prefix SHOULD be accompanied by changes to all ROAs covering the same MOAS prefix to preserve uniform validity attributes across the set. Consequently, these changes SHOULD be published within a single RPKI Repository Delta Protocol (RRDP) serial increment, to ensure synchronicity on the relying party end [RFC8182].¶
This document makes no requests of IANA.¶
This section will be added later based on community review and feedback¶