Cloudflare · OFFICIAL ARTICLE

BGP ORIGIN 属性操纵及其对互联网的影响

通过深入测试，我们发现近 70% 的 BGP 路径都会被中转提供商重写 ORIGIN 属性，以谋求流量优势。我们审视了这一做法对全球的影响，并主张在路由选择中弃用 ORIGIN。

2026-07-25 01:25来源：Cloudflare ↗

ORIGINAL · 官方原文

BGP ORIGIN attribute manipulation and its impact on the Internet

详细说明

Blog Better Internet BGP Network Services +2 Show 2 more tags

5 Tags Show 5 tags

Routing Routing Security

Better Internet BGP Network Services Routing Routing Security

July 24, 2026

Selected Tags
Better Internet BGP Network Services Routing Routing Security
All tags
Matching tags
No tags found
1.1.1.1
2FA
Abuse
Access
Access Control Lists (ACLs)
Accessibility
Account Takeover
Acquisitions
Addressing
Advanced Certificate Manager
Advanced DDoS
Advertising
Aegis
Africa
Afroflare
Agent Readiness
Agents
Agents Week
AI
AI Bots
AI Gateway
AI Search
AI-SPM
AI WAF
AI Week
Alertmanager
Always Online
AMD
AMP
Analytics
Anonymous
Anti Malware
Anycast
API
API Gateway
API Security
API Shield
APJC
Apple
Application Security
Application Services
Area 1 Security
Argo Smart Routing
ASCII
Asia
Athenian Project
Atlassian
Attacks
Audit Logs
Austin
Australia
Authentication
Authy
Automatic HTTPS
Automatic Platform Optimization
Automation
AutoMinify
Auto Rag
Awards
AWS
Baidu
Bandwidth Alliance
Bandwidth Costs
Best Practices
Beta
Better Internet
BGP
Birthday Week
Blackbird
Black Friday
Bot Fight Mode
Bot Management
Botnet
Bots
BPF
Brand
Brand Protection
Brazil
Browser Insights
Browser Rendering
Browser Run
Bug Bounty
Bugs
BYOIP
Cache
Cache Purge
Cache Reserve
Cache Rules
California
Canada
Cap'n Proto
CAPTCHA
Careers
CASB
Categories
CDN
CDNJS
Certificate Authority
Certificate Pinning
Certificate Transparency
Certification
CFSSL
Challenge Page
ChatGPT
China
China Network
Christmas
Chrome
CIO Week
CISA
Claire
CLI
ClickHouse
Clientless
Clientless Web Isolation
Cloud Connector
Cloud Email Security
Cloudflare Access
Cloudflare Apps
Cloudflare Area 1
Cloudflare Calls
Cloudflare Email Service
Cloudflare for Campaigns
Cloudflare for SaaS
Cloudflare for Startups
Cloudflare Gateway
Cloudflare History
Cloudflare Images
Cloudflare Media Platform
Cloudflare Meetups
Cloudflare Network
Cloudflare One
Cloudflare One Client
Cloudflare One User Risk Score
Cloudflare One Week
Cloudflare Pages
Cloudflare Polish
Cloudflare Queues
Cloudflare Realtime
Cloudflare Stream
Cloudflare Tunnel
Cloudflare TV
Cloudflare Workers
Cloudflare Workers KV
Cloudflare Workers KV (ES)
Cloudflare Workers (PT)
Cloudflare Zero Trust
Cloudforce One
Cloudy
Code Orange
Coinbase
Colombia
Community
Compliance
Compression
Config Rules
Configuration Management
Congestion Control
Connectivity
Connectivity Cloud
Consumer Services
Containers
Content Independence Day
Content Scanning
Context
Core
COVID-19
Crawler Hints
CrowdStrike
Cryptography
Crypto Week
CSAM Reporting
Customers
Customer Success
Customer Zero
CVE
CVE-2023-50387
Cyber Readiness
Cybersecurity
D1
Dashboard
Data
Database
Data Catalog
Data Center
Data Localization
Data Localization Suite
Data Loss
Data Loss Prevention
Data Platform
Data Privacy Day
Data Protection
Data Sovereignty
Data Transfer Bucket
DDoS
DDoS Alerts
DDoS Reports
Debugging
Deep Dive
Descaler
Design
Deskope
Developer Documentation
Developer Platform
Developers
Developer Spotlight
Developers Storage
Developer Week
Device Security
DevOps
DEX
Digital Experience Monitoring
Digital Forensics
Disrupt
Distributed
Distributed Systems
Distributed Web
Diversity
DLP
DMARC
DNS
DNS Filtering
DNS Flood
DNSSEC
DNS Security
Dogfooding
DoH
Domain Rankings
Domain Scoped Roles
dosd
Drupal
Due Process
Durable Execution
Durable Objects
Early Hints
Earth Day
eBPF
EC2
eCommerce
Edge
Edge Computing
Edge Database
Edge Rules
Education
Egress
Elastic
Elections
Election Security
Elliptic Curves
Email
Email Routing
Email Security
Email Workers
EmDash
Emissions
Employee Resource Groups
Encrypted SNI
Encryption
Engineering
Enterprise
Entropy
EPYC
Ethereum
Europe
European Union
Events
Exploit
Facebook
Fancy Bear
Fast Fonts
FCC
Feature Flags
FedRAMP
FedRAMP High
FedRAMP Moderate
Firefox
Firewall
Firmware
Florida
Football
Formal Methods
Forrester
Fortran
Foundation DNS
Founders' Letter
France
Fraud
Free
Freedom of Speech
Front End
Full Stack
Full Stack Week
Fun
Gartner
Gatebot
GA Week
GDPR
General Availability
Generative AI
Gen X
Geo Key Manager
Germany
GitHub
Go
Google
Google Analytics
Google Cloud
Google Workspace
Government Innovation
Grace Hopper
Grafana
GraphQL
Green
Grinch
Growth
gRPC
Guest Post
Hackathon
Halloween
Hardware
HashiCorp
Hertzbleed
Heuristics
History
Holidays
Holocaust
Hong Kong
Hosting Con
Hostnames
HTTP2
HTTP3
HTTPS
Human Rights
Hurricane
Hybrid Cloud
Hyperdrive
IBM
ICANN
iCloud Private Relay
Identity
IETF
IL4
Image Optimization
Image Recognition
Image Resizing
Image Storage
Impact
Impact Week
I'm Under Attack Mode
Incident Report
Incident Response
India
Indicators of Compromise
Indonesian
Infrastructure
Infrastructure as Code
Insights
Intel
Interconnection
Internal DNS
Internet Performance
Internet Quality
Internet Regulation
Internet Shutdown
Internet Summit
Internet Traffic
Internet Trends
Internship Experience
Intrusion Detection
Investors
IoCs
iOS
IoT
IPFS
IPsec
IPv4
IPv6
IRAP
Israel
Italy
IWD
JAMstack
Japan
JavaScript
Jengo
Jengo Policy
Joomla
Judeoflare
Kafka
Kernel
Keyless SSL
KeyTrap
Key Value
Killnet
Korea
Kubernetes
LangChain
Latency
Latin America
Latinflare
LavaRand
Lazarus group
Leaked Credential Checks
Legal
Legal Patents Sable
LGBTQIA+
Life at Cloudflare
Linux
Lisbon
Live Streaming
Llama
LLM
Load Balancing
Localization
Log4J
Log4Shell
Logging
Log Push
Logs
LUA
Machine Learning
Magecart
Magic Firewall
Magic Network Monitoring
Magic Transit
Magic WAN
Magic WAN Connector
Malicious JavaScript
Malware
Managed Components
Managed Rules
March of Cloudflare
MASQUE
MCP
Meerkat
MeetUp
Meris
Message Protocol
Mexico
Micro-frontends
Microsoft
Microsoft 365
Microsoft Azure
Middle East
Migration Hub
Milestones
Miniflare
Mirage
Mirai
Mitel
Mitigation
Mixed Content Errors
MLops
Mobile
Mobile SDK
Model Context Protocol
Moldova
Monitoring
Multi-Cloud
Multi-User
MySQL
NaaS
Net Neutrality
Network
Networking
Network Interconnect
Network Performance Update
Network Protection
Network Services
New Year
NGINX
Ninjas
NIST
Node.js
North America
Notebooks
Notifications
NSEC3
OAuth
Observability
Oceania
OCSP
Offices
Okta
Olympics
Onboarding
OpenAI
Open API
OpenBMC
OpenDNS
Open Source
OpenSSL
OpenTelemetry
Optimization
Origin Rules
Outage
Oxy
Pacific Northwest
Page Rules
Page Shield
Parallels
Partners
Partnership
Password-reuse
Passwords
Passwords (PT)
Patents
PAYGO
Payments
Pay Per Crawl
PCI Certified
Peering
Performance
Phishing
php
Phython
Pingora
Pipelines
PlanetScale
Plans
Platform Engineering
Platform Week
Plesk
Policy & Legal
Politics
Portugal
Postgres
Post Mortem
Post-Quantum
Precursor
Prepared Statements
Prisma
Privacy
Privacy Pass
Privacy Week
Private IP
Private Network
Product Design
Product News
Programming
Programming (PT)
Project Fair Shot
Project Galileo
Project Honey Pot
Project Pangea
Project Safekeeping
Project Turpentine
Prometheus
Protocols
Proudflare
Proxying
Public Sector
Python
Queues
QUIC
QUICHE
Quicksilver
R2
R2 Super Slurper
Radar
Radar Alerts
Radar API
Radar Maps
Railgun
Randomness
Ransom Attacks
Rapid Reset
Raspberry Pi
Rate Limiting
RC4
RDDoS
React
Reading List
Real-time
Recruiting
Regional Services
Registrar
Reliability
Remote Browser Isolation
Remote Desktop Protocol
Remote Work
Replication
Research
Resolver
Restreaming
Retreat
Reverse Engineering
REvil
Risk Management
Road to Zero Trust
Rocket Loader
RocksDB
Routing
Routing Security
RPKI
RRDNS
RSA
Russia
Rust
Rust Workers
SaaS
SAAS Security
Sable
Salt
Sampling
Sandbox
SASE
Save The Web
SDK
Search Engine
Secrets Store
Secure Web Gateway
Security
Security Analytics
Security Center
Security Posture
Security Posture Management
Security Service Edge
security.txt
Security Week
SEO
Serverless
Serverless AI
Serverless (PT)
Serverless Week
Server Push
Servers
SIEM
Signed Exchanges (SXG)
SIM
Singapore
Single Sign On (SSO)
Smart Placement
Smart Shield
Snippets
SOC as a Service
South Africa
South America
Spain
spdy
Spectrum
Speed
Speed Brain
Speed & Reliability
Speed Week
Spoofing
Sports
SQL
SRE
SSE
SSH
SSL
Standards
Startup Enterprise Plan
Statistics
StopTheHacker
Storage
Sumo Logic
Super Bowl
Supercloud
Supply Chain Attacks
Support
Sustainability
SWAG
SWG
Swift
Switzerland
SXSW
SYN
SYN Flood
Syria
TCP
Team
Teams Dashboard
TechCrunch
Technical Writing
Tech Talks
Terraform
Testimonials
Testing
Texas
Thanksgiving
The Serverlist Newsletter
Threat Data
Threat Feeds
Threat Intelligence
Threat Operations
Threats
Tiered Cache
TikTok
TLS
TLS 1.3
Tools
Tor
Tracing
Traffic
Transform Rules
Transparency
Trends
Trust & Safety
TTFB
TTL
TURN
TURN Server
Turnstile
TypeScript
UDP
Ukraine
United Kingdom
Universal SSL
URL Scanner
USA
User Research
VDI
Vectorize
Vetflare
Video
Visibility
Vite
VoIP
VPC
VPN
Vulnerabilities
WAF
WAF Attack Score
WAF Rules
Waiting Room
WARP
WARP Connector
WASM
Web3
Web Application Firewall
WebAssembly
Web Asset Discovery
Webinars
WebP
WebRTC
WebSockets
Wildebeest
Womenflare
WordPress
Workers AI
Workers Launchpad
Workers Logs
Workers Observability
Workers Sites
Workers Unbound
Workers VPC
Workflows
World IPv6 Day
Wrangler
x402
Year in Review
Z3
Zaraz
Zero Day Threats
Zero Trust
Zero Trust Week
Zone Versioning

