BGP ORIGIN attribute manipulation and its impact on the Internet (opens in new tab)
BGP’s ORIGIN attribute is intended to describe how a route entered the protocol and should remain unchanged after being set by the originating AS. However, the investigation found that roughly 70% of observed paths had an ORIGIN value different from the original, often because transit providers manipulate it to influence route selection and attract traffic. This widespread practice turns a supposedly stable routing signal into a tool in a revenue-driven competition between networks. ## What the BGP ORIGIN Attribute Means - ORIGIN describes how a route was injected into BGP, rather than identifying the originating Autonomous System. - It has three values: - **IGP (0):** The route originated within the AS. - **EGP (1):** A historical value associated with the obsolete Exterior Gateway Protocol. - **INCOMPLETE (2):** The route was learned through an unknown or external mechanism. - Across routes visible through RIPE RIS and RouteViews: - 89.8% used IGP. - 3.5% used EGP. - 6.7% used INCOMPLETE. - When Local Preference and AS_PATH length are equal, BGP prefers the lower ORIGIN value, making IGP preferable to EGP and INCOMPLETE. - RFC 4271 states that ORIGIN is generated by the originating speaker and **should not be changed** by other speakers. ## How Providers Use ORIGIN Manipulation - A transit provider can rewrite a route’s ORIGIN to IGP, making its path more attractive during BGP route selection. - In the example: - AS64501 announces a route with ORIGIN INCOMPLETE. - AS64502 and AS64503 propagate the route to AS64504. - AS64503 changes the ORIGIN to IGP. - Because both paths have equal AS_PATH lengths, AS64504 selects the path through AS64503. - This manipulation redirects traffic—and potentially transit revenue—toward the provider that altered the attribute. - Some operators also rewrite routes to EGP or INCOMPLETE to make them less preferred than customer routes. - The practice has been discussed at RIPE and LACNIC meetings and has contributed to proposals recommending that ORIGIN be deprecated. ## Measuring ORIGIN Rewriting - The researchers announced: - Three IPv4 prefixes. - Three IPv6 prefixes. - Each prefix used a different ORIGIN value: IGP, EGP, or INCOMPLETE. - Announcements were made from multiple peering locations using BGP Anycast. - After propagation, the prefixes were withdrawn to trigger BGP path hunting, exposing additional routes. - Researchers analyzed: - MRT UPDATE messages from RIPE RIS and RouteViews. - Local BMP data from their border routers. - BGPKIT tools for parsing the data. - UPDATE messages were chosen over routing-table snapshots because they reveal more paths during both announcements and withdrawals. ## Visibility Challenges - Public collectors cannot observe every AS involved in a route’s propagation. - The growth of hyperscalers, CDNs, and direct local peering has flattened the traditional transit hierarchy. - As a result, many paths bypass publicly visible transit networks. - Conclusions about which AS changed an attribute therefore carry some uncertainty, especially beyond directly observed peers. ## Direct-Peer Findings - The first analysis examined two-AS paths such as `ASX AS13335`, where ASX was a direct peer of the researchers. - Because the researchers controlled the original ORIGIN value, any different value observed from a direct peer indicated that peer had rewritten it. - Among 352 IPv4 direct peers: - Three ASes consistently changed routes to EGP. - Four changed routes to INCOMPLETE, potentially attempting to deprioritize them. - One contacted operator confirmed that it rewrote peer- and provider-learned routes to EGP so customer routes would be preferred. - Several ASes advertised both the original ORIGIN and IGP for non-IGP prefixes, likely because they received the routes at multiple locations and altered the value to steer traffic through preferred sites. - Combining these behaviors, the researchers found that nearly 10% of direct peers were rewriting ORIGIN, while the broader experiment detected changes on approximately 70% of observed paths. Network operators should treat ORIGIN rewriting as a significant deviation from BGP’s intended behavior, since it can alter routing decisions, distort traffic engineering, and create commercial incentives for further manipulation.