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 round 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.

Not-found simply means no ROA exists, and is generally still accepted. Invalid is the dangerous state, and it means a ROA exists but the announcement contradicts it, either from the wrong AS or with a prefix longer than the maximum length allows.

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.

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 has to cover the provider's ASN rather than your own, because their network originates the route. Every provider documents which ASN they use.

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.

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.
• 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. For a lease, tell us the ASN you will announce from 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 and are not sure whether its RPKI state is sane, that is a quick thing for us to look at. We usually reply in 1-3 business hours.