## 3 Methodology
### Identification of Possible Communication Failures  
The implementation guide for Modbus TCP closely aligns with the traditional operating conditions of Modbus over serial communication media [29], in particular RS-232 and RS-485. In these conditions, the client is always the only device initiating a connection to the server. We found from our review of the protocol specification that this operating principle was similarly applied to Modbus TCP, in which clients are still the only devices allowed to make TCP connections. Thus, if a device crashes or has a communication failure, it is the responsibility of the client to re-establish its TCP communication, even if the server is able to detect that communication failure and may even have pending data. In the case of a single device disconnecting, we refer to this as a single-ended communication failure. The procedures for handling these scenarios are largely dependent on the underlying transport technology--in this case, TCP/IP. These failures are subsequently remedied by the client re-initiating a handshake. However, failure to respond expands the retry time based on TCP's exponential backoff. We contrast this to DNP3's implementation guide [4], which allows for connection establishment by both the master and outstation. In DNP3's implementation,there are also rules that connections can be established as soon as data is available. Overall, we found from our review that Modbus TCP's protocol specification is in large part driven by its serial communication roots, whereas DNP3 more aptly considers its TCP/IP-based operating environment.  
For the one-sided communication crashes in Modbus TCP, we can examine them as client-based, as shown in Figure 1 and server-based, as shown in Figure 2. The client crashing or losing communication in some form performs similarly to standard TCP connection establishment, as the client will send a SYN packet to the server to establish a new link. This can, however, cause issues for time-sensitive communications, as the server may not accept the client's request if ports are reused until the Keep-Alive timeout occurs or the client's new synchronization packet prompts the server to reset the connection.  
Furthermore, our review found that server crashes are more severe in their potential ramifications on OT operations, because they may, in effect, cause more time delays in re-establishment due to the exponential backoff implemented by Modbus TCP clients. In this case, a client that is unable to connect on its first attempt will increase the time between attempts until the maximum is reached, typically 64 s. This can become increasingly important, as this can easily be exploited by a malicious actor sending malicious packets that interrupt communication and thereby force the exponential backoff to approach its upper limit. As a result, the connection will remain interrupted for extended periods of time, with significant repercussions for safety-critical applications.  
We modeled both client-side and server-side fault conditions using controlled packet injection and reset mechanisms. Packet capture tools such as Wireshark and device-level logging were used to trace connection recovery behavior, latency, and TCP retransmission patterns. Malicious traffic scenarios, which included spoofed SYN and RST packets, were crafted to test the robustness of client reconnection logic and protocol handling. This  
Figure 1: Client crash connection establishment.  
expanded testing and evaluation methodology ensures that our findings are grounded in both theoretical review and empirical observations.