Route Origin Authorization (ROA) Governance for Anycasted Services with Unique Origin ASNs

Introduction 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 , 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.

Conventions Used in This Document

Anycast:: the practice of making a particular service address available in multiple, discrete, autonomous nodes, such that data-grams sent are routed to one of several available nodes .
Multi-origin Autonomous System:: a particular setup of Anycast routing, where each node originating the same service is identified by a unique Autonomous System Number (ASN) .

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 . They key words "VALID", "INVALID" and "UNKNOWN", are to be interpreted as RPKI validity states as described in 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 when, and only when, they appear in all capitals, as shown here.

Single-prefix Minimal ROAs 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 . Doing so, ensures that routes of a MOAS prefix do not share fate with unrelated resources.

Sequential-Use EE Certificate 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 ). 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.

Single Signing Time 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 .

Synchronous Operations 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 , 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 .

IANA Considerations This document makes no requests of IANA.

Security Considerations This section will be added later based on community review and feedback