A Profile for Route Origin Authorizations (ROAs)
obsoletes
- rfc-6482 — A Profile for Route Origin Authorizations (ROAs)
Extracted elements (24)
A canonical form for ipAddrBlocks is defined because the ASN.1 structure allows many different encodings of the same IP address information. Having a unique representation enables unambiguous comparison, deduplication, and validation by Relying Parties.
If an address space holder needs to authorize multiple ASes to advertise the same set of prefixes, the holder issues multiple ROAs, one per AS number. The ROA eContent identifies only a single AS.
The ipAddrBlocks syntax is more restrictive than the IP address delegation extension in RFC 3779 because ROAs only need to represent IP prefixes, not arbitrary address ranges.
RFC 9582 obsoletes RFC 6482 with the following significant changes: clarified IP address and AS identifier X.509 certificate extension requirements, strengthened ASN.1 formal notation, incorporated errata for RFC 6482, added a canonical form for ipAddrBlocks, and added an example ROA payload.
Before using a ROA, a Relying Party MUST perform all validation checks in RFC 6488 plus: (1) the EE certificate contains an IP address delegation extension covering every prefix in the ROA payload; (2) that extension MUST NOT contain 'inherit' elements; (3) the AS identifier delegation extension MUST NOT be present in the EE certificate.
Certification Authorities SHOULD use the canonical form for ipAddrBlocks and SHOULD anticipate that future Relying Parties will impose a strict requirement for this canonical form. The canonicalization builds on RFC 3779 Section 2.2.3.6.
If any ROA-specific validation check fails, the ROA in its entirety MUST be considered invalid and an error SHOULD be logged.
The addressFamily field MUST be either 0x0001 (IPv4) or 0x0002 (IPv6). IPv4 prefixes MUST NOT appear as IPv4-mapped IPv6 addresses.
The maxLength element SHOULD NOT be encoded if the maximum length is equal to the prefix length. Certification Authorities SHOULD anticipate that future Relying Parties will treat superfluous maxLength elements as encoding errors.
The OID id-ct-routeOriginAuthz MUST appear within both the eContentType in the encapContentInfo object and the content-type signed attribute in the signerInfo object.
The version field of the RouteOriginAttestation MUST be 0.
There MUST be only one ROAIPAddressFamily instance per unique AFI in the ROA; therefore the ROAIPAddressFamily structure MUST NOT appear more than twice.
When present, the maxLength element MUST be an integer greater than or equal to the accompanying prefix length and less than or equal to the maximum address length for the applicable address family (32 for IPv4, 128 for IPv6).
A canonical form for ipAddrBlocks is defined so that every set of IP address information has a unique representation. Each ROAIPAddress is mapped to an abstract 4-tuple (afi, addr, plen, mlen) and the set is sorted and deduplicated in ascending order by those four fields in priority order.
A Route Origin Authorization (ROA) is a CMS-wrapped, digitally signed object identified by OID id-ct-routeOriginAuthz (1.2.840.113549.1.9.16.1.24). It authorizes a single AS to originate routes to one or more IP address prefixes and uses the RPKI signed object template from RFC 6488.
IANA has allocated Decimal 75 (id-mod-rpkiROA-2023) in the 'SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)' registry for RFC 9582.
IANA has updated the application/rpki-roa media type in the 'Media Types' registry. The media type uses binary encoding, carries no active content, and is associated with the .roa file extension.
IANA has updated the id-ct-routeOriginAuthz entry (Decimal 24) in the 'SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)' registry to reference RFC 9582.
IANA has updated the .roa file extension entry in the 'RPKI Repository Name Schemes' registry to reference RFC 9582.
IANA has updated the Route Origination Authorization entry (OID 1.2.840.113549.1.9.16.1.24) in the 'RPKI Signed Objects' registry created by RFC 6488 to reference RFC 9582.
The integrity of a ROA MUST be established. The ROA uses the RPKI signed object format (CMS signed message), so all security considerations of RFC 6488 and CMS apply. The signer's right to authorize the target AS is established through the address space and AS number PKI described in RFC 6480.
There is no assumption of confidentiality for ROA data; ROAs are expected to be stored in publicly accessible repositories. There is no explicit authentication—the RPKI PKI provides authorization only, not authentication—and non-repudiation is not intended.
ROAIPAddressFamily contains a 2-octet addressFamily AFI field and an addresses sequence of ROAIPAddress elements. Each ROAIPAddress holds an address of type BIT STRING (the IP prefix) and an optional maxLength INTEGER.
The ROA eContent is the ASN.1 type RouteOriginAttestation, encoded in DER, containing: a version integer (default 0), an asID (ASID ::= INTEGER 0..4294967295), and an ipAddrBlocks sequence of 1 or 2 ROAIPAddressFamily elements.