Publishing ROAs and dropping RPKI-invalid routes is the most effective routing security step most networks can take, yet both halves can cause outages if they are done without an inventory, redundant validators and a monitored rollout. A wrong ROA makes your own prefixes invalid to every network that validates; a validator outage or stale cache can quietly turn enforcement off, or worse, drop good routes. This guide treats RPKI and route origin validation (ROV) as an operational project: inventorying what you announce, designing ROAs, choosing hosted or delegated RPKI, deploying relying party software and the RPKI-to-router protocol, setting router policy for Valid, Invalid and NotFound, handling exceptions, and monitoring. It is written for network engineers at ISPs, hosting and cloud providers and enterprises that hold their own address space. Concepts such as ASPA, BGPsec and route leaks are covered in the BGP and Routing Security Guide.
Key takeaways
- Inventory before you sign. List every prefix you announce, every AS that originates it (including DDoS scrubbing providers, CDNs and customers) and every prefix length you use; ROAs created from memory make your own routes invalid.
- Keep ROAs tight. One AS per ROA (RFC 9582), maxLength only where you really announce more-specifics, and separate ROAs rather than one broad maxLength, as RFC 7115 advises.
- Validation is a state, enforcement is your policy. RFC 6811 only labels routes Valid, Invalid or NotFound; you decide to drop Invalid on external sessions and keep NotFound usable.
- Run more than one validator. Routers should peer with more than one cache, at least one local (RFC 7115), and validators should come from different code bases so one bug does not take out validation.
- Monitor both directions. Watch your own prefixes for Invalid status, your ROAs for expiry, and your validators for staleness and disagreement.
Scope: who needs which half
| Organisation | Create ROAs | Deploy ROV | Notes |
|---|---|---|---|
| Enterprise using provider address space | No (provider's job) | No | Ask providers whether they sign ROAs for your assignments and enforce ROV; put it in contracts |
| Enterprise with own address space, multihomed | Yes | Optional, if you take full tables | Default routes from upstreams that enforce ROV give much of the benefit |
| Hosting, cloud and content providers | Yes, including customer and bring-your-own-IP space | Yes on all external sessions | Customer ROAs must authorise your AS before you announce their prefixes |
| Transit and access ISPs | Yes | Yes on peers, upstreams and customers | Also filter customers by IRR or RPKI-derived prefix lists, per MANRS Filtering |
| Internet exchanges and route servers | Own space | Yes on route servers | Members benefit even if they do not validate |
NIST SP 800-189 Rev. 1, "Border Gateway Protocol Security and Resilience", was published as an Initial Public Draft on 3 January 2025 (comment period closed 25 February 2025; no final version was listed when checked on 27 October 2026). It recommends RPKI, ROAs, ROA-based origin validation and prefix filtering, so expect it to shape US federal and supplier requirements.
Phase 1: inventory and ROA design
Build the inventory from what is actually in BGP, not from the IPAM: export your announcements from route collectors or your edge routers and reconcile them with RIR records and contracts.
- Prefixes and lengths: every prefix and more-specific you announce, including those only announced during DDoS mitigation or traffic engineering.
- Origin ASes: your own ASNs, DDoS scrubbing services that originate your prefixes, CDNs, cloud bring-your-own-IP services and customers that announce sub-allocations of your space.
- Sub-allocations: RFC 7115 warns that before issuing a ROA for a super-block you must confirm that customer sub-allocations announced in BGP have correct ROAs; otherwise they become Invalid.
- Unused space: blocks you hold but do not announce, which can be protected with an AS0 ROA so that any announcement of them is invalid.
| Situation | ROA pattern | Why |
|---|---|---|
| Single /24 announced by your AS | Prefix /24, your AS, no maxLength | RFC 9582 says maxLength should not be encoded when it equals the prefix length |
| /22 announced as /22 plus two /24s | One ROA listing the /22 and the two /24s explicitly | Avoids a maxLength 24 that would also authorise the other /24s for forged-origin hijacks |
| Prefix announced by you and a DDoS provider | Two ROAs, one per AS | Each ROA authorises a single AS |
| Customer announces a /24 from your /20 | ROA for the /24 with the customer's AS, created before or with the /20 ROA | Prevents the customer route turning Invalid |
| Space held but not routed | AS0 ROA | Makes any announcement Invalid to validating networks |
| Traffic engineering with frequent more-specifics | Explicit ROAs for each more-specific actually used; avoid broad maxLength | RFC 9319 advises operators to avoid maxLength where possible |
Phase 2: hosted or delegated RPKI
Each regional internet registry (RIR) offers ways to issue ROAs for the resources it allocated. ARIN, for example, lists hosted, delegated and a repository publication service.
| Model | Who runs the certificate authority | Pros | Cons | Choose when |
|---|---|---|---|---|
| Hosted RPKI | The RIR, in its member portal | No infrastructure; ROA creation in a web interface or API; RIR handles publication and key management | Depends on portal account security; less automation in some portals | Almost all enterprises and most providers |
| Delegated RPKI | You run your own CA software under the RIR's certificate | Full control and automation, multi-RIR resources in one system | You run a 24x7 CA and publication point; mistakes or outages make your ROAs disappear | Large providers with automation needs and operations staff |
| Delegated with hosted publication | You run the CA; the RIR publishes | Removes the publication server burden | Still operate CA keys and software | Delegated users who want less infrastructure |
- Protect the portal account: whoever can sign in to your RIR account can create ROAs that make your prefixes invalid or authorise an attacker's AS. Use named accounts, phishing-resistant MFA and role separation, and treat RIR API keys as privileged machine credentials. See the API Key Management Guide.
- Delegated CA keys are signing keys for your routing identity; keep them in an HSM or equivalent and back them up. See the Machine Identity, PKI and Certificate Lifecycle Guide.
- Contacts: RFC 7115 recommends Ghostbusters records for each publication point you control so other operators can reach you about problems.
Phase 3: relying party software and RTR
Relying party (RP) software, often called a validator, downloads the global RPKI from the trust anchors and repositories, validates signatures and produces validated ROA payloads (VRPs). Routers do not do this themselves; they receive VRPs from a cache over the RPKI-Router Protocol.
| Item | Standard or guidance | Practice |
|---|---|---|
| Protocol | RFC 8210, RPKI-Router Protocol version 1 (updates RFC 6810) | Carries IPv4 and IPv6 prefix origin data and router keys from cache to router |
| Transport | TCP port 323 mandatory to implement; TLS on port 324; SSH subsystem; TCP-AO preferred | Plain TCP only where router and cache are on the same trusted, controlled network, as RFC 8210 requires; never across the internet |
| Timers | Defaults Refresh 3600 s, Retry 600 s, Expire 7200 s | Expire decides how long a router keeps data if all caches vanish; monitor it rather than raising it blindly |
| Redundancy | RFC 7115: peer with more than one cache, at least one local; caches near routers | Two or more validators per region, ideally different RP implementations |
| Bootstrap | RFC 7115: reach a cache without depending on DNS or routing convergence | Address caches by IP over the management network |
| Sync | RFC 7115: keep caches in your AS synchronised, at least every four to six hours | Alert when a validator's data is older than your threshold |
| Time | RFC 7115: router clocks accurate to about an hour, NTP for routers | Certificate validity checks depend on correct time |
- Harden validators: they are now part of your routing control plane. Patch them, restrict management access, and monitor their outbound fetches (rsync and RRDP to repositories).
- Local exceptions with SLURM: RFC 8416 lets an operator filter VRPs or add local assertions, for example for private address space and private ASNs, or to protect routes from adverse actions by a certificate authority or repository until resolved. Keep the SLURM file in version control with an owner and expiry for every entry.
Phase 4: router policy and invalid handling
| RFC 6811 state | Definition | Recommended policy on external sessions |
|---|---|---|
| Valid | At least one VRP matches the route prefix (prefix within maxLength and same origin AS) | Accept; may be preferred over NotFound |
| NotFound | No VRP covers the route prefix | Accept; RFC 7115 says NotFound must stay usable while coverage is incomplete |
| Invalid | At least one VRP covers the prefix, but none matches | Drop; RFC 7115 warns that de-preferencing alone is not enough because longest-match forwarding can still send traffic to an invalid more-specific |
- Where to apply: on all eBGP sessions (transit, peers, customers, route servers). Customers are the most likely source of mistakes, so validating them protects everyone downstream of you.
- Egress validation: RFC 8893 asks validating speakers to validate on export using the effective origin AS after egress policy, catching cases where private AS removal or confederations change the origin.
- Do not trust neighbours' signals: RFC 7115 says not to accept validity-state signals from neighbour ASes, and to make sure community signalling cannot upgrade an Invalid route.
- Revalidation: ensure routers re-evaluate routes when VRPs change, without a manual session reset; check how your platform handles soft reconfiguration and memory.
- iBGP consistency: caches are loosely synchronised, so validity can briefly differ between routers (RFC 7115). Validate at the edge and carry the decision in policy, rather than expecting identical state everywhere.
Rolling out ROAs and ROV
- Inventory and dry run: compare your planned ROAs against current announcements with an RPKI analysis tool or your validator's "what if" output, and list any route that would become Invalid.
- Fix first, sign second: correct customer and DDoS provider ROAs before creating covering ROAs; agree a change window with them.
- Create ROAs: in the RIR portal or delegated CA, with peer review of every change; record the change ticket in the ROA description where supported.
- Verify from outside: confirm your prefixes show as Valid in public route collectors and looking glasses within the propagation window.
- Deploy validators: two or more per region, RTR to routers over a protected transport, alerting on staleness.
- Tag, do not drop: configure routers to mark validation state (for example with a local community or attribute) and log Invalid routes for a few weeks. RFC 7115 suggests not dropping Invalid until logs show the results are correct.
- Review the invalids: for each Invalid route you would drop, check whether it is a hijack, a misconfiguration by its owner, or an error on your side.
- Enforce in stages: drop Invalid first on one peering edge, then on transit, then on customers, with traffic monitoring at each step.
- Rollback: keep a pre-approved policy change that returns to tag-only mode, and a SLURM entry process for emergency exceptions. Roll back if valid traffic drops unexpectedly or validators disagree.
Decision guidance
- Hosted versus delegated: choose hosted unless you have resources across several RIRs, need full automation, and can run a CA and publication point with on-call cover.
- Drop versus de-prefer Invalid: drop. De-preferring keeps the route in the table and, if it is a more-specific, traffic still follows it.
- Prefer Valid over NotFound: optional. It can help during a hijack of an unsigned prefix but may change traffic engineering; test it first.
- Small networks: sign ROAs in the RIR portal, check that upstreams enforce ROV, and run one or two validators only if you take full tables.
- Large networks: automate ROA management from a source of truth, run validators from at least two implementations, and integrate RPKI state into customer onboarding and BYOIP workflows.
Monitoring and measurement
| What to watch | Signal | Action |
|---|---|---|
| Your prefixes in global BGP | Any of your prefixes seen Invalid, or seen originated by an unexpected AS | Treat as possible hijack or ROA error; follow the hijack runbook in the BGP and Routing Security Guide |
| ROA and certificate expiry | Objects nearing expiry (RFC 7115 recommends expiry warning tools) | Renew or confirm auto-renewal |
| Validator health | Data older than threshold, repository fetch failures, VRP count jump or drop | Page on-call; compare with the second validator |
| Validator disagreement | Different VRP sets between implementations | Investigate before routers act on either |
| Router RTR sessions | Session down, data expired | Restore caches; confirm fallback behaviour |
| Dropped Invalid routes | Count and top originators | Review for your customers' errors and notify them |
| RIR portal and CA changes | ROA created or deleted outside a change ticket | Investigate as a security event |
Metrics:
- ROA coverage: percentage of your announced prefixes (and customer prefixes you originate) that are Valid (target 100 percent).
- ROA tightness: number of ROAs with a maxLength wider than the lengths actually announced (target zero).
- ROV enforcement coverage: percentage of eBGP sessions dropping Invalid.
- Validator availability and maximum data age per region.
- Time to detect and correct a self-inflicted Invalid in exercises or incidents.
Common failure patterns
- Covering ROA before customer ROAs: a /20 ROA for your own AS turns every customer /24 in it Invalid overnight.
- Forgotten DDoS or CDN origin: the scrubbing provider announces your prefix during an attack, it is Invalid, and validating networks drop the mitigation route exactly when you need it.
- Broad maxLength: a /22 maxLength 24 authorises any /24 from your AS, so an attacker forging your AS as origin passes ROV.
- Single validator: one RP instance fails, routers expire the data and enforcement silently stops; or a bug produces a bad VRP set everywhere at once.
- Plain TCP RTR across networks: an attacker on the path can feed routers false VRPs, which RFC 8210 restricts to trusted, controlled networks for plain TCP.
- Weak RIR account security: a phished portal login can delete ROAs or authorise another AS, and nobody alerts on it.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-189 Rev. 1 (Initial Public Draft) | RPKI, ROAs, ROA-based origin validation, prefix filtering | Primary routing security guidance |
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; SC-5 Denial-of-service Protection | Filtering invalid routes at the network edge |
| NIST SP 800-53 Rev. 5 | CM-3 Configuration Change Control; CM-6 Configuration Settings | ROA changes and router policy under change control |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring; AU-6 Audit Record Review | Prefix, ROA and validator monitoring |
| NIST CSF 2.0 | PR.IR-01; PR.PS-01; DE.CM-01; ID.AM-03; GV.SC-05 | Network protection, configuration management, monitoring, network flow records and provider requirements |
| MANRS for network operators | Filtering; Anti-spoofing; Coordination; Global information | Industry baseline that RPKI supports |
| ISO/IEC 27001:2022 | A.8.20 Networks security; A.8.21 Security of network services | Network controls and provider requirements |
Practitioner checklist
- Export what you actually announce and list every origin AS, including DDoS, CDN, cloud and customers.
- Create customer and third-party ROAs before covering ROAs, and protect unused space with AS0 ROAs.
- Use one ROA per AS and avoid maxLength unless the more-specifics are really announced.
- Secure the RIR portal with named accounts and phishing-resistant MFA, and alert on ROA changes.
- Run at least two validators per region, preferably different implementations, with staleness alerts.
- Connect routers to caches over TCP-AO, TLS or SSH, or plain TCP only on a trusted management network.
- Tag and log validation state first, then drop Invalid in stages on all eBGP sessions, with a tag-only rollback.
- Keep SLURM exceptions in version control with owners and expiry dates.
- Monitor your prefixes for Invalid status and unexpected origins, and track ROA coverage monthly.
- Require RPKI signing and ROV enforcement from upstream providers in contracts.
Standards and references
- NIST: SP 800-189 Rev. 1 (Initial Public Draft) Border Gateway Protocol Security and Resilience
- IETF: RFC 6811 BGP Prefix Origin Validation
- IETF: RFC 7115 Origin Validation Operation Based on the RPKI (BCP 185)
- IETF: RFC 8210 The RPKI to Router Protocol, Version 1
- IETF: RFC 9582 A Profile for Route Origin Authorizations
- IETF: RFC 8416 Simplified Local Internet Number Resource Management with the RPKI (SLURM)
- IETF: RFC 8893 RPKI Origin Validation for BGP Export
- ARIN: Resource Public Key Infrastructure
Related NHI Mgmt Group resources: BGP and Routing Security Guide · DDoS Protection Guide · Telecom Network Security Guide · Network Security Guide