# AccFlow: Defending against the Low-Rate TCP DoS Attack in Drones
## 3 AccFlow Design
### Aggressive Detection  
To effectively detect attacking flows, it is essential to identify unique features that set them apart from legitimate ones. Given that attackers consistently generate high traffic volumes to overload the network, the loss rates of their flows (the ratio of lost packets to the total transmitted packets) are expected to be higher compared to legitimate flows. Consequently, a straightforward method to distinguish between legitimate flows and attacking flows is by using the loss rate as a differentiator. In order to validate the effectiveness of this intuitive approach, we conducted a study on the loss rates of each flow during the simulation, as discussed in the previous section. The centralized controller closely monitors the traffic and performs periodic statistical analysis on all traversing flows. The flow analysis period of the controller should be set to two or three times the typical Round-Trip Times (RTTs) of the traversing flows. This enables the controller to gain accurate insights into the behaviors of these flows and respond rapidly to attacks. In our simulation, we configured this period to be 0.5 s, which is approximately twice the typical RTTs of the traversing flows. In the rest of the paper, we use the term _detection period_ to indicate the controller's analysis period. The results of the simulation are presented in Figure 4a. Figure 3: AccFlow architecture. It is evident that the loss rate of attacking flows remains consistently high. However, we have observed that in certain detection periods, the loss rates for some legitimate flows are even higher. Consequently, relying solely on loss rate as a detection criterion may lead to false positives. Upon closer examination of the traffic generated by each flow, we have identified the reason behind these higher loss rates in legitimate flows during specific detection periods. This phenomenon occurs when a legitimate flow sends only one packet within a detection period, and that single packet is dropped. In such cases, the legitimate flow reacts by stepping back and waiting for one retransmission timeout before entering the TCP slow start phase. At the outset of the slow start, the flow sends out one packet to probe the available bandwidth. In cases of extreme network congestion, this newly generated packet is highly likely to be dropped. Consequently, the legitimate flow is compelled to endure an even longer retransmission timeout. This explains why the loss rate of a legitimate flow is either 1 (the only packet is dropped) or 0 (waiting in retransmission timeout). In contrast, the attacking flow adopts a different strategy. It continuously dispatches a substantial volume of packets without any form of backing off, even when a significant number of preceding packets are dropped. As a result, the attacking flow maintains a consistently high loss rate. In our framework, we propose to use _Uniform Loss Rate (ULR)_ which is defined in Equation (1). We use it to differentiate the attacking flow from legitimate flows. \[ULR=loss\ rate\times usage\ rate \tag{1}\]  
The usage rate of one flow is defined in Equation (2). In the equation, the usage rate of one flow is the ratio of the number of its transmitted packets in one detection period over the total number of arriving packets from all flows in this detection period. \[usage\ rate=transmitted\ packets\div total\ packets \tag{2}\]  
The attacking flow is featured with high ULR since it has to consistently send large numbers of packets (high usage rate) and never backs off even if its packets are dropped (high loss rate). As illustrated in Figure 3(b), there is a notable gap between the ULR of the attacking flow and legitimate flows. Therefore, ULR is an effective feature to leverage to differentiate the attacking flow from legitimate ones. Whenever detecting a flow with excessively high ULR while other flows' ULRs are close to zero, the centralized controller will identify it as an attacking flow and completely block its traffic.