# Analyzing Impact and Systemwide Effects of the SlowROS Attack in an Industrial Automation Scenario
## 6 Tests, Results, and Analysis
### Identification of the Connection Timeout Used by the ROS Master  
As anticipated, a first, crucial step needed to evaluate the feasibility and success probability of the SlowROS threat is to determine the value of the server-side timeout \(T_{i}\) adopted by the ROS Master. Namely, servers are typically programmed to close pending connections on their own initiative when a specific inactivity timeout \(T_{i}\) expires. Under normal conditions, such expiration typically occurs when communicating with badly connected nodes or nodes interrupting the communication without advising it. A correct identification of \(T_{i}\) enables the attacker to optimize the network resources it spends to keep its connections awake, hence maintaining the DoS state. To do this, the attacker shall send some more data on each connection every \(T_{c}\), namely, the Wait Timeout [6], where \(T_{c}\leq T_{i}-\epsilon\). On the one hand, \(\epsilon>0\) shall be a time buffer large enough to accommodate transmission timing inaccuracies due, for instance, to network latency or unpredictable delays, as well as \(T_{i}\) measurement. On the other hand, according to the general bandwidth-saving requirement typical of slow DoS attacks, \(\epsilon\) shall also be as small as possible. In other words, the attacker shall send some data just before \(T_{i}\) expires but not more often than needed. Indeed, keeping those illegitimate connections alive without \begin{table}
\begin{tabular}{r r r r r} \hline \hline \(f\) & \(s\) & \(c\) (from (1)) & \(c^{\prime}\) (Measured) & \(k\) (calc.) \\ \hline
1024 & 4096 & 1152 & 1148 & 4 \\
768 & 96 & 864 & 860 & 4 \\
512 & 96 & 608 & 604 & 4 \\
512 & 64 & 576 & 572 & 4 \\
256 & 64 & 320 & 316 & 4 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Maximum number of connections \(c^{\prime}\) for varying \(f\) and \(s\). letting the server close them denies legitimate users the ability to connect to the service and use it. The test strategy put into effect for \(T_{i}\) identification in this work assumes that \(T_{i}\) is fixed, as, to the best of our knowledge, is typically the case. It involves establishing a single connection with the ROS Master, possibly transmitting some data, and then waiting until the peer closes the connection. Sending different amounts of valid (and possibly invalid) data in different tests is crucial to detect whether \(T_{i}\) is fixed or changes depending on the specific, incoming data-dependent state the server's protocol stack is brought in. To avoid indefinite waits, the test program only waits for the connection to be closed for up to \(T_{max}\) before exiting. When this occurs (i.e., the connection is not closed by the server within \(T_{max}\)), the test is unable to determine \(T_{i}\) precisely, but it can still be safely stated that \(T_{max}\) is a lower bound of \(T_{i}\), that is, it must be \(T_{i}\geq T_{max}\). Since there may be different timeout settings depending on the protocol layer currently in charge of handling the partial payload received by the ROS Master, several different tests were performed, truncating the full message listed in Figure 3 at various points before suspending the transmission and waiting for further ROS Master's actions as further detailed in the following. Table 2 summarizes the results obtained with \(T_{max}=3600\) s. From left to right, the columns represent the following:  
* A numeric identifier used to refer to the test. * Brief description of the scenario considered. * Information about the application payload being sent by the test program, if any. When sending a partial payload, it simply refers to a range of lines of Figure 3. When sending an altered payload, details of the alteration are reported in the scenario description: for instance, in test 4, the partial payload being sent consists of lines 1-8 of Figure 3 plus an invalid XML-RPC token. * Information on the measured connection closure time \(T_{i}\).