# Random Segmentation: New Traffic Obfuscation against Packet-Size-Based Side-Channel Attacks
## 2 Related Work  
Many studies have shown how packet-length information can be exploited to identify IoT devices [4] and specific events [3; 6]. The Onion Router (Tor), a well-known privacy-preserving system, addresses such side-channel leakage by sending data in a fixed packet length [14]. Nevertheless, adopting Tor increases the amount of received traffic and adds additional latency due to the multi-hop nature of Tor. Packet padding has an acceptable effectiveness but incurs a high data overhead. The authors of [7] reported that several packet-padding strategies could thwart the attackers' classification but increased the amount of data sent significantly (>500%). A lightweight solution presented by [PERSON] et al. [15] could reduce the accuracy of IoT device identification to higher than random guessing by 15%. Their mechanism inserts random bytes between 1 and the available space to fill the packet (i.e., to equal MTU). Still, the added noisy data (54%) can lead to an undesirable communication overhead. A closely related defense [16] can successfully defeat analytics based on WiFi eavesdropping. It uses dummy traffic to shape a pair of devices' traffic to be similar. The technique could spoof other devices' traffic by constructing the flow of dummy packets using prerecorded traces of the targeted device. Thus, an attacker cannot identify a specific device. Moreover, it incurs zero Internet bandwidth overhead by dropping the dummy packets at the access point (AP) before sending them to the Internet. The WiFi-based AP needs to be modified to drop dummy packets, which are flagged using the reserved bit flag on the IP header. However, its effectiveness diminishes when the attacker can monitor the IP-level traffic. Insiders accessing the IP header, such as rogue APs and network snoopers, can filter out flagged dummy packets. As a result, network-layer observers can recover the original/undefended traffic and overcome the defense. Our technique addresses the size-based leakage against both internal and external adversaries (i.e., IP- and MAC-level observers) because our segmentation occurs at the transport layer before the packet construction. Traffic splitting was initially introduced for multi-path routing [17], which splits the flow across different paths to prevent malicious intermediary nodes from recording the whole traffic. It presented two levels of defense. First, the network-layer defense applies a multipathing strategy within the Tor network to obscure the traffic patterns. The second application-layer defense follows the same concept. It decomposes HTTP requests into sub-requests in parallel over multiple paths or sends a single HTTP request for different web objects over different entry nodes in Tor circuits. Assuming partial data is insufficient to perform traffic analysis attacks, this defense is effective against remote observers. However, in this paper, we are also concerned about local eavesdroppers who are physically close to the device transmission range. No middleboxes are involved in this scenario; hence, the attacker can collect the complete capture to perform the attack. On the other hand, our defense considers all observers positioned in the link between the source and destination, remote and local observers alike. Traffic shaping has been introduced as a routing-optimization technique for vehicular ad hoc networks [18]. This approach employs reinforcement learning to enhance the efficiency of routing decisions, particularly in demanding and real-world situations marked by unstable connections, varying communication ranges, and rapid topology changes. This objective is achieved through distributed reinforcement learning, enabling the routing protocol to learn from vehicle experiences to make optimal decisions and adjust to the network's unpredictable fluctuations. This work cannot be extended to determine packet sizes, as its primary objective is to manage packet routing rather than packet sizes.