IP tunneling encapsulates packets in outer IP headers to support IPv4/IPv6 coexistence, site interconnection, and VPN, mobile, and satellite networks. An endpoint removes the outer header and forwards the inner packet, but this transparency becomes a security blind spot when it contains a complex IPv6 Extension Header (EH) chain.
In our recent USENIX Security 2026 paper, we present TED, a Pulsing Denial-of-Service (PDoS) technique that turns permissive tunnel hosts into programmable delay lines. Instead of relying on DNS, Network Time Protocol (NTP), Content Distribution Networks (CDNs), or other application-layer services, TED combines nested paths, EH delays, and packet scheduling to focus traffic sent over seconds into a narrower burst.
This post covers the tunnel/EH interaction, measurements, controlled experiments, and practical mitigations.
Why revisit tunnel security?
Several widely deployed tunnel protocols provide neither authentication nor encryption by default. Without effective peer validation and forwarding controls, an exposed endpoint can accept encapsulated traffic from unauthorized senders and act as an open relay, forwarding decapsulated inner packets.
IPv6 Fragment, Routing, and Destination Options headers can be chained, yet routers, firewalls, and tunnel implementations handle them inconsistently. Many measured tunnel hosts inspected only what forwarding required, allowing deeply nested inner headers to survive decapsulation without normalization or rejection.
Tunnels do more than relay traffic: EH processing and multi-hop tunnelling create different, partly controllable delays. With reverse-order scheduling, long-path packets are sent before short-path packets. Accurate estimates make them converge at a chosen time.
From transparent forwarding to a programmable pulse
TED organizes the process into five stages:
- Discover: Find tunnel hosts that decapsulate and forward traffic under the tested protocol conditions.
- Measure: Use EH-aware probes to obtain round-trip measurements and infer one-way delays for the relevant path segments.
- Construct: Build valid nested paths and EH combinations within Path MTU constraints.
- Schedule: Subtract each path’s estimated delay from a common target arrival time.
- Inject: Send comparatively evenly so distributed paths focus traffic into a short target pulse.
TED has important prerequisites. An attacker needs raw-packet capability; paths must permit nested encapsulation and relevant EHs; spoofing-dependent steps require absent or incomplete source validation; and one-way delays must match estimates closely. Route changes, filtering, loss, and drift reduce fidelity. TED therefore demonstrates a measured attack surface under stated conditions, not that every tunnel host can target any victim at any time.
How large is the exposed surface?
From June 2025 to January 2026, we ran 44 scans at randomized intervals. Each covered about 3.7 billion IPv4 addresses and 20 million IPv6 Hitlist addresses. Cumulatively, 1,909,440 hosts passed forwarding tests for six tunnel protocols: 1,618,576 IPv4 and 290,864 IPv6 addresses.
Tunnel protocol | Observed vulnerable hosts |
6to4 | 552,762 |
4in6 | 80,052 |
GRE | 539,237 |
GRE6 | 4,681 |
IPIP | 526,577 |
IP6IP6 | 206,131 |
Total | 1,909,440 |
This is a cumulative result, not a live census. Addresses, policies, timing, and forwarding properties can change. The claim is therefore limited to hosts observed under the tested protocol, spoofing, and timing conditions during the measurement window.
EH interaction was also material. Average EH survivability exceeded 70.9% among tested IPv6 tunnel hosts, and 81.6% of cases showed a significant processing-delay increase after EH insertion. Across six controlled targets, 82.5% of combined one-way-delay estimation errors were within ±10ms, supporting the evaluation’s 20ms pulse window. These figures describe the selected protocols, headers, targets, and period, not all IPv6 networks.
What changed in controlled experiments?
We targeted no operational third-party service. Instead, six controlled dual-stack targets were deployed in China, Japan, Germany, and the United States. We measured Path MTU, capped each intermediate host at 10 packets per millisecond, and repeated each scenario ten times.
A single-hop baseline sent 11,000 packets through naturally distributed tunnel delays, producing a 12× pulse. TED distributed 35,029 packets across 4.2 seconds at about 8,340 packets per second. More than 34,000 arrived within 0.25 seconds; in the critical 20ms window, the peak exceeded 180 times the sender’s average rate.
The 180× value measures temporal concentration: Target peak packet rate divided by the attacker’s average send rate. It is neither byte amplification nor traffic created by tunnel hosts. It shows dispersed traffic synchronizing into an instantaneous burst that can threaten a target link or queue.
Why should operators care?
The first concern is visibility. Application-layer defences may block abused DNS or NTP services, but TED operates below them. The target sees ordinary decapsulated traffic from many paths, while each intermediate network sees a low local rate and may not inspect deeply enough to recognize a coordinated pulse.
Tunnel exposure crosses administrative and infrastructure boundaries. We found hundreds of responsive GRE and GRE6 addresses in AS14593 prefixes; reverse DNS associated examples with Starlink user terminals and ground points of presence. We did not use operational Starlink services as victims. The observation warns that strict inbound rules may still admit selected encapsulation protocols, extending relay exposure into satellite networks.
Practical mitigations
Operators can reduce exposure now by removing open-relay behaviour and making nested packets visible:
Restrict tunnel peers: Accept encapsulated traffic only from configured or authenticated endpoints; disable open Internet-facing decapsulation.
Validate source addresses: Apply ingress and egress validation to outer and inner packets, and verify inner sources against authenticated customers or expected prefixes.
Limit recursion: Drop or quarantine unexpected nesting; depth greater than one is unusual in many legitimate deployments.
Constrain risky EH chains: Block deprecated RH0, limit repeated Fragment Headers, and reject unneeded combinations. Where legitimate functions require EHs, use a role-specific allowlist instead of indiscriminate blocking.
Inspect and log after decapsulation: Expose counters for tunnel depth, EH type and count, failures, and unexpected inner source addresses; inspect or normalize before forwarding.
Detect coordinated pulses: Add short-window queue, loss, and arrival-rate monitoring; low local tunnel rates can combine into a high-rate destination burst.
Vendors should reject arbitrary tunnel senders, enforce nesting limits, and parse EHs consistently across fast and slow paths. Tests should cover recursive decapsulation, inner fragments, deprecated Routing Headers, and source validation.
Concluding thoughts
TED illustrates a broader IPv4-to-IPv6 transition lesson: Mechanisms manageable alone can interact unsafely. Tunnelling hides structure while EHs add flexible processing. Permissive handling can provide the delay diversity and relay behaviour needed to focus traffic in time.
The priority is to close open tunnels, validate inner and outer sources, cap nesting, and make EH handling observable. These controls also constrain attacks exploiting ambiguous trust boundaries inside encapsulated traffic.
For full methods, limitations, and evaluation, read TED: Abusing Tunnel Hosts and IPv6 Extension Headers for Pulsing DoS Attacks. The dataset and proof-of-concept code are in the TED repository.
Le Gai is a PhD student at Tsinghua University, where he studies Internet measurement, IPv6 security, and DoS attacks. Other authors, Lin He, Ying Liu, Zedong Jia, Daguo Cheng, and Chentian Wei, also contributed to this post.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.