Creating Route Origin Authorizations (ROAs)

What Is a ROA?

A Route Origin Authorization (ROA) is a cryptographically signed statement that says: "AS X is authorized to originate prefix Y with a maximum length of Z."

ROA example:
  Prefix:     203.0.113.0/24
  MaxLength:  /24
  Origin AS:  64512
  Signed by:  ARIN CA (via your account)

When other networks perform Route Origin Validation (ROV), they check received BGP announcements against published ROAs. Invalid announcements are rejected.

Why Create ROAs?

• Protect your prefixes from BGP hijacking -- hijackers cannot pass ROV checks.
• Prevent sub-prefix hijacks -- Setting maxLength to your announcement size blocks more-specific hijacks.
• Improve reachability -- Networks that prefer RPKI-valid routes give your prefixes higher priority.
• It is becoming mandatory -- Major networks (Cloudflare, Google, AWS) reject RPKI-invalid routes.

Step-by-Step: Creating ROAs by RIR

ARIN (North America)

1. Log in to rpki-dashboard.arin.net
2. Click "Create ROA Request"
3. Enter your prefix, origin AS, and maxLength
4. Submit -- ARIN signs and publishes within minutes

RIPE NCC (Europe, Middle East, Central Asia)

1. Log in to my.ripe.net
2. Navigate to "RPKI" in the left menu
3. Click "Create ROA"
4. Select your prefix, enter origin AS and maxLength
5. Confirm -- Published immediately

APNIC (Asia-Pacific)

1. Log in to myapnic.net
2. Go to "Resources" then "RPKI"
3. Click "Create ROA"
4. Fill in prefix, origin AS, maxLength
5. Submit and sign

LACNIC (Latin America)

1. Log in to milacnic.lacnic.net
2. Navigate to RPKI section
3. Create ROA with your resource details

AFRINIC (Africa)

1. Log in to my.afrinic.net
2. Access RPKI management
3. Create ROA for your prefixes

MaxLength Best Practices

The maxLength field is critical for security. It defines the most specific prefix length you authorize:

Rule: Set maxLength equal to the most specific prefix you actually announce. If you only announce a /24, set maxLength to /24. This maximizes protection against sub-prefix hijacks.

Verifying Your ROAs

After creating ROAs, verify they are visible:

# Check ROA status via RIPE RPKI Validator
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=64512&prefix=203.0.113.0/24" | jq '.data.validating_roas'

# Check via Cloudflare RPKI portal
# Visit: rpki.cloudflare.com

# Check via NIST RPKI Monitor
# Visit: rpki-monitor.antd.nist.gov

Common Mistakes

• Forgetting to create ROAs for all prefixes -- Any prefix without a ROA has "NotFound" status. While not rejected today, "NotFound" may be treated as "invalid" in the future.
• MaxLength too permissive -- Setting maxLength to /32 when you only announce /24 opens you to sub-prefix hijacks from anyone who knows your AS number.
• ROA for decommissioned prefix -- Remove ROAs when you return address space.
• Wrong origin AS -- Double-check the AS number, especially if you use multiple ASes or AS sets.