## 4 Results
### Testbed Effects of Malicious Traffic  
The focus of the testbed experiments was to validate our protocol review findings regarding the Modbus protocol's safety implications and also to illustrate the issues with connection re-establishment in Modbus TCP implementations. Towards that goal, we first conducted baseline performance measurements focusing on characterizing latency with and without security features, comparing the use of external security gateways and a software-defined switch. UDP broadcast packets were generated by the attacking agent, emulating additional background traffic from an active network. While each packet was routed to the interfaces of the OT devices, the packets had no data intended for the devices and were expected to be discarded during normal operation. The results, shown in Table 1, demonstrate minimal impact from the additional security features. This is likely due to the  
Figure 4: Increasing impact of exponential backoff. Gray packets indicate synchronization attempts. low link requirements of OT devices (operating at 100 Mbps) and the efficient processing capabilities of both the security gateway firewall and the software-defined switch. Since the TCP connection time was the focus of our tests, and the security appliances added limited latency to the communication, the attacking agent was subsequently utilized to imitate new connection requests using SYN messages to the server side, and reset (RST) requests to the client, as shown in Figure 5.  
This attack mimics a SYN-flood attack that might be carried out on other TCP connections. However, by changing the IP and MAC addresses listed within the packet, we can successfully trick the gateway into sending the reset packet to the PLC. This, in effect, tells the PLC (client) that the connection has been closed and a new one needs to be initiated. The effect of this can be seen in Figure 6. If these attacks are applied consistently over a long period of time, the communication can effectively be stopped between the two devices, requiring minimal effort by the attacker. However, there are built-in mitigation strategies within many devices for this case. An example is the SYN-flood protection available within the gateway's configuration. However, this protection seems to only come into effect after 50 or more packets are received per second, which we tested in increments of 5, as shown in Figure 7. This figure shows that even with SYN-flood mitigation attempts that act to prevent Denial-of-Service, access to the network makes communication disruption possible and trivial. \begin{table}
\begin{tabular}{c c c c c c c c c c c} \hline \hline \multirow{2}{*}{**Latency (ms)**} & \multicolumn{8}{c}{**Background Traffic (Mbps)**} \\  & **5** & **10** & **15** & **20** & **25** & **30** & **35** & **40** & **45** & **50** & **55** \\ \hline Gateway & 2.898 & 3.123 & 2.880 & 2.896 & 2.835 & 2.924 & 2.865 & 2.931 & 2.886 & 3.107 & 3.117 \\ Security Gateway & 3.001 & 3.201 & 3.0331 & 3.277 & 3.210 & 3.070 & 3.093 & 3.900 & 3.086 & 3.002 & 3.192 \\ \hline Difference (ms) & 0.103 & 0.078 & 0.153 & 0.381 & 0.374 & 0.146 & 0.227 & 0.968 & 0.199 & \(-\)0.104 & 0.074 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Latency introduced by security gateway, Modbus TCP traffic. Figure 5: Generated traffic for single-sided TCP connection closure. A further interesting observation from this behavior was that the PLC failed to correctly filter the packet for the correct port number. To have the intended effect, the attack packet needed to be timed to arrive while the PLC was awaiting a Modbus response. Any packets received outside of this window were handled correctly. Additional testing revealed that the PLC did not correctly filter these packets based on port numbers, sequences, or acknowledgment numbers. Thus, subsequent connection attempts could also be reset by the same reset packet. However, these packets required the sequence and acknowledgment numbers to increment to avoid being processed as retransmissions.