# AccFlow: Defending against the Low-Rate TCP DoS Attack in Drones
###### Abstract  
As drones are widely employed in various industries and daily life, concerns regarding their safety have been gradually emerging. Denial of service (DoS) attacks have become one of the most significant threats to the stability of resource-constrained sensor nodes. Traditional brute-force and high-rate distributed denial of service (DDoS) attacks are easily detectable and mitigated. However, low-rate TCP DoS attacks can considerably impair TCP throughput and evade DoS prevention systems by inconspicuously consuming a small portion of network capacity, and whereas the literature offers effective defense mechanisms against DDoS attacks, there is a gap in defending against Low-Rate TCP DoS attacks. In this paper, we introduce AccFlow, an incrementally deployable Software-Defined Networking (SDN)-based protocol designed to counter low-rate TCP DoS attacks. The main idea of AccFlow is to make the attacking flows _accountable_ for the congestion by dropping their packets according to their loss rates. AccFlow drops their packets more aggressively as the loss rates increase. Through extensive simulations, we illustrate that AccFlow can effectively safeguard against low-rate TCP DoS attacks, even when attackers employ varying strategies involving different scales and data rates. Furthermore, whereas AccFlow primarily addresses low-rate TCP DoS attacks, our research reveals its effectiveness in defending against Deep So attacks. These general attacks do not rely on the TCP retransmission timeout mechanism but rather deplete network resources, ultimately resulting in a denial of service for legitimate users. Additionally, we delve into the scalability of AccFlow and its viability for practical deployment in real-world networks. Finally, we demonstrate the effectiveness of AccFlow in safeguarding network resources. d 2023  
Compared to general DoS attacks in which malicious users cause a denial of service by sending continuous high-rate flows, rather than relying on the TCP retransmission timeout mechanism, the time-averaged bandwidth usage of the low-rate TCP DoS attacking flow is small. In some cases, it can even be much less than the total available bandwidth. This is why we refer to such an attack as the _low-rate_ TCP DoS attack. Another noteworthy characteristic of the low-rate TCP DoS attacking flow is its periodic traffic pattern, which bears a resemblance to legitimate TCP periodic traffic, such as video traffic adopting the DASH (Dynamic Adaptive Streaming over HTTP) [5] standard. Despite the apparent similarity in traffic patterns, a fundamental distinction exists between benign TCP periodic flows and the low-rate TCP DoS attacking flow. The key difference lies in how they respond to the packet loss. Legitimate TCP flows follow a protocol that involves backing off and entering retransmission timeout when their packets are lost. In contrast, the low-rate TCP DoS attacking flow does not exhibit this behavior. Although the low-rate TCP DoS attack has been proposed for nearly ten years, it has not been fully addressed. [PERSON] et al. [6] use signal processing (autocorrelation of the traffic) to detect the periodic burst attack at the congested router. Whenever attacks have been detected, the router traces back to its upstream routers to find the attack source. Such a solution may not work if the congested router has multiple upstream routers so that the bursty traffic it detects consists of the aggregate traffic from these upstream routers. Therefore, it is possible that the upstream routers cannot detect the bursty attacking traffic, which disrupts or halts the tracing back process. The work by [PERSON] et al. [7] addresses this problem by assigning high priorities to the packets that are destined for high loss rate TCP application ports. However, such a defense mechanism can be breached if the attackers send large volumes of traffic to a specific protected port to cause a high loss rate at this port. Consequently, the attackers' traffic will be marked as high-priority traffic. [PERSON] et al.