Technical guide
What Is RPKI? How RPKI and ROA Secure BGP
Resource Public Key Infrastructure (RPKI) is a cryptographic framework designed to improve the security of Internet routing. It allows holders of IP address resources to publish verifiable information about which Autonomous System (AS) is authorized to originate their IP prefixes in the Border Gateway Protocol (BGP).
The most widely deployed use of RPKI today is Route Origin Validation (ROV). A network operator can compare a BGP announcement against cryptographically validated Route Origin Authorizations (ROAs) and determine whether the announced prefix and originating ASN are consistent with the authorization published for that address space.
RPKI does not replace BGP, determine the entire route a packet should follow, or eliminate every type of routing incident. Instead, it adds a verifiable authorization layer that helps operators identify incorrect or unauthorized route origins and make more informed routing decisions.
Table of Contents
What Is a Route Origin Authorization (ROA)?
RPKI Valid, Invalid and NotFound Explained
What Is Route Origin Validation?
How RPKI Helps Against BGP Hijacking
What RPKI Does Not Protect Against
Understanding the RPKI Trust Model
Common RPKI Configuration Problems
RPKI Best Practices for Network Operators
Key takeaway: RPKI helps answer a specific routing-security question: “Is this Autonomous System authorized to originate this IP prefix?” It strengthens BGP origin validation, but it does not validate the complete AS path or replace broader routing-security and operational controls.
What Is RPKI?
RPKI stands for Resource Public Key Infrastructure. It is a specialized public key infrastructure designed for Internet number resources, including IPv4 addresses, IPv6 addresses, and Autonomous System Numbers.
The RPKI architecture uses digital certificates and cryptographically signed objects to associate Internet number resources with authorization information. Its most common routing application is allowing a resource holder to specify which ASN is authorized to originate a particular IP prefix.
This is important because traditional BGP was not designed with a built-in mechanism for cryptographically confirming whether the network announcing an IP prefix is authorized to originate it.
Also Read: What Is Border Gateway Protocol (BGP)?
Why Is RPKI Needed?
The global Internet consists of thousands of independently operated Autonomous Systems exchanging routing information through BGP. Each network announces which IP prefixes it can reach, and neighboring networks use this information when selecting routes.
Without an additional validation mechanism, BGP itself does not cryptographically prove that the originating AS has authorization to announce a specific prefix. Incorrect announcements may occur because of configuration mistakes or deliberate attempts to redirect traffic.
RPKI Adds a Verifiable Authorization Layer
Without RPKI: A network receiving a BGP announcement does not have an RPKI-based cryptographic statement confirming whether the origin ASN is authorized for that prefix.
With RPKI: The receiving network can compare the announcement with validated ROA data and determine whether the origin authorization matches.
RPKI therefore improves the information available to network operators when they evaluate BGP route origins.
How Does RPKI Work?
RPKI follows the existing hierarchy of Internet number resource registration. Resource certificates describe IP address or ASN resources associated with entities within that hierarchy, while signed RPKI objects can be published and cryptographically validated by relying parties.
For route origin validation, the process can be simplified into five stages:
RPKI Process
1. Resource certification: Internet number resources are represented within the RPKI certification hierarchy.
2. ROA creation: A resource holder creates a Route Origin Authorization specifying which ASN may originate a prefix and, where applicable, the maximum permitted prefix length.
3. Publication: The signed RPKI objects are made available through RPKI repositories.
4. Validation: Relying Party software retrieves and cryptographically validates RPKI data and produces validated authorization information.
5. Routing policy: Network operators can provide the validated information to routers and use Route Origin Validation results as part of their local BGP policy.
What Is a Route Origin Authorization (ROA)?
A Route Origin Authorization (ROA) is a cryptographically signed RPKI object that states which Autonomous System is authorized to originate one or more IP prefixes covered by the authorization.
A ROA contains three particularly important elements:
IP prefix: The address block covered by the authorization.
Origin ASN: The Autonomous System authorized to originate the route.
Maximum prefix length: An optional value defining how specific an authorized announcement may be.
For example, if an organization holds 203.0.113.0/24 and intends AS64500 to originate exactly that /24, the corresponding authorization can identify AS64500 as the permitted origin.
The maximum-length setting requires careful attention. If legitimate more-specific announcements are required, they must be covered appropriately. At the same time, setting the maximum length more broadly than necessary can authorize more-specific announcements that the resource holder did not operationally intend.
Also Read: What Is Route Origin Authorization (ROA)?
RPKI Valid, Invalid and NotFound Explained
When a BGP route is evaluated using validated RPKI data, its origin-validation state is commonly classified as Valid, Invalid, or NotFound. NotFound is also sometimes described as Unknown.
| RPKI State | Meaning | Typical Reason |
| Valid | The route is authorized by at least one matching validated ROA. | The origin ASN and prefix length are permitted by the ROA. |
| Invalid | A covering authorization exists, but the route does not match an authorized origin and prefix-length combination. | Wrong origin ASN, unauthorized more-specific prefix, or incorrect ROA configuration. |
| NotFound | No validated ROA covers the route announcement. | The resource holder has not published a relevant ROA or none is available in the validated data. |
An Invalid result does not automatically prove malicious activity. A legitimate network can also become Invalid because of an incorrect ASN, an overly restrictive maximum-length setting, a migration that was not reflected in the ROA, or another configuration error.
That is why change management and monitoring are essential when RPKI is used in production.
What Is Route Origin Validation?
Route Origin Validation, or ROV, is the process of evaluating a BGP announcement against validated RPKI authorization data.
A relying party validator retrieves signed RPKI material and validates the cryptographic certificate chain and relevant objects. The resulting validated information can then be supplied to routers, commonly through the RPKI-to-Router protocol, so that route-origin status can be incorporated into routing policy.
The final routing decision remains with the network operator. RPKI provides validated information; it does not independently operate BGP routers or dictate every routing-policy decision.
Important: A route being RPKI Valid means its origin authorization is consistent with the validated ROA data. It does not mean the entire AS path has been cryptographically validated, nor does it prove that every operational characteristic of the route is safe or correct.
How to Use RPKI
RPKI deployment has two complementary sides: publishing authorization information for your own prefixes and validating route origins received from other networks.
1. Create ROAs for Your IP Prefixes
The resource holder first identifies the prefixes to be announced and the ASNs that should originate them. RPKI services available through the relevant resource-certification environment can then be used to create the necessary ROAs.
Before publishing a ROA, verify:
• The correct IP prefix.
• The correct originating ASN.
• Any legitimate more-specific announcements.
• An appropriate maximum prefix length.
• Planned routing migrations or multi-origin arrangements.
2. Validate RPKI Data
A network that performs ROV normally uses Relying Party software to retrieve and validate RPKI repositories. This produces validated authorization data that can be passed to compatible routing systems.
3. Connect Validation Data to Routers
Routers capable of using RPKI validation information can receive validated data from the local validator. The operator can then incorporate origin-validation states into existing routing policies.
4. Monitor Before and After Changes
Before changing a ROA, ASN, prefix announcement, or maximum length, check the relationship between the intended BGP state and the RPKI state. After changes are published, verify global route visibility and RPKI validity.
How RPKI Helps Against BGP Hijacking
BGP prefix hijacking occurs when a network originates address space that it is not expected or authorized to originate. This may happen accidentally through misconfiguration or deliberately.
If a resource holder has created an appropriate ROA, another network performing ROV can determine whether an announcement’s origin ASN and prefix length match the authorization.
Example
Suppose a ROA authorizes AS64500 to originate 203.0.113.0/24. If AS64500 announces the authorized prefix, the announcement can be classified as Valid.
If another ASN originates that same covered prefix without matching authorization, the announcement can be classified as Invalid. Networks using ROV can then apply their local routing policy to that result.
Also Read: How ROA Validation Helps Protect Against BGP Hijacking
What RPKI Does Not Protect Against
RPKI is an important routing-security mechanism, but its capabilities should not be overstated. Current widely deployed RPKI-based Route Origin Validation focuses on whether an authorized ASN originates a prefix.
| Security Question | Does RPKI ROV Address It? |
| Is this ASN authorized to originate this prefix? | Yes — this is the core purpose of ROA-based origin validation. |
| Is every AS in the full BGP path authorized? | No — ordinary ROV does not validate the complete AS path. |
| Does RPKI prevent every route leak? | No — some route leaks can involve a legitimate origin ASN and therefore remain origin-valid. |
| Does RPKI replace BGP filtering and monitoring? | No — it should be used alongside broader routing-security practices. |
| Does RPKI automatically decide whether a router accepts a route? | No — operators determine how validation results are applied in local routing policy. |
RPKI should therefore be considered one layer of routing security rather than a complete replacement for prefix filters, route monitoring, BGP policy, operational coordination, and other security mechanisms.
Understanding the RPKI Trust Model
RPKI is a public key infrastructure and therefore relies on certificate-validation chains and trust anchors. Its architecture reflects the existing Internet number resource registration hierarchy.
In operational deployments, relying parties commonly validate material associated with the trust anchors operated by the five Regional Internet Registries. Relying Party software uses Trust Anchor Locators (TALs) to locate and verify the relevant trust-anchor certificates and the signed objects beneath them.
Operational consideration: RPKI improves route-origin verification, but it also introduces dependencies on certificate data, repositories, validation software, authorization accuracy, and the trust model itself. Network operators should understand these dependencies rather than treating RPKI as an automatic or infallible source of routing decisions.
This does not remove the security value of RPKI. It means operators should apply the same operational discipline to RPKI that they apply to other critical routing infrastructure: understand the trust boundaries, monitor changes, maintain independent visibility, and plan for failure conditions.
Common RPKI Configuration Problems
One of the most important practical lessons about RPKI is that authorization data must match the real routing configuration. A legitimate route can become RPKI Invalid if operational changes are not reflected correctly in the corresponding ROA.
Incorrect Origin ASN
If a prefix moves to a different originating ASN but the ROA still authorizes the previous ASN, the new legitimate announcement can become Invalid.
Incorrect Maximum Length
If the maximum prefix length is shorter than the prefixes legitimately announced in BGP, those more-specific routes can be classified as Invalid.
ROA Not Updated During Migration
Provider changes, ASN migrations, anycast deployment, network restructuring, and multi-origin configurations may require ROA changes. Authorization should be prepared before the routing change where possible.
Overly Broad Authorization
Setting an unnecessarily broad maximum length can reduce the precision of the authorization. Operators should authorize the routing design they actually intend rather than automatically permitting every possible more-specific prefix.
Validator or Repository Problems
Relying Party software, repositories, network connectivity, certificate lifecycles, and data synchronization all form part of the operational chain. Monitoring should distinguish an actual authorization conflict from a data-availability or validation problem.
RPKI Best Practices for Network Operators
RPKI Operational Checklist
Maintain accurate ROAs: Ensure the prefix, origin ASN, and permitted prefix length match your intended BGP announcements.
Use change control: Coordinate ROA changes with ASN migrations, provider transitions, deaggregation, anycast changes, and other routing modifications.
Monitor global validity: Regularly verify how your prefixes appear in BGP and whether they are Valid, Invalid, or NotFound from external perspectives.
Do not rely on RPKI alone: Continue using prefix filtering, BGP monitoring, route-policy controls, incident response, and other routing-security practices.
Understand NotFound correctly: The absence of a covering ROA is different from an Invalid authorization state.
Monitor your validators: Treat RPKI validation infrastructure as production network infrastructure and monitor its availability, synchronization, and data freshness.
Maintain continuity procedures: Know how routing policy should behave if validation infrastructure becomes unavailable or authorization data unexpectedly changes.
Also Read: RPKI Security Best Practices
Why RPKI Matters for IP Resource Management
RPKI demonstrates why managing public IP resources involves more than simply having access to an address block. An IPv4 or IPv6 prefix must also be correctly documented, routed, authorized, monitored, and maintained throughout its operational lifecycle.
This becomes particularly important during IP leasing, address transfers, network migrations, ASN changes, multi-homing, and infrastructure expansion. If the registry information, routing configuration, and RPKI authorization do not remain aligned, a technically legitimate deployment may still encounter reachability problems.
LARUS perspective: Public IP resources should be managed for operational continuity. RPKI can strengthen route-origin security, but effective IP management also requires accurate registration, routing readiness, BGP coordination, reputation management, monitoring, and contingency planning.
For organizations managing IPv4 resources across multiple providers or regions, treating routing authorization and continuity as part of the same operational process can reduce avoidable deployment risk.
Conclusion
Resource Public Key Infrastructure is an important component of modern Internet routing security. By enabling resource holders to publish cryptographically verifiable Route Origin Authorizations, RPKI allows network operators to check whether the ASN originating an IP prefix is consistent with the authorization associated with that resource.
Its most widely deployed application, Route Origin Validation, classifies route announcements as Valid, Invalid, or NotFound and gives operators additional information that can be incorporated into local BGP policy.
RPKI should nevertheless be understood within its actual technical boundaries. It validates route origin authorization rather than the entire BGP path, does not prevent every routing incident, and depends on accurate authorization data, validation infrastructure, and a defined trust model.
For network operators, the strongest approach is therefore not simply to “enable RPKI,” but to integrate RPKI with disciplined BGP operations, monitoring, IP resource management, and continuity planning.
Frequently Asked Questions
1. What does RPKI stand for?
RPKI stands for Resource Public Key Infrastructure. It is a cryptographic framework used to support improved security for Internet number resources and BGP routing.
2. What is the main purpose of RPKI?
Its most widely deployed purpose is to allow network operators to verify whether the origin ASN of a BGP route is authorized for the announced IP prefix.
3. What is a ROA in RPKI?
A Route Origin Authorization is a signed RPKI object specifying which ASN is authorized to originate an IP prefix and, where configured, the maximum prefix length that may be announced.
4. What does RPKI Invalid mean?
Invalid means that a covering ROA exists but the route announcement does not match an authorized combination of origin ASN and permitted prefix length. It can indicate unauthorized routing or a configuration mistake.
5. What does RPKI NotFound mean?
NotFound means that no validated ROA covers the route. It is not the same as Invalid.
6. Does RPKI prevent BGP hijacking?
RPKI can help networks detect and reject certain unauthorized route-origin announcements when appropriate ROAs exist and Route Origin Validation is deployed. It does not eliminate every form of BGP hijacking or routing attack.
7. Does RPKI validate the complete BGP path?
No. Standard ROA-based Route Origin Validation checks the origin ASN and prefix authorization. It does not cryptographically validate the complete AS_PATH.
8. Can an incorrect ROA cause an outage?
An incorrect ROA can cause legitimate BGP announcements to become RPKI Invalid. Networks that reject Invalid routes may then stop accepting those announcements, which is why careful change management and monitoring are important.
9. Is RPKI only for IPv4?
No. RPKI supports Internet number resources including both IPv4 and IPv6 address space.
10. Is RPKI mandatory?
RPKI deployment and the routing policies applied to validation results are operational decisions made by network operators, subject to any contractual, provider, technical, or regulatory requirements that may apply to their environment.
Production IPv4
Need IPv4 for a live network?
Check available capacity, then choose the Continuity level that matches the cost of disruption and renumbering.