Signs of Border Gateway Protocol (BGP) hijacking include an unexpected origin autonomous system (AS) for a prefix or an unplanned announcement for a smaller range within that prefix. The smaller range is called a more-specific prefix. To spot these changes, compare observed announcements with the address holder's approved prefix and origin records.

The Routing Information Service's RIS Live feed can supply public BGP updates for this comparison. An alert flags a possible routing problem; investigate it using other observations and the affected network's change records.

A provider migration, a mitigation service, or an incorrect advertisement can produce an unusual announcement without proving malicious intent. Keep the first observation and investigate promptly, even when the cause is still uncertain.

Record the Prefixes and Origins That Are Authorized

Build the expected routing record from the address holder's approved configuration and service arrangements. For each prefix, record the authorized origin autonomous system number (ASN) or ASNs, any specifically approved more-specific prefixes, and the dates when a planned change applies. A provider that carries a route through its network does not necessarily originate that route.

Include scheduled failover and mitigation arrangements before they are needed. If another network is authorized to originate a prefix during a defined event, that authorization belongs in the record with its conditions. Allowing every ASN associated with a service provider would hide discrepancies that the monitor needs to detect.

Do not treat the current public routing table as the sole source of authorization. An incorrect announcement could already be present when monitoring begins. Public observations are useful for establishing what collectors currently see, but the operator's approved record establishes what should be announced.

Compare address ranges using Classless Inter-Domain Routing (CIDR) arithmetic. A contained prefix must belong to the same address family and fall entirely inside the monitored range. Text matching can miss equivalent IPv6 notation or mistakenly group unrelated addresses, so normalize prefixes before comparing them.

Subscribe to the Relevant RIS Live Updates

The WebSocket endpoint is wss://ris-live.ripe.net/v1/ws/. After connecting, a client sends a subscription defining which updates it needs. The following illustrative payload selects the documentation prefix 203.0.113.0/24 and its more-specific announcements, while excluding covering aggregates:

{"type":"ris_subscribe","data":{"type":"UPDATE","prefix":"203.0.113.0/24","moreSpecific":true,"lessSpecific":false}}

Replace the example with an authorized production prefix. Leaving the path filter unset avoids filtering out unexpected origins, and omitting an announcements-only requirement keeps withdrawals in the feed. Leaving the host filter unset avoids deliberately restricting the subscription to one collector.

A receiving application should check each announced or withdrawn prefix against its own monitored ranges. Treat the subscription as a way to reduce incoming data, rather than a substitute for the comparison that creates alerts. Keep malformed or unrecognized records available for investigation instead of converting a parsing failure into a clean result.

Store the collector, peer, AS path, prefix, and receive timestamp with the original message. Separate the collector's receive time from the time when the monitoring application processed the message. A delayed application can otherwise make an older announcement appear to be a new event.

Classify the Announcement before Raising an Alert

For an ordinary ordered AS path, the origin is the ASN at the right end. The collector's immediate BGP peer can be a transit network and must not be substituted for that origin. If the path does not provide an unambiguous origin, record that limitation rather than choosing an ASN arbitrarily.

Consider a hypothetical baseline authorizing AS64500 to originate 203.0.113.0/24, with no approved more-specific announcements. The addresses and ASNs in this example are reserved for documentation. Three observations would need different explanations:

  • The same /24 appears with origin AS64501: the observed origin differs from the authorized origin.
  • 203.0.113.128/25 appears with origin AS64501: both the origin and the more-specific announcement are unexpected.
  • 203.0.113.128/25 appears with origin AS64500: the origin is expected, but that smaller prefix was not approved in the baseline.

The /25 covers half of the example /24. Its appearance matters even if the /24 remains visible, because forwarding selects a matching more-specific route when that route is installed. Which networks actually accept and use the /25 remains a separate question.

A changed transit path with the same approved prefix and origin belongs in a different category. It might reflect a provider change or a route leak that preserves the origin. Keeping those categories separate makes an escalation more precise and avoids treating every path change as an origin hijack.

