Technical guide
What is Route Origin Authorization (ROA)
A Route Origin Authorization (ROA) is a cryptographically signed object within the Resource Public Key Infrastructure (RPKI) that allows an IP address resource holder to specify which Autonomous System (AS) is authorized to originate routes for particular IP prefixes. ROAs provide network operators with verifiable information that can be used to evaluate the origin of Border Gateway Protocol (BGP) announcements.
ROAs are an important part of modern routing security because BGP itself does not cryptographically verify whether the Autonomous System announcing an IP prefix has been authorized by the resource holder. When combined with Route Origin Validation (ROV), ROA data helps networks identify announcements whose origin information conflicts with published routing authorization.
However, a ROA does not validate the complete BGP path and does not prevent every type of route leak or routing incident. Understanding exactly what a ROA authorizes — and how to configure it correctly — is essential for maintaining both routing security and network continuity.
Table of Contents
What Is Route Origin Authorization (ROA)?
What Information Does a ROA Contain?
How ROA and RPKI Work Together
ROA Validation: Valid, Invalid and NotFound
How ROA Helps Reduce BGP Hijacking Risk
What ROA Does Not Protect Against
Common ROA Configuration Mistakes
Key takeaway: A ROA answers a specific routing-security question: which Autonomous System is authorized to originate this IP prefix? It provides cryptographically verifiable authorization for route origin validation, but it does not validate the entire BGP path or replace broader routing-security controls.
What Is Route Origin Authorization (ROA)?
A Route Origin Authorization (ROA) is a digitally signed RPKI object through which an IP address resource holder authorizes a particular Autonomous System Number (ASN) to originate routes for one or more IP prefixes.
ROAs form part of the Resource Public Key Infrastructure. Their purpose is not to tell routers which path is best. Instead, they provide verifiable authorization information that network operators can compare with BGP announcements.
For example, an organization controlling an IPv4 prefix may create a ROA stating that AS64500 is authorized to originate that prefix. Networks performing Route Origin Validation can then compare observed BGP announcements with the authorization.
The current IETF standard defining the ROA profile is RFC 9582, published in 2024, which replaced the earlier RFC 6482 specification.
Why Is ROA Important?
Border Gateway Protocol (BGP) is responsible for exchanging routing information between Autonomous Systems across the Internet. BGP allows networks to announce which IP prefixes they can reach, but traditional BGP does not contain a built-in cryptographic mechanism proving that the origin ASN is authorized by the holder of that address space.
This creates the possibility that an incorrect ASN could announce another network's prefix, whether through configuration error or malicious activity.
Why ROAs Matter
Origin authorization: A ROA provides verifiable information about which ASN is permitted to originate an IP prefix.
BGP hijack detection: Networks using ROV can identify announcements that conflict with published ROA information.
Routing accuracy: Correct ROAs provide operators with an additional signal for evaluating incoming BGP routes.
Operational protection: Accurate route authorization can reduce exposure to certain accidental or unauthorized origin announcements.
How Does a ROA Work?
ROA-based route validation involves several separate components. The resource holder publishes the authorization, RPKI validation software verifies the cryptographically signed data, and network operators decide how the resulting validation information should influence BGP routing policy.
ROA Validation Process
1. Determine the intended BGP announcement: The resource holder identifies the IP prefix, originating ASN, and any legitimate more-specific prefixes that should be announced.
2. Create the ROA: The holder publishes an authorization specifying the permitted origin ASN and prefix information.
3. Publish the signed object: The ROA becomes available through the RPKI repository system.
4. Validate RPKI data: Relying Party software retrieves RPKI objects and performs cryptographic validation.
5. Generate validated authorization information: Validated ROA data is converted into information that routing systems can use for Route Origin Validation.
6. Apply local routing policy: The network operator determines how Valid, Invalid, and NotFound routes should be handled.
Important: BGP routers do not normally query an RPKI repository for every received route. Relying Party validation software retrieves and validates RPKI data, then provides validated authorization information to routers for use in routing policy.
What Information Does a ROA Contain?
For routing purposes, three pieces of information are particularly important when understanding a ROA:
| ROA Element | Purpose |
| Origin ASN | Identifies the Autonomous System authorized to originate the route. |
| IP Prefix | Defines the IPv4 or IPv6 address space covered by the authorization. |
| Maximum Length | Defines the most-specific prefix length that the authorized AS may originate when this optional value is used. |
A single ROA object authorizes one origin ASN. If the same address space must legitimately be originated by multiple Autonomous Systems, multiple ROAs can be created to represent those authorizations.
How ROA and RPKI Work Together
ROA and RPKI are closely related, but they are not the same thing. RPKI is the broader cryptographic framework for Internet number resources. A ROA is one type of signed object created within that framework.
| Term | Meaning |
| RPKI | The public key infrastructure used to create and validate cryptographically signed information associated with Internet number resources. |
| ROA | A signed RPKI object authorizing an ASN to originate one or more IP prefixes. |
| ROV | Route Origin Validation, the process of comparing BGP announcements with validated RPKI authorization data. |
Also Read: What Is RPKI and How Does It Work?
ROA Validation: Valid, Invalid and NotFound
When a BGP announcement is compared with validated RPKI authorization information, the origin-validation result is commonly classified as Valid, Invalid, or NotFound. Some interfaces may use the term Unknown for the third state.
| Status | Meaning |
| Valid | At least one validated authorization covers the route and permits its origin ASN and prefix length. |
| Invalid | A covering authorization exists, but the announcement has an unauthorized origin ASN or exceeds the permitted prefix length. |
| NotFound | No validated ROA payload covers the announcement. |
An Invalid route should not automatically be interpreted as proof of an attack. Legitimate routes can become Invalid because of an outdated ROA, incorrect ASN, migration, or improperly configured maximum length.
What Is maxLength in a ROA?
The optional maxLength field determines how specific an announcement may be while remaining authorized by that ROA.
Suppose an organization controls 203.0.113.0/24. If it authorizes AS64500 to originate only that exact /24, it does not need to permit additional more-specific prefixes.
If the organization legitimately needs AS64500 to advertise /25 prefixes inside the /24, the authorization can permit more-specific announcements up to /25.
Best practice: Do not automatically set maxLength to the largest possible value. Authorize only the prefix lengths required by the actual routing design. Excessively broad authorization can reduce the precision of the protection ROA is intended to provide.
How ROA Helps Reduce BGP Hijacking Risk
A BGP prefix hijack can occur when an Autonomous System originates address space that it is not authorized or expected to originate. Incorrect announcements may result from configuration mistakes or malicious activity.
Publishing an accurate ROA allows networks performing ROV to distinguish an authorized origin from an announcement that conflicts with the resource holder's published authorization.
Example
A resource holder authorizes AS64500 to originate 203.0.113.0/24.
If AS64500 originates the authorized route, the announcement can receive a Valid origin-validation state.
If AS64501 instead originates the covered prefix without matching authorization, the announcement can become Invalid. Networks performing ROV can then apply their own routing policy to that result.
What ROA Does Not Protect Against
ROA is a valuable security mechanism, but its function should not be overstated. Standard ROA-based Route Origin Validation focuses specifically on route origin authorization.
| Question | ROA / ROV Coverage |
| Is the origin ASN authorized for this prefix? | Yes — this is the core purpose of ROA-based validation. |
| Is the entire AS_PATH legitimate? | No — ordinary ROA-based ROV does not validate the complete BGP path. |
| Will it prevent every route leak? | No — a route leak can retain an authorized origin ASN and therefore remain origin-valid. |
| Does it replace route filtering? | No — operators still need BGP filtering, monitoring, routing policy, and incident-response controls. |
This distinction is especially important because describing ROAs as a general solution for route leaks can create an inaccurate expectation of their protection scope.
How to Create a ROA
The exact process for creating a ROA depends on how the organization's RPKI certification environment is managed. Internet number resource holders commonly interact with RPKI services associated with the appropriate Regional Internet Registry or operate delegated RPKI infrastructure where applicable.
Before creating the authorization, the network team should determine the intended production routing configuration.
Before Creating a ROA, Confirm:
• Which IPv4 or IPv6 prefixes will be announced.
• Which ASN will originate each prefix.
• Whether more-specific prefixes will be announced.
• The appropriate maximum prefix length.
• Whether multiple origin ASNs require separate authorizations.
• Whether any ASN migration, provider change, or routing transition is planned.
Once published, the ROA should be checked against the organization's actual BGP announcements. Monitoring should continue after deployment rather than treating ROA creation as a one-time configuration task.
Common ROA Configuration Mistakes
Wrong Origin ASN
If the ASN specified in the ROA does not match the ASN actually originating the route, a legitimate announcement can become Invalid.
Incorrect Maximum Length
A network may legitimately advertise more-specific prefixes, but if the authorization does not permit those prefix lengths, the announcements may be classified as Invalid.
Overly Broad maxLength
Allowing substantially more-specific prefixes than the network intends to announce can unnecessarily broaden the scope of the authorization.
Forgetting to Update ROAs During Migration
If a network changes upstream providers or moves a prefix to another origin ASN, its routing authorization should be coordinated with the migration. Otherwise, the new legitimate route may become Invalid.
Deleting Authorization Too Early
During routing migrations, removing the old authorization before traffic has completely moved can create temporary origin-validation problems. Authorization changes and BGP changes should follow a controlled sequence.
ROA Best Practices for Network Operators
ROA Operational Checklist
Match ROAs to real BGP: Authorization should reflect actual production announcements.
Keep maxLength restrictive: Permit only the more-specific prefixes required by the routing design.
Coordinate routing changes: Update authorization when changing ASN, upstream provider, anycast architecture, or prefix structure.
Monitor validity externally: Check how the prefix appears from outside the local network after changes.
Investigate Invalid routes promptly: Invalid does not always mean malicious activity; configuration errors should be ruled out quickly.
Maintain independent routing visibility: ROA status should be considered alongside BGP monitoring and operational network data.
Document responsibility: Define which team is responsible for changing ROAs when routing architecture changes.
ROA and IP Address Management
ROA management demonstrates why public IP address management extends beyond simply possessing or accessing an address block. A production IPv4 or IPv6 resource must also be correctly routed, registered, authorized, monitored, and maintained.
This becomes particularly important during IPv4 leasing, network migrations, provider changes, multi-homing, and infrastructure expansion. Routing authorization must remain aligned with the actual origin ASN throughout the operational lifecycle.
LARUS perspective: A usable IP resource is more than an address entry. Production continuity depends on the address block, routing configuration, authorization records, reputation, operational documentation, and network deployment remaining aligned. ROA is one important part of that broader management process.
Organizations managing public IPv4 resources should therefore include ROA and RPKI review in their routing-change procedures rather than treating them as separate administrative tasks.
Conclusion
Route Origin Authorization is one of the most important components of RPKI-based routing security. A ROA allows an IP address resource holder to publish cryptographically verifiable authorization stating which Autonomous System may originate specified IP prefixes.
Networks performing Route Origin Validation can compare BGP announcements with this authorization and classify route origins as Valid, Invalid, or NotFound. This provides an additional security signal that can help identify certain unauthorized or misconfigured origin announcements.
ROAs must nevertheless be managed carefully. An incorrect origin ASN, overly restrictive or overly broad maximum length, or poorly coordinated routing migration can affect legitimate route validation. ROA also does not validate the complete BGP path or eliminate every form of route leak.
For network operators, ROA should therefore be treated as part of a broader routing and IP resource management strategy combining accurate authorization, BGP monitoring, route filtering, change control, and operational continuity.
Frequently Asked Questions
1. What does ROA stand for?
ROA stands for Route Origin Authorization. It is a signed RPKI object that authorizes an Autonomous System to originate routes for specified IP prefixes.
2. What is the difference between ROA and RPKI?
RPKI is the broader cryptographic infrastructure for Internet number resources. A ROA is one type of signed object within RPKI that describes route-origin authorization.
3. What information is included in a ROA?
For routing purposes, a ROA identifies an authorized origin ASN and one or more IP prefixes. Each prefix can also include an optional maximum length defining how specific an authorized BGP announcement may be.
4. What does a Valid ROA mean?
A Valid route-origin state means the BGP announcement is covered by at least one validated authorization that permits its origin ASN and prefix length.
5. What does RPKI Invalid mean?
Invalid means a covering authorization exists, but the BGP announcement does not match an authorized origin ASN or permitted prefix length.
6. What does NotFound mean?
NotFound means that no validated ROA covers the announced prefix. It is different from Invalid and does not itself indicate unauthorized routing.
7. Does ROA stop BGP hijacking?
ROA-based Route Origin Validation can help networks identify certain unauthorized route origins when appropriate ROAs exist. It reduces risk but does not prevent every form of BGP hijacking.
8. Does ROA prevent route leaks?
Not necessarily. A route leak may still originate from the correct authorized ASN and therefore appear Valid under Route Origin Validation. ROA does not validate the complete AS path.
9. Can a wrong ROA disrupt legitimate routing?
Yes. Incorrect ASN or prefix-length authorization can make legitimate BGP announcements Invalid. Networks that reject Invalid routes may then stop accepting those announcements.
10. When should a ROA be updated?
ROAs should be reviewed whenever the origin ASN, prefix structure, more-specific announcements, upstream architecture, or other relevant routing configuration changes.
Production IPv4
Need IPv4 for a live network?
Check available capacity, then choose the Continuity level that matches the cost of disruption and renumbering.