A Profile for Route Origin Authorizations (ROAs)
obsoleted by
- rfc-9582 — A Profile for Route Origin Authorizations (ROAs)
Extracted elements (18)
The ipAddrBlocks syntax is more restrictive than RFC 3779's IP address delegation extension: RFC 3779 can represent arbitrary address ranges, but ROAs need only represent prefixes. This constraint reflects the routing use case where prefixes, not arbitrary ranges, are advertised.
A ROA MAY contain two ROAIPAddress elements with identical IP address prefixes, but this is NOT RECOMMENDED because the element with the shorter maxLength grants no additional privileges and can be omitted without changing the ROA's meaning.
Before using a ROA to validate a routing announcement, a relying party MUST first validate the ROA by performing all validation checks in RFC 6488 plus the ROA-specific step of verifying that each prefix in the ROA is contained within the EE certificate's IP address delegation extension.
If present, the maxLength MUST be an integer greater than or equal to the length of the accompanying prefix and less than or equal to the maximum prefix length for the address family (32 for IPv4, 128 for IPv6).
The IP address delegation extension (RFC 3779) MUST be present in the EE certificate contained within the ROA, and each IP address prefix in the ROA must be contained within the set of IP addresses specified by that extension.
The ROA content-type OID 1.2.840.113549.1.9.16.1.24 MUST appear within the eContentType in the encapContentInfo object as well as the content-type signed attribute in the signerInfo object.
The version number of the RouteOriginAttestation MUST be 0.
Within ROAIPAddressFamily, the addressFamily field MUST be either 0001 (IPv4) or 0002 (IPv6); no other address families are supported.
A ROA (Route Origin Authorization) is a CMS-wrapped digitally signed object that authorizes a single AS to originate routes to one or more IP address prefixes. It uses the RPKI signed object template defined in RFC 6488.
The asID field contains the AS number authorized to originate routes to the prefixes listed in the ROA. If multiple ASes need authorization for the same prefixes, the address space holder must issue multiple ROAs, one per AS.
The maxLength field, when present, specifies the maximum prefix length the AS is authorized to advertise. When absent, the AS is only authorized to advertise the exact prefix in the ROA. For example, prefix 203.0.113/24 with maxLength 26 authorizes any more-specific up to /26.
The ROA content-type OID is routeOriginAuthz with numerical value 1.2.840.113549.1.9.16.1.24. This OID MUST appear in both the eContentType in encapContentInfo and the content-type signed attribute in signerInfo.
IANA has registered the ROA as an RPKI Signed Object with OID 1.2.840.113549.1.9.16.1.24, referencing RFC 6482.
ROAs provide no confidentiality guarantee and are expected to be publicly accessible to all ISPs and Internet users. There is no explicit per-message authentication; the PKI provides authorization but not authentication, and there is no intent to convey non-repudiation.
The integrity of a ROA MUST be established. ROAs use the RPKI signed object format (RFC 6488) with CMS signed message structure, inheriting all security considerations from both. The ROA signer's right to authorize an AS is established through the address space and AS number PKI (RFC 6480).
To verify a ROA, one MUST verify the ROA signature using an X.509 certificate issued under the RPKI (RFC 6480) and check that the prefixes in the ROA match those in the certificate's address space extension.
ROAIPAddressFamily ::= SEQUENCE { addressFamily OCTET STRING (SIZE(2..3)), addresses SEQUENCE (SIZE(1..MAX)) OF ROAIPAddress }. ROAIPAddress ::= SEQUENCE { address IPAddress, maxLength INTEGER OPTIONAL }. IPAddress is encoded as BIT STRING.
The ROA eContent is defined as RouteOriginAttestation ::= SEQUENCE { version [0] INTEGER DEFAULT 0, asID ASID, ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily }, DER-encoded. The asID is an INTEGER holding the authorized AS number.