BGP ORIGIN attribute manipulation and its impact on the Internet

How ORIGIN Really Behaves in the Wild

Border Gateway Protocol (BGP) is the glue that holds the Internet's routing together. Every route announcement carries a set of path attributes that routers use to make forwarding decisions, and one of the most fundamental is the ORIGIN attribute. By design, ORIGIN is set exactly once — by the Autonomous System (AS) that originates a route into BGP — and it is supposed to remain untouched as the announcement propagates across the globe. RFC 4271 is explicit on this point: the value SHOULD NOT be changed by any other speaker.

ORIGIN tells a router how a route was introduced into BGP, not which AS introduced it (that is the job of the origin AS in the AS_PATH). Its three possible values are:

• IGP (0) — the route is internal to the originating AS
• EGP (1) — a historical value from the obsolete Exterior Gateway Protocol that should not appear in the modern Internet
• INCOMPLETE (2) — the route was learned from an unknown or non-BGP source

When a router evaluates competing paths for the same prefix, it compares ORIGIN values early in the selection process — after Local Preference and AS_PATH length, but before most other attributes. Lower values win, so a route marked IGP will be preferred over one marked INCOMPLETE when everything else is equal. That simple ordering creates a powerful incentive: an AS that rewrites a route's ORIGIN to IGP can make its path look more attractive without touching the AS_PATH.

A Revenue-Driven Twist on an RFC Rule

The theoretical model is clean. In practice, it is not. A survey of all routes visible at the public collectors of RIPE RIS and RouteViews shows that while IGP dominates at 89.8%, the two non-IGP values account for a meaningful minority: 3.5% of routes carry EGP and 6.7% are INCOMPLETE. Those shares might seem small, but they represent roughly one in ten routes that could be steered in a different direction by a single attribute rewrite.

The trick works like this: AS64501 announces a prefix with ORIGIN set to INCOMPLETE and hands it to two customers, AS64502 and AS64503. Both forward the route to a common downstream customer, AS64504. If AS64503 rewrites the ORIGIN to IGP before passing the route along, AS64504 now sees two paths of equal length where one carries the preferred value. Traffic flows through AS64503, and the transit provider that cheated captures more revenue. This behavior has been an open secret in the operator community for years, and it was spotlighted publicly by James Bensley at RIPE 91 and by Celsa Sánchez at LACNIC 45, who examined the practice in the Latin American region.

Public discussion has not shamed anyone into compliance. Quite the opposite — route selection is effectively a competition for traffic, and operators who assume their competitors are rewriting ORIGIN have little reason to stay RFC-pure themselves. The inconsistency became so pronounced that an Internet-Draft was proposed to deprecate the attribute altogether, though that draft has since expired.

Measuring a ~70% Discrepancy

Our own investigation set out to quantify how widespread ORIGIN manipulation really is. Instead of relying on reported or assumed behavior, we compared the ORIGIN value that appears on routes at numerous vantage points against the value that was originally set by the originating AS. The results were far from theoretical: approximately 70% of observed paths at those vantage points carried an ORIGIN value different from what the originator had set.

That level of divergence does not happen by accident. It requires deliberate action somewhere along the path. An AS that changes ORIGIN was not the originator of the route — it is an intermediate speaker rewriting an attribute it was told to leave alone. The motivation is straightforward: with ORIGIN evaluated so early in BGP's best-path algorithm, a swap to IGP is one of the cheapest, most effective ways to tilt route selection in one's favor. The impact is not limited to a handful of contentious interconnects; it reshapes traffic flow on a global scale.

The persistence of EGP and INCOMPLETE values, combined with the scale of ORIGIN rewriting we observed, paints a picture of an attribute that retains academic importance but has effectively lost its integrity in the real world. It is still mandatory, still evaluated during path selection, and still widely modified — a contradiction that the industry has neither resolved nor fully acknowledged.

Hunting for ORIGIN rewrites across the Internet

To measure how widely the ORIGIN path attribute gets altered, we announced three IPv4 and three IPv6 prefixes from all of our peering locations via Anycast, each carrying a different ORIGIN value (IGP/EGP/INCOMPLETE). After confirming the routes propagated globally, we withdrew them to trigger path hunting, which surfaces additional routes and increases the chances of catching modified ORIGIN values.

Rather than rely on Routing Information Base (RIB) snapshots, we parsed the BGP Update messages from the Multi-threaded Routing Toolkit (MRT) dumps collected by RIPE RIS and RouteViews, plus local BMP data from our border routers, using the BGPKIT toolkit. Updates capture routes from both the announcement and withdrawal phases, giving us a wider window into how different ASes treat the attribute.

We acknowledge a fundamental limit of this kind of measurement: no single vantage point sees every AS on the Internet. The flattening of the Internet, with hyperscalers and CDNs favoring direct local peering over traditional transit, means public collectors miss meaningful portions of the topology for any given prefix. Inferences about AS behavior always carry some uncertainty.

