# Analyzing Impact and Systemwide Effects of the SlowROS Attack in an Industrial Automation Scenario
## 6 Tests, Results, and Analysis
### Connection Request Flooding Bypass  
While conducting the experiments discussed previously, care was taken not to trigger any connection request flooding protection mechanism built in the Linux TCP/IP protocol stack. These mechanisms typically activate when the connection request rate exceeds a certain threshold and are worth further investigation because, although they were likely not specifically designed with slow DoS threats in mind, they might still falsify experiment results and mitigate or disrupt the slow DoS attack itself. To this purpose, we performed a set of tests similar to the ones discussed in Section 6.1, in which our attacking node tried to establish \(c^{\prime}=1148\) connections to the ROS Master, with a varying connection request rate, that is, with a varying time interval \(T_{SYN}\) between consecutive SYNs. The client did not send any data after connection establishment and just closed the connection after \(T_{max}=3600\,\mathrm{s}\). By means of suitable probes located in the test bed, we measured the number of SYN retransmissions, as well as the difference between the number of successfully established connections on the test program (client) and ROS Master (server) side. The values of \(T_{SYN}\) used for the experiments were primarily chosen to highlight the knees of the two curves, to be discussed in the following. Multiple experiments were performed at around \(T_{SYN}\simeq 0.6\,\mathrm{ms}\) to assess and confirm result repeatability. The minimum value \(T_{SYN}\simeq 0.1\,\mathrm{ms}\) corresponds to the maximum connection request rate attainable by the test program on the machine used as attacker. Figure 6 depicts the results. As shown in the figure, under normal operating conditions (\(T_{SYN}\) above about \(2.5\,\mathrm{ms}\)) the number of SYN retransmissions is negligible (\(<\)1%) with respect to the total number of connections. Moreover, both the client and the server agree on how many connections have been established, that is, the difference between the number of connections registered by the protocol stack on the two sides is zero. This is in fact the condition under which all experiments discussed previously have been performed. In the approximate range \(1\,\mathrm{ms}\leq T_{SYN}<2.5\,\mathrm{ms}\), a significant increment of the number of SYN retransmissions can be observed, which gradually grows up to about 60% of the total number of connections. However, as shown, this does not lead to any discrepancy on the number of established connections registered on the client versus the server side. A likely reason for this behavior is server-side network buffer overload, which leads the server to drop part of the incoming SYNs. Then, client-side retransmissions lead the server to fully recover from these drops. Instead, a significant pattern from the slow DoS attack's point of view emerges when \(T_{SYN}\) falls below \(1\,\mathrm{ms}\). While the number of SYN retransmissions further increases up to about 75% of the total number of connections as \(T_{SYN}\) decreases, the number of established connections on the server side also becomes systematically lower, and lower than the number of connections on the client side. When this happens, the server-side kernel starts reporting that it detected, and is reacting to, a \"SYN flooding\" [53]. From the practical point of view, triggering this protection means that the server-side protocol stack tricks the client into thinking that the expected number of connections has been established--by completing the three-way TCP handshake as normal--but these connections are neither registered in the protocol stack nor passed up into user space. As a result, they do not contribute to the depletion of any server resources, thus mitigating any slow DoS attack that might be in progress. We were able to validate this last statement further by analyzing the client-server traffic.