Internet Protocol tunneling has long served as a fundamental backbone for modern networking, quietly encapsulating packets within outer IP headers to bridge the architectural gap between IPv4 and IPv6, connect disparate enterprise sites, and power complex virtual private networks, mobile architectures, and satellite data links. In a typical routing scenario, a tunnel endpoint simply strips away the outer header and forwards the inner packet onward to its ultimate destination. However, security researchers have demonstrated that this vital transparency can easily transform into a dangerous security blind spot when a malicious actor slips complex IPv6 Extension Header chains inside those nested packets.
In a landmark research paper presented at the prestigious USENIX Security conference, a team of network security experts detailed a sophisticated Pulsing Denial-of-Service attack technique known as TED. This novel methodology cleverly repurposes permissive, unauthenticated tunnel hosts scattered across the global internet, turning them into programmable delay lines. Instead of relying heavily on traditional application-layer infrastructure such as the Domain Name System, the Network Time Protocol, or massive Content Distribution Networks to coordinate an assault, TED ingeniously combines nested forwarding paths, Extension Header processing delays, and precise packet scheduling. This allows an attacker to synchronize traffic sent continuously over a period of several seconds, condensing it into an intensely concentrated, high-rate burst upon arrival at a target.
The research team, which includes scholars from Tsinghua University, provides a comprehensive look at how tunnel protocols and IPv6 Extension Headers interact, outlines their extensive global measurement campaigns, reviews controlled empirical experiments, and highlights practical mitigations that network operators can implement to safeguard their infrastructure.
Why Revisit Tunnel Security in Modern Networks?
To understand the mechanics of the threat, security professionals must re-examine foundational assumptions about tunnel protocol design. Several widely deployed tunneling protocols provide neither native authentication nor encryption by default. Without effective peer validation and strict forwarding controls, any exposed tunnel endpoint can inadvertently accept encapsulated traffic from unauthorized senders, acting essentially as an open relay that forwards decapsulated inner packets without question.
Compounding this architectural vulnerability is the nature of IPv6. Features like Fragment, Routing, and Destination Options headers can be chained together in complex sequences. Yet, intermediate routers, enterprise firewalls, and diverse tunnel implementations handle these extension headers with frustrating inconsistency. During their global scans, the researchers discovered that many measured tunnel hosts inspected only the bare minimum required for basic forwarding, allowing deeply nested inner headers to survive the decapsulation process entirely intact, without undergoing necessary normalization or rejection.
Tunnels accomplish much more than merely relaying traffic from one point to another. The processing overhead associated with Extension Headers and the deliberate utilization of multi-hop tunneling introduce variable, yet partly controllable, delays across the network path. By employing reverse-order scheduling—wherein packets destined for long, circuitous paths are transmitted prior to those taking short, direct paths—an attacker can leverage these calculated delays. With accurate timing estimates, packets traveling vastly different routes can be made to converge precisely at a chosen target at an exact moment in time.
From Transparent Forwarding to a Programmable Pulse
The mechanics behind this attack technique organize the operational process into five distinct stages of discovery, measurement, construction, scheduling, and execution. First, an attacker systematically scans the public address space to identify permissive tunnel hosts that fail to validate sources or restrict relay traffic. Next, the attacker measures the specific, variable delays introduced by processing IPv6 Extension Headers across those routes. Armed with this telemetry, the attacker constructs deeply nested packets designed to exploit the discovered latency profile. Finally, through careful packet scheduling, the traffic is dispersed across multiple paths and staggered in time to achieve simultaneous convergence at the destination.
Executing such an operation requires specific foundational capabilities. An attacker must possess raw-packet generation capabilities, and the network paths involved must permit nested encapsulation alongside the relevant extension headers. Furthermore, steps that rely on IP spoofing assume an absence or incompleteness of source address validation along the path, while success ultimately hinges on one-way delays matching empirical estimates closely. Natural network phenomena such as unexpected route changes, aggressive packet filtering, background packet loss, and clock drift can reduce the fidelity of the pulse. Consequently, the research demonstrates a measured attack surface under stated experimental conditions, rather than a universal capability to target any network host from any location at whim.
Measuring the Global Exposure of Vulnerable Tunnels
To gauge the scale of the underlying problem, the research team conducted a massive scanning campaign between June 2025 and January 2026, running a total of 44 distinct scans at randomized intervals. Each individual scan covered approximately 3.7 billion IPv4 addresses and 20 million IPv6 Hitlist addresses. Over the course of the study, the cumulative measurements identified nearly 1.91 million unique hosts that passed forwarding tests across six distinct tunnel protocols, comprising over 1.61 million IPv4 addresses and nearly 290,864 IPv6 addresses.
The observed vulnerable infrastructure spanned multiple traditional and modern tunneling standards, including 6to4, 4in6, Generic Routing Encapsulation, GRE6, Internet Protocol in Internet Protocol, and IP6IP6. The researchers emphasize that this figure represents a cumulative tally observed across multiple scan windows rather than a static, live census of the internet. IP addresses, administrative security policies, network routing, and forwarding behaviors frequently change over time, meaning the findings reflect conditions measured specifically during the testing window under targeted protocol and spoofing parameters.
The interaction with IPv6 Extension Headers proved equally significant during the analysis. Average extension header survivability exceeded 70 percent among the tested IPv6 tunnel hosts, and more than 81 percent of cases exhibited a measurable, significant increase in processing delay following the insertion of extension headers. Across six controlled experimental targets, the vast majority of combined one-way-delay estimation errors remained within a tight ten-millisecond margin, validating the effectiveness of the evaluation’s twenty-millisecond pulse window.
Insights from Controlled Experiments and Traffic Concentration
Rather than targeting operational third-party services on the public internet, the research team established six controlled, dual-stack targets distributed globally across China, Japan, Germany, and the United States to measure the real-world impact of the technique. The team carefully measured Path MTU limitations, capped each intermediate host at ten packets per millisecond to prevent runaway traffic, and repeated each test scenario ten times to ensure statistical reliability.
A conventional single-hop baseline transmitting eleven thousand packets through naturally distributed tunnel delays produced a modest twelve-fold temporal concentration pulse. In contrast, when the experimental technique distributed over 35,000 packets across a four-second interval at an average rate of roughly 8,340 packets per second, the results were starkly different. More than 34,000 of those packets arrived at the target within a quarter-second window, and during the critical twenty-millisecond peak, the packet arrival rate exceeded 180 times the sender’s average transmission rate.
This dramatic metric measures temporal concentration—calculated as the target’s peak packet rate divided by the attacker’s average sending rate. It does not represent byte amplification or the generation of synthetic traffic by the tunnel hosts themselves. Instead, it demonstrates how widely dispersed, low-rate traffic streams can synchronize into a sudden, intense burst capable of overwhelming target link capacities or routing queues.
Implications for Network Operators and Infrastructure Security
The findings present serious challenges for defenders, primarily concerning operational visibility. Traditional application-layer defenses are typically designed to detect and block abused network services like DNS or NTP, but this pulsing attack operates entirely beneath that architectural layer. To a standard monitoring tool at the destination, the incoming traffic appears as ordinary, decapsulated packets arriving from a multitude of seemingly legitimate paths. Concurrently, each intermediate network observes only a low local traffic rate, failing to inspect packets deeply enough to recognize that they form part of a globally coordinated pulse.
Furthermore, this tunnel exposure blurs traditional administrative and infrastructure boundaries. During their scans, researchers identified hundreds of responsive GRE and GRE6 addresses located within specific autonomous system prefixes, with reverse DNS records associating examples directly with commercial satellite user terminals and ground points of presence. While the researchers strictly avoided using operational satellite services as victims in their tests, the observation serves as a stark warning that strict inbound security rules can still inadvertently permit selected encapsulation protocols, thereby extending relay exposure directly into satellite and mobile networks.
Practical Mitigations for Network Defenders
Network operators can take immediate steps to reduce their exposure by eliminating open-relay behaviors and increasing the visibility of nested packets. Security teams should restrict tunnel peers by accepting encapsulated traffic exclusively from pre-configured or cryptographically authenticated endpoints, effectively disabling open, internet-facing decapsulation services. Implementing robust ingress and egress source address validation on both outer and inner packets ensures that inner sources can be verified against authenticated customer records or expected prefix assignments.
Operators should also limit packet recursion by dropping or quarantining unexpected nesting depths, as nesting levels greater than one are exceedingly rare in legitimate production deployments. Risky extension header chains must be constrained by blocking deprecated routing headers, limiting repeated fragment headers, and rejecting unneeded header combinations. Where legitimate business functions require specific extension headers, organizations should deploy role-specific allowlists rather than relying on indiscriminate blocking strategies.
Additionally, infrastructure teams should inspect and log metrics following decapsulation, maintaining active counters for tunnel depth, extension header types, parsing failures, and unexpected inner source addresses. Implementing short-window queue monitoring, packet loss detection, and arrival-rate analysis can help identify when low local tunnel rates are suspiciously combining into high-rate destination bursts. Equipment vendors must also do their part by rejecting arbitrary tunnel senders, enforcing strict nesting depth limits, and parsing extension headers consistently across both fast and slow routing paths.
The research was authored by Le Gai, a PhD student at Tsinghua University specializing in internet measurement, IPv6 security, and denial-of-service defense, alongside co-authors Lin He, Ying Liu, Zedong Jia, Daguo Cheng, and Chentian Wei. Complete methodological details, evaluation limitations, and proof-of-concept code remain publicly accessible via the research team’s project repository.
