# Use RPKI route-origin validation without confusing Valid with safe > RPKI lets resource holders authorize which ASN may originate a prefix and lets operators validate BGP origins. It does not validate the full AS path or prove a route is benign. Build careful ROAs, redundant validators, policy, and monitoring. - Canonical URL: https://update.dsesecurity.com/updates/rpki-route-origin-validation-operations/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:03:00+00:00 - Modified: 2026-08-11T14:48:24+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know RPKI lets resource holders authorize which ASN may originate a prefix and lets operators validate BGP origins. It does not validate the full AS path or prove a route is benign. Build careful ROAs, redundant validators, policy, and monitoring. ## Potentially affected Organizations holding public IP resources or an ASN; internet edge routers; transit and peering; BGP policy; Regional Internet Registry accounts; RPKI validators; route monitoring; network change and incident response. ## DSE recommendation Inventory originated prefixes and legitimate origin ASNs, publish least-permissive ROAs, validate them against live announcements, deploy redundant validators, observe validation states, and introduce routing policy through a measured rollback-ready change. ## Article ## Source facts: origin authorization is powerful and deliberately limited [ARIN’s RPKI overview](https://www.arin.net/resources/manage/rpki/) explains that a legitimate holder obtains a resource certificate and uses it to make cryptographically signed statements about which Autonomous System Number may originate an IP prefix. Network operators retrieve and validate RPKI data, compare it with Border Gateway Protocol announcements, and apply their own routing policy. The signed object commonly used for this purpose is a Route Origin Authorization. Its practical controls are the prefix, authorized origin ASN, and maximum prefix length. A maximum length wider than the routes the organization truly intends to announce authorizes extra more-specific origins; one that is too narrow can make a legitimate traffic-engineering or mitigation announcement Invalid. IETF RFC 6811 defines three route-origin validation states. A route is Valid when at least one validated record covers the prefix, permits its length, and matches the origin ASN. It is Invalid when a record covers the prefix but none matches both length and origin. It is NotFound when no validated record covers the route. RFC 7115 emphasizes that operators choose how those states influence local policy and that policy changes can shift traffic. These states validate only the origin relationship. They do not cryptographically validate every ASN in the path, prove that the authorized network is uncompromised, evaluate business relationships, or determine performance. “Valid” must not be translated into “safe,” and “NotFound” does not by itself mean malicious. ## DSE recommendation: operate publication and enforcement as one control Begin with authoritative routing data: every public prefix, actual route length, legitimate origin ASN, upstream or mitigation arrangement, registry account, routing contact, and change owner. Compare this record with announcements seen from multiple external vantage points before creating a ROA. Include disaster-recovery, DDoS-scrubbing, and provider-originated scenarios that may be dormant during normal operation. - Publish narrowly. Create only the prefix, origin, and maximum length required by the approved design. Avoid a blanket maximum length merely to prevent future edits. Record the reason, requester, approver, and expected BGP announcements for each authorization. - Validate from the outside. Confirm that production routes become Valid through independent observation. Check every more-specific and every legitimate origin. A portal success message proves object creation, not worldwide routing behavior. - Protect registry administration. Restrict RIR roles, use phishing-resistant authentication where available, maintain more than one current authorized contact, review API credentials, and alert on certificate, ROA, and contact changes. - Run redundant relying parties. Use supported validator software, current trust anchors, separate failure domains, monitored repository synchronization, and documented router behavior when validation data is stale or unavailable. Test loss of one validator without waiting for an outage. - Observe before rejecting. Export Valid, Invalid, and NotFound counts and examples by peer and prefix. Model which routes would change, check legitimate exceptions with their owners, and introduce policy on a limited edge or peer set before broader enforcement. - Coordinate every routing change. Update authorization and routing plans in the correct sequence for migrations, new origins, deaggregation, mitigation, transfers, and withdrawals. Define rollback for both the BGP announcement and the ROA. Monitor Invalid routes accepted or rejected, validator freshness, repository and session failures, unexpected origin changes, ROA changes, prefixes without authorization, and authorization that is broader than the live design. Preserve emergency contacts and an out-of-band path to the registry account. The goal is a verifiable origin signal embedded in disciplined routing operations—not a security label that overrides all other BGP engineering. The incident runbook should distinguish an incorrect local ROA, stale validation data, a legitimate provider change, and an unauthorized origin. For each case, name who may change the ROA, who may change edge policy, how external propagation is verified, and when customer or provider communications begin. Practice with a documentation prefix or lab route where possible. ## Official references - American Registry for Internet Numbers, [Resource Public Key Infrastructure (RPKI)](https://www.arin.net/resources/manage/rpki/), living guidance reviewed August 11, 2026. - IETF, [RFC 6811: BGP Prefix Origin Validation](https://www.rfc-editor.org/rfc/rfc6811.html), January 2013; and [RFC 7115: Origin Validation Operation Based on the RPKI](https://www.rfc-editor.org/rfc/rfc7115.html), January 2014. ## Primary reference - Name: American Registry for Internet Numbers: Resource Public Key Infrastructure - Authority: www.arin.net - URL: https://www.arin.net/resources/manage/rpki/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Use RPKI route-origin validation without confusing Valid with safe,” DSE Security, https://update.dsesecurity.com/updates/rpki-route-origin-validation-operations/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.