Analyzing Impact and Systemwide Effects of the SlowROS Attack in an Industrial Automation Scenario

Abstract

The ongoing adoption of Robot Operating Systems (ROSs) not only for research-oriented projects but also for industrial applications demands a more thorough assessment of its security than in the past. This paper highlights that a key ROS component—the ROS Master—is indeed vulnerable to a novel kind of Slow Denial of Service (slow DoS) attack, the root reason of this vulnerability being an extremely high idle connection timeout. The effects of vulnerability exploitation have been evaluated in detail by means of a realistic test bed, showing how it leads to a systemwide and potentially dangerous disruption of ROS system operations. Moreover, it has been shown how some basic forms of built-in protection of the Linux kernel can be easily circumvented, and are therefore ineffective against this kind of threat.

1. Introduction

Nowadays, the Robot Operating System (ROS) enjoys widespread popularity in industrial operational technology environments due to its open-source nature, its ease of use, and the support of leading stakeholders [1]. Being used for different applications, such as edge robotics [2] or Industry 4.0 and Industrial Internet of Things (IIoT, in short) [3,4], today, ROS represents a leading protocol in the industrial sector [5]. In virtue of this, investigating its potential security weaknesses becomes essential to protect it from external threats that might disrupt manufacturing plants and lead to possible economic loss and equipment damage, not to mention the possible harm to human safety.

In the cybersecurity panorama, denial of service (DoS) threats are perpetrated to make a network service unreachable by its intended users. Considering such threats, conventional flooding-based approaches require a huge amount of attack resources, whereas other menaces, such as slow DoS, use limited attack bandwidth. slow DoS threats are therefore particularly relevant from this point of view because they can exhaust some kind of resource of the system they target while effectively deceiving detection mechanisms. In fact, proper protection against last-generation distributed DoS threats, such as slow DoS threats [6], is still an open research challenge.

This work investigates the susceptibility of an ROS system deployed in an industrial context to a slow DoS threat and evaluates its adverse effects on the overall system behavior. To this purpose, we evaluate and validate SlowROS, an innovative slow DoS threat that targets the ROS Master, a mandatory component that is invariably present in all ROS systems. To the best of our knowledge, the literature on industrial security does not cover slow DoS threats targeting the ROS protocol. In addition, to date, there are no known ROS vulnerabilities related to the exploitation of slow DoS-oriented approaches.

The contributions of this paper are the following: (i) address the lack of extensive analysis of the impact of slow DoS-like attacks on industrial protocols; (ii) evaluate the efficacy of the SlowROS threat by executing proper tests on a real network scenario; (iii) attempt to identify the optimal attack setup in terms of attack timeout: by doing this, in Section 6.2 we will find that the ROS Master does not implement any connection-closure timeout; and (iv) discuss possible protection approaches able to counter SlowROS.

In detail, after providing an overview of the state of the art and related work in Section 2, the paper continues with some basic information about ROS in Section 3. The slow DoS attack to ROS is discussed in Section 4, while the test bed used to demonstrate it is described in Section 5. Section 6 presents and comments on the experimental results while Section 7 outlines possible protection approaches to counter slow DoS attacks. Finally, Section 8 concludes the paper.

2. Related Work

For the sake of clarity, the discussion of the related work has been split into two parts. The first, in Section 2.1, concerns slow DoS attacks in general, regardless of the specific protocol or system they are directed against. The second part, in Section 2.2, summarizes the ROS security analysis work carried out since its inception.

2.1. Slow DoS

Slow DoS attacks are introduced in [6], defining them as “denial of service attacks which make use of low attack bandwidth to accomplish their purpose”. Particularly, the aim of [6] is to properly categorize slow DoS attacks, considering available threats, born both in the wild and as a result of research activities. The work identifies a set of server timeouts the attacker can potentially exploit to deploy a successful slow DoS attack. Among these timeouts, the ${\Delta }_{req}$ timeout, exploited by threats like Slowloris [7] or SlowComm [8], is the same timeout targeted by the threat subject of this work.

Other work has instead been focused on targeting specific protocols. While the most popular attack in this context, Slowloris [9], is able to target HTTP/HTTPS only, other threats are aimed at disrupting different services. In this context, an evolution of Slowloris is proposed in [10], introducing a new threat targeting HTTP/2 by sending specific HTTP requests to the server. Differently, ref. [11] proposes SlowTT, a slow DoS attack targeting the MQTT protocol. By following a similar approach, in this paper, we aim at targeting the ROS protocol through a dedicated attack. Although a preliminary version of the work appears in [12], the current work extends the concept previously introduced by considering attack optimization strategies and by identifying, evaluating, and overcoming the limits of the previously introduced threat.

Today, the protection from distributed slow DoS attacks represents an open research challenge. Even though identifying threats executed from a single malicious node is trivial [13], detecting distributed attacks is particularly challenging, as the network traffic they generate appears to be legitimate upon analysis [14]. In addition, as the payload exchanged during an ongoing attack complies with the exploited protocol, distinguishing between a malicious slow DoS scenario and a “legitimate” flash crowd is arduous [15]. Indeed, both situations generate a surge in traffic, making it difficult to differentiate between malicious intent and legitimate high-demand behavior [16].

Although an efficient detection of slow DoS attacks is not straightforward, multiple research works propose solutions in this context. Particularly, refs. [7,17,18] propose a literature analysis on the topic, while [16] introduces a detection system able to distinguish flash crowds from denial of service attacks, by exploiting network flows correlation. Similarly, analogies between network flows are investigated in [19] for slow DoS detection purposes. Instead, ref. [20] introduces a detection system based on user behavior forecasting. As authors analyze traffic patterns and related delays, a malicious user may tune the attack to mimic user timings and exploit randomization techniques to bypass detection. Ref. [21] makes use of artificial intelligence algorithms to detect slow DoS attacks, also considering encrypted traffic. Other similar approaches consider deep learning [22,23], fuzzy logic [24], or neural networks [25]. Most of the mentioned works focus on the ability to successfully identify an attack, without considering detection times. To this aim, ref. [13] proposes a detection system able to identify running slow DoS attacks shortly after it begins. Given the novelty of the SlowROS threat considered in this paper, although approaches similar to the ones mentioned could in principle be deployed to detect the attack, to the best of our knowledge, specific solutions able to efficiently identify a running SlowROS threat are still missing in the literature.

