# AccFlow: Defending against the Low-Rate TCP DoS Attack in Drones
###### Abstract
[8] propose a defense method based on sFlow and an improved Self-Organizing Map (SOM) model in Software-Defined Networking (SDN). This approach defines a metric to differentiate between genuine normal traffic and large-scale attack traffic, allowing for the issuance of drop or rate-limiting rules near the source of the attack. However, when two types of traffic are very similar, stricter restrictions may affect the experiences of normal users. [PERSON] et al. [9] proposed a mechanism based on correlation coefficients to detect low-rate and high-rate DDoS attacks. Partial rank correlation is used to detect low-rate attacks. However, this mechanism may not be effective when only one macro traffic attacks the network. [PERSON] et al. [10] present a honeypot-based approach that can be taken as a productive outset towards combatting Zero-Day DDoS Attacks to analyze ways to prevent SSH and Telnet Protocol Attacks [11]. [PERSON] [12] proposed a detection method to identify LDOS attacks at the transport layer and used data mining technology to analyze network anomalies under LDOS attacks to complete the detection. Furthermore, because all of the aforementioned solutions target solely the ideal low-rate TCP DoS attack, one alternative strategy for attackers to circumvent the defense could be splitting their traffic into multiple attacking flows to trigger distributed DoS attacks. Additionally, they do not illustrate how their defending protocols will impact the benign periodic flows, such as the aforementioned video traffic. In this paper, we introduce an Accountable Flow (AccFlow) protocol to offer effective defense against low-rate TCP DoS attacks. AccFlow has been developed to offer effective defense against low-rate TCP DoS attacks while ensuring that there is no performance degradation for legitimate periodic flows. Additionally, AccFlow offers robust protection against general DoS or DDoS attacks. In contrast to previous literature, our approach to designing AccFlow distinguishes itself by integrating the principles of Software-Defined Networking (SDN) [13] and emphasizing flow accountability. Within the SDN architecture, decisions concerning packet routing and forwarding are centralized, distinguishing it from conventional networking approaches. This centralized approach empowers explicit execution of distinct policies for various flows, thereby offering flexibility and innovation in network configuration. For instance, one notable advantage of this centralized architecture is that it empowers network operators to effectively manage traffic, resulting in the creation of low-latency and congestion-free networks. This is particularly advantageous in data center environments [14, 15]. Although originally not designed to address security issues in computer networking, the concept of SDN, a network architecture that centralizes control and offers innovative avenues for reevaluating and mitigating such challenges [16]. Notably, the centralized network architecture enables the controller to perform real-time traffic monitoring and analysis. When attacking flows are identified, the controller can promptly block them, preserving network resources for legitimate flows. This ability to quickly respond to threats and prioritize legitimate traffic is one of the key advantages of SDN-based defense techniques. These techniques offer immediate benefits to the deployed routers or Autonomous Systems (ASes) since they do not necessitate reconfiguration in other parts of the network. Despite these advantages, flow-based security protocols must be scalable to effectively handle a large volume of attacking flows, particularly when considering deployment in Wide Area Networks (WANs). In this paper, we propose to use flow aggregation (we use source IP address-based flow aggregation; the detailed explanation is in Sections 4.1 and 5.2) and virtual centralized controller (the concept of virtual centralized controller is that we use multiple coordinated processors to serve as the centralized controller; the details are in Section 4.2).