Iran's censor and AT&T's Stream Saver restrict DPI inspection strictly to port 80; traffic on any other TCP port escapes classification entirely. Iran additionally inspects the full flow (not just initial packets), unlike T-Mobile and the testbed device which only inspect the first few packets, making packet-count-based evasion insufficient against Iran on port 80.

Middlebox classification state is ephemeral: the testbed carrier-grade DPI device flushes results after 120 seconds (or 10 seconds after a TCP RST), and the GFC flushes state after 40–240 seconds depending on time of day. A strategically timed pause before the matching payload, or a TTL-limited RST packet, causes the classifier to re-evaluate the connection as unclassified traffic.

§4.3, §5.3 detection

TCP segment splitting and out-of-order delivery evades DPI classification in the testbed, T-Mobile, and Iran, but fails against the GFC—which performs extensive packet validation and correctly reassembles reordered streams—and AT&T, which uses a transparent HTTP proxy that normalizes all traffic before inspection. Payload splitting to one byte in the first packet is sufficient to defeat packet-count-limited classifiers.

§4.3, Table 3 evaluation

lib·erate's TTL-limited inert packet insertion—sending a decoy packet with TTL set to expire at the middlebox but carrying a misclassifying payload—successfully evades classification in a carrier-grade testbed DPI device, T-Mobile's Binge On, and the Great Firewall of China, but fails against Iran's censor and AT&T (Table 3). When bilateral server support is available, inserting a single dummy packet at flow start evades classification in all four deployments.

§4.3, Table 3 evaluation

None of the operational networks tested—T-Mobile, AT&T, the Great Firewall of China, and Iran—classify UDP traffic; the authors describe this as 'a surprisingly easy way to evade their policies.' Iran's censor inspects the entire TCP flow but leaves UDP flows untouched across all tested applications.

§1 (key findings), §6 detection

The June 2025 Iran shutdown—carried out during the Iran-Israel war beginning ~June 19—did not use BGP route withdrawals as in 2019. Instead, authorities applied service-level restrictions at the national border: DNS poisoning of foreign destinations, protocol whitelisting permitting only pre-approved domestic services, and DPI to block circumvention-tool traffic. Iran's international traffic fell roughly 90% while the country's BGP routes remained advertised, making the shutdown invisible to BGP-based monitoring systems. OONI measurement volume, which totalled 121,333 in June 2025, collapsed to under 200 submissions on June 19-20.

2025-iran-shutdown-measurement Executive Summary / §2 dpidns-poisoningport-blockingip-blocking

During the June 2025 shutdown, Iranian authorities blocked international One-Time Password (OTP) SMS delivery, preventing new sign-ins to foreign secure-messaging platforms and VPN services. This forced users toward government-approved domestic platforms that lack security and privacy protections. The blockade of OTPs effectively weaponized account-recovery flows as a secondary shutdown layer, disproportionately affecting users who needed to activate new circumvention tools during the crisis.

2025-iran-shutdown-measurement §Human Rights Implications port-blockingdpikeyword-filtering

VPN search demand in Iran spiked approximately 707% during the June 2025 stealth blackout, as measured by Top10VPN analytics, making it one of the highest-documented circumvention-demand spikes associated with a single shutdown event. Despite this demand, many VPN connections failed because the protocol whitelist eliminated non-HTTPS tunneling methods and HTTP-level filters could detect known VPN signatures on port 443.

2025-aryapour-stealth-blackout §1, §5 dpiport-blockingtraffic-shape

Iran's June 2025 shutdown enforced a strict national protocol whitelist: only DNS (UDP/53), HTTP (port 80), and HTTPS (port 443) traffic from Iranian networks to external servers was forwarded; all other protocols—including OpenVPN (UDP/1194), SSH (port 22), and arbitrary TCP/UDP ports—were silently dropped without response by DPI at the border.

2025-aryapour-stealth-blackout §4.4 dpiport-blockingfully-encrypted-detect

The August 20, 2025 unconditional RST event revealed an asymmetry in the GFW's triggering mechanism: for traffic originating inside China, both the client SYN and the server SYN+ACK each independently triggered three injected RST+ACK packets (six total per connection). For traffic to China from outside, only the Chinese server's SYN+ACK triggered RSTs — the foreign client's SYN alone was insufficient. This asymmetry implies the responsible device observed the SYN+ACK from the Chinese server as the trigger condition, not a port-match rule on the SYN.

2025-gfw-port443-rst §2.1, §2.2 rst-injectionport-blockingdpi

Starting October 3, 2022, more than 100 users reported simultaneous blocking of TLS-based circumvention servers running Trojan, Xray, V2Ray TLS+WebSocket, VLESS, and gRPC. Blocking was port-specific initially (mainly port 443, but also non-443 ports), then escalated to full IP blocking when users switched ports. Domain names were not added to DNS or SNI blocklists. naiveproxy was notably not affected. The blocking was dynamic in at least some cases (browsers could still reach the port, but circumvention tools could not), strongly indicating protocol-level identification rather than blind port blocking.

2022-blocking-tls-circumvention full post fully-encrypted-detectdpitls-fingerprintport-blocking