2.2. ROS Security

The security of ROS 1 has been the subject of a fair amount of scrutiny by researchers and practitioners alike, especially since it gained traction for industrial applications. Initially, researchers [26,27,28] focused on the lack of enforceable authentication and encryption between ROS nodes, which makes them susceptible to replay attacks and service hijacking. However, they did not consider denial of service (DoS) attacks specifically and did not provide any details about their execution.

Later work [29,30] discussed ROS penetration testing and demonstrated more elaborate attacks that crash or disable some ROS nodes, thus making the services they provide unavailable to other nodes and, eventually, making the ROS system as a whole inoperable. Although the final result of those attacks is similar to the ones presented in this paper, in their case, the attack strategy is radically different. In fact, they leverage specific software vulnerabilities (for instance, CVE exploits), rather than a slow DoS attack strategy. Even a recent comprehensive review of ROS security [31] still does not mention slow DoS attacks at all.

Moreover, the official “Python library reference” [32] warns that the xmlrpc.server module—used by the ROS communication layers—is not robust against maliciously crafted data. However, it does not mention the possibility of perpetrating attacks by means of legitimate data as the slow DoS attack proposed in this work does.

Finally, a query performed on the Common Vulnerabilities and Exposures (CVEs) list at the time of this writing with “ROS” as the search term [33] returned 114 records. Of them, 82 were disputed, and hence, were not further considered. Of the remaining 32, 19 pertained to other products with a similar name (for instance, the Rugged Operating System by Siemens) and 2 were about ROS 2, leaving 11 records related to ROS 1. A further refinement of the query including “noetic” as the search term eventually returned two records, CVE-2020-16124 and CVE-2021-37146.

CVE-2020-16124 discusses an integer overflow or wraparound vulnerability in the XML-RPC library, while CVE-2021-37146 reports an infinite loop in the XML-RPC server that may be triggered by a malicious RPC call. Neither of those vulnerabilities nor their underlying operating principle have been exploited for the attack discussed in this paper, thus confirming that the attack is, in fact, novel.

The mitigation techniques discussed so far in the literature belong to three broad categories. The first category aims at preventing attacks, for instance, by means of additional security-oriented components, like Rosbridge and SROS. Rosbridge is a WebSocket–ROS bridge that grants web applications controlled access to ROS nodes, and can indeed prevent attackers from reaching the ROS system directly from the Internet. However, it may be ineffective against insider threats, which act from the private side of the industrial network. SROS adds TLS support to the existing ROS protocols but is currently still experimental and has no longer been maintained since 2022 [34]. The recommendation of restricting access to the ROS network by isolating it from the Internet, advocated by the official ROS documentation [35], belongs to the same category. Nonetheless, this policy may be hard to enforce, considering that a relatively recent study [36] found a plethora of ROS systems that were indeed publicly reachable.

The second category of mitigation techniques aims at detecting attacks instead, usually by means of machine learning algorithms [37,38,39]. To the best of the authors’ knowledge, none of the existing work considers slow DoS attacks, focusing instead on data injection attacks [37] or on traditional DoS attacks [38] involving large amounts of illegitimate data. The use of deep reinforcement learning to identify vulnerabilities in ROS-based robot navigation is explored in [39] but without explicitly considering DoS attacks.

The last mitigation technique simply consists of switching to ROS 2, also because the most recent version of ROS (Noetic Ninjemys, often abbreviated as noetic) is meant to be the last version of ROS before the transition to ROS 2 and will reach its End-Of-Life (EOL) date in mid-2025. Nevertheless, assessing and analyzing ROS security as performed in this work still makes sense despite this impending transition due to its rather significant installed base in real-world applications. Even more importantly, the slow pace at which ROS 2 is replacing it [40] suggests that the final phase-out of ROS and its replacement by ROS 2 will undoubtedly require a significant amount of time beyond 2025, also considering the unavoidable inertia of industrial equipment procurement and production lines commissioning. Finally, since ROS 2 relies on the Data Distribution Service (DDS) standard [41] for communication, it is indeed affected by its own vulnerabilities [42], which have recently led to an ICS advisory [43].

3. ROS Primer

This section contains a brief introduction to ROS, encompassing its evolution and fundamental concepts. It then describes in more detail the protocol used by the ROS Master, the ROS agent whose vulnerability has been exploited for the work being discussed in this paper.

3.1. History

In a nutshell, ROS is a set of open-source libraries and tools that provide commonly used robot control functionalities and algorithms. Although, strictly speaking, ROS is not an operating system per se because it relies on “true” operating systems such as Linux as a foundation, it still provides hardware abstraction and platform-independent robotic device control and access, along with a comprehensive message passing subsystem based on the publisher–subscriber communication paradigm and a modular, high-level software packaging framework.

In embryonic form, ROS development began in late 2006 in the context of the Stanford Personal Robotics Program [44]. One of the main initial goals—maintained through the whole project history—was to facilitate code reuse so that researchers would focus more on designing and developing innovative robot control software, rather than re-implementing the underlying middleware infrastructure anew whenever they moved to a new project or new hardware.

Even though ROS was initially geared towards robotic research and hobbyists’ projects, it gained more and more industrial interest with time, fueled by initiatives like the ROS Industrial Consortium [1], whose charter is to extend ROS to work effectively with industrial relevant hardware and applications. Current consortium members include leading robot OEM manufacturers, end-users such as large international manufacturing companies, and research institutes worldwide.

The most recent released version of ROS, Noetic Ninjemys (often abbreviated noetic), was released in mid-2020 and is meant to be the last version of ROS before the transition to ROS 2, slated for mid-2025 when noetic will reach its End-Of-Life (EOL) date. Despite this impending transition, noetic is the ROS release to be considered in this work.

3.2. Basic Concepts

From the software organization and communication standpoint, an ROS system is composed of a set of cooperating processes structured in a computation graph. Within the graph, each node is a process responsible for a portion of data processing. Links in the graph represent communication paths among nodes. Since ROS encourages fine-grained modularity, a typical ROS system consists of multiple nodes. Nodes are written with the help of a client library that depends on the programming language being used. For instance, nodes written in Python (both version 2 and 3 are supported) use the rospy library.

