tapdance   TapDance

For Iran, a greedy cumulative-coverage analysis over 22,799 resolver-to-uncensored-AS paths shows that the top 5 ASes cover 59% and the top 10 ASes cover 76.6% of all DNS resolution paths. AS3257 (GTT Communications) and AS174 (Cogent Communications) each appear in approximately 15.7% of paths and contribute nearly all their usage as unique (non-overlapping) paths.

2025-umesh-improved §5.2, Figure 3–4 evaluation

Prior decoy routing deployments suffered severe throughput degradation: the TapDance ISP pilot reported average client throughput of only ~5 KB/s, making it unsuitable for most web content; other DR prototypes restricted evaluation to files under 1 MB in controlled lab settings, with some reporting over 30 seconds to load home pages under 1.5 MB in size.

2020-sharma-siegebreaker §3, §2.3 evaluation

Total hardware cost for four detector stations plus a central proxy was approximately $30,000 USD, with estimated annual operating costs of ~$13,000 for co-location and ~$24,000 for a 2 Gbps upstream connection, plus ~40% FTE of an ISP network engineer—costs that are structurally higher than endpoint-based circumvention due to mandatory network-operator co-location requirements.

2020-vandersloot-running §5.2 deployment

During a major censorship event in April 2019, new censor techniques blocked many Psiphon transports while TapDance remained accessible, causing a 4× increase in the fraction of TapDance-enabled clients' traffic and daily users peaking above 25,000—with no measurable degradation in connection success rate or per-session throughput under the increased load.

2020-vandersloot-running §4.5 evaluation

Over 115 days of operation with 1,500–2,000 active decoys, the busiest decoy site averaged only 13.24 concurrent connections and 12.32 MB of traffic per day; only 2 of roughly 3,000 candidate decoy sites opted out via robots.txt over 18 months, and none reported operational problems, confirming that decoy websites are not meaningfully burdened at this deployment scale.

2020-vandersloot-running §4.3, Table 1 evaluation

The first production Refraction Networking deployment used four TapDance stations at Merit Network observing 140 Gbps aggregate capacity and served up to 33,000 unique users per month across 559,000 Psiphon installations, proxying up to 500 Mbps of circumvention traffic during the first year of continuous operation.

2020-vandersloot-running §1, §3, §4 deployment

Approximately 50% of TapDance client connection attempts failed to pass through any station due to routing variability at the ISP, producing an average of about one failed decoy per successful connection and time-to-first-byte exceeding five seconds in typical cases, even though median session RTT remained under one second.

2020-vandersloot-running §4.4, §5.4 evaluation

Conjure achieves 20% lower latency, 14% faster download bandwidth, and over 1400 times faster upload bandwidth compared to TapDance on a 20 Gbps ISP testbed. TapDance upload is throttled to approximately 0.1 Mbps because it must reconnect for every 32 KBytes sent; Conjure maintains a single persistent connection. At the 99th percentile, Conjure is 281 ms (92%) faster than TapDance.

2019-frolov-conjure §6.1 evaluation

For China (a highly connected, routing-capable adversary), the gossip protocol combined with any symmetric decoy routing design requires only 5 heavyweight downstream stations plus 880 lightweight upstream gossip stations — versus 880 heavyweight stations for purely symmetric designs. Five downstream stations alone impact 78% of routes from Chinese users, while a single downstream station already covers nearly 25% of traffic.

2018-bocovich-secure Table 2 / §3.2 evaluation

Between 80% and 90% of internet routes are asymmetric, with only about 10% of flows symmetric in Tier-1 (backbone) networks and roughly 70% symmetric at the network edge. This asymmetry makes decoy routing systems requiring relay stations on both upstream and downstream paths impractical for the majority of real-world deployments.

2018-bocovich-secure §3 evaluation

MultiFlow enables a tap-based decoy router to authenticate clients without inline traffic blocking by having the decoy router resume the client's TLS 1.3 session with the decoy host. The client embeds 112-byte sentinel values in the ClientRandom and key-share fields; the decoy router uses the exfiltrated 219-byte NewSessionTicket to perform the resumption. If the decoy host accepts the resumed session rather than falling back to a full handshake, the client is confirmed live.

2018-manfredi-multiflow §3.1 defense

