Create RPKI ROAs at RIPE NCC, ARIN and APNIC

A Route Origin Authorisation (ROA) is a signed statement from the holder of an IP prefix: "this AS may originate this prefix, up to this prefix length". Networks that perform route origin validation (ROV), which now includes most large transit providers and many access networks, compare every BGP announcement with the published ROAs and drop the ones that contradict them. With ROAs in place, a mistaken or malicious announcement of your space from another AS is filtered across much of the internet. Get them wrong and it is your routes that get dropped. This guide covers creating ROAs at the three largest regional internet registries (RIRs), using 192.0.2.0/24, 2001:db8::/32 and AS64500 as examples.

How validation works

Each route gets one of three states (RFC 6811):

The important consequence: the moment you publish one ROA for a block, every announcement inside that block not matched by some ROA becomes invalid. Publishing ROAs is therefore an inventory exercise first.

Step 1: List what you announce

1. Look up your AS with ASN & BGP prefix lookup to see every prefix currently originated, and each prefix to see whether more-specific routes exist and who originates them.
2. Run each prefix through the RPKI / ROA validator. With no origin AS given, it checks the AS currently announcing the prefix and lists any ROAs that already cover it.
3. Add the announcements others make for you, which are easy to forget:
   • a DDoS mitigation service that announces your prefixes, or more specific /24s, from its own AS during an attack;
   • a customer or a second site announcing a sub-prefix of your allocation from its own AS;
   • a cloud provider announcing your addresses with Bring Your Own IP;
   • planned announcements, such as a new IPv6 deployment.

Write each down as prefix, origin AS and the most specific length announced. That list becomes your ROAs.

Step 2: Choose max-length carefully

The max-length field allows more specific announcements than the prefix itself. It is tempting to set it generously "just in case", but RFC 9319 recommends avoiding it where possible:

• A ROA for 192.0.2.0/22, AS64500, max-length /24 makes any /23 or /24 inside it valid from AS64500.
• If you only announce the /22, an attacker can announce 192.0.2.0/24 with a forged path ending in AS64500. It is RPKI valid, and because it is more specific, it attracts your traffic.

The safer approach is one ROA per prefix you actually announce, with max-length equal to the prefix length:

A longer max-length is reasonable when you genuinely announce the more specifics, or when a DDoS provider needs to announce /24s on demand. In that case, create the ROA for the provider's AS with the specific max-length it needs, and keep your own ROAs tight. The RIPE NCC also discourages max-length for the same reason.

For address space you hold but do not route, a ROA with origin AS0 (RFC 6483) says that nobody may announce it.

Step 3: Create the ROAs at your RIR

Each RIR runs a "hosted" RPKI service in its member portal, which handles the keys, signing and renewal for you. The menus change from time to time, so treat these as signposts.

RIPE NCC

From the RIPE NCC's ROA management documentation:

1. Sign in to the RPKI dashboard with your RIPE NCC Access account. LIRs set up a hosted certificate authority there first; holders of provider-independent or legacy space follow the RIPE NCC's separate guide for their resources.
2. On the announcements tab, select announcements already seen in BGP and choose Create ROA. The max-length defaults to the prefix length.
3. For announcements not yet in BGP, add the ROA on the ROAs tab.
4. Changes can be applied at once or collected under pending changes. The dashboard shows which announcements each change would make valid or invalid, and asks for confirmation before publishing a ROA that would invalidate a route it can see.
5. Under alert configuration, add an email address to be told about invalid announcements of your space.

ARIN

From ARIN's hosted RPKI and ROA pages:

1. Your resources must be covered by an ARIN registration services agreement.
2. In ARIN Online, open Routing Security, sign up for RPKI for your organisation and choose the hosted option.
3. Under Manage RPKI, go to ROAs and select Create ROA. Enter the origin AS, the prefix and max-length, and optionally a name.
4. Review and submit. ARIN offers to create a matching IRR route object at the same time, which is usually what you want.

Each ARIN ROA holds one origin AS, so create one per origin. Resources ARIN has reassigned or reallocated to someone else cannot be added.

APNIC

1. Sign in to MyAPNIC with multi-factor authentication, which APNIC requires for RPKI.
2. Open route management under your resources and add a new route: prefix, origin AS and the most specific length to announce. APNIC can create the matching whois route object as well.
3. Submit. APNIC checks the request against BGP and warns before publishing a ROA that would make a current announcement invalid; confirm and commit to publish.

LACNIC and AFRINIC offer similar hosted services in their member portals. If your addresses come from a provider rather than directly from an RIR, the provider holds the resources and must create the ROAs for you; ask them, giving the prefix, origin AS and max-length.

Step 4: Check the result

ROAs reach validators within minutes to an hour, depending on the RIR's publication and on how often each network's validator refreshes.

1. Run each prefix and origin AS through the RPKI / ROA validator. You want "RPKI valid". The tool lists the ROAs covering the prefix and explains invalid results: "the prefix is longer than the ROA allows" is a max-length problem; "no ROA authorises this origin" means the ROA names the wrong AS.
2. Check every more-specific and third-party announcement from step 1 the same way, not just your main prefix.
3. Look at the prefix with ASN & BGP prefix lookup to confirm that visibility has not dropped. A route that has become invalid disappears from a large part of the internet within the hour.

Keep ROAs up to date

• Before you change provider, add a DDoS service or move a prefix to a new origin AS, create the new ROA first, then make the BGP change, then remove the old ROA.
• Keep a record of why each ROA exists, especially those for other networks' ASes.
• Hosted RPKI renews certificates automatically, but resources that lapse, or a membership that ends, take their ROAs with them.

FAQ