BGP ORIGIN attribute manipulation and its impact on the Internet

# BGP ORIGIN attribute manipulation and its impact on the Internet Source: [https://blog.cloudflare.com/bgp-origin-attribute/](https://blog.cloudflare.com/bgp-origin-attribute/) Border Gateway Protocol \([BGP](https://www.cloudflare.com/learning/security/glossary/what-is-bgp/)\) is the de facto routing protocol of the Internet\. It offers built\-in mechanisms to allow entities, represented by Autonomous Systems \(ASes\), to express how they want to send and receive traffic on the Internet\. One such mechanism is[path attributes](https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2), which carry essential routing information and metadata for their associated route\. The path selection algorithm processes some of these path attributes in a[deterministic sequence](https://datatracker.ietf.org/doc/html/rfc4271#section-9.1)to calculate the best path for this specific prefix\. Using our unique position on the Internet, we took an investigative look at one of the well\-known mandatory attributes in BGP, the[**ORIGIN**](https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.1)attribute\. ORIGIN must be present in every BGP prefix[announcement](https://datatracker.ietf.org/doc/html/rfc4271#section-4.3)and should not be modified by any router after being set by the originating one\. What we found through our own experiments was a dramatic ~70% of observed paths in numerous vantage points have a**different**ORIGIN value compared to what was set by the originating Autonomous System\. This ORIGIN attribute manipulation has a significant impact on the way traffic is forwarded on the Internet, as we’ll explore in this post\. ## BGP ORIGIN and its operational history The ORIGIN attribute indicates**how**a route was injected into BGP — not to be confused with the origin AS that indicates**which**ASannounced a route\. It has three possible values: \(0\) IGP: Indicates the route is interior to the originating AS \(1\) EGP: A historical value indicating that the route was learned via the old[Exterior Gateway Protocol \(EGP\)](https://datatracker.ietf.org/doc/html/rfc904), which is obsolete and not intended to be used in the modern Internet \(2\) INCOMPLETE: Indicates the route was learned via an unknown or external source Among total observable routes from all the public BGP collectors of[RIPE RIS](https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/)and[RouteViews](https://www.routeviews.org/routeviews/), 89\.8% have ORIGIN set to IGP, 3\.5% to EGP, and 6\.7% are INCOMPLETE\. As mentioned above, EGP is meant to be deprecated entirely and INCOMPLETE carries a minority share of total routes\. These figures suggest that while IGP is by far the most popular value for ORIGIN, more than 10% of routes have an EGP or INCOMPLETE value that could make a difference in routing decisions\. As a part of the BGP[path selection process](https://datatracker.ietf.org/doc/html/rfc4271#section-9.1), a router evaluates the ORIGIN if two routes have equal Local Preference and AS\_PATH length, selecting and installing the path with the lower ORIGIN value\.  Aside from the path selection decision, it is worth noting that[RFC4271 states the following](https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.1)about ORIGIN: `The ORIGIN attribute is generated by the speaker that originates the associated routing information\. Its value SHOULD NOT be changed by any other speaker\.` Though the guidance is to not modify the ORIGIN attribute, due to its early evaluation in the route selection process, this attribute has presented an attractive option for ASes to alter route preferences and divert traffic either through or away from their networks\. For example, in the diagram below, AS64501 announces a prefix with ORIGIN set to INCOMPLETE and propagates this announcement to both of its customers, AS64502 and AS64503\. Normally, both of them should prepend their own AS in the AS\_PATH and forward the announcement to their common customer AS64504, preserving the INCOMPLETE value\. However, to increase the likelihood of their route being selected over competitors’, AS64503 modifies the ORIGIN to IGP\. As a result, AS64504 receives two routes for the prefix with equal AS\_PATH lengths, but the one from AS64503 carries the preferred IGP value\. Thus, AS64504 will select the route through AS64503 to send traffic to AS64501, driving more traffic and revenue to that provider\. This simple change, to an inaccurate but more preferable ORIGIN, allows the transit provider to draw traffic and profit\.  The network operators community has silently accepted the reality that transit providers have been rewriting the ORIGIN attribute to IGP in order to attract more traffic to their links\. However, James Bensley at the[RIPE 91 meeting](https://ripe91.ripe.net/programme/meeting-plan/sessions/30/GJ8PFJ/)was the first to spotlight the widespread adoption of this manipulation technique by major networks\. A follow\-up presentation by Celsa Sánchez at the[LACNIC 45 meeting](https://www.youtube.com/watch?v=YaY0-4aGCnQ)investigated the impact of this behavior in the LACNIC \(Latin American and Caribbean\) region\. While a public disclosure should discourage this practice, it highlights the reality that route selection is a revenue\-driven arms race\. Rather than waiting for competitors to resume RFC compliance, network operators are more likely to quickly resort to rewriting the ORIGIN simply to level the playing field\. This increasingly inconsistent handling of ORIGIN across the Internet prompted the creation of a now\-expired[Internet\-Draft](https://datatracker.ietf.org/doc/draft-marenamat-idr-scrub-bgp-origin/00/)that recommended its deprecation\. To uncover the extent of this phenomenon and track its actors along with their intentions, we conducted our own experiments and share the results in the next section\. ## ORIGIN attribute manipulation analysis In our experiment, we announced three IPv4 and three IPv6 prefixes, each with a different ORIGIN value \(IGP/EGP/INCOMPLETE\) from all of our peering locations using BGP[Anycast](https://www.cloudflare.com/learning/cdn/glossary/anycast-network/)\. After confirming global propagation, we later withdrew the prefixes to trigger the[path hunting](https://blog.cloudflare.com/going-bgp-zombie-hunting/#path-hunting)process, revealing more paths to the test prefixes, giving us more opportunities to spot altered ORIGINs\. As shown in the figure below, we used the[BGPKIT](https://bgpkit.com/)toolkit to parse the Update messages from the Multi\-threaded Routing Toolkit \([MRT](https://datatracker.ietf.org/doc/html/rfc6396)\) dumps of all the public BGP collectors from[RIPE RIS](https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/)and[RouteViews](https://www.routeviews.org/routeviews/), and the local BMP data that we collect from our border routers\. Note that we opted to analyze the Updates instead of the Routing Information Base \(RIB\) dumps, which are snapshots of the routing tables of the peer ASes, to retrieve as many as possible routes both during the announcement and the withdrawal phase\.  A fundamental difficulty of BGP analysis is the[lack of visibility](https://www.routeviews.org/routeviews/2025/01/10/routeviews-peering-policy/#:~:text=The%20changing%20internet%20landscape)into**all**ASes on the Internet for a single routing announcement\. This gap is widened by the modern[flattening of the Internet](https://blog.apnic.net/2020/12/04/unpacking-a-flattened-internet/), driven by hyperscalers and CDNs bypassing traditional transit routes in favor of direct, local peering\. Consequently, public monitors miss a significant portion of the BGP topology for a given prefix, meaning inferences about AS properties always carry inherent uncertainty\. ### Finding ORIGIN rewriters in two\-hop AS\_PATHs First, we focused on AS\_PATHs with only two ASes: “*ASX AS13335”*, where we call*ASX*a direct peer\. Since we configured our routers to propagate our announcements with a specific ORIGIN, we are confident that if we observe a different ORIGIN,*ASX*must have changed it to its new value\. The table below shows the manipulation behavior of the 352 direct peers for IPv4 where the “Advertised ORIGIN” column shows what value is being advertised for each of our three prefixes, and the right\-hand side columns list the ORIGIN values observed by direct peer ASes: Advertised ORIGIN \(IPv4\)Observed ORIGIN at direct peerIGPEGPINCOMPLETEIGP \+ EGPIGP \+ INCOMPLETEIGP3453400EGP32313430INCOMPLETE32331403 We would like to point out two interesting observations\. First, three ASes change the ORIGIN to EGP, and four ASes change it to INCOMPLETE, regardless of its original value, meaning that they are potentially attempting to deprioritize these routes\. We reached out to one of these ASes’ network engineers and confirmed that they are rewriting the ORIGIN to EGP on routes received from peers or providers \(to render them less preferred compared to customers’ routes\)\. Second, for the non\-IGP prefixes, three ASes propagate routes with both the original value and IGP \(the two right\-most columns above\)\. Based on other attributes of the routes such as[communities](https://datatracker.ietf.org/doc/html/rfc1997)and[AGGREGATOR](https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.7), we infer that these ASes receive our routes at multiple peering locations and update the ORIGIN to IGP, presumably to forward traffic through a preferred point\. Combining the latter ASes with the ones consistently rewriting to IGP, we discover that almost 10% of the direct peers change the ORIGIN attribute to IGP\. In testing IPv6, we expected similar results but wanted to note discrepancies involving the manipulation of the ORIGIN value by the same AS between two address families\. In the following table we present the manipulation behavior of the 315 direct peers for IPv6: Advertised ORIGIN \(IPv6\)Observed ORIGIN at direct peerIGPEGPINCOMPLETEIGP \+ EGPIGP \+ INCOMPLETEIGP3083400EGP29280420INCOMPLETE29328102 Most noteworthy is that two direct peers change the ORIGIN to IGP only for IPv4 prefixes and not IPv6, implying different configurations for the two address families\. Narrowing our analysis to the[Tier\-1 ASes](https://bgp.tools/kb/what-is-a-upstream), six out of the 16 appear to manipulate the ORIGIN value to IGP, matching the results of the[previous study](https://ripe91.ripe.net/programme/meeting-plan/sessions/30/GJ8PFJ/)\. Note that through manual investigation we found that one Tier\-1 network changes the ORIGIN value to IGP for routes learned from peers, while it preserves it for customer routes\. This pattern of behavior across several Tier\-1 networks reflects the drive to attract the most traffic and cancel out other ORIGIN modifiers’ advantage\. ### Identifying rewriters in longer AS\_PATHs Based on these initial results, we extended our methodology to process longer paths and infer the behavior of more ASes\. Briefly, our algorithm works as follows: 1. We seed our*trusted*set*\(T\)*with AS13335\.*T*holds all the ASes that preserve the ORIGIN\. 2. For each AS\_PATH:1. Filter out all ASes in*T*\. 2. If only one AS remains, we can attribute the ORIGIN to that AS\. We record the mapping*AS → ORIGIN\(s\)\.* 3. For each pair*AS → ORIGIN\(s\)*:1. If*ORIGIN\(s\) == original value*, we add AS to*T\.* 2. Else, we add AS to*M\(odifiers\)\.* 4. If*T*was updated in 3, repeat the procedure from 2\. Applied to the routes of our IPv4 and IPv6 prefixes originated with EGP and INCOMPLETE, this methodology increases our AS attribution to 606 out of 802 \(75\.6%\) visible ASes in the AS\_PATHs, out of which 64 \(10\.6%\) are changing the ORIGIN to IGP\. Motivated by the Tier\-1s adopting this technique, we studied the significance of the attributed ASes using[CAIDA’s AS Rank](https://asrank.caida.org/)\. AS Rank provides a ranking of the ASes based on their customer cone \(i\.e\., themselves and all the ASes that can be reached through provider\-customer links\)\. In the figure below, we show the cumulative distribution \(CDF\) of AS Ranks of the attributed ASes\. An interesting observation is that the IGP\-rewriting ASes are highly concentrated at the top of the AS hierarchy, with 20\.3% of the rewriting ASes falling in the top\-50 of AS Rank\.  ### Impact of large ASes rewriting ORIGIN In total, 26% of the top 50 ASes and 20% of the top 100 ASes are manipulating the ORIGIN attribute, highlighting that despite their overall low percentage, the ASes resetting the ORIGIN are highly central and impactful on the Internet\. The impact is further reinforced by the finding that a staggering 70% of the unique IPv4 AS\_PATHs and 67% of IPv6 AS\_PATHs observed in the experiment have ORIGIN reset to IGP\. We also studied the changes imposed on best path selection by consolidating BGP Updates to compute the converged active routing\-table state of each peer AS\. We used the prefix advertisement with ORIGIN set to IGP as a[control group](https://www.britannica.com/science/control-group)to compare AS\_PATHs observed versus our EGP and INCOMPLETE announcements\. When doing so, we found in IPv4 that 110 AS\_PATHs out of the total 539 \(20%\) traversed Tier\-1 networks and that resetting the ORIGIN to IGP secured for ORIGIN rewriters 12 additional paths \(an increase of 18%\) that would otherwise go through the networks that preserve ORIGIN\. The effect is even stronger in IPv6, where the rewriters gained 33 more paths \(40%\)\. These include 11 paths that for our control group did not traverse any Tier\-1 network\. This highlights the redirection of traffic toward large Tier\-1 ISPs when the ORIGIN was manipulated, diverting traffic away from alternative ISPs\. As you can see, Internet routing is significantly impacted by the manipulation of the ORIGIN attribute\. In our experiments, we can easily observe the effects on BGP path selection and demonstrate how rewriting ORIGIN is a way to siphon traffic and generate revenue\. There is no valid*technical*reason to require a rewrite of the ORIGIN attribute, and we can see it does not make sense to depend on ORIGIN as a driving factor in deciding what routes to take\. ## Deprecating the ORIGIN attribute Given our findings of widespread ORIGIN manipulation, we have to ask ourselves whether this attribute has a meaningful role at all in the modern Internet\. We think the answer is**No**\. The inconsistent treatment of ORIGIN creates unfairness between networks opportunistically changing it and networks complying with the RFC\. While immediate deprecation of a**mandatory**attribute in BGP would be infeasible, there has already been work[proposed in the IETF](https://datatracker.ietf.org/doc/html/draft-marenamat-idr-scrub-bgp-origin-00)to make the ORIGIN attribute less relevant in BGP path selection\. We believe requiring BGP \(vendor\) implementations to set ORIGIN as IGP on**all**routes received and advertised is a reasonable starting point\. IGP is already set as ORIGIN on the great majority of routes\. We want to revive these conversations in the community and the IETF about the ORIGIN attribute and its future \(or lack thereof\) on the Internet\. This may include renewing the expired draft “Scrubbing BGP ORIGIN Attribute” \([draft\-marenamat\-idr\-scrub\-bgp\-origin\-00](https://datatracker.ietf.org/doc/html/draft-marenamat-idr-scrub-bgp-origin-00)\), or may include a new approach entirely\. Internet routing would be better and fairer without the ORIGIN attribute carrying influence\.