Without per-site connection limits, popular decoy hosts risk resource exhaustion (Apache's default cap is 150 simultaneous connections); enforcing an initial limit of 30 concurrent clients per site—coordinated across stations via a central collector—kept the median site load at ~5 simultaneous clients, with the 99th-percentile site peaking at 37 after the limit was raised to 45.

2017-frolov-isp-scale §3.5, §4.3, Figure 9 deployment

Filtering candidate decoy sites by a minimum 15 KB TCP window eliminated 24% of the initial ~5,500 HTTPS hosts; a 30-second HTTP-timeout floor eliminated a further 11%; and AES-128-GCM cipher-suite support requirements eliminated an average of 32%—together reducing the viable decoy-site pool by approximately 55% before any live reachability tests.

2017-frolov-isp-scale §3.3, Figures 2–3 defense

The one-week trial served over 50,000 unique users (peak daily count: 57,000) with up to 4,000 concurrent sessions simultaneously, demonstrating that a four-station refraction deployment co-located at two mid-sized network operators can support tens of thousands of real censored users.

2017-frolov-isp-scale §4.2, Figures 4, 7 evaluation

The trial explicitly obtained no evidence about TapDance's resistance to adversarial censor countermeasures: its scale and duration were judged small enough that censors likely did not observe it, leaving theoretical censorship-resistance claims unvalidated against active blocking responses.

2017-frolov-isp-scale §2, §6 evaluation

TapDance was deployed on four ISP uplinks (two 40 Gbps, two 10 Gbps) using commodity 1U servers running a Rust/PF_RING zero-copy implementation; CPU load remained below 25% while handling a peak of ~14,000 new TLS connections per second across 34 cores, with cumulative mirrored traffic peaking at 55 Gbps across all stations.

2017-frolov-isp-scale §3.1, §4.1, Figure 1 deployment

Router-level mapping of the 30 key ASes reveals that 11,709 individual routers must be replaced with Decoy Routers (non-censorious ASes only), at a hardware cost exceeding $10.3 billion USD. Individual large ASes require hundreds to over 1,600 router replacements (e.g., AS3356 needs 576, AS209 Quest Communications needs 1,662). Even targeting the weakest adversary studied, Syria (containable by 3 ASes at AS level), requires 1,117 DRs.

2017-gosain-devil-s §5.2, §6.4, Table 3–4 evaluation

Table 1 shows Slitheen is the first decoy routing system to simultaneously defend against latency analysis, website fingerprinting, and protocol fingerprinting attacks, while also resisting TCP replay and Crazy Ivan active attacks. This security is achieved at the cost of requiring symmetric flows and inline blocking—requirements previously considered prohibitive—which the authors argue are increasingly met by commercial DPI traffic-shaping appliances (e.g., Sandvine) already deployed by ISPs.

2016-bocovich-slitheen §4.5, Table 1 evaluation

TapDance's non-blocking asymmetric design leaves the overt connection open but abandoned, enabling an active censor to inject a TCP ACK carrying a stale sequence number; the overt server responds with its true TCP state, exposing the discrepancy and confirming decoy routing. The attack requires no clean-path routing capability: the injected packet is forwarded through the tainted path by the non-blocking TapDance station itself.

2016-bocovich-slitheen §2.2, §4.3 detection

Asymmetric IP routing is a fundamental constraint on prior E2M designs: tier-2 ISPs typically see around 25% of packets on asymmetric paths, while tier-1 ISPs can have up to 90% of packets on asymmetric flows. Because Telex requires observing both directions of a connection to derive the client-server TLS master secret, this asymmetry severely constrains where it can be deployed. TapDance resolves this by using chosen-ciphertext steganography to leak the master secret from client to station in a single upstream packet, making it functional under fully asymmetric routing.

2014-wustrow-tapdance §1, §6 evaluation

TapDance introduces chosen-ciphertext steganography, which allows the client to embed an arbitrary-length hidden message inside a valid TLS ciphertext without invalidating the TLS MAC or session. By exploiting ciphertext malleability in both stream-cipher (counter) mode and CBC mode, the client can choose specific byte values to appear in the ciphertext while constraining plaintext to a safe ASCII range (0x40–0x7F), encoding 6 bits of tag data per ciphertext byte. This provides unbounded covert-channel bandwidth, compared to the fixed 224-bit TLS nonce used by Telex and Decoy Routing or the 24-bit TCP ISN used by Cirripede.

2014-wustrow-tapdance §3, §6 defense

All three prior end-to-middle (E2M) schemes — Telex, Cirripede, and Decoy Routing — require an inline flow-blocking component at the participating ISP, which adds latency, introduces a single point of failure, and may violate carrier SLAs. In private discussions with ISPs, the authors found that despite willingness to assist Internet freedom technically and financially, none were willing to deploy existing E2M technologies due to these operational impacts. TapDance removes the inline blocking requirement entirely, requiring only a passive tap and packet-injection capability.

2014-wustrow-tapdance §1, §6 deployment

Scanning a 1% sample of the IPv4 address space and the Alexa top-1-million domains, the authors found that over half of all TLS hosts will leave an incomplete HTTP request connection open for at least 60 seconds before sending data or closing the connection; many had timeouts exceeding 5 minutes. The 16-core TapDance station prototype processes over 12,000 tag verifications per second per core, with approximately 90% of CPU time consumed by a single ECC point multiplication on Curve25519. The station adds a median latency of 270 milliseconds to page downloads versus direct connections, and a single station instance can be overwhelmed by approximately 1.2 Gbps of TLS application-layer traffic.

2014-wustrow-tapdance §7.3, §8, Figure 5 evaluation

Because TapDance does not block client-to-server packets, a censor can inject a TCP packet with a stale acknowledgment number directly to the true decoy server; the server will reply with its actual TCP sequence state, which will differ from the sequence numbers the TapDance station has been using — confirming the flow is proxied. This active packet-injection attack is qualitatively easier to execute against TapDance than against Telex or Cirripede, which used inline blocking to prevent such probes from reaching the server. Table 1 in the paper confirms that TapDance, unlike Telex, lacks replay/preplay attack resistance and has no traffic-analysis defense.

2014-wustrow-tapdance §5.2, Table 1 detection