Route Origin Authorizations: The Core Authorization Object

Author

K19G

Updated

October 31, 2026

Route Origin Authorizations: The Core Authorization Object

In the RPKI ecosystem, the digital object that directly governs BGP route validation is the Route Origin Authorization (ROA), defined in RFC 6482. A ROA is a cryptographically signed statement that specifies which Autonomous System is authorized to originate a given IP prefix into the global BGP routing system.

What a ROA Is and What It Proves

A ROA is an encapsulated Cryptographic Message Syntax (CMS) signed object. It contains a signed payload that binds: 1. An Autonomous System Number (ASN). 2. One or more IP prefixes (IPv4 or IPv6). 3. An optional Maximum Length (maxLength) for each prefix.

A valid ROA proves that the legitimate holder of the IP address space has authorized the specified AS to originate BGP announcements for that address block up to the specified prefix length.

Crucially, a ROA proves origin authorization only. It does not prove: - That the originating AS has active physical connectivity to the Internet. - That the AS path between the origin and the receiving router is honest or loop-free. - That the originating AS will actually forward data plane traffic.

Creating a ROA: Prefix, AS Number and Maximum Length

When a network operator creates a ROA through their RIR portal (e.g., ARIN Online, RIPE NCC LIR Portal) or via a delegated Krill CA, the ROA payload structure is formatted as follows:

RouteOriginAttestationPayload ::= SEQUENCE {
    asID            ASID,
    ipAddrBlocks    SEQUENCE OF ROAIPAddressFamily
}

ROAIPAddressFamily ::= SEQUENCE {
    addressFamily   OCTET STRING (2 octets),  -- IPv4 or IPv6
    addresses       SEQUENCE OF ROAIPAddress
}

ROAIPAddress ::= SEQUENCE {
    address         IPAddress,                -- e.g., 198.51.100.0/22
    maxLength       INTEGER OPTIONAL          -- e.g., 24
}

Example ROA entry: - Prefix: 198.51.100.0/22 - Origin ASN: AS65001 - Maximum Length (maxLength): 24

This ROA authorizes AS65001 to originate the aggregate /22, as well as any constituent /23 or /24 subprefixes (e.g., 198.51.100.0/24, 198.51.101.0/24). It explicitly forbids AS65001—and every other AS on Earth—from originating prefixes longer than /24 (such as a /25).

Max-Length: How It Controls Subprefix Authorization

The maxLength attribute is an operational convenience, but it represents the most dangerous trap in RPKI:

ROA Configuration Authorized Announcements Unauthorized Announcements (Flagged INVALID)
198.51.100.0/22 without maxLength Exactly 198.51.100.0/22 only from AS65001 Any /23, /24, or subprefix from any AS (including AS65001)
198.51.100.0/22 with maxLength: 24 198.51.100.0/22, and any /23 or /24 from AS65001 Any /25 or longer from AS65001; ANY prefix from any other AS

The maxLength Security Vulnerability (RFC 9319)

If an operator announces only 198.51.100.0/22 in BGP, but creates a ROA with maxLength: 24 “just in case we want to split it later”, an attacker can execute a forged-origin subprefix hijack: 1. The attacker announces 198.51.100.0/24 with AS_PATH: [Attacker_AS, 65001]. 2. The router evaluating ROV checks the origin: the origin is AS65001. 3. The router checks prefix length: /24 is \(\le 24\) (maxLength). 4. The router flags the attacker’s announcement as VALID! 5. Longest Prefix Match directs all traffic for that /24 to the attacker.

[!IMPORTANT] RFC 9319 Best Current Practice: Do not use maxLength unless actively necessary. Instead, create explicit minimal ROAs matching the exact prefix lengths currently advertised in BGP. If you announce a /22 and two /24s, publish three distinct ROAs with exact lengths.

ROA Lifespan, Expiration and Revocation

ROAs are cryptographic objects with a defined validity period (notBefore and notAfter dates, typically 12 to 36 months).

  • Automated Re-signing: Hosted RIR CAs automatically re-sign ROAs prior to expiration. If an operator runs a delegated CA (e.g., Krill) and lets the daemon crash or neglect automated re-signing, the ROA expires. Once expired, the prefix transitions from Valid to NotFound.
  • Revocation: If a network changes upstream providers or reassigns an IP block, the old ROA is revoked. The CA signs a Certificate Revocation List (CRL) and publishes a new manifest.

Common Mistakes: Over-Permissive, Under-Covered and Conflicting ROAs

  1. Under-Covered ROAs (Self-Inflicted Outage): An operator announces 198.51.100.0/24 in BGP, but registers a ROA for 198.51.100.0/22 without maxLength. The router running ROV flags the operator’s own /24 announcement as INVALID because the announced prefix length (\(24\)) exceeds the authorized length (\(22\)). Upstream transit networks drop the route, severing connectivity.
  2. Conflicting Multi-Origin ROAs: When transitioning between transit providers, an operator must ensure that ROAs for both ASNs exist concurrently before shifting BGP traffic, preventing temporary Invalid states during convergence.
  3. Ghost ROAs: Retaining active ROAs for IP space that was transferred or sold to another organization.