RPKI and ROAs for Regional Networks: What a ROA Says, Route-Origin Validation and ARIN Hosted RPKI

The problem RPKI addresses

BGP, the protocol that carries routes between networks, accepts an announcement from a neighbor and passes it on. ARIN's overview describes the history: in the early Internet routing depended on mutual trust, and as the network grew into a commercial platform it became vulnerable to abuse. A wrong announcement can be an accident, such as a leaked route or a mistyped prefix, or an attack that pulls traffic toward the wrong network. Either way, customers see an outage or their traffic is diverted.

RPKI is the Internet's answer to a narrow part of that problem. As ARIN puts it, it uses cryptographically verifiable statements to ensure that Internet number resources are certifiably linked to the stated holders, so a holder can attest which ASNs should originate its prefixes. The architecture is described in RFC 6480: a public key infrastructure for Internet number resources, ROAs as signed objects and repositories that distribute them.

What a ROA states

ARIN describes a ROA as a cryptographically signed object that states which ASN is authorized to originate a particular IP address prefix or set of prefixes. In ARIN Online a ROA is built from an origin AS, a prefix with a maximum length, and an optional name. The ROA can only cover resources in your own resource certificate. Space that was reallocated or reassigned to someone else cannot be added to your certificate.

Read the statement carefully. It says that this ASN may originate this prefix, and that announcements more specific than the maximum length are not authorized. It does not say which networks may carry the route, and it does not validate the path. It is an origin claim, and that is by design.

Route-origin validation: valid, invalid, not found

A ROA does nothing until a network checks routes against it. RFC 6811 defines how. A validator downloads and checks the signed objects and builds a local cache of validated ROA payloads, each with an address, a prefix length, a maximum length and an origin ASN. The router then compares each received route to that data. The RFC defines the terms: a route prefix is covered when a payload prefix is equal to or shorter than it and matches in the shared bits, and matched when it is covered, no longer than the maximum length and the origin ASN is the same.

• Valid: at least one payload matches the route.
• Invalid: at least one payload covers the route, but none matches it. Either the origin ASN is wrong, or the route is more specific than any payload allows.
• NotFound: no payload covers the route at all. Routes for address space that has no ROA yet land here.

The RFC leaves the policy to the operator. A network can prefer valid routes, or drop invalid ones. It also warns that the global RPKI presents a loosely consistent view, and that one cache or router can have different data than another, so allow time after any change.

ARIN hosted RPKI for a regional network

ARIN offers three models: hosted, delegated, and a repository publication service. Hosted RPKI is the simplest. ARIN hosts the certificate authority and signs your ROAs, with the keys protected by a hardware security module and a repository that ARIN runs. It needs little or no coding. Only direct resource holders can take part, and the resources must be covered by an ARIN agreement. A downstream customer that received space from an upstream provider must ask that provider to submit the ROAs.

The steps, in ARIN Online: open Routing Security, sign up for RPKI for the organization, choose Hosted, request the certificate, then create ROAs from the ROA page. During creation you can choose whether to create a matching route object in the Internet Routing Registry. After submission the information reaches ARIN's repository within a few minutes. ARIN notes that duplicate and overlapping ROAs are no longer allowed, because the ROA auto-renew feature removed the need for them. Check that a ROA is live with an RPKI validator that has fetched ARIN's repository. A deleted ROA takes effect immediately in ARIN's database and in the public repository within 24 hours.

Writing ROAs that will not hurt you

The usual failure is a ROA that is wrong, not one that is missing. Work through this list before you publish.

• Inventory your announcements. Pull the routes you originate today and the ASN that announces each one. Include anything announced from a backup site or from a mitigation provider during an attack.
• Match the real announcements. If you announce a /22 as two /23s, the ROA must cover what you actually send.
• Keep maxLength tight. RFC 9319 explains that loose maxLength values are a hijack risk: measurements it cites found that most prefixes in such ROAs were exposed to a forged-origin sub-prefix hijack. It recommends minimal ROAs that authorize only what is originated in BGP, and avoiding maxLength except in specific cases.
• Add ROAs for every origin. If two ASNs may legitimately originate a prefix, publish a ROA for each, so an upstream change does not turn your route Invalid.
• Check after every renumbering, transfer or new circuit. An address transfer is the moment ROAs most often go stale.

Start validating, too

Once your own space is covered, add validation to your edge routers: run a validator, connect your routers to it, and apply policy. A careful order is to log and tag invalid routes for a few weeks, check for false positives, then prefer valid routes over not-found ones, and finally reject invalids. Run more than one validator so validation keeps working if one fails.

Where MANRS fits

Mutually Agreed Norms for Routing Security (MANRS) is a community effort that asks network operators for a small set of routing-security actions. Described generally, they cover filtering so you announce only what you should and accept only what you should, preventing spoofed traffic, keeping contact information current so other operators can reach you, and publishing routing information, including ROAs, so others can validate your routes. RPKI work maps onto the last of these. We make no claim about any network's participation; use the program's own pages as the source if you want to join.

Our team designs and operates BGP edges, RPKI publication and route-origin validation for regional networks, and helps with address transfers so that ROAs stay correct.

Sources

• Resource Public Key Infrastructure (RPKI) (American Registry for Internet Numbers)
• Route Origin Authorizations (ROAs) (American Registry for Internet Numbers)
• Hosted RPKI (American Registry for Internet Numbers)
• RFC 6480: An Infrastructure to Support Secure Internet Routing (RFC Editor)
• RFC 6811: BGP Prefix Origin Validation (RFC Editor)
• RFC 9319: The Use of maxLength in the RPKI (RFC Editor)

This article is general information, not legal or technical advice for your environment. Product menus, license names and provider rules change; check the vendor's current documentation before you act. Last reviewed November 9, 2026.

Next article

Next · SecurityA Conditional Access Baseline for Small Microsoft 365 Tenants: Report-Only First, Break-Glass AlwaysConditional Access is where a Microsoft 365 tenant decides who gets in, from what, and how. A small tenant needs only a handful of policies, switched on in the right order. This is a baseline built from Microsoft Learn guidance: test in report-only mode, block legacy sign-in, protect administrators, keep emergency accounts out of the blocks, then add device rules.8 min read

Related reading

• InfrastructureBacking Up Entra ID and Microsoft 365 Configuration: What the Recycle Bin Covers and Misses8 min
• InfrastructureSeparating Global Networks: VRFs, VLANs and VXLAN-EVPN Across Datacenters10 min