Blog · Hosting

Cloudflare Finds Widespread BGP ORIGIN Attribute Manipulation on the Internet

Cloudflare has published findings on a subtle but consequential form of BGP manipulation: the alteration of the ORIGIN path attribute by transit providers to win more traffic. According to Cloudflare’s analysis of public BGP data and its own experiments, around 70% of observed paths across numerous vantage points showed an ORIGIN value different from the one set by the originating Autonomous System (AS), even though the protocol specification says this attribute should not be changed after it is set.

What the ORIGIN attribute does

The ORIGIN attribute is a mandatory field in every BGP prefix announcement, indicating how a route entered BGP. It takes one of three values: IGP (interior route), EGP (a historical, now obsolete signal from the old Exterior Gateway Protocol), or INCOMPLETE (learned from an unknown or external source). During BGP’s path selection process, when two routes have equal Local Preference and AS_PATH length, the router prefers the path with the lower ORIGIN value, giving IGP an advantage over EGP or INCOMPLETE.

Cloudflare’s review of data from RIPE RIS and RouteViews collectors found that 89.8% of routes carry IGP, 3.5% carry EGP, and 6.7% are INCOMPLETE, meaning more than one in ten routes hold a value that can tip path selection decisions.

Why networks rewrite it

Because ORIGIN is evaluated early in the path selection process, some transit providers rewrite INCOMPLETE or EGP values to IGP on routes passing through their network, making their path look more attractive to downstream customers even though the change violates RFC 4271 guidance. Cloudflare describes this as an accepted, if unofficial, practice among network operators, one first spotlighted publicly by James Bensley at the RIPE 91 meeting and further examined by Celsa Sanchez at LACNIC 45 for the Latin America and Caribbean region. The inconsistency has even prompted an (expired) Internet-Draft proposing that ORIGIN be deprecated altogether.

How Cloudflare tested it

Cloudflare announced three IPv4 and three IPv6 test prefixes, each with a distinct ORIGIN value, from all of its peering locations using BGP Anycast, then withdrew them to trigger path hunting and surface additional paths. Update messages from RIPE RIS, RouteViews MRT dumps, and Cloudflare’s own BMP data were parsed with the BGPKIT toolkit to track where ORIGIN values changed in transit.

Why this matters for hosting operators

For hosting providers and site owners who depend on network routing behind the scenes, the research is a reminder that BGP path attributes, which are supposed to be trustworthy signals of how traffic should flow, can be silently altered by intermediate networks pursuing more traffic and revenue. This has real implications for route selection, latency, and traffic engineering across the Internet, even though most end users will never see it directly.