The internet can appear to choose a direct path, but traffic actually crosses networks run by different companies, universities, governments, and cloud providers. Those networks use the Border Gateway Protocol, or BGP, to announce which internet addresses they can reach. The system is resilient and decentralized, but its original design does not authenticate every route announcement.
Resource Public Key Infrastructure, usually called RPKI, adds cryptographic evidence about which autonomous system is authorized to originate a block of addresses. It can stop a useful class of mistakes and hijacks. It is not, however, a complete security layer for BGP, and describing it that way can hide the controls operators still need.
Why BGP Trust Can Go Wrong
The global routing system connects autonomous systems, each identified by an autonomous system number. A network announces address prefixes to its neighbors, those neighbors select routes according to policy, and the information propagates. If an organization accidentally announces a prefix it does not operate, or an attacker deliberately advertises a false origin, other networks may accept the route.
Traffic can then be dropped, diverted, or sent along an unexpected path. The event may affect one narrow prefix or a widely used service. BGP’s distributed design makes rapid coordination possible, but it also means one faulty announcement can travel beyond the network that created it.
These incidents are different from the application attacks covered by memory-safe software development. A website can have secure code and encrypted connections while the network path used to reach it is still incorrectly announced.
RPKI Connects Address Space to an Authorized Origin
RPKI lets a holder of internet number resources create a Route Origin Authorization, or ROA. A ROA states that a particular autonomous system is authorized to originate a prefix and specifies the most-specific route length allowed. The authorization is signed through a certificate hierarchy tied to address-resource allocation.
Routers do not normally fetch and validate public-key objects while making every forwarding decision. Operators use RPKI validators to collect repository data, check the cryptographic chain, and present validated origin information to routing systems. This separation keeps heavy validation work away from the packet-forwarding path, but it makes validator availability and configuration operational concerns.
RFC 6483 describes three origin-validation outcomes. A route is valid when a matching authorization permits its origin and prefix length. It is invalid when covered resource data exists but the announcement conflicts with it. It is not found, often called unknown, when no covering authorization is available.
Route Origin Validation Turns Evidence Into Policy
Publishing a ROA does not automatically change how the rest of the internet routes traffic. Receiving networks must perform Route Origin Validation, or ROV, and apply a policy to the result. Many reject invalid announcements, prefer valid routes, or use validation state as one signal among several.
A cautious rollout matters. A legitimate route can become invalid because its owner entered the wrong origin number, set an overly restrictive maximum prefix length, or changed providers without updating the authorization. Monitoring first, maintaining accurate ROAs, and coordinating changes can prevent a security control from causing an avoidable outage.
NIST’s draft revision of Special Publication 800-189 discusses RPKI, ROAs, ROV, prefix filtering, and complementary BGP security practices. Its layered treatment is important: validation is a process involving resource holders, transit providers, route collectors, and operational response, not a box that one organization checks alone.
What RPKI Can Stop
ROV is well suited to an origin hijack in which the wrong autonomous system announces another organization’s prefix. If the resource holder has published a correct ROA and receiving networks enforce invalid-route policy, the false origin can be filtered before it attracts traffic.
It can also catch common configuration mistakes. A provider announcing a customer’s address space from an unauthorized origin, or announcing a more-specific prefix longer than the authorized maximum, can produce an invalid state that monitoring systems flag quickly.
The protection grows as both sides participate. Resource holders must create and maintain authorizations, while networks that receive routes must validate and use the result. An accurate ROA still provides useful visibility when deployment is incomplete, but it cannot force every remote network to reject an invalid announcement.
What RPKI Does Not Prove
Origin validation answers a narrow question: is the final autonomous system authorized to originate this prefix? It does not prove that the complete AS path is legitimate. A route leak can retain a valid origin while carrying an implausible or unauthorized path through other networks. An attacker may also construct an announcement that ends at the authorized origin but manipulates earlier path information.
RPKI also does not replace prefix filters, maximum-prefix limits, peer policy, route monitoring, incident contacts, or secure router administration. Repository outages and stale data need defined fail-safe behavior. Operators should test how validators, routers, and policy respond before treating validation state as a hard dependency.
This layered approach resembles zero-trust security: one verified attribute can narrow risk without making every surrounding component trustworthy. It also benefits from the inventory discipline discussed in software bill of materials programs. Organizations cannot maintain route authorizations well if ownership, providers, prefixes, and responsible teams are unclear.
Policy Attention Is Increasing
Governments are paying closer attention because routing failures can affect communications and critical services beyond one operator. In 2024, the US Federal Communications Commission issued a Notice of Proposed Rulemaking that discussed BGP security risk-management plans and reporting on ROA coverage for certain providers.
That document was a proposal, not a blanket final mandate for every internet network. The distinction matters. Operators should follow current regulatory decisions and contractual requirements instead of treating an earlier proposal as settled law.
A Practical Deployment Sequence
- Inventory every prefix, origin autonomous system, transit relationship, and responsible owner.
- Create accurate ROAs with deliberate maximum lengths and a documented change process.
- Run redundant validators, monitor repository freshness, and compare results before enforcement.
- Observe invalid routes, investigate legitimate exceptions, and then apply policy in stages.
- Retain prefix filters, peer limits, route monitoring, incident contacts, and configuration controls.
Measurements should distinguish ROA coverage from ROV enforcement. A network may authorize all its own routes yet accept invalid routes from peers, or enforce validation while its own address space remains partly undocumented. Both sides are necessary for meaningful ecosystem protection.
What to Watch Next
Watch the share of announced address space covered by valid ROAs, the number of major networks rejecting invalid routes, and progress on mechanisms that validate more than the origin. Also watch operational quality: inaccurate authorizations can undermine confidence even when deployment statistics rise.
RPKI is valuable precisely because it solves a defined problem. It can make false route origins much harder to propagate, but internet routing will remain a layered trust system. The strongest outcome is accurate origin authorization combined with path-aware monitoring, careful peering policy, and operators prepared to respond when the global view changes.
Leave a Reply