Border Gateway Protocol ( 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 , 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 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 attribute. ORIGIN must be present in every BGP prefix announcement 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 AS announced 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) , 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 and 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 , 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 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 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 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 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 .
After confirming global propagation, we later withdrew the prefixes to trigger the 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 toolkit to parse the Update messages from the Multi-threaded Routing Toolkit ( MRT ) dumps of all the public BGP collectors from RIPE RIS and 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 into all ASes on the Internet for a single routing announcement.
Originally published at blog.cloudflare.com
