Skip to content

CLOUDFLARE

Read original ↗

BGP ORIGIN attribute manipulation and its impact on the Internet

Summary

Cloudflare investigates widespread manipulation of the BGP ORIGIN attribute — a mandatory path attribute that RFC 4271 states SHOULD NOT be modified after origination. Using controlled experiments from all Cloudflare peering locations (announcing prefixes with known ORIGIN values via anycast), Cloudflare discovers that ~70% of observed AS_PATHs have ORIGIN rewritten to IGP by intermediate ASes. Among direct peers, ~10% change ORIGIN to IGP; among the top-50 ASes by CAIDA AS Rank, 26% manipulate it. The manipulation is concentrated in highly-connected Tier-1 transit providers who gain traffic (and revenue) by making their routes appear more preferable. Cloudflare argues the ORIGIN attribute no longer has a meaningful role in modern Internet routing and supports its deprecation.

Key takeaways

  1. ORIGIN has three values — IGP (0), EGP (1), INCOMPLETE (2) — indicating how a route entered BGP. IGP is most-preferred in path selection when Local Preference and AS_PATH length are tied. (Source: RFC 4271 §5.1.1, §9.1)

  2. Current distribution: 89.8% of observable routes have ORIGIN=IGP, 3.5% EGP, 6.7% INCOMPLETE — meaning >10% of routes have a non-IGP ORIGIN that could be exploited as a preference differentiator. (Source: RIPE RIS + RouteViews data)

  3. ~10% of direct peers rewrite ORIGIN to IGP for non-IGP prefixes. This was measured precisely via two-hop AS_PATHs where Cloudflare (AS13335) is the originator with a known ORIGIN value. (Source: controlled experiment across 352 IPv4 / 315 IPv6 direct peers)

  4. Some ASes deliberately deprioritize routes: three ASes set ORIGIN=EGP on routes from peers/providers (confirmed with operator), using the mechanism in reverse to render routes less preferred vs customer routes. (Source: operator confirmation)

  5. Revenue-driven arms race: once one Tier-1 rewrites ORIGIN to IGP, competitors must follow to avoid losing traffic. Six out of 16 Tier-1 ASes observed manipulating ORIGIN — matching the results of the 2024 RIPE 91 presentation by James Bensley. (Source: experiment results + prior work at RIPE 91)

  6. Algorithmic AS attribution expands visibility: an iterative seed-and-propagate algorithm starting from the trusted AS13335, attributing ORIGIN behavior across longer paths, identified 606 out of 802 (75.6%) visible ASes — of which 64 (10.6%) rewrite to IGP. (Source: Cloudflare methodology)

  7. Impact quantified: ~70% of unique IPv4 AS_PATHs and ~67% of IPv6 AS_PATHs had ORIGIN reset to IGP. In the control analysis, ORIGIN rewriters gained 12 additional paths (18% increase) in IPv4 and 33 additional paths (40% increase) in IPv6 that would otherwise traverse non-rewriting networks. (Source: control-group analysis)

  8. IPv4/IPv6 behavioral divergence: two direct peers manipulate ORIGIN only for IPv4 and not IPv6, implying distinct address-family configurations — a diagnostic signal for network operators. (Source: experiment observation)

  9. Deprecation argument: there is no valid technical reason for any intermediate AS to rewrite ORIGIN. Cloudflare supports setting ORIGIN=IGP on all routes received and advertised as a step toward deprecation, per the expired IETF Internet-Draft draft-marenamat-idr-scrub-bgp-origin. (Source: Cloudflare position)

  10. Measurement methodology: path-hunting triggered by prefix withdrawal revealed additional paths beyond the steady-state routing table, giving more opportunities to observe manipulation. BGP Updates (not RIB dumps) from both RIPE RIS and RouteViews MRT dumps were analyzed alongside Cloudflare's local BMP data. (Source: experimental design)

Systems / concepts extracted

  • concepts/bgp-origin-attribute — the mandatory BGP path attribute under investigation; three values (IGP/EGP/INCOMPLETE); evaluated early in path selection after Local Preference and AS_PATH length
  • concepts/bgp-path-selection — RFC 4271 §9.1 deterministic sequence; ORIGIN is evaluated at step 3 (after Local Preference, AS_PATH length)
  • concepts/traffic-engineering — ORIGIN manipulation is a revenue-driven traffic-engineering technique
  • concepts/as-rank — CAIDA's ranking metric based on customer-cone size; IGP-rewriting ASes cluster at the top of the hierarchy
  • systems/bgpkit-monocle (referenced implicitly via BGPKIT toolkit for MRT parsing)
  • systems/ripe-ris — RIPE Routing Information Service BGP collectors
  • systems/routeviews — University of Oregon RouteViews BGP collectors

Operational numbers

Metric Value
Direct IPv4 peers tested 352
Direct IPv6 peers tested 315
Direct peers rewriting to IGP (IPv4) ~10% (32 out of 352)
Tier-1 ASes rewriting ORIGIN 6 out of 16 (37.5%)
Top-50 ASes rewriting ORIGIN 20.3% of IGP-rewriters fall in top-50
Top-100 ASes rewriting ORIGIN 20%
Total ASes attributed 606 out of 802 (75.6%)
ASes confirmed as rewriters 64 (10.6% of attributed)
IPv4 AS_PATHs with ORIGIN=IGP (expected non-IGP) ~70%
IPv6 AS_PATHs with ORIGIN=IGP (expected non-IGP) ~67%
IPv4 paths gained by rewriters vs control 12 (18% increase)
IPv6 paths gained by rewriters vs control 33 (40% increase)

Caveats

  • The BGP topology is inherently partially observable — public collectors see only a fraction of all AS paths; the true manipulation rate may be higher.
  • The algorithmic AS attribution relies on transitivity assumptions; ASes in the "trusted" set are assumed to never modify ORIGIN, which may not hold for all operational configurations.
  • Cloudflare acknowledges it cannot distinguish intentional manipulation from misconfiguration in all cases (though the revenue incentive argument is strong for Tier-1s).
  • The expired Internet-Draft draft-marenamat-idr-scrub-bgp-origin is one approach; vendor implementation and community consensus timelines are uncertain.

Source

Last updated · 595 distilled / 1,807 read