# Random Segmentation: New Traffic Obfuscation against Packet-Size-Based Side-Channel Attacks
## 4 Materials and Methods  
### Noise-Free Randomization  
We defend against traffic-analysis attacks by enabling IoT applications to control their packets, where it is not typically controllable. The application layer delivers a message of byte stream to the transport layer, which appends its header information (e.g., port number) and passes the data to the network layer as a segment. The segment size is determined by the maximum segment size (MSS) and specific situations summarized below [24]:  
* If the application message \(\geq\) MSS, the TCP protocol sends the data in full segments equal to MSS for transmission and holds any portion of data surpassing MSS in an incomplete segment accumulating more bytes.
* If the message \(<\) MSS (i.e., there is still space in the segment) and a previously sent packet has not been acknowledged yet, the protocol waits for some time (\(+/-200\) ms [13]) to accumulate more bytes. This time delay allows for collecting more data to optimize network usage.
* If no additional data arrives within the timer period, the protocol dispatches the available data for transmission.  
The network layer, which is responsible for sending the data over the network, receives the segments and breaks them into as few full packets as possible by the MTU restriction. Indeed, the MSS value at the transport layer depends on the underlying network MTU to ensure TCP segments can be properly encapsulated within network packets. MSSparameters are exchanged during the TCP-handshake phase, and the network interface card's device driver provides the TCP/IP stack with the MTU value.  
With our defense, the packet size is indistinguishable due to the randomness. That is, it consistently breaks thet received messages into arbitrarily sized segments. Suppose an IoT application sends a message \(m\) of \(n\) bytes. As stated earlier, the system, by default, will transmit \(m\) in a single segment if \(n=\) MSS or pass the small message (\(n<\) MSS) as it is after the timeout period (\(+\) /\(-\)200 ms). If \(n>\) MSS, \(m\) will be divided into \(\left\lceil n/\text{MSS}\right\rceil\) segments, all equal to MSS except the last segment if \(n\) is not an exact multiple of MSS (i.e., \(n\%\text{MSS}>0\)); then, the last segment will hold the remaining bytes (\(n\%\text{MSS}\)). For example, assuming MSS is 1500, an application message of 3500 bytes will be transmitted in three segments (1500, 1500, 500). Unlike this dynamic, our defense will divide \(m\) into a random number of segments, and each segment's length will also be random. As a result, the data pattern from the length features is not predictable.  
Figure 1 depicts two communication scenarios between a cloud server and an IoT device; the top represents the regular/undefended traffic, and the bottom shows the shaped/defended one. In both examples, we assume the server sends the same message two times. We here focus on the incoming traffic from the server side to demonstrate the concept of our defense. However, we expect both endpoints (i.e., server and client IoT) to implement our defense when communicating with each other. Thus, the bidirectional traffic is fully obfuscated.  
In the first scenario, the server with no defense sends data in a typical packetized flow, leaking exploitable signatures for fingerprinting attacks. In contrast, the second defended scenario shows that randomization occurs at the transport layer. Specifically, our technique passes random-sized segments to the network layer. Consequently, the traffic pattern generated by our shaping technique is challenging to classify.