ROA/RPKI Validation

ROA/RPKI Validation

What is a ROA?

A ROA (Route Origin Authorization) is a cryptographically signed record that states which Autonomous System (ASN) is authorized to announce a specific IP prefix on the global internet.

ROAs are part of the RPKI (Resource Public Key Infrastructure) system, which helps secure internet routing.

RADb strictly enforces RPKI Validation.

RPKI Invalid objects can’t be created in RADb and Existing RPKI Invalid objects can’t be queried.

Example:

A ROA might say: “AS64500 is allowed to announce 203.0.113.0/24”

This information is published by a Regional Internet Registry (like ARIN, RIPE, or APNIC) and verified by routers that support RPKI Route Origin Validation (ROV).

How ROAs Work

  1. Created by Resource Holders – Only the holder of an IP prefix can create a ROA.

  2. Published in RPKI Repositories – ROAs are stored and made available for routers to fetch.

  3. Validated by Networks – Routers using RPKI validation can compare BGP routes against ROAs and tag them as:

    • Valid – Prefix and ASN match

    • Invalid – Prefix exists in ROA, but ASN doesn’t match

    • Not Found – No ROA exists for the prefix

Understanding Max-Length

The maxLength field in a ROA defines the longest prefix (smallest subnet) that the ASN is allowed to announce.

Example:

If your ROA says:

Prefix: 203.0.113.0/24
Max Length: 24
ASN: AS64500

Then AS64500 is only authorized to announce 203.0.113.0/24 — nothing more specific.

If instead the max length were set to 26, AS64500 could also announce:

  • 203.0.113.0/25

  • 203.0.113.128/25

  • 203.0.113.0/26

  • etc.

Important: Be cautious with max-length. Setting it too high (like /32) can unintentionally allow hijacks or overly granular announcements to be considered "valid."

How ROAs Relate to RADb

  • RADb is a traditional IRR (Internet Routing Registry) where operators manually register routing data (like route objects) to document which ASN is announcing which prefix.

  • ROAs are a cryptographically verified version of this same idea, but managed through RPKI instead of a registry like RADb.

Key Differences:

Feature

RADb

ROA (RPKI)

Feature

RADb

ROA (RPKI)

Verification

Manual, not cryptographically secure

Cryptographically signed

Entry Control

Anyone with maintainer access

Only the IP prefix holder

Used For

IRR-based routing filters

RPKI-based origin validation

Tooling

Whois, IRRd, bgpq3, etc.

RPKI validators (Routinator, OctoRPKI, etc.)

Should I Use Both?

Yes — for now, many networks still rely on IRR data from RADb for routing filters, but RPKI/ROA adoption is growing rapidly.

Creating ROAs for your prefixes is highly recommended for modern routing security.

Best Practice: Keep your RADb route objects and ROAs consistent.

If your route object says AS64500 announces 203.0.113.0/24, your ROA should say the same.

Please contact RADb Support for Assistance at support@radb.net or (734) 527-5776.