# Random Segmentation: New Traffic Obfuscation against Packet-Size-Based Side-Channel Attacks
## 5 Evaluation and Results
### Effectiveness
#### 5.1.1 Preliminary Data Analysis  
Figure 2 presents a sample traffic flow observed over a period of 10 min before and after implementing our defense. Before obfuscating the traffic, we observed variable traffic patterns in the light bulb and smart plug. Specifically, the bulb's traffic was higher than the plug's in seven instances, lower in two instances, and similar in one case (Figure 2a). This inconsistency in traffic poses a challenge for reliable device profiling based on data-volume-related features. The impact of this variability is evident in the spike in bulb traffic (Figure 2a, traffic period 5), which was misclassified as camera traffic. \begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Parameter**} & \multicolumn{2}{c}{**Low-Bandwidth Devices**} & \multicolumn{2}{c}{**High-Bandwidth Devices**} \\ \cline{2-5}  & **Bulb and Plug** & \multicolumn{2}{c}{**Doorbell and Camera**} \\ \hline _Prob_ & 0.8 & & 0.8 & \\ _Min_ & 5 & L1 = 20 & L2 = 100 & L3 = 500 \\ _Max_ & 20 & L1 = 40 & L2 = 300 & L3 = 1000 \\ \hline \hline \end{tabular}  
* L1, L2, and L3 refer to the three levels of segmentation introduced in Section 4.3.  
\end{table} 
Table 1: Our experimental setup of the system parameters *. On the contrary, the camera and dorbell exhibit stable traffic patterns while operating in a fixed working mode, such as recording videos (Figure 1(c)). However, the camera's higher resolution results in significantly larger traffic compared to the doorbell. Therefore, to account for the variance in data volume between the camera and doorbell, we introduced covered bytes to the doorbell to compensate for the variance in data volume (Figure 1(d)). Dummy/covered packets can be labeled and discarded at the receiving side. We assume the defender can leverage the header field of the Traffic Flow Confidentiality (TFC) mechanism [25]. This mechanism provides a tool to inject dummy packets using a wrapped header field that is encrypted and cannot be observed by network observers. The injection statistics are summarized in Table 2, revealing that no dummy packets were injected for the bulb and plug since the data rate does not serve as a suitable representative for those two devices. Conversely, the doorbell necessitates a greater incorporation of covered bytes to achieve parity with the camera in order to introduce confusion within the classifier's discrimination between the two devices. Additionally, a marginal proportion of covered bytes (0.7%) was introduced to the camera to mask its disparities from the doorbell, particularly during periods of inactivity. It is important to highlight that we incorporated a 20% time delay (refer to Equation (2) for the specific computation) in our simulation to align it with the findings in Section 5.3. As a result, the overall traffic attributes were affected. For instance, the event surge observed in the light bulb's traffic before applying our defense (Figure 1(a), traffic period 5) can be seen in the subsequent observation time window in the defended traffic (Figure 1(b), traffic period 6). \begin{table}
\begin{tabular}{c c} \hline \hline
**Device** & **Covered Bytes (\%)** \\ \hline Bulb & 0 \\ Plug & 0 \\ Camera & 0.7 \\ Doorbell & 340 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Injected covered bytes to hide data-rate features. Figure 2: Traffic flow of four IoT devices over 10 min. Figure 3 illustrates the impact of our approach on the packet size. We chose the bulb and plug for demonstration as they rely entirely on random segmentation for packet-size obfuscation (i.e., no covered bytes were injected). Before implementing our defense, we can notice in Figure 2(a) a steady average size (nearly 130 bytes) sent by the plug versus fluctuating value by the light bulb. (After subtracting the frame header (82 bytes), a data frame of 130 bytes means there are 48 (i.e., 130-82) bytes in the payload for the segmentation.) We can observe similar behavior in the return traffic represented by negative values in Figure 2(c).