# Random Segmentation: New Traffic Obfuscation against Packet-Size-Based Side-Channel Attacks
## 6 Discussion  
Effectiveness: Our results validate that our approach can disrupt packet length features to protect against traffic-analysis attacks. By simulating our defense on a trace from real IoT devices, we show that the obfuscated traffic resulted in a baseless classifier comparable to random guessing. This is because our defense sends data packets in random sizes, which prevents the classifier from learning length-based fingerprints for profiling. Our technique does not consider timing characteristics, such as the interarrival time. However, the issue of timing leakage has been addressed by delaying the data packets to obscure the related patterns [8]. This approach can be integrated with our defense to effectively conceal both the timing and the length features. Efficiency: Our randomization technique is noise-free, and hence, more data-efficient than other noise-based approaches like packet padding. However, there is a case where the header overhead of our defense is higher than padding. If the size of the transmitted flow is relatively small compared to the packet headers (54 bytes), then every split with our approach adds more data than the payload itself. For example, if we have a device that sends a small packet of 100 bytes per second, it becomes expensive to split the packet into multiple chunks, as the header overhead from generating an additional packet becomes 54% (54/100). Nevertheless, such small traffic would be marginal to the total bandwidth in the network. In terms of time overhead, our countermeasure incurs a reasonable latency (20.5%), which many IoT devices can tolerate, such as sleep monitors and smart plugs [26]. However, high-bandwidth devices like cameras may experience degradation due to the need for greater bandwidth to support video streaming. One interesting insight we observe in Figure 4 is that intensive obfuscation (i.e., a higher degree of randomness) does not increase the latency. Although the number of packets is higher with our mechanism, it does not add a noticeable latency due to the immediate transmission enabled by the TCP_NODELAY option. The factor that led to the increase in transmission time was the limited send buffer, which puts the socket on hold from pushing more data until the buffer is empty. It is evident from Table 5 that smaller buffer sizes increase the time overhead significantly. Note that we are not claiming that the deactivation of [PERSON]'s algorithm is an efficient solution, as sending small packets can result in additional header and processing overhead. However, turning off [PERSON]'s algorithm has been introduced in prior studies as an effective technique with no adverse effect on performance, such as preventing many deadlock situations [24]. Similarly, our proof-of-concept implementation on consumer-grade laptops shows that our defense can mitigate privacy leakage but may introduce some latency, as the sender needs to send the data stream in a larger number of packets. With that being said, further research is needed to investigate the impact of our technique on devices with limited  
Figure 4: Latency (\(T\)) and packet header overhead (\(B\)) using the two randomization levels: \(Rand_{(low)}\) and \(Rand_{(high)}\). processing capacity and storage, similar to IoT devices. We plan further investigations in this direction as future work. Compatibility and Deployment Challenges: While our current implementation showcases the feasibility of the approach through a client-server setup using TCP sockets, we fully acknowledge that IoT environments present unique challenges. For instance, adapting our proposed technique for communication with generic browsers in server roles may necessitate updates on server-side software. Hence, there could be technical issues in accommodating all existing devices, necessitating further investigation in future research. Vulnerability Analysis: It is vital to address potential vulnerabilities and ensure the robustness of our approach.