RPKI and ROAs: what buyers and lessees actually need to do

Why this stopped being optional

For years RPKI was something operators agreed was a good idea and did not get around to. That changed when the large networks began actually enforcing it. Major transit providers, the big cloud platforms and several large content networks now perform Route Origin Validation and discard routes that come back invalid.

The practical consequence is blunt. A prefix with a broken ROA is not merely unprotected, it is unreachable from a growing share of the internet. And the failure is partial and confusing: some users reach you, some do not, and traceroutes look fine from wherever you happen to be testing.

If you are buying or leasing address space, this is the single configuration detail most likely to cost you a day.

What a ROA actually is

RPKI is a system of cryptographic attestations tied to the address registry. The object that matters day to day is the Route Origin Authorization, or ROA, and it contains exactly three things:

• The prefix. For example 192.0.2.0/24.
• The origin AS. The autonomous system number permitted to announce it.
• A maximum length. The longest prefix that may be announced within that block.

That is the whole object. It is a signed statement from the address holder saying "this AS is allowed to originate this space, up to this specific size". Routers do not read it directly. Validators fetch and verify the RPKI data, and feed the result to routers, which then classify each route as valid, invalid or not-found.

Each route comes out in one of three states. Valid: a ROA covers the prefix and the announcement matches it. NotFound, which many tools show as Unknown: no ROA covers the prefix at all. Invalid: a ROA covers the prefix, but the announcement contradicts it, either from the wrong AS or with a prefix longer than the maximum length allows.

The order of those states matters more than people expect. A route with no ROA is still accepted almost everywhere: it is unprotected, but it gets through. A route that comes back Invalid is dropped by every network that enforces validation. No ROA is better than a wrong ROA. The goal is a correct one, but if the details are not settled on the day you announce, announcing without a ROA and adding it once they are is far safer than publishing one that contradicts what you send.

Who creates it depends on how you got the space

This trips people up constantly, so it is worth being explicit.

If you bought the block, it is registered to you and you create the ROA yourself in your registry's portal, or ask your sponsoring LIR to create it if one holds the registry relationship on your behalf. Do it after the transfer completes, not before, because the object has to be created under the new holder. Bought legacy space in the RIPE NCC region needs a contract with the RIPE NCC or a sponsoring LIR before it can have a ROA at all (the RIPE NCC).

If you are leasing, the block is not registered to you and you cannot create the ROA. The holder does it, for your ASN. That means you have to tell them two things up front: the ASN you will announce from, and whether you intend to announce anything more specific than the whole block. A lease where the ROA has not been created for your ASN will validate as invalid the moment you announce it.

If you are announcing through a cloud provider under BYOIP, the ROA usually has to name the provider's ASN rather than yours, because their network originates the route: AS16509 and AS14618 at AWS, AS8075 at Azure, AS396982 at Google Cloud on its Premium tier. Some providers let you originate from your own ASN instead, either over a BGP session of your own (Vultr, Cherry Servers) or as a "bring your own ASN" option on top of BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Then a ROA names your ASN, and AWS and Oracle Cloud want one naming theirs as well. Most providers document the ASN the ROA must name, and a few, Gcore among them, give it only when you ask, so check before you create anything; our provider guides list them.

The two mistakes that cause outages

Nearly all real-world RPKI breakage comes down to max length.

Setting it too permissive. A ROA for 192.0.2.0/24 with a maximum length of /32 means any announcement of any size inside that block validates. That defeats much of the point: a hijacker announcing a more specific route from your AS number still comes back valid, and more specific routes win in BGP. The safe default is to set maximum length equal to the prefix length unless you have a concrete reason not to.

Setting it too strict. If you announce a /24 covered by a ROA, then later need to deaggregate into two /25s for traffic engineering, those /25s become invalid instantly and disappear from a large part of the internet. If you plan to announce more specifics, the ROA has to allow for it before you start.

The rule that avoids both: make the ROA describe exactly what you actually announce, and update it in the same change window as any routing change, not afterwards.

ASPA: the next layer

A ROA protects the first link of a route: who may originate it. It says nothing about the path after that, which is where route leaks happen, when a network passes on routes it should have kept to itself. ASPA, Autonomous System Provider Authorization, covers part of that gap.

An ASPA object is signed by the holder of an AS number and lists the ASes that are its upstream providers. Networks that validate it can reject a path in which your AS appears to reach the internet through someone who is not your provider. It is an emerging IETF standard. The RIPE NCC describes it as ready for use in signing, and ARIN and APNIC let holders sign ASPAs as well (the registries compared).

• If you have your own ASN, publish an ASPA listing every upstream that carries your routes to the internet. Leave out peers and your own customers.
• Keep it current. A provider missing from the object can get your routes rejected through that provider by networks that enforce ASPA, so add a new transit before you turn it up and remove an old one after you turn it down.
• Bringing your own ASN to a cloud? AWS recommends an ASPA that lists AS16509 and AS14618 as providers of your ASN; without them, the routes it readvertises for you fail ASPA validation.
• Leasing? ASPA belongs to your ASN, not to the prefix, so it is yours to publish, not ours.

The checklist

Before the space carries production traffic:

• ROA exists for the correct prefix and the correct origin AS.
• Maximum length matches your real announcement plan.
• IRR route objects are in place too. RPKI has not replaced them. Plenty of upstreams still build prefix filters from IRR data, so a valid ROA with no matching route object still gets you filtered.
• ASPA lists every upstream, if you publish one, and no peers or customers.
• Validate externally. Check from an outside looking glass or an RPKI validator, not from your own network, which will happily accept your own routes.
• Clean up on the way out. When a lease ends or you stop announcing a block, the ROA should be withdrawn or updated. A stale ROA pointing at an ASN that no longer announces the space is a problem for whoever gets it next.

Where RTM Networks fits

We create and maintain ROAs as part of both leasing and sponsorship rather than as an add-on (lease IPv4, PI and ASN sponsorship). For a lease, tell us the ASN you will announce from, or the cloud provider you are bringing the space to, and whether you need more specifics, and the ROA is configured before handover. For sponsored resources, we manage the RPKI configuration alongside the other registry objects.

If you are taking over space from elsewhere, who sets up RPKI depends on the route: a buyer does it for the block itself, and for a lease the lessor does. We can check whether a ROA exists for the block and, if it does, whether it is valid.