What is a ROA?
A ROA (Route Origin Authorization) is a signed RPKI record stating which AS may originate a prefix and its maximum allowed prefix length (maxLength).
Last updated:
A ROA (Route Origin Authorization) is a digitally signed RPKI object in which the holder of a prefix declares which autonomous system (AS) is allowed to originate that prefix in BGP, and up to which maximum prefix length. The ROA is the foundation of Route Origin Validation (ROV). From it, a router or validator decides whether a given BGP announcement is legitimate or instead signals a hijack or a misconfiguration.
What a ROA record contains
A ROA binds three pieces of information together and is signed with a certificate tied to the resource allocation, whose chain of trust leads back to the trust anchor of the relevant regional registry (RIR), such as RIPE NCC. The ROA format is defined in RFC 6482, and its use for validating routes is defined in RFC 6811.
- The IPv4 or IPv6 prefix (or set of prefixes) the authorization covers.
- The AS number authorized to originate that prefix as the origin AS.
- maxLength: the longest prefix length the prefix may be announced at; omitting it means only the exact prefix length is valid.
- The digital signature and certificate chain leading to the RIR trust anchor.
ROA and validation states: valid, invalid, unknown
During Route Origin Validation (ROV), a router compares the announced prefix and origin AS against the set of ROAs fetched from a validator and assigns one of three states. A single ROA can cover multiple prefixes and multiple AS numbers, but each pairing is evaluated separately.
- Valid: a ROA exists whose origin AS matches the announcement and whose prefix length falls within maxLength.
- Invalid: a ROA exists for the prefix, but the origin AS differs or the prefix is longer than maxLength. This is a sign of a hijack or a mistake.
- Unknown (NotFound): no ROA covers the prefix, so its correctness cannot be decided.
The maxLength trap and ROA hygiene
The most common mistake when creating a ROA is too broad a maxLength. Setting /24 on a /22 that you do not actually deaggregate opens the door for an attacker to announce a more specific, still-valid prefix. Good practice (per BCP 185 / RFC 7115) is a maxLength equal to the length you actually announce. An expired certificate or a typo in the AS number can turn your own routes invalid overnight, so ROA status must be monitored continuously.
ROA in the AS202520 SkyPass network
For every prefix we originate as AS202520 we publish ROAs with the correct origin AS and a maxLength matched to the actual length. On our BGP sessions across IP transit, peering, and remote access in THINX, TPIX, WRIX, and 1-IX, we drop invalid routes. If you announce prefixes through our IP transit or peering, we help you verify your ROAs so that traffic is not blocked by a wrong maxLength or an expired certificate.
Frequently asked questions
How is a ROA different from RPKI?
RPKI is the whole public key infrastructure for internet resources. A ROA is one specific signed record within it that states which AS may originate a given prefix and up to which maxLength.
What should I set maxLength to?
The safest value is a maxLength equal to the length of the prefix you actually announce. Too broad a maxLength lets an attacker announce a more specific prefix that is still evaluated as valid.
Will a missing ROA block my routes?
No. A prefix with no ROA gets the unknown (NotFound) state and is accepted normally. Only invalid routes are dropped, that is, those where a ROA exists but does not match.
Where do I create a ROA?
In your RIR portal (for example RIPE NCC), using a certificate tied to your allocated addresses and AS number. The record is then published and fetched by validators worldwide.