Direct peers reveal the clearest signal

We started with the most straightforward case: AS_PATHs containing exactly two ASes, ASX AS13335, where ASX is a direct peer. Since we controlled the ORIGIN on our own announcements, any different value observed from these peers must have been inserted by them. The table below summarizes the behavior of the 352 direct peers for IPv4.

Two patterns stand out. First, three peers rewrite ORIGIN to EGP and four to INCOMPLETE, regardless of the original value, suggesting an attempt to deprioritize the routes. One of those networks confirmed to us that they downgrade ORIGIN to EGP for routes learned from peers and providers, making them less preferred than customer routes. Second, for our EGP and INCOMPLETE prefixes, three ASes forwarded routes with both the original value and IGP. Based on accompanying attributes like communities and AGGREGATOR, these ASes appear to receive our routes at multiple locations and switch ORIGIN to IGP to steer traffic toward a preferred ingress. Counting those with the peers that always set IGP, nearly 10% of direct peers rewrite the attribute to IGP.

Our IPv6 test involved 315 direct peers, as shown below.

The notable discrepancy: two direct peers rewrite ORIGIN to IGP for IPv4 only, not IPv6, implying separate routing policies for the two address families.

Focusing on the 16 Tier-1 ASes, six appear to rewrite the attribute to IGP, consistent with a prior study. Manual investigation revealed that at least one Tier-1 network sets IGP for routes learned from peers but leaves customer routes untouched. This behavior across several Tier-1s suggests they are trying to attract the most traffic and cancel out the preference advantage gained by other networks modifying the attribute.

Extending attribution to longer paths

To identify rewriters beyond direct peers, we developed an iterative inference algorithm over longer AS_PATHs:

1. Seed a trusted set T with AS13335; T contains all ASes known to preserve ORIGIN.
2. For each AS_PATH, filter out ASes in T. If only one AS remains, attribute the observed ORIGIN to that AS.
3. If the attributed ORIGIN equals our original value, add the AS to T; otherwise mark it as a modifier.
4. If T grew in step 3, repeat from step 2.

Applying this to our EGP and INCOMPLETE announcements, we could attribute ORIGIN behavior to 606 of the 802 visible ASes (75.6%) in the collected paths. Of those, 64 (10.6%) rewrite the attribute to IGP.

Using CAIDA’s AS Rank, which scores ASes by customer cone size, we examined where the modifiers sit in the Internet hierarchy. The IGP-rewriting ASes are heavily clustered near the top: 20.3% of them fall in the top-50 by AS Rank.

The centrality of these rewriters amplifies their impact. Overall, 26% of the top-50 ASes and 20% of the top-100 ASes manipulate ORIGIN. Despite being a small fraction of all ASes, they are precisely the ones whose routing decisions propagate widely.

Traffic redirection at scale

The practical effect is dramatic. Across all routes observed in the experiment, 70% of unique IPv4 AS_PATHs and 67% of IPv6 AS_PATHs had ORIGIN reset to IGP by the time they reached collectors. To gauge how this alters best-path selection, we consolidated BGP Updates into converged routing tables per peer AS, using our control announcement with ORIGIN set to IGP as a baseline for comparison.

In IPv4, 110 of 539 AS_PATHs (20%) traversed Tier-1 networks. Rewriting ORIGIN to IGP earned the rewriters 12 additional paths (an 18% increase) that would otherwise have gone to networks preserving the original value. The effect was stronger in IPv6, where the rewriters gained 33 extra paths (40%), including 11 that did not traverse any Tier-1 network in our control group. The shift consistently redirects traffic toward the large Tier-1 ISPs modifying ORIGIN and away from the alternative ISPs that leave it unchanged.

The manipulation is observable and consequential. There is no technical requirement forcing a rewrite of ORIGIN, and relying on it as a meaningful input to route selection has become indefensible given how widely it is gamed for competitive advantage.

Should ORIGIN still influence routing?

These results force a question: does the ORIGIN attribute still serve a useful purpose? We argue it does not. Inconsistent handling creates an uneven playing field between networks that rewrite it opportunistically and those that follow the RFC as written.

Because ORIGIN is a mandatory BGP attribute, immediate deprecation is not practical. But there is already an expired IETF proposal, draft-marenamat-idr-scrub-bgp-origin-00, aimed at reducing its weight in path selection. We believe a reasonable first step is to mandate that router implementations set ORIGIN to IGP on all received and advertised routes. Most routes already carry that value anyway.

We want the community and the IETF to revisit this discussion, whether by reviving the scrubbing draft or taking a fresh approach. Routing would be simpler and fairer if the ORIGIN attribute carried no influence at all.