BGP ORIGIN attribute manipulation and its impact on the Internet

Iliana Xygkou and Bryton Herdes

11 minute read

COPY URL

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. This gap is widened by the modern flattening of the 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 peer

IGP

EGP

INCOMPLETE

IGP

345

EGP

313

INCOMPLETE

314

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 and AGGREGATOR , 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 peer

IGP

EGP

INCOMPLETE

IGP

308

EGP

280

INCOMPLETE

281

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 , six out of the 16 appear to manipulate the ORIGIN value to IGP, matching the results of the previous study . 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.

EGP
INCOMPLETE
EGP
INCOMPLETE

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:

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 . 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.

We seed our trusted set (T) with AS13335. T holds all the ASes that preserve the ORIGIN.
For each AS_PATH: Filter out all ASes in T .
If only one AS remains, we can attribute the ORIGIN to that AS. We record the mapping AS → ORIGIN(s).
For each pair AS → ORIGIN(s) : If ORIGIN(s) == original value , we add AS to T.
Else, we add AS to M(odifiers).
If T was updated in 3, repeat the procedure from 2.

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 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 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 ), or may include a new approach entirely. Internet routing would be better and fairer without the ORIGIN attribute carrying influence.

Related tags

Better Internet BGP Network Services Routing Routing Security

Follow on Social Media

Cloudflare
Iliana Xygkou
Bryton Herdes