RPKI and ROAs: Preventing BGP Route Hijacks

An incorrect BGP announcement can redirect traffic, make a service unreachable, or expose packets to an organization that was never meant to receive them. BGP was designed to exchange reachability between autonomous systems, but its basic announcement model does not prove that the originating AS is authorized to use the prefix it claims. A typo and a deliberate hijack can therefore look alike to networks receiving the route.

Resource Public Key Infrastructure, or RPKI, adds a cryptographic statement about that missing piece of information. The holder of an IP prefix publishes a Route Origin Authorization, or ROA, naming the AS allowed to originate it. Other operators retrieve and validate those statements, then use Route Origin Validation, or ROV, as one input to their BGP policy. This guide explains what the system proves, how the three validation states are calculated, and how to deploy it without creating an outage of your own.

What RPKI Actually Authenticates

RPKI is a trust system for Internet number resources. Certificates connect an address holder’s resources to signed objects, and a ROA expresses the holder’s authorization for an origin AS to announce one or more prefixes. A relying party validator downloads the published objects, checks their certificate chain and signatures, and exposes the resulting validated ROA payloads to routers, commonly through the RPKI to Router protocol.

The important boundary is in the name: Route Origin Validation checks the origin, not the whole path. A valid result says that at least one ROA authorizes this AS to originate this prefix at this prefix length. It does not prove that every AS in the path is trustworthy, that the route was learned from an intended neighbor, or that the path is free from a route leak. RPKI is a powerful control for origin hijacks, but it is one layer of BGP security.

What a ROA Says

A ROA has three operational values that matter when you create one: an IP prefix, an origin AS, and an optional maximum length. Suppose your organization announces 203.0.113.0/24 from AS 64520. The safest matching authorization normally names that exact prefix and AS, with no permission for longer prefixes. If a transit provider originates the route on your behalf, the origin AS in the ROA must match the AS that appears as the route origin in BGP, which may be the provider’s AS rather than yours.

The maximum length deserves deliberate attention. A ROA for 203.0.113.0/16 with a maximum length of /24 authorizes the named AS to originate the aggregate and every covered route down to /24. That can be necessary for a real deaggregation plan, but it also creates a wide authorization surface. If you do not announce those more specific routes, do not authorize them just because the field is available.

How the Three Validation States Work

The result is calculated against all validated ROA payloads that cover the announced prefix. A route is Valid when at least one covering payload authorizes both the origin AS and the prefix length. It is Invalid when a covering payload exists but none authorizes the announcement, such as when the origin AS is wrong or the route is more specific than the allowed maximum length. It is Not Found, sometimes labeled Unknown, when no covering payload exists.

These states are not three equal grades of confidence. Invalid is an explicit contradiction of published intent. Not Found is an absence of published intent, which may happen because the holder has not deployed RPKI, because the resource is not covered yet, or because the validator has a data or publication problem. Many operators reject Invalid routes while continuing to accept Not Found routes, although the exact action is local policy and should be tested before enforcement.

Create ROAs Without Creating an Outage

Start with an inventory of every public prefix you originate, the AS that appears as its origin, and the exact prefix lengths you announce. Include customer or partner space when your AS originates it, and include every legitimate origin when a prefix is intentionally announced from more than one AS. Do not build the list from an old router configuration alone, because a configuration can contain a dormant route that nobody intends to advertise and miss an announcement made by another edge.

Create exact matching ROAs first. If you announce only a /24, authorize that /24 and set no broader maximum length. If you intentionally announce /24 and /25, create permissions that reflect that plan and record why the more specific route exists. When a provider originates the route for you, confirm the provider’s origin AS from a live BGP view before publishing the authorization. Then check the published object through more than one vantage point, because publication and validator refresh are not instantaneous.

Run the route in a monitoring or test policy before dropping Invalid announcements. Your own route should become Valid at the routers that will enforce the policy, and the same check should remain true after a validator restart, a router reload, and a planned provider failover. Keep alerts for an unexpected Invalid state, an expiring certificate, a missing prefix, or a newly observed origin AS. These alerts turn a hijack signal and a configuration mistake into the same useful first response: verify the change against the intended record.

Common ROA Mistakes

The most dangerous mistake is authorizing the wrong origin AS. This often happens during a provider migration, when the new provider starts announcing a prefix before the ROA is updated, or when an operator assumes that the customer AS remains the origin even though the provider originates the route. A second common mistake is creating a ROA for the aggregate while announcing a more specific route without permitting that length. The result is an Invalid route that looks like a hijack to every network enforcing ROV.

Overlapping ROAs also deserve review. Multiple ROAs can be correct when a prefix is deliberately originated from multiple ASes, but an extra stale ROA can make the policy difficult to understand and can hide the fact that a route is no longer supposed to exist. Keep an owner, purpose, origin AS, prefix length, provider, and review date with every authorization. When a prefix is retired, remove its ROA after the route has disappeared and the change has been verified, rather than leaving an authorization for a resource you no longer use.

The maximum length is the other recurring source of weakness. Setting it to the smallest length you really announce limits the damage from an accidental or malicious more specific announcement. Setting it to the maximum possible specificity makes the ROA easier to write, but it also says that every one of those more specific routes is authorized. That convenience works against the protection you were trying to create.

What RPKI Does Not Prevent

RPKI does not make BGP confidential, encrypt traffic, or authenticate the entire AS path. It does not stop a route leak where an authorized AS announces a route to neighbors that should never receive it. It also cannot help a prefix that has no usable authorization, because a Not Found route gives receiving networks no positive statement to evaluate. Those problems require other controls such as strict import and export filters, max prefix limits, peer policy, IRR data, and careful monitoring.

ROV also depends on adoption. Publishing a correct ROA protects your prefix at networks that retrieve the data and apply a policy to Invalid routes. A hijack can still affect networks that do not validate, and a legitimate route can still be rejected if your ROA is wrong. That is why deployment should be treated as an operational system with ownership, alerts, change review, and a rollback plan, not as a certificate that you create once and forget.

Keep Routing Intent Auditable

The technical object is small, but the context around it is not. Your team needs to know which organization owns the prefix, which AS originates it, which provider carries it, which edge devices announce it, and what should happen during a migration. Keeping those relationships beside the rest of your address plan in an IP address management record gives a change reviewer a place to verify the ROA before a BGP session is modified.

The practical lesson is simple: publish exact authorizations, validate your own announcements, monitor for drift, and update the ROA as part of every provider or origin change. RPKI cannot secure every part of BGP, but it gives the global routing system a signed answer to one of its most important questions: which AS is allowed to originate this prefix?