iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Short answer: Detect a possible BGP hijack by confirming an unexpected prefix-origin change, checking the new origin against RPKI and IRR data, looking for bogon space and implausible AS relationships, and examining the complete AS path from several vantage points. RPKI and route-origin validation (ROV) can reject announcements whose origin is unauthorized, but they do not authenticate every AS in the path or guarantee that every network will filter an invalid route.
This distinction matters because a BGP alert is evidence for investigation, not proof of an attack. Legitimate renumbering, maintenance, mergers, provider changes and configuration mistakes can all produce a surprising announcement. The safest response combines routing data with ownership and change-context checks before you describe an event as malicious or estimate its impact.
What BGP route hijacking is
The Border Gateway Protocol (BGP) exchanges reachability information between autonomous systems (ASes). An announcement says, in effect, that an AS can reach a particular IP prefix and can carry traffic toward it. The base protocol does not itself establish that the announcing AS is authorized to originate that prefix.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesA route hijack occurs when an AS announces a prefix it is not authorized to originate, intentionally or accidentally. Other networks may select the false route according to their policies and BGP path-selection rules. Traffic can then be redirected to the announcing network, dropped, inspected, or sent along a path that causes an outage. A more-specific announcement can be especially disruptive because routers generally prefer it over a covering, less-specific route.
#1 Best Overall
A route leak is different. The origin AS can be legitimate, but an AS propagates a route beyond the customer or provider relationship allowed by its policy. Path manipulation can also alter the apparent route without changing the authorized origin. These events are why origin validation and path-validation controls must be treated as complementary.
Origin validation is not full path validation
What RPKI and ROAs check
A resource holder can publish a Route Origin Authorization (ROA) in the Resource Public Key Infrastructure (RPKI). A ROA states which AS is authorized to originate a prefix and, where applicable, the maximum prefix length it may announce. A receiving network downloads validated ROA data, evaluates an announcement and assigns a validation state such as valid, invalid or not found. Route Origin Validation (ROV) is the policy step that uses that state, commonly to reject or de-preference routes marked invalid.
ROV answers one narrow question: Is this AS authorized to originate this prefix according to the applicable ROA? It does not prove that every AS listed in the AS path forwarded the route according to its customer and provider agreements, nor does it prove that the route is operationally reachable.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What path controls add
Path-oriented mechanisms address problems that an origin check cannot. RFC 9234 defines BGP roles and the Only-To-Customer (OTC) attribute for preventing or detecting route leaks caused by policy mistakes. Cloudflare has also described ASPA objects, which bind an AS to authorized providers, as a path-validation approach under continuing development. These mechanisms target relationships between successive ASes rather than only the final origin.
A cautious BGP-hijack detection workflow
Use the following sequence when a monitoring system, customer or router reports an unexpected route. Keep a timestamp and the vantage points used at every stage; routing observations can change while you investigate.
Rank #2
- Record the trigger. Capture the prefix, announced origin AS, first-seen time, previous origin if known, and the observation source. An origin change, a newly visible more-specific prefix, an RPKI-invalid state or an abrupt path change is a useful starting signal.
- Confirm the announcement from more than one view. Compare observations from independent route collectors, looking glasses or monitoring services. Determine whether the route is visible only at one peer or is propagating across several regions. A public anomaly feed is an investigative aid, not a universal view of every router’s accepted routes.
- Check RPKI status. Compare the announced origin and prefix length with the currently validated ROA payload. A covered announcement from an unauthorized origin is RPKI-invalid. A route with no applicable ROA is “not found,” which is not the same as valid or invalid. Confirm that the ROA was current at the time of the announcement; publication and cache refresh delays can create temporary differences.
- Check maintained IRR data. Look for route objects that describe the expected origin and prefix. IRR validity is a useful additional signal, but the records should not be treated as cryptographically equivalent to an RPKI authorization. A mismatch between the route and maintained registry objects increases the need for verification.
- Screen for bogon space. Check whether the prefix or origin AS is private, reserved or otherwise not expected to appear on the public Internet. Bogon space in an announcement is a strong anomaly signal, although an apparent bogon can also reflect a stale or incomplete data set.
- Compare organizations and relationships. Identify the organization associated with the previous and new origin. A change between unrelated organizations is generally more suspicious than a change between commonly owned networks. A direct, documented customer-provider or peer relationship can make a route change less suspicious, while an implausible relationship raises the score for investigation.
- Inspect the AS-path context. Compare the old and new paths, path length, neighboring ASes and where the path diverges. A path that still traverses the previous origin can weigh against a simple hijack hypothesis. Look for an unexpected provider, an apparent customer-to-provider reversal or propagation beyond an allowed relationship. Origin validation alone cannot reveal all of these conditions.
- Estimate propagation and likely scope. Determine which collectors and networks accepted the route, whether the announcement is still active, and whether it is a more-specific prefix. Acceptance by one peer is not equivalent to global propagation. Conversely, an event seen from many regions does not by itself establish how much user traffic was actually redirected.
- Verify change context. Contact the prefix holder, the announced origin and relevant transit providers through established operational channels. Check planned maintenance, migration, renumbering, acquisitions, emergency traffic engineering and recent ROA or IRR changes. Do not infer intent from an alert alone.
- Classify and preserve evidence. Mark the event as a likely legitimate change, configuration error, route leak, suspected hijack or unresolved anomaly. Preserve time-stamped announcements, validation states, paths and operator responses so the classification can be revisited as new data arrives.
How to interpret detection signals
No individual signal is decisive. A practical detector combines several evidence classes and assigns more weight to combinations that are difficult to explain operationally.
| Signal | What it tells you | Why it is limited |
|---|---|---|
| Origin change | The prefix is now attributed to a different AS than before. | Planned migrations, provider changes and mistakes also change origins. |
| RPKI state | Whether the announced origin agrees with applicable ROAs. | “Not found” means no applicable ROA; ROV requires deployment and enforcement by the receiving network. |
| IRR state | Whether maintained route objects describe the announcement. | IRR records are operational data and are not established here as cryptographically authenticated authorizations. |
| Bogon check | Whether the prefix or origin appears private, reserved or otherwise unexpected. | Data sets can be incomplete or stale, and an anomaly does not identify intent. |
| Organization and AS relationships | Whether the old and new origins have a plausible business or ownership connection. | Public organization data can be ambiguous, outdated or hidden behind subsidiaries. |
| AS-path context | How the route propagated and whether the path fits expected policy. | Path observations differ by vantage point and do not prove every router’s behavior. |
Cloudflare describes a scoring approach that weighs these classes together. An event that is RPKI- or IRR-invalid is more suspicious, while shared ownership, a direct business relationship or a path that still traverses the previous origin can reduce suspicion. The score is a triage mechanism. It can produce false positives and false negatives and should be tuned with additional data and manual review.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallDoes RPKI prevent BGP hijacking?
RPKI reduces the chance that an invalid origin will be accepted, but it does not prevent every hijack. Three conditions must line up:
- The prefix holder must publish an applicable ROA with the correct authorized origin and maximum length.
- The receiving network must fetch and validate the ROA data.
- That network must configure policy to reject or otherwise filter routes whose validation state is invalid.
If any of these conditions is missing, an unauthorized announcement may still be accepted. RFC 8481 clarifies that implementations assign a validation state to prefixes, but operators must configure the policy that acts on that state. NIST SP 1800-14 describes a standards-based ROV platform intended to mitigate some misconfigurations and malicious attacks; it is not a claim that every network enforces the same policy.
What the published measurements show
Cloudflare reported that about 45% of routable IP prefixes had some ROA coverage on July 27, 2023. In the same article, it estimated that 6.5% of Internet users were protected by ROV. These are historical, Cloudflare-attributed measurements, not current global adoption figures. No current independent worldwide percentage is established here.
Cloudflare also relayed an Internet Society MANRS estimate of more than 3,000 route leaks and hijacks in 2020. That is a 2020 estimate reported by Cloudflare, not a current incident count.
A 2025 incident that illustrates the gap
The Root Server Technical Operations Association’s report on a June 20, 2025 route hijack describes three hijacked root-server prefixes that had covering ROAs. At least one network apparently accepted the routes without implementing ROV. Other policy, topology and BGP selection processes limited further propagation. The incident demonstrates why publishing a ROA is valuable but cannot force every network to enforce it.
Route leaks and path manipulation need separate controls
An authorized origin can still be propagated in an unauthorized direction. For example, a provider may export a route learned from one customer to another customer, or a router may apply an incorrect import or export policy. The resulting leak can attract traffic even though the origin passes RPKI validation.
RFC 9234’s BGP roles and OTC attribute are designed to prevent or expose this class of policy error. Operators need to define the relationship on each relevant session, apply the role consistently and monitor for violations. These controls complement, rather than replace, ROV.
ASPA is another path-oriented approach described by Cloudflare. An ASPA object records authorized providers for an AS, allowing path analysis to identify provider relationships that do not fit the published authorization. Deployment and ecosystem support are still important practical prerequisites, so ASPA should be treated as an additional control rather than a universal substitute for current filtering.
Free tools Windows power users keep installed
One-click scans. No signup required.
Defense comparison: what each control validates
| Control | Primary threat covered | Required data | Operator deployment | What it cannot establish |
|---|---|---|---|---|
| RPKI and ROV | Unauthorized origin announcements and some origin mistakes | Applicable ROAs, validated ROA payloads | Validators plus an import policy that filters invalid routes | That every AS in the path is authorized or that uncovered routes are safe |
| IRR-based filtering | Origin and prefix policy according to registry objects | Maintained route objects and AS-set data | Registry ingestion, filter generation and update procedures | Cryptographic proof of ownership or complete path authorization |
| BGP roles and OTC | Route leaks caused by incorrect export or import relationships | Configured session roles and OTC handling | Consistent policy on participating sessions and monitoring | Authorization of the original prefix owner |
| ASPA-style path validation | Unexpected provider relationships and path anomalies | Provider authorizations for participating ASes | Support in validators, routers and operational policy | Universal visibility where objects or enforcement are absent |
| Monitoring and anomaly feeds | Early detection of origin, path and propagation changes | Observations from collectors, RPKI, IRR and relationship data | Alerting, triage and human verification | Certainty about intent or visibility into every router’s accepted table |
Using public monitoring during an investigation
Cloudflare Radar publishes BGP anomaly and hijack-detection results and provides API access. The API documentation states that a token must include the Account:Radar permission. Use Radar as one observation source: compare its event, timestamps and affected prefixes with independent collectors and with the prefix holder’s own telemetry.
Public monitoring can miss a route that never reaches its collectors, show a route after local caches update, or flag a legitimate change. It also generally cannot tell you exactly which customer sessions accepted a route. Treat the feed as a way to prioritize investigation, then confirm acceptance, propagation and impact with operators that control the relevant networks.
Operational practices for prefix holders
Publish accurate origin authorizations
- Create a ROA for every announced prefix, using the actual origin AS.
- Set the maximum length to the longest prefix length you intentionally announce; an overly broad value can authorize more-specific announcements you did not intend.
- Review ROAs during renumbering, provider changes, acquisitions and emergency routing work.
- Remove or amend obsolete authorizations so an old origin is not left valid indefinitely.
Make planned changes visible
Keep a change record for origin and path changes, including the expected start time, old and new ASes, affected prefixes and rollback contact. Notify transit providers and important peers through established channels before a high-impact migration. A monitoring team can then distinguish a planned event from an unexplained one without suppressing all alerts for the prefix.
Monitor from outside your network
Internal router state cannot show what every external network selected. Collect observations from multiple geographic and provider viewpoints, alert on origin changes and unexpected more-specifics, and retain the old path long enough to compare it with the new one. Add RPKI, IRR, bogon and relationship data to the alert record rather than relying on a single “hijack” label.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Operational practices for network operators
- Run RPKI validation and make the treatment of valid, invalid and not-found routes explicit in import policy.
- Apply invalid-route filtering where your risk and connectivity policy justify it, and test the policy so a validator outage does not silently disable protection.
- Use IRR data as a second source for filter construction, with review and change control for route objects and AS-sets.
- Define customer, peer and provider relationships accurately and implement leak-prevention controls such as BGP roles and OTC where supported.
- Investigate unusual paths and more-specific announcements even when the origin is RPKI-valid; validity does not make a leak impossible.
- Coordinate with affected networks before dropping a route that could be a legitimate emergency change, while preserving a rapid path for confirmed invalid announcements.
Common mistakes when declaring a hijack
“RPKI-invalid means malicious”
It means the origin conflicts with the applicable ROA. A stale ROA, an unannounced migration or an operator error can produce the same state. Verify ownership and change context before assigning intent.
Best Value
- Available with the Cloud Labs which provide a hands-on, immersive mock IT infrastructure enabling students to test their skills with realistic security scenarios
- New Chapter on detailing network topologies
- The Table of Contents has been fully restructured to offer a more logical sequencing of subject matter
- Introduces the basics of network security—exploring the details of firewall security and how VPNs operate
- Increased coverage on device implantation and configuration
“No ROA means the route is legitimate”
Not found means that no applicable ROA was available for the announcement. It provides no positive authorization. Use IRR, ownership, relationships and path evidence to fill the gap.
“One monitor saw it, so the Internet was hijacked”
A single observation establishes visibility from that vantage point, not global acceptance or user impact. Measure propagation across independent collectors and, where possible, obtain confirmation from affected networks.
“The origin is valid, so the path is safe”
ROV does not validate every AS in the path. A route leak or policy violation can carry an authorized origin through an unauthorized relationship. Inspect path behavior and use leak-oriented controls.
“Filtering invalid routes solves the whole problem”
ROV only helps where the prefix has a covering ROA and the receiving network enforces a policy. The 2025 root-server incident shows that even covered routes can be accepted by a network that does not implement ROV.
A practical incident record
For repeatable investigations, record the following fields in one case:
- Prefix and any more-specific prefixes
- Previous and observed origin ASes
- First-seen, last-seen and observation times in UTC
- RPKI state, ROA issuer data and maximum-length result
- IRR objects and their last-known update times
- Bogon or reserved-space findings
- Old and new AS paths from each vantage point
- Origin organizations and known customer, provider or peer relationships
- Collectors or networks that accepted the announcement
- Prefix-holder and operator confirmations
- Containment, withdrawal or filtering actions and their timestamps
This record separates what was observed from what was inferred. It also makes it possible to correct a false positive without losing the evidence that triggered the alert.
Bottom line
BGP hijack detection is a correlation problem. Start with the changed announcement, validate the origin with RPKI and IRR, screen for bogons, assess organizational and AS relationships, inspect the full path, and measure propagation from multiple viewpoints. RPKI and ROV are essential protections against unauthorized origins, but they depend on ROA coverage and enforcement and do not authenticate the entire path. Route-leak controls, accurate routing policy, external monitoring and direct operator verification are required to cover the remaining failure modes.
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