Use RPKI State to Explain the Discrepancy

Resource Public Key Infrastructure (RPKI) origin validation compares the observed prefix and origin with validated authorization records. Valid means at least one covering record permits that origin and prefix length. Invalid means covering records exist, but none permits the observed combination; NotFound means there is no covering record in the validator's available data.

For an Invalid result, inspect the origin and length separately. The origin may be unauthorized, or an approved origin may have announced a prefix longer than its authorization permits. An outdated authorization during a legitimate change can therefore produce an Invalid route.

A Valid result does not validate the full AS path or establish that every network carrying the route followed its export agreements. An unauthorized announcement can still claim the expected origin ASN, so a Valid result alone cannot rule out hijacking. A NotFound result supplies no origin authorization evidence in either direction.

Record when the validation data was retrieved. A check made after an incident may use authorizations that have since changed, so it cannot automatically establish the state at the first announcement. Compare historical observations with historical authorization data when that data is available, and state clearly when only a current check was possible.

Confirm What Other Observers and the Operator See

RIS collectors receive routes from their peers, and their observations depend on those peer sessions. Multiple messages from the same peer are not multiple independent confirmations. Compare collector and peer combinations, and examine whether apparently separate paths share the same upstream network.

For an unexpected announcement, look for the same prefix and origin in other available routing views. Record the views that show it and the views that do not, with their observation times. The absence of a route in one view limits that view's evidence; it does not prove that the announcement never propagated elsewhere.

Check the authorized network's actual outgoing announcements and its change records. Confirm whether a provider migration, failover, or mitigation arrangement explains the precise prefix-origin combination. An explanation for a nearby prefix is insufficient, and a planned future change does not automatically explain an announcement made before its approved start time.

Compare reported service symptoms separately. A routing anomaly may precede visible disruption, and a service outage can have another cause. The incident record should distinguish BGP evidence, the operator's confirmation, and observed traffic effects instead of merging them into a single claim.

Track Withdrawals and Monitoring Gaps

Maintain the observed state by collector, peer, and prefix. A withdrawal changes what that particular peer has advertised to the collector. It does not establish that every network has removed the route, so an alert should remain tied to the views where its state is known.

The UPDATE subscription does not include RIS_PEER_STATE messages. Subscribe to that message type separately if the monitor needs collector peer session notifications, and record reconnects even when no BGP withdrawal was delivered.

A broken WebSocket connection or a lost collection session creates an observation gap. Record the gap and reconstruct the missing observations from archived data where possible. Silence during a gap cannot be used as evidence that the suspicious announcement ended.

When monitoring starts or resumes, establish the observed routing state from an available snapshot and subsequent updates. A live update feed alone may miss a route announced before the subscription began.

Group repeated messages about the same discrepancy while preserving the first and last observation, additional peers, and changes in the path. This keeps notification volume manageable without discarding evidence that the event spread or changed. A new prefix or origin should remain visible as a distinct development.

Escalate with the Evidence Needed to Investigate

An escalation should let the responsible operator locate the route and compare it with the intended configuration. Include the following details in the incident record:

  • The exact announced prefix and observed origin ASN.
  • The approved prefix-origin combination and the authorization or change record used for comparison.
  • The first and most recent observation times in Coordinated Universal Time (UTC), with collector and peer identifiers.
  • The relevant AS paths, withdrawals, and any known collection gaps.
  • The validation state, the data retrieval time, and whether the state was checked historically or only currently.
  • The operator's explanation so far, any verified service effects, and what remains unconfirmed.

Use a verified operational contact for the affected network or its routing provider. Describe the discrepancy directly, such as an unexpected origin seen through named peers, and avoid assigning intent that the evidence cannot establish.

When the announcement disappears from the observed views, retain the messages and the explanation of its cause. Those records can reveal an expired exception, a missing baseline entry, or a configuration error that needs correction before the same alert appears again.