Routing Behaviour That Requires Investigation
Unexpected origin changes, abnormal routing behaviour and unusual path transitions can indicate conditions that require further investigation.
A BGP route leak occurs when a route is propagated beyond its intended scope. RFC 7908 describes it as the propagation of routing announcements in violation of the intended policies of the receiver, the sender or one of the autonomous systems (AS) along the path. A common example is a network that learns routes from one provider or peer and re-announces them to another provider or peer, effectively offering itself as a transit path it was never meant to be.
Route leaks usually occur without any malicious intent. Typical causes include a missing or incorrect export filter, a policy change applied to the wrong session, a route redistribution mistake, or a new peering or customer session brought up before its filters were in place. Because BGP relies on each network to apply its own policy correctly, a single configuration error can allow leaked routes to spread to neighbouring networks and beyond.
The effect depends on how widely the leaked routes are accepted. Traffic may be drawn through a network that lacks the capacity or intent to carry it, which can lead to higher latency, packet loss, congestion or loss of reachability for the affected prefixes. Traffic may also pass through networks it would not normally traverse.
A route leak rarely announces itself as one. What teams see instead is routing behaviour that differs from what they expect: a prefix suddenly reached through an unfamiliar AS, an AS path that becomes longer or passes through networks that do not normally provide transit, a surge in the number of prefixes received from a peer, or an origin that does not match the one normally associated with a prefix. Each of these can have a legitimate explanation, such as planned maintenance, a provider change or a traffic engineering decision. That is why they are best treated as signals that require investigation rather than as proof of a leak.
Evidence to Review
RouteMon routing-security visibility can surface evidence associated with potential route leaks without presenting an isolated event as a confirmed security incident.
Determining whether a route leak has occurred usually involves comparing several pieces of evidence rather than relying on a single alert. The following types of evidence help teams build a clearer picture of what changed and whether the change is consistent with expected routing policy.
- Unexpected origin changes
- Routing anomalies
- Path anomalies
- Route validation context
- RPKI visibility
Unexpected origin changes
The origin AS is the network that first announces a prefix. When a prefix is seen with an origin that differs from the one normally associated with it, the change warrants a closer look. In a classic route leak the original origin is often preserved and the change appears in the path instead, but a leak combined with route redistribution or a misconfiguration can also show up as a different origin. An unexpected origin can equally reflect a mis-origination, a hijack or a legitimate change such as a prefix moving between networks, so it is a reason to investigate rather than a conclusion in itself.
Routing anomalies
Routing anomalies are departures from a prefix's or a peer's usual behaviour. Examples include a sudden increase in the number of prefixes received from a peer, a more specific prefix appearing where only a covering prefix was previously seen, or a burst of route changes affecting many prefixes at once. Route leaks often affect many prefixes together, so a broad change arriving through a single neighbour is a useful indicator to review alongside other evidence.
Path anomalies
The AS path shows which networks a route has traversed. Path anomalies include a route that suddenly passes through an AS that does not normally provide transit for it, a path that becomes noticeably longer or shorter, or a sequence in which routes learned from one provider or peer appear to be re-announced to another. Comparing the path before and after a change helps teams see where a route started to deviate from its expected propagation and which network may have introduced the change.
Route validation context
Validation context places an observed route alongside the information that describes how it is expected to look, such as published route origin authorisations, Internet Routing Registry objects and a network's own record of its prefixes and expected upstreams. This context helps distinguish a route that conflicts with documented intent from one that is unusual but consistent with it. It also helps teams avoid treating every unfamiliar route as suspicious.
RPKI visibility
Resource Public Key Infrastructure (RPKI) allows prefix holders to publish signed Route Origin Authorisations (ROAs) that state which AS is authorised to originate a prefix. Route Origin Validation classifies an announcement as valid, invalid or not found based on those ROAs. RPKI visibility shows how routes for important prefixes are classified and when that classification changes.
It is important to understand what origin validation does and does not cover. It checks the origin AS and the prefix length, not the full AS path. Because a leaked route frequently keeps its legitimate origin, it can still be classified as RPKI valid. RPKI status is therefore one piece of context to review alongside path and routing behaviour, not a test that confirms or rules out a route leak on its own. Newer mechanisms such as BGP roles and the Only to Customer attribute (RFC 9234) and AS Provider Authorization (ASPA) are designed to address route leaks more directly, but their deployment is still developing.
Continuous Routing Visibility
Monitoring route, prefix, peer and path behaviour over time helps teams identify suspicious changes and focus a routing-security investigation.
A route leak can begin and end within minutes or persist for hours. Periodic checks or manual looking-glass queries can miss short-lived events entirely, or capture only part of a longer one. Continuous monitoring records routing behaviour as it changes, so teams can see when unusual behaviour started, which prefixes and peers were involved and when routing returned to its normal state.
Visibility over time also establishes what normal looks like. Knowing the usual origins, upstreams, AS paths and prefix counts for important prefixes and peers makes it easier to recognise a departure from that baseline and to judge whether it fits a planned change or needs further attention.
When suspicious routing behaviour appears, continuous visibility helps teams:
- Identify which prefixes were affected and when the change began
- Compare AS paths before, during and after the change
- See which peer or upstream introduced the unexpected routes
- Review origin and RPKI validation context for the affected prefixes
- Build a routing timeline that supports investigation and communication with other networks
Route leaks are difficult to prevent entirely because they depend on the policies of many independent networks. What network teams can control is how quickly they notice suspicious routing behaviour and how much evidence they have when they do. Continuous routing visibility gives teams that evidence, so they can focus an investigation on the changes that matter and act on what the routing data shows rather than on assumptions.