Introduction
Ensuring censorship resistance is a critical challenge when deploying applications within Trusted Execution Environments (TEEs) like Intel TDX. While TEEs provide strong security guarantees for computation, a fundamental security boundary issue emerges: even with secure code execution, all network traffic remains controlled by the host system.
This challenge is particularly relevant in blockchain systems like Ethereum’s block building infrastructure, including Flashbots’ BuilderNet, where censorship resistance is essential to maintaining the network’s core values of openness and neutrality. Understanding the limitations of TEEs for network traffic is crucial for designing systems that can effectively detect or mitigate censorship attempts.
Problem Statement
When applications run within a TEE, a critical security boundary exists between protected data, protected computation, and unprotected network communication. The TEE protects computation integrity and data confidentiality, but all network traffic must pass through the host’s network stack.
For the purposes of this blog post, we define two distinct censorship scenarios:
General Censorship: Complete prevention of specific traffic, where the host blocks certain data from ever reaching the application inside the TEE. This form cannot be technically prevented when the host controls the network stack.
Selective Censorship: Selective manipulation of traffic that can potentially be detected and proven. This form can be addressed through various detection and accountability mechanisms.
In blockchain contexts like Ethereum block building, this means that even with perfectly secure code execution inside the TEE, the host can effectively censor the block builder by controlling what network traffic reaches it. No amount of security within the TEE can prevent the host from manipulating, delaying, or blocking network traffic.
The purpose of this blog post is to shed the lights on the problem’s background before diving into potential solutions in the subsequent following blog posts.
Network Packet Structure and Filtering
To understand how censorship occurs at the network level, we need to examine how network packets are structured and processed.
IPv4 Packet Structure
Source: IPv4 - Wikipedia
TCP Header Format
Source: TCP Header
UDP Header Format
Source: https://ipwithease.com/udp-user-datagram-protocol
The figures above show the structure of an IPv4 packet with its headers and payload and TCP/UDP header formats. For network-level censorship, several elements across different protocol layers are significant: IP addresses (in the IPv4 header), port numbers (in the TCP/UDP headers that follow), TCP flags (in the TCP header, particularly SYN, ACK, RST, and FIN flags), and payload data. These elements across the network and transport layers are primarily used for filtering decisions.
Packet Filtering Censorship
Network-level censorship occurs through several filtering mechanisms:
Address-based Filtering: The host can examine source and destination IP addresses to filter packets from specific blockchain nodes or MEV relays. This happens at the network layer and requires no deep inspection of packet contents.
Port-based Filtering: By blocking traffic on specific TCP/UDP ports (like Ethereum’s default P2P port 30303), the host can prevent connections to the broader network regardless of packet contents.
Protocol Identification: Unlike simple port filtering, protocol identification examines packet patterns and signatures to identify Ethereum traffic even on non-standard ports. This type of “deep packet inspection” looks beyond headers into behavior patterns and protocol characteristics to identify and potentially block specific protocols.
Content Filtering: For unencrypted traffic, the host can inspect payload contents to identify specific transactions or addresses, enabling precise censorship targeting. For example: Blocking transactions interacting with sanctioned addresses
Encryption’s Impact on Filtering Capabilities
Encryption significantly changes the censorship landscape, though it doesn’t prevent it entirely.
When traffic is unencrypted, the host has complete visibility into payload contents, enabling precise filtering based on the specific data being transmitted. In blockchain contexts, this could enable filtering of specific interactions, but the principle applies broadly across all networked applications.
An important technical point is that encryption only protects the payload contents, not the fundamental TCP/IP packet structure. The TCP/IP headers remain unchanged and visible regardless of whether TLS or other encryption is used. This means IP addresses, ports, and other metadata remain available for filtering even when the payload is fully encrypted.
When traffic is encrypted (via TLS, Ethereum’s devp2p with RLPx, etc.), the host cannot directly view transaction details. However, the host still maintains significant censorship capabilities. Despite encryption, a host can identify protocol types through TLS signatures, filter based on connection endpoints, perform timing analysis to identify patterns, and simply block all encrypted channels that match certain characteristics.
Encryption shifts censorship from content-specific to connection-specific, but doesn’t fundamentally prevent it. The host might not know which specific transactions are being processed, but can still block entire classes of connections based on metadata and traffic patterns.
Network Stack Layers and Censorship Points
+-----------------------------------------------+
| APPLICATION LAYER |
| (Ethereum Transactions/Blocks) | <- Block builder operates here
| | (protected by TEE)
+-----------------------------------------------+
| TRANSPORT ENCRYPTION |
| (TLS, RLPx) | <- Protects content, not metadata
| |
+-----------------------------------------------+
| TRANSPORT LAYER |
| (TCP/UDP) | <- Host can filter by port
| |
+-----------------------------------------------+
| NETWORK LAYER |
| (IP) | <- Host can filter by IP
| |
+-----------------------------------------------+
| LINK LAYER |
| (Ethernet, WiFi) | <- Host controls all interfaces
| |
+-----------------------------------------------+
|
V
External Network
This layered view shows that while encryption may protect the application data, the host still controls all lower network layers, allowing various forms of censorship even when transaction data itself is encrypted.
Types of Network Censorship Attacks
Network censorship can occur through various techniques, ranging from complete blocking to subtle manipulation. Understanding these attack vectors is crucial for developing effective countermeasures.
Attacks Against Encrypted Traffic
Even with strong encryption protecting content, several attack vectors remain available to the host:
Metadata Analysis: While the host can’t see encrypted contents, it can analyze connection endpoints (IPs, domains), packet sizes and timing, and traffic volume patterns. This allows identification and blocking of connections to known Ethereum nodes without needing to decrypt the traffic.
TLS Fingerprinting: The host can identify protocols by examining TLS handshake characteristics and block traffic based on TLS version or cipher suites that match known Ethereum patterns.
Traffic Correlation: By analyzing timing patterns between packets and correlating encrypted traffic with known blockchain activities, the host can identify transaction broadcasts by their timing patterns alone.
Protocol Identification: Using machine learning and traffic pattern analysis, hosts can detect and block Ethereum protocol traffic even when encrypted, based solely on behavioral signatures.
Client (TEE) Ethereum Node
| |
| +---------------------------+ |
|<---| Encrypted Data (TLS) |----->|
| +---------------------------+ |
| |
| ^ |
| | |
| Host can still analyze: |
| • Connection endpoints |
| • Traffic patterns |
| • Timing and volume |
| • Protocol fingerprints |
Direct Interference Techniques
Beyond the analysis of encrypted traffic, hosts can employ more direct forms of interference:
Packet Dropping: The most straightforward censorship technique involves silently discarding packets that match certain criteria. With no feedback or error messages provided, the block builder has no way to differentiate intentional censorship from normal network loss.
Block Builder (TEE)
^
| √ √ × √ × (Packets selectively dropped)
|
Host Network Stack -----+
^ |
| V
Internet ----> Filtering Rules
• Drop if source = X
• Drop if contains address Y
Latency Manipulation: More subtle than outright blocking, artificially delaying specific traffic creates timing issues for time-sensitive operations like block building. Transactions can be delayed just enough to miss inclusion in the current block.
Normal Traffic: [Tx] ---> [Block Builder] (5ms)
|
V
[Block Created]
Manipulated: [Tx] --------------> [Block Builder] (850ms)
|
V
[Too Late for Current Block]
Bandwidth Throttling: By limiting throughput for specific traffic, the host creates artificial congestion for targeted data types, making high-volume operations unreliable without completely blocking them.
Connection Disruption: Actively breaking established connections through TCP reset packets, periodic connection drops, or DNS manipulation can effectively censor specific peers without appearing as outright blocking.
Traffic Redirection: Manipulating where traffic goes through techniques like DNS manipulation, or routing table modifications can redirect connections to controlled or non-existent endpoints.
Packet Reordering: Particularly effective against UDP traffic, which lacks the built-in ordering mechanisms of TCP. By deliberately reordering packets, the host can corrupt message sequences or cause protocol-level failures. Since UDP applications must handle packet ordering themselves, manipulating the sequence can cause application-level errors or data corruption without appearing as outright censorship. This technique can be particularly disruptive for time-sensitive applications like streaming data or real-time communication protocols.
Real-world Censorship Scenarios
In practice, network-level censorship against Ethereum block builders might manifest in several ways:
MEV Extraction Advantage: A host controlling network infrastructure might subtly delay competitors’ transactions to prioritize their own MEV opportunities. By introducing artificial latency for specific transaction sources, they gain timing advantages for frontrunning or sandwich attacks.
Protocol-Specific Filtering: Some hosts might identify and block connections to specific DeFi protocols deemed risky or competitive. This targeted censorship could use protocol signatures to filter transactions interacting with particular contracts or services.
Geographic Restrictions: Jurisdictional requirements might lead to filtering transactions from specific regions based on IP address ranges. This geofencing at the network layer prevents participation from restricted locations without affecting other traffic.
Fee Market Manipulation: A host might selectively delay or drop transactions with lower fees to artificially inflate the fee market or prioritize more profitable transactions, creating an invisible transaction filtering layer before transactions even reach the block builder.
MEV Tax Evasion: A host might intercept and block transactions implementing “MEV tax” mechanisms at the network layer. These mechanisms rely on fair transaction ordering by priority fee to redirect extractable value from block builders to applications and users. A host could capture MEV while avoiding the application’s tax system by filtering or delaying competing high-priority transactions before they reach the TEE, then inserting its own lower-priority transactions. This undermines application-level economic protections through network-level intervention.
These real-world scenarios demonstrate how censorship can be sophisticated, targeted, and difficult to distinguish from normal network behavior.
The Operator/Owner Separation Challenge
The problem becomes even more complex when the TEE operator differs from the application owner. In this context, the application owner is the entity that develops, deploys, and is responsible for the application running inside the TEE, while the operator is the entity that controls the physical hardware and network infrastructure on which the TEE runs. This separation creates a fundamental trust issue that cannot be resolved through technical means alone.
The application owner has no visibility into network operations, no control over host networking, limited ability to detect censorship, and no reliable way to monitor traffic outside the TEE.
Meanwhile, the host operator maintains complete control over all network interfaces, the ability to filter or modify all traffic, control over logging and monitoring systems, and the ability to hide censorship activities.
This division of capabilities means that even with perfect TEE security, the application running inside remains vulnerable to network manipulation by the host, with limited options for detection or prevention
Conclusion and Implications
The network-level censorship problem has several important implications:
Security Boundary Limitation: TEEs protect computation and data in memory but not communication. The network remains a fundamental weak point in any TEE-based security architecture, creating an unavoidable trust dependency on the host.
Detection Challenges: Differentiating intentional censorship from normal network issues is extremely difficult, especially with limited visibility from within the TEE. The host can manipulate monitoring data to hide censorship activities.
Technical Solution Limitations: Purely technical solutions are mostly limited to specific aspects when it comes to "general censorship” at the network level since all traffic must ultimately pass through the host-controlled network. This shifts the focus to detecting and creating consequences for censorship rather than preventing it entirely.
While we will explore comprehensive solutions in subsequent blog posts, approaches generally fall into three categories: Network-level Solutions (such as path diversity and privacy networks), Application-level Solutions (like distributed validation and commitment schemes), and Economic and Social Solutions (including reputation systems and incentive mechanisms). Each category addresses different aspects of the censorship problem, but none can completely eliminate the host’s fundamental control over network traffic.
Understanding these limitations is crucial when designing censorship-resistant systems. Rather than attempting the impossible task of preventing network censorship entirely, effective approaches must combine technical mitigations with detection mechanisms and accountability frameworks.
Having outlined how a determined host can censor traffic, we next examine which network-level techniques can mitigate, if not fully eliminate, these vulnerabilities and discuss their trade-offs. Stay tuned for the follow-up blog post!