The basic unit of communication among nodes is the message, a simple data structure comprising typed fields. ROS supports the most common primitive types, like Booleans, integers, and floating-point values. They can be placed into arrays and structures, which can then be nested arbitrarily.

The main ROS message transport system is based on the publisher–subscriber paradigm. In this approach, nodes send out data of possible interest to others by publishing messages to a certain topic. Interested nodes subscribe to the topic to receive them. Each topic supports a single message type and has a unique name in the system, which both publishers and subscribers use to refer to it. There may be multiple publishers and subscribers to the same topic, and an individual node may publish and subscribe to multiple topics, thus establishing a many-to-many communication relationship.

To better accommodate one-to-one, synchronous, request–reply interactions between nodes, ROS also supports the concept of service. A service has a unique name, like a topic, and has two message structures associated to it, one for requests and one for replies. A server node that offers a service registers it under a unique name. Client nodes locate a server by looking up the name of the service it offers, send a request message to it, and wait for a reply. From the programmer’s perspective, this kind of interaction is usually seen as a Remote Procedure Call (RPC).

In both cases, the ability to resolve a name and determine which nodes are related to it as publishers–subscribers of a topic or as service provider is crucial, also considering that ROS nodes are not a priori aware of each other’s existence and position in the computation graph. This role is fulfilled by the ROS master, whose identity is expressed by a Uniform Resource Identifier (URI) and is assumed to be well known to all other nodes.

The master acts as a centralized store of registration information about topics and services for other nodes to use. For instance, publishers of a certain topic contact the master to inform it of their presence. The master keeps the list of publishers of a certain topic up to date so that subscribers can acquire this information as needed. The master may also call nodes back when the registration information changes, thus enabling nodes to adapt to a dynamically changing communication graph topology.

It is work noting that, although the ROS master plays the role of a broker, unlike other kinds of brokers, it is not directly involved in publisher–subscriber data transfer. In order to do that, nodes will indeed make use of the information they acquired from the master but will then use it to establish a direct peer-to-peer data connection.

The last ROS component to be discussed here is the parameter server. It acts as a centralized store of $(\mathrm{key},\mathrm{data})$ pairs that all ROS nodes may obtain and set at will. In the pair, $\mathrm{key}$ uniquely identifies a certain parameter and $\mathrm{data}$ is its value. Parameters are often used to store settings for an ROS application as a whole and make them globally accessible. Although the parameter server was originally meant to be used sparingly and mostly during initialization, to retrieve parameters that are not going to change while the system is operational, ROS noetic actually calls it much more frequently as better explained in Section 6.4.

Most importantly for the threat to be discussed in Section 4, the parameter server is currently implemented as part of the ROS master process and hence shares network communication resources with it. As a consequence, any attack that hinders network access by the master also affects the parameter server in the same fashion.

3.3. ROS Master Protocol

ROS nodes interact with the master via the XML-RPC protocol [45]. XML-RPC is a connection-oriented protocol that uses HTTP [46] POST requests to transport XML-encoded [47] RPC requests and receive responses. ROS layers the master APIs on top of XML-RPC by defining suitable RPC method names, along with their parameters and return values. In turn, HTTP runs over a TCP [48] connection initiated by a ROS client node and accepted by the master.

As an example relevant to the discussion in Section 4, Figure 1 shows the request and response messages exchanged between an ROS node on host bravo and the master on alfa to register the node as a publisher of a certain topic. For simplicity, the figure omits all details about TCP connection establishment and segmentation.

The ROS node sends an HTTP POST request to the master at alfa:11311, which contains an XML-RPC methodCall to the ROS method registerPublisher. Its four arguments are the unique identifiers of the publisher (/talker_39066_1706698579110), the name of the topic it publishes (/chatter), the data type of the topic messages (std_msgs/String, corresponding to the basic string type), and the URI of the publisher (http://bravo:40717/), which may be used to contact it.

If there are no HTTP-layer errors, the master always returns the HTTP status 200 OK in its response. The XML-RPC methodResponse, as required by the ROS master API upon successful RPC completion, contains a single <value> enclosed in a <param> and then in a <params>. If the XML-RPC layer detects an error, the methodResponse would instead contain a <fault> that, in turn, would contain additional information about the error itself.

The <value> in the response represents the return value(s) of the method. For the registerPublisher method, the return values are an integer ROS-layer status code (1 indicates that the request has been fulfilled successfully), a human-readable message that summarizes the operation just performed, and an <array> that contains the URIs of the current subscribers to the topic. In this case, the array is empty because there were no subscribers when the publisher registered itself.

4. Attack Context and Description

4.1. Underlying Protocol Mechanisms

In the TCP protocol, a three-way handshake procedure determines how connections between the client and the server are established [49]. Although the way network packets are exchanged during such a procedure may be familiar, the local activities executed on the hosts may need further discussion.

In particular, referring to Figure 2, before sending the first SYN packet to the server [49], the client allocates a local socket for the connection. When the server receives the SYN packet, it does not immediately allocate a dedicated socket yet. At this point, it merely allocates an in-kernel state vector to keep track of the connection state and puts it in the so-called TCP SYN queue while the handshake proceeds towards full connection establishment.

The socket is in fact allocated on the server only at the end of the three-way handshake, when the ACK packet has been received and the server has eventually been informed about the new connection by the successful completion of an accept() system call. After accepting the new connection, the server also usually allocates an application slot for it, to store all the information the server needs for its management.

4.2. Kernel Behavior and System Limits in TCP Connection Handling

Important constraints on the maximum number of concurrent connections a server can support come from the internal logic of the server itself, besides several kernel parameters related to protocol stack resource management. For instance, connections that require a large quantity of server-side memory to be handled may exhaust the total amount of memory allotted to the server well before hitting against any other system limit.

Moreover, flaws in the server implementation, like the failure to release sockets upon normal or abnormal connection closure, may lead to premature socket exhaustion. Unfortunately, memory requirements and implementation quality are usually very specific to a certain kind/version of a server, and can hardly be generalized. In addition, while testing the ROS Master implementation, we found no indication of any memory or socket leak. Its memory allocation level stayed well below the upper limit as well.

For all these reasons, in this paper, we focus only on system-level limits that depend on the Linux kernel configuration, and hence, impose an upper bound to the number of concurrent TCP connections that a certain server can successfully support, regardless of its internal structure. While such a choice may represent a limit for slow DoS categories like delayed or long responses DoS, it has no impact on our long request attack [6].

Furthermore, we also assume there is a one-to-one correspondence between established TCP connections and sockets in the ROS Master. This is not strictly true for the partially established TCP connections outlined in Section 4.1, that is, connections that went through the first two stages of the three-way TCP handshake and are waiting for the final ACK from the initiator.

For these connections, the in-kernel protocol stack has already allocated a state vector but, since processes are not made aware of incoming connections until they are fully established, no sockets in the user space have been assigned to them yet. However, the net.ipv4.tcp_max_syn_backlog parameter (128 by default on the nodes described in Section 5) determines the maximum number of partially established TCP connections that the kernel allows for the whole system. This limit prevents both crashes and protocol stack memory exhaustion due to this reason.

Two other kernel and process parameters apply to the different stages an incoming TCP connection may be in. In particular, we have the following:

• When they have been fully established from the TCP/IP protocol stack point of view, incoming connections enter the backlog of the listening socket, waiting to be accepted by the server by means of an accept() system call. The actual limit to the backlog length is primarily set by the server through the second parameter of listen(), but a kernel parameter sets an upper bound to what the server may ask for. The parameter is net.core.somaxconn, and its default value is 4096 on the nodes used in our test bed.
• As also discussed in Section 4.1, when the server eventually tries to accept an incoming connection, a new socket must be allocated for it within the accept(). Linux, like many other operating systems, represents a socket in user space with a file descriptor. Therefore, the maximum number of connections a server can accept is also limited by the maximum number of open file descriptors the server is allowed to have.

Unlike the previous two, the maximum number of file descriptors a process may open is not set by a kernel parameter but is primarily a per-process limit that can be set by means of the setrlimit (set resource limit) system call [50]. Resource limits are uniquely identified by a symbolic constant, RLIMIT_NOFILE in this particular case, which becomes the first argument of setrlimit. The second argument represents the desired value of the limit being set, encoded in a struct rlimit. The shell command ulimit -n provides a more user-friendly interface to the same underlying system call. The default value of the file descriptor limit is 1024 on the nodes used in this paper.

Therefore, if we call f the value of RLIMIT_NOFILE and b the listening socket backlog length, in a congestion scenario like a slow DoS one, assuming that a server accepts incoming connections as soon as they come in and has no other internal constraints, the following occurs:

• The server accepts the first $f-k$ incoming connections, where k represents the number of file descriptors already opened by the server for other purposes.
• Then, b more connections are established at the TCP level but stay in the listening socket backlog.
• Eventually, further connections requests are postponed by the TCP/IP protocol stack, which stops acknowledging incoming SYNs.

4.3. Slow DoS Attack Description and Analysys

If we consider the ROS protocol as mentioned above, it is a TCP-based application layer protocol used to manage communication inside of an industrial IoT network, based on a publish–subscribe approach. In more detail, the ROS protocol makes use of HTTP REST-based APIs, including XML-formatted data.

Considering such aspects, the slow DoS Attack examined in this paper is going to act in two stages: (i) At first, a specific amount of simultaneous connections with the server is established in order to seize all available connection slots that the (application) server is able to support. (ii) Then, each connection is kept alive as long as possible in order to prevent its closure by the server. Such typical behavior of slow DoS Attacks [6] leads to a denial of service on the server and attempts to keep it as long as possible.

In detail, the number of connections that the attacker has to simultaneously establish and keep alive depends on the application server configuration. Although for specific daemon software, such as the Apache web service, such a value can be set up, it may not have an impact on the attack success, while, by increasing such a value, the attacker would require more resources to accomplish its goal.

Instead, in order to keep the connection as long as possible, different approaches are possible: in our case, by implementing a so-called Long Request DoS, we split the transmission of the request payload in multiple cycles, sending a predefined payload to the server, split into multiple portions on each round. In particular, the considered payload transmitted by the attacker may vary and may exploit different functionalities/methods provided by the ROS server. In our case, we adopt a payload similar to the one reported in Figure 3.

For the sake of readability, we indent content in the figure, whereas when sending data over the network, the content is not indented. Token and field separators—the \r\n sequence between HTTP headers and any amount of white space between XML syntactic elements—are not shown, either. Moreover, although XML tags and ROS-specific fields are split into multiple lines in Figure 1, we do not consider such formatting in Figure 3 to better represent the actual payload sent by the attacker. We also replace specific information (such as the value of the HTTP Host parameter) with generic tags to provide a more general payload applicable independently on the target.

It should be noted that any payload compliant to the protocol is valid to perpetrate a successful attack. In addition, payloads not compliant to the ROS protocol may lead to a successful DoS as well [8].

As the payload sent by the attacker typically is a legitimate payload compliant to the ROS protocol, it is not trivial to detect an ongoing attack, by analyzing the data exchanged by the client and the server. In addition, although in this paper we consider, for simplicity, a single attacking host, whose detection of the malevolent aims at the network layer would be trivial, it is quite simple for a real attacker to distribute the threat to multiple malicious nodes, coordinated to perpetrate a common attack against a simple server. In such a case, the detection of an ongoing attack would be more difficult.

Figure 4 summarizes the prospective attack sequence as a whole. The attacker is shown on the left and regular ROS nodes on the right. The ROS Master and parameter server are represented as two separate entities in the middle of the figure, although, as discussed in Section 3.2, they are implemented within the same process. The sequence consists of the following steps, whose number is also recalled in the figure for clarity:

• In the system initialization and setup phase, regular ROS nodes interact with the ROS Master to register themselves as publishers and/or subscribers. The attacker does not interfere with this phase.
• ROS nodes typically do not interact with the ROS master anymore when the system enters the operational phase. Instead, they exchange process data through dedicated point-to-point TCP connections and may query the ROS parameter server. As also mentioned in Section 3.2, in the ROS version considered in this paper, parameter server access is not as sporadic as it was supposed to be when ROS was designed. Even more importantly, its use is not at all confined to the setup phase.
• At this point, the attacker opens a number of TCP connections to the ROS Master by conducting the three-way handshake shown in Figure 2 and, optionally, sending partial requests to it. As described in Section 4.1, the ROS Master has to allocate some resources for each open connection.
• As the number of malicious connections keeps increasing, the ROS Master exhausts its resources. Most notably, it runs out of file descriptors as outlined in Section 4.2. Resource exhaustion affects not only the ROS Master but also the parameter server since they share the same pool of process-level file descriptors.
• The final effect of the attack is that operational ROS nodes become unable to reach the parameter server. Moreover, any ROS node that attempts to recover and repeat the setup phase to become operational again can no longer communicate with the ROS Master to announce itself.

Figure 4. Sequence diagram of the attack scenario.

Figure 4. Sequence diagram of the attack scenario.

In order to evaluate the possibility of carrying out a successful attack along the lines just presented, also as a function of the payload sent and the attack approach adopted, in terms of timings and data sent at each round of attack, in the next section, we are going to define the testbed considered in our experimentation.

5. Test Bed

In order to validate the efficacy of the threat introduced in Section 4, we built a setup representing a full ROS-powered network. Overall, the test bed being presented and used to conduct and analyze the slow DoS attack is meant to represent a simplified, but still realistic, implementation of a typical industrial production line.

As shown in Figure 5, it consists of five nodes interconnected by means of a 100BaseTX shop-floor network, depicted as a green line. This network emulates a local plant network; its IP addresses are assigned statically and lie in the same /24 subnet. More specifically, we have the following:

• Node alice, depicted on the right of the figure, is an Interbotix PincherX-100 robot arm (4 DOF plus gripper) controlled by an 8^th Gen Intel NUC equipped with the Interbotix-provided distribution of Ubuntu 20.04 and ROS noetic. It corresponds to one of the regular ROS nodes depicted on the right side of Figure 4. The NUC runs the ROS joint control software and, possibly, additional ROS applications that implement any local robot arm control algorithms needed by the application at hand.
• Nodes alpha, bravo, and charlie are also regular ROS nodes, based on Raspberry PI 3 model B boards equipped with an off-the-shelf distribution of Ubuntu 20.04 and ROS noetic. They run ROS code that performs various higher-level system coordination and supervision functions. According to the guidelines presented in [51], alpha also hosts the centralized ROS Master and parameter server shown in the middle of Figure 4, which all ROS nodes query as described in Section 3. Node charlie is the malicious node that conducts the slow DoS attack. In our scenario, we assume this node has been compromised in some way to act malevolently and implement the attack sequence summarized in Figure 4.
• The gateway shown at the far left of Figure 5 grants external access to the shop-floor network, for instance, through a wired or WiFi connection to a plant-wide SCADA or MES network. This node usually incorporates a firewall that protects the shop-floor network from unauthorized access, while still allowing control and supervision traffic to pass through. For instance, a SCADA system might obtain access to robot arm operating information and statistics by means of an OPC-UA/ROS software gateway installed at the shop-floor boundary, or use ROS directly for the same purpose. In the example attack described in this paper, the gateway represents the entry point leveraged by the remote attacker to inject malicious software into node charlie.

In the specific test bed version used in this paper, the ROS Master is implemented by means of the off-the-shelf rosmaster process found in the ROS noetic distribution. The joint control software running on alice is the robot_state_publisher application provided by Interbotix with the robot arm, whose communication functions to the ROS Master are also based on unmodified, lower-level software libraries from ROS noetic.

The high-level ROS application (also running on alice) is simulated by a Python application, derived from one of the ROS examples, which drives the gripper through a closed Cartesian trajectory in space indefinitely, until stopped by hand. Finally, system coordination and supervision functions are simulated by a telemetry application based on the standard rostopic tool, which runs on bravo and periodically reports the joints’ position, velocity, and torque.

This rather conservative approach is meant to realize a “minimal working example” of the vulnerable industrial system and guarantees that neither application-specific nor vendor-specific code is involved in the communication between the ROS Master and the rest of the ROS software. This aspect will turn out to be crucial to ensure that the attack discussed in Section 4 does not depend on the specific test bed in use or any custom software that runs on it, and can hence be exploited on a variety of ROS-based systems.

6. Tests, Results, and Analysis

In this section, we report the results of the tests we executed in our test bed, with the aim to evaluate the performance of the considered SlowROS attack and define an optimal attack strategy.

6.1. Identifying the Maximum Number of TCP Connections the Server Can Simultaneously Manage

Understanding what is the maximum number of concurrent TCP connections a Linux process can successfully support is crucial to properly configure the attack described in Section 4. First of all, since the value of b defined in Section 4.2 partly depends on the server itself (net.core.somaxconn is merely its upper bound), we determined it by inspecting the source code of the ROS master used in the experiments, available at [52]. Namely, b is set at xmlrpc.py::132 of the ros_comm ROS component as follows:

self.request_queue_size = min(socket.SOMAXCONN, 128)

Neglecting k, which is unknown for the time being, the maximum number of established connections c towards the ROS Master can be approximated by

$$c=f+min(s,128),$$

(1)

where s is the value of net.core.somaxconn. We checked (1) with a set of experiments in which we measured the actual maximum number of established connections $c^{\prime }$ to the ROS Master for varying f and s, obtaining the results shown in

Table 1. Maximum number of connections $c^{\prime }$ for varying f and s.

f	s	c (from (1))	${\mathit{c}}^{\prime }$ (Measured)	k (calc.)
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

.

As shown in the table, the value of k derived from c and $c^{\prime }$ is consistently $k=4$. This confirms both the validity of (1) and the experiments accuracy, given that we expect the server to use three file descriptors for its standard input, output, and error streams plus one more for the listening socket. Additional tests were executed to analyze the behavior of the server as a function of its load. In detail, by varying the number of legitimate clients connected during the attack (denoted as $c_l$), we measured that $c^{\prime }$ assumes the value $c-k-c_l$.

Once the number of concurrent connections the server is able to manage was determined, we attempted to identify another relevant attack parameter, namely, the time interval to be adopted by the attacker to slow data transmission down as much as possible, as described in the next section. For all subsequent tests, the ROS Master was configured according to the first row of Table 1.

6.2. 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_{\mathit{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_{\mathit{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_{\mathit{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\le T_i-ϵ$. On the one hand, $ϵ>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_{\mathit{i}}$ measurement. On the other hand, according to the general bandwidth-saving requirement typical of slow DoS attacks, $ϵ$ shall also be as small as possible. In other words, the attacker shall send some data just before $T_{\mathit{i}}$ expires but not more often than needed. Indeed, keeping those illegitimate connections alive without 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_{\mathit{i}}$ identification in this work assumes that $T_{\mathit{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_{\mathit{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_{\mathit{max}}$ before exiting. When this occurs (i.e., the connection is not closed by the server within $T_{\mathit{max}}$), the test is unable to determine $T_{\mathit{i}}$ precisely, but it can still be safely stated that $T_{\mathit{max}}$ is a lower bound of $T_{\mathit{i}}$, that is, it must be $T_{\mathit{i}}\ge T_{\mathit{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. Tests for ROS Master Timeout Identification, $T_{\mathit{max}}=3600\mathrm{s}$.

				Response	Response upon Close
#	Scenario	Payload	${\mathit{T}}_{\mathit{i}}$	Time (ms)	HTTP	XML
1	Basic	none	$\ge T_{\mathit{max}}$	—	none	N/A
2	POST only	1–1	$\ge T_{\mathit{max}}$	1.44	HTTP/1.1 500	N/A
3	Full HTTP header	1–7	$\ge T_{\mathit{max}}$	1.45	HTTP/1.1 200	<fault>
4	Invalid XML-RPC request	1–8	$\ge T_{\mathit{max}}$	1.16	HTTP/1.1 200	<fault>
5	Partial XML-RPC request	1–11	$\ge T_{\mathit{max}}$	1.84	HTTP/1.1 200	<fault>
6	Ending newline missing	1–25	$\ge T_{\mathit{max}}$	3.42	HTTP/1.1 200	<methodResponse>
7	Full, valid request	1–35	$\ge T_{\mathit{max}}$	—	HTTP/1.1 200 (immediate)	none

summarizes the results obtained with $T_{\mathit{max}}=3600\mathrm{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_{\mathit{i}}$.
• The time required by the server to return either an error indication or a method response, from the reception of the connection closure packet from the client.
• The final application server response when the connection is closed, for both HTTP and XML protocol layers, which does not affect $T_{\mathit{i}}$ assessment but will be further discussed in Section 6.3.

The rationale behind the partial payloads used for the tests is that, in test 1, nothing is sent, to make the server process wait for HTTP headers. Differently, in test 2, the server receives a valid POST request and reassembles the remaining HTTP headers. Instead, in test 3, the server waits for an XML-RPC request to start, while in test 4, the server reassembles an XML-RPC request that contains an invalid token.

Test 5 is similar to test 4, but the partial XML-RPC request sent to the server is valid. In test 6, a fully valid XML-RPC request is sent to the server, but the request is one byte shorter than what the HTTP Content-Length says. All in all, these tests stops the HTTP/XML-RPC payload reassembly and interpretation process performed by the server at different stages to determine the $T_{\mathit{i}}$ of each stage.

Finally, in test 7, the test program sends a full XML-RPC request whose length is consistent with the HTTP Content-Length, followed by silence. This test’s goal is to clarify whether the server behaves differently for what concerns $T_{\mathit{i}}$ while waiting for the very first XML-RPC request (as it does in test 1) rather than the next.

As reported in Table 2, we find that in no tests did the ROS master close the connection on its own initiative, leading to the important conclusion that $T_{\mathit{i}}\ge 3600\mathrm{s}$. Considering that a timeout of $3600\mathrm{s}$ is typically considered quite high for this kind of protocol; this observation paved the way to suspecting that $T_{\mathit{i}}$ might be infinite, at least in some cases.

To further validate this hypothesis, test 1 was repeated with a longer timeout, that is, $T_{\mathit{max}}={10}^9\mathrm{s}$. Also in this case, the server did not close the connection until the test program was manually interrupted after about 11.85 days. Despite the manual interruption, the connection was closed with an FIN rather than a RST because the test program still terminated it with a close() system call, corresponding to an orderly connection shutdown from the transport point of view.

This result confirms that, for all intents and purposes, the ROS Master connection inactivity timeout can be considered infinite, at least for completely inactive connections, that is, connections on which no data have been sent after establishment. It is worth mentioning that a direct communication between the attacker and the victim takes place as shown in Figure 5. A more accurate characterization of $T_{\mathit{i}}$ was not performed because it would serve no practical purpose at this stage.

Variant of tests 1–7 were then executed to check whether or not the ROS Master implements any dynamic connection closure strategy, for instance, whether it starts closing idle connections when it detects a possible overload condition on the number of open connections. As determined in Section 6.1, in its default configuration (corresponding to the first row of Table 1) the ROS Master supports up to $c^{\prime }=1148$ connections. Considering there is always one active connection to the ROS Master whenever a fully functional ROS system is brought up (due to the presence of a mandatory subscriber to the ROS logging topic /rosout), the test programs now opens $c^{\prime }-1=1147$ connections to the ROS Master instead of one, in order to bring the total number of established connections to the ROS Master exactly to $c^{\prime }$.

Event log and traffic analysis confirmed that the ROS Master did not attempt to close any connections, thus confirming the apparent lack of dynamic connection closure and all results reported in Table 1. Last, but not the least, manual inspection of the ROS code base under analysis confirmed the absence of any time- or load-dependent connection timeout mechanism. If this were not the case or, more generally, when confronted with a closed-source ROS Master implementation, a dynamic adjustment of $T_{\mathit{c}}$ based on real-time connection closure monitoring would become necessary.

Summarizing, we found that the ROS protocol is, at least in our scenario, vulnerable to different attack approaches, occurring at different stages of the communication with the ROS Master. In addition, its extremely high $T_{\mathit{i}}$ value gives a vantage point to the adversary, enabling it to perpetrate a potentially successful attack even with a minimum amount of network resources. In detail, we found that once the attack is initiated, the DoS state is potentially maintained indefinitely, even without any action by the attacker, which may even be disconnected by the network for a long time, leaving the server under the DoS state. Considering the executed tests, in the next section, we further analyze the server response to the different scenarios introduced in Table 2.

6.3. Response of the ROS Master Service to Different Malicious Payloads

As outlined in the previous section, some of the test programs aimed at determining $T_{\mathit{i}}$ also send to the ROS Master a (possibly partial) payload before eventually closing the connection. The server’s responses, summarized in the rightmost column of Table 2, provide valuable information on how the software modules responsible for implementing the protocol layers on the server side exchange data.

Firstly, when the test program sends either no data at all (test 1) or a complete, valid request from both the HTTP and XML-RPC viewpoints (test 7), the server does not send any response when the client closes the connection. Instead, as expected, in the same test, the server sends back a normal reply containing an indication of success at both the HTTP and XML-RPC layers upon receiving the request. This suggests that none of the software layers involved in the communication perform any action besides housekeeping upon connection closure.

In test 2, the server replies with an HTTP error (namely, 500 Internal Server Error). This is consistent with the HTTP layer trying to parse an incomplete set of HTTP headers, in which some mandatory information is missing. In tests 3–5, the HTTP layer responds with a success indication (200 OK) because it obtains a valid set of HTTP headers, but the XML-RPC layer reports a fault because the request it obtains from the HTTP layer is incomplete or invalid. In all cases, the fault indication reflects the issue in the request. More specifically, we have the following:

• In test 3, the XML-RPC fault indication contains the error “no element found” from the XML parser because empty XML-RPC requests are forbidden.
• In test 4, the parser reports a syntax error that pinpoints the invalid token present in the request.
• In test 5, the parser is unable to find the end of the dangling <params> clause.

Interestingly, the reply the server sends in test 6 contains a success indication at both the HTTP and XML-RPC layers, although the actual requests for the length are shorter than what is declared in the HTTP Content-Length. Hence, the fact that the request is actually incomplete (a well-known fact at the HTTP layer) is not properly forwarded to the XML-RPC layer, which then proceeds to parse it as normal.

Another important, counterintuitive conclusion that can be drawn from tests 2–6 is that, regardless of everything else, the ROS master tries to process any partial payload it may have received from a client when the client closes the connection. The reason behind this behavior has not been further investigated because it falls outside the scope of the present work but may be conducive to other kinds of attack, such as delayed or long-response DoS [6].

6.4. Systemwide Effects of the Attack

For the reasons outlined at the end of Section 3.2, the consequences of the attack presented in this paper go far beyond a disruption of the publisher–subscriber registration and notification mechanism that the ROS Master implements. If this were the case, the impact of the attack would still be significant but also somewhat limited in scope because it would just prevent new publishers and subscribers from registering, without interfering with existing ROS nodes that already entered the operational phase after a successful registration. So, for example, the attack would prevent a remote monitoring ROS subscriber (typically instantiated on demand) from accessing and displaying system information but would not affect the core robot control nodes.

However, as also mentioned in Section 3.2, in ROS noetic both the ROS Master and the parameter server are part of the same process, an implementation choice that the ROS specification does not explicitly forbid. As a consequence, any DoS attack that depletes some process-wide resource, such as file descriptors, also prevents ROS nodes from accessing system parameters.

Finally, the JointStateListener of ROS noetic queries the parameter server on every control cycle to retrieve the tf_prefix parameter from the closest namespace by means of the method getTFPrefix() (file joint_state_listener.cpp, line 91). Being a standard component, the JointStateListener is going to be present in virtually all ROS noetic-based systems.

These observations are crucial to understand why an attack involving solely the ROS Master eventually leads to a full, systemwide lockup like the one discussed in [12], instead of having more localized and less severe effects.

This discussion also calls attention to the importance of chain effects in cyber attacks, which are rather common and make their ultimate effects hard to predict. In this particular case, the combination of the following make the attack perimeter way larger than it could have been anticipated by intuition: (a) A DoS attack against a very specific ROS component (the ROS Master); (b) A legitimate implementation choice fully within the ROS specification boundaries (putting the ROS Master and parameter server together in the same process); (c) A coding peculiarity within a crucial ROS node (leading to the retrieval of a parameter on every robot control cycle).

By considering instead how the attack effects on the targeted server might vary depending on the actual deployment of TCP flooding countermeasures, in the next section, we discuss how a malicious user could bypass potential connection request flooding mitigation approaches.

6.5. 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_{\mathit{SYN}}$ between consecutive SYNs. The client did not send any data after connection establishment and just closed the connection after $T_{\mathit{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_{\mathit{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_{\mathit{SYN}}\simeq 0.6\mathrm{m}\mathrm{s}$ to assess and confirm result repeatability. The minimum value $T_{\mathit{SYN}}\simeq 0.1\mathrm{m}\mathrm{s}$ 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_{\mathit{SYN}}$ above about $2.5\mathrm{m}\mathrm{s}$) 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{m}\mathrm{s}\le T_{\mathit{SYN}}<2.5\mathrm{m}\mathrm{s}$, 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_{\mathit{SYN}}$ falls below $1\mathrm{m}\mathrm{s}$. While the number of SYN retransmissions further increases up to about $75\%$ of the total number of connections as $T_{\mathit{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. We observed that, when the client eventually closes its connections by sending FINs, the server responds with a FIN/ACK for the connections that are considered established on both sides, whereas it responds with RST to the connections established only on the client side. According to the TCP specification, the transmission of RST instead of FIN confirms that the corresponding connection was never established on the server side.

The mitigation has indeed a significant impact because, at the maximum connection request rate reached in our experiments ($T_{\mathit{SYN}}=158\mu \mathrm{s}$), about $55\%$ of the connections “established” by the client are silently discarded and never reach the ROS Master. What makes the SYN flooding protection mechanism even more relevant in this context is that it is part of the standard TCP/IP protocol stack and does not depend on the installation and configuration of any dedicated kernel modules and utilities like, for instance, Iptables [54]. Therefore, it can be assumed to be ubiquitously present on virtually all Linux-based systems.

Unfortunately, from the victim’s point of view, the SYN flooding protection can, however, be easily circumvented exactly as we did for our experiments, that is, by ensuring that the attacker’s connection request rate stays sufficiently low. This approach is also in line with the typical stealthiness goal of slow DoS attacks that, among other requirements, stipulates a carefully controlled and limited peak bandwidth usage.

As a final remark, the actual $T_{\mathit{SYN}}$ thresholds for the two behaviors just described (about $2.5\mathrm{m}\mathrm{s}$ and $1\mathrm{m}\mathrm{s}$, respectively) may likely depend on the specific hardware capabilities and software configuration of the server operating system. This aspect has not been further investigated in the present work and will be the subject of future work concerning attack strategy optimization.

7. Countermeasures and Protection

If we consider the protection from the SlowROS attack discussed in this paper, although the approaches found in the literature and mentioned in Section 2 could be adapted to this aim, a dedicated detection and mitigation system able to protect from the considered threat is still missing. Nevertheless, in Section 6.5 we analyzed how protection systems embedded on many Linux-based operating systems can apply some kind of mitigation, identifying the attack as a SYN flood attack. Although the mitigation could be effective to protect from specific executions of SlowROS, we demonstrated that a malicious user could still fine-tune the attack and slow down the connection establishment procedure by means of specific delays (i.e., $T_{SYN}$), thus bypassing the restriction. As an additional benefit, such an approach would also lead to a reduction in the attack bandwidth. In other words, since the protection can easily be circumvented by the attacker, it should not be considered an efficient countermeasure.

Other protection approaches may filter network connections through dedicated firewall rules, embedded on the targeted host or on an intermediary firewall. To this aim, it is possible to use tools like Iptables or nfw [55] to block single node attacks, by limiting the number of concurrent connections a single node is allowed to establish with the server [56] and forcibly closing open connections, regardless of the server-side timeout settings described in Section 6.2. Such an approach is effective to counter slow DoS scenarios, even though it it may be ineffective against distributed attacks and artificially reduce server capacity. Indeed, in such a case, the attacking group of nodes may not be sufficient, in terms of the number of attacking bots, to lead a denial of service on the victim.

Another mitigation option may involve the implementation of a server-side timeout, used to close connections that do not respect minimum bandwidth requirements. Such an approach is implemented, for instance, by the reqtimeout module for the Apache web server [57]. By following this direction, let B be the bandwidth required for a single connection. During a flooding-based attack, B is supposed to assume particularly high values. On the contrary, in a slow DoS scenario, B is extremely low. As normal/legitimate flows are characterized by “in-between” values of B, it could be possible to implement a flow-control threshold $T_B^s$ that lets connections stay alive only if $B>T_B^s$, hence being able to counter slow DoS threats. Typically, such an approach is adopted to implement $B<T_B^f$, with $T_B^f$ being the threshold used to filter flooding-based threats. Therefore, generally speaking, implementing two lower and upper thresholds $T_B^s$ and $T_B^f$ may filter anomalous traffic. Nevertheless, identifying proper $T_B^s$ and $T_B^f$ values may not be trivial, as they depend on the behavior of the underlying network components. In addition, referring to $T_B^f$ in particular, accurately defining when to apply the thresholds, in terms of time from the establishment of the connection, may not be trivial as well, as it may lead to temporary denial of service states. Therefore, although such an approach may represent a good choice for web server protection, the identification of an appropriate bandwidth threshold(s) to adopt may be complex, due to the nature of the ROS traffic. In addition, it is important to consider that such an approach may interrupt malicious connections only after the denial of service state has been experienced. Further variants of the mitigation technique may consider the use of dynamic thresholds, varying as a function of the number of currently established connections.

Instead, relying on various forms of server-side payload syntax checking is going to be ineffective because, as shown in Section 4, the slow DoS threat described in this paper only transmits legitimate payloads to the server. Finally, reimplementing the ROS Master and parameter server as two separate processes would avoid the chain effect discussed in Section 6.4. However, new publishers and subscribers would still be unable to contact the ROS Master and make themselves known to the system while an attack is ongoing.

8. Conclusions

This paper discussed and evaluated SlowROS, an innovative slow DoS threat directed towards the ROS Master, a mandatory ROS 1 component. In spite of the impending transition to ROS 2, improving ROS security is still quite relevant for the reasons given in Section 2.2. Among them, the most important one is that the deployment of ROS 2 is advancing more slowly than anticipated [40]. Hence, the possible security-related implications of the ROS/ROS 2 transition has been left to future work.

By means of a realistic experimental test bed, it was shown that the attack effect unexpectedly went well beyond the single component being targeted, as it could seem at first sight. Instead, it caused a systemwide service disruption that eventually affects all ROS nodes.

Table 3. Summary of test scenarios.

Scenario	Paper Section	Strategy	DoS?
1	Section 6.2	Single connection, $T_{\mathit{max}}={10}^9\mathrm{s}$	X
2	Section 6.2	Multiple connections, no payload, $T_{\mathit{max}}=3600\mathrm{s}$	√
3	Section 6.3	Multiple connections, partial/malformed payload, $T_{\mathit{max}}=3600\mathrm{s}$	√
4	Section 6.3	Multiple connections, full payload, $T_{\mathit{max}}=3600\mathrm{s}$	√
5	Section 6.5	Multiple connections, $T_{\mathit{SYN}}<1\mathrm{m}\mathrm{s}$ (SYN flooding)	X

summarizes all test scenarios.

While designing SlowROS, the inner workings of the ROS Master and its underlying protocols were also thoroughly investigated. Besides being important for the design itself, the analysis led to an accurate characterization of the ROS Master connection timeout. Notably, one relevant discovery was related to the particularly high idle connection timeout adopted by the server. Future work on the topic may address such an aspect through additional tests. This characterization is crucial to saving bandwidth and making the SlowROS attack harder to detect.

Moreover, the ROS Master response to different kinds of payloads, both legitimate and invalid, has been determined. This information is useful to devise future, stealthier variations of SlowROS. Finally, the information gained about the Linux TCP/IP protocol stack was leveraged to circumvent its SYN flooding detection and protection mechanism.