Post by @Jhaas@infosec.exchange

2026-08-01 16:39 UTC

AS_PATH Length is the tool everyone is used to using to impact attracted traffic: You prepend your own AS to make a path less preferable. Unfortunately the efficacy of this practice is clumsy. Depending on where you sit in the Internet and who your providers are, you end up playing with the number of prepends to see how well you can influence the incoming traffic. Excessive prepending opens you up to easier route hijack. (https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/) When you're not lucky, traffic load balancing seems fine and then all of a sudden may shift. Often this is how a provider discovers BGP Wedgies where the "state machine that is the Internet" has latched temporally on your advertised routes... and then it moved. (https://datatracker.ietf.org/doc/html/rfc4264) On an incoming basis, providers may proxy prepend incoming routes to locally bias their traffic. However, that also impacts downstream traffic attraction and thus you have to be careful about that.

Replies (1)

@Jhaas@infosec.exchange 2026-08-01 16:40

ORIGIN, right below AS_PATH length, offers an "attractive nuisance" to bias traffic. As the various articles running around have noted, ORIGIN is a vestigial feature partially designed to help with the transition of ARPAnet/Internet routing from EGP to BGP. The primary motivation to move to BGP-4 was support of CIDR so we could get out of classful use of IP address space. I wasn't there, but talking with those that were, this transition was done very rapidly. As a result, migration mechanisms like ORIGIN to bias route selection and ATOMIC_AGGREGATE to try to avoid programmatic (de-)aggregation were largely non-issues. It's worth mentioning that even after a second round of moving from RFC 1771 which gave us our second (!) but well deployed version of BGP version 4 to RFC 4271 which cleaned up a lot of issues didn't fully clarify how ORIGIN is used. Probably the biggest lingering headache is "what is the ORIGIN of my static routes?" Some vendors do IGP, some do Incomplete. The result is that just for harmony in multi-vendor networks the ORIGIN is manually adjusted anyway - so tweaking things isn't exactly foreign to service providers. This hammer has been getting used further by providers, and its popularity is why we have the current kerfluffle: A service provider may choose to manipulate the ORIGIN at import time. This permits paths that are otherwise of similar length to stay that length, while providing some preference as to which ones you use throughout the AS. Some of you immediately say "well, why not use LOCAL_PREF?" The simple answer is that LOCAL_PREF is the biggest hammer in the toolbox. It stops caring about AS_PATH length or other tweaks unless you encode your entire AS-wide route selection policy and flatten it into an integer. Most providers say "yuck" and reach for the smaller hammers. Many providers as part of their policy will simply ignore received ORIGIN values anyway and reset them. This already means that even if the originating AS set it to one value that another may not respect that, expecting manipulation. Instead, they're violating the originating ASes intent. Which moves into the second part where this slightly smaller hammer is used: It's an attempt to put a lighter hand on incoming traffic load balancing. When it works, it's helpful. But it depends on downstream service providers themselves choosing to respect the upstream provider's desired intent. AS_PATH length thus is reasonably respected. ORIGIN might help, but is often ignored. The result is the toolbox has one solid tool available, and it is very clumsy.

Open ##5311551