A route to a website can be technically valid BGP and still be disastrously wrong. The useful first question is not simply whether the incident was a “leak” or a “hijack.” It is what changed: the origin, the path, or the policy that was supposed to limit where an announcement travelled.
That distinction matters because the controls are different. Route Origin Validation can reject an unauthorized origin. It does not prove that every autonomous system in the path handled the route according to the intended business relationship.
The short answer
A BGP route leak sends a legitimate or learned route beyond its intended scope. A customer might accidentally advertise a route learned from one transit provider to another provider, effectively offering to carry traffic it was never meant to carry.
A route hijack is the common operational label for an unauthorized announcement that attracts traffic. The unauthorized system may originate someone else’s prefix, or announce a more-specific part of it. The terminology is not perfectly clean: the IETF’s route-leak taxonomy includes prefix re-origination as one kind of leak.
So the labels overlap at the edges. A practical diagnosis checks three separate questions:
- Is the origin AS authorized for the prefix?
- Does the AS path make sense?
- Was the route exported to the correct type of neighbor?
What BGP actually announces
The Border Gateway Protocol does not carry a map of the internet. A BGP update advertises a reachable IP prefix and includes attributes that help other networks choose a path. The AS_PATH lists the autonomous systems the announcement has traversed, while the rightmost AS normally identifies the origin.
Networks apply local policy when importing and exporting those routes. A provider may accept its customer’s prefixes and send them onward. A customer should not normally take a route learned from one provider and advertise it to another as though it were providing transit.
That policy is external to the basic reachability claim. A route can have a recognizable prefix and a plausible-looking AS path while violating the commercial relationship that should constrain its propagation.
A route leak breaks the export boundary
RFC 7908 defines a route leak as propagation beyond an announcement’s intended scope. Its basic example is a multihomed customer that learns a prefix from one transit provider and sends it to another. The second provider then propagates the leaked route.
The prefix may still be originated by the correct network. The problem is that an intermediate network exported it where it should not have gone.
If the leaked path looks shorter or otherwise more attractive, other networks can shift traffic through the offending system. That can produce congestion, a black hole, or an unintended traffic path. RFC 7908 notes that leaks are often caused by misconfiguration, although the impact can resemble a deliberate interception.
The same document classifies several relationship mistakes, including provider routes leaked to peers and peer routes leaked to providers. It also includes accidental publication of internal or more-specific prefixes.
A hijack changes who appears entitled to the route
“Route hijack” is broader operational language rather than a single BGP validation state. A common form is origin hijacking: an unauthorized AS announces a prefix owned by someone else. Another is more-specific hijacking, where an attacker announces a narrower prefix. Longest-prefix matching can steer traffic toward that route even when the legitimate aggregate remains visible.
Origin hijacking is exactly the problem that Resource Public Key Infrastructure, or RPKI, is designed to make easier to detect. A Route Origin Authorization states which AS may originate a prefix and the maximum permitted prefix length.
RFC 6811 describes how a router assigns an origin-validation state by comparing a received route with validated prefix-to-AS data. The result can be valid, invalid, or not found, depending on whether the prefix is covered and whether the origin and prefix length match an authorization.
That check is useful but deliberately limited. RFC 6811 says complete attestation of the AS_PATH is outside its scope. A route can therefore have a valid origin and still have been leaked through an unintended path.
Why the two incidents can look alike
Suppose AS 64510 legitimately originates a prefix. Its customer-facing provider advertises the route normally. A small multihomed network then learns that route from one provider and accidentally exports it to another.
The origin remains AS 64510, so origin validation may still say valid. Yet traffic can be drawn through the small network because its leaked path looks attractive.
Now suppose AS 64599 announces the same prefix as its own. Origin validation can mark the route invalid if a covering authorization names AS 64510 instead. That is the clearer origin-hijack case.
There is still a gray area. RFC 7908’s Type 5 leak strips the received AS path and re-originates the prefix, while retaining a data path to the legitimate origin. People may call that a leak, a mis-origin, or a hijack. The label matters less than identifying both the unauthorized origin and the broken export policy.
Controls solve different parts of the problem
Route Origin Validation
Origin validation checks whether the origin AS and prefix length agree with published authorizations. It can catch many accidental and malicious origin changes, but it does not validate the complete path.
Operators also need a policy for invalid and not-found routes. “Not found” does not mean malicious. It means no relevant validated authorization was available.
Import and export filters
Networks can restrict customer announcements to expected prefixes and reject routes that should never arrive from a particular relationship. These filters address the policy boundary directly.
They require accurate prefix lists, customer data and operational maintenance. A stale filter can block a legitimate change; an absent one can let a mistake spread.
BGP Roles and the OTC attribute
RFC 9234 adds BGP Roles so two external BGP speakers can establish their relationship during session setup. It also defines the Only-To-Customer attribute, which helps detect routes that should not be sent from one provider or peer to another.
This targets route leaks that origin validation cannot see. Deployment has to exist on both sides and across enough of the network to provide useful coverage.
Monitoring
Route collectors, alerting services and an organization’s own telemetry can reveal an unexpected origin, a new more-specific route, or a surprising AS path. Monitoring does not prevent propagation, but it shortens the time between a bad announcement and an operator response.
The lesson resembles Certificate Transparency monitoring: a public record is valuable only when someone watches it and has a response plan.
A useful incident checklist
When a route incident appears, preserve the actual updates and timestamps rather than relying on a screenshot of a dashboard. Then work through the evidence:
- Compare the observed prefix with the organization’s expected aggregates and more-specifics.
- Check the origin AS against current authorizations.
- Inspect the full AS path and the neighbor relationship at each suspicious export.
- Separate traffic redirection from reachability loss. They are related but not identical.
- Identify which filter, role agreement, or authorization should have rejected the route.
- Confirm recovery from multiple vantage points. A withdrawal may propagate unevenly.
This produces a more actionable conclusion than arguing over the label alone.
