# AccFlow: Defending against the Low-Rate TCP DoS Attack in Drones
## 5 Experimental Results
### Short Selfish TCP Flow Attack  
In this section, we discuss a very effective DoS attack which is similar to but still fundamentally different from the low-rate TCP DoS attack. The attacking technique is that malicious users periodically set up many short TCP flows to gain unfair share of network resources. Specifically, the early coming short TCP flows congest the network and cause all flows (including both legitimate TCP flows and themselves) to enter retransmission timeouts. Then, the attackers selfishly start new short TCP flows to occupy the whole network bandwidth since no one apart from attackers is transmitting now. The interesting point of such DoS attacks is that it seems that the attackers never deviate from the TCP protocol since these short TCP flows will back off when their packets are lost. However, the attackers are able to cause very severe denial of service to legitimate users simply by  
Figure 8: Under all three settings, AccFlow can effectively defend legitimate TCP flows from being attacked. The achieved throughput for each legitimate flow is almost the same as its original transmission rate. breaking their traffic into small short flows. We name such an attack the Short Selfish TCP Flow (SSTF) attack. Note that the difference between the SSTF attack and low-rate TCP DoS attack is that the former cannot synchronize all these short TCP flows to create the regular periodic burst traffic since transmitters have to wait for the ACKs before sending new packets. We set up simulations to illustrate the effectiveness of the SSTF attack. In our simulation, we have 10 attackers and each of them sends one short TCP flow with 3 Mbps data rate every 200 ms. Furthermore, we have nine legitimate TCP flows with 1 Mbps transmission rate each. The results, illustrated in Figure 10, show that the SSTF attack is able to effectively throttle the legitimate users to almost zero throughput. Now, we explain why the SSTF attack can cause such an effective denial of service to legitimate users even though each individual short flow itself behaves exactly the same as a legitimate TCP flow (here, we mean each short TCP flow complies with the TCP protocol and will back off when a congestion happens). First, let us reconstruct the attacking procedure. Assume that attackers first set up \(n\) short TCP flows \(\mathcal{A}=\{A_{1},A_{2},...,A_{n}\}\) to cause congestion. Then all the legitimate flows and attacking flows in \(\mathcal{A}\) will suffer from severe packet losses and enter retransmission timeouts. After a short period, attackers set up another set of short TCP flows \(\mathcal{B}=\{B_{1},B_{2},...,B_{m}\}\). Since no one is transmitting now, \(\mathcal{B}\) will occupy the whole network resources. When the legitimate flows try to recover from timeouts, they may face another set of short attacking flows started by the attackers after flows in \(\mathcal{B}\) finish. Again, congestion happens and the legitimate flows are forced to enter even longer retransmission timeouts. The cycle repeats and the attackers are able to selfishly utilize nearly the whole network resources. In a word, by sacrificing a small fraction of their traffic, the attackers create a \"clear\" network environment for most of their traffic and cause severe denial of service to the legitimate users. Figure 9: Convergence time of AccFlow. The trick played by the attackers is to evade accountability by continuously generating fresh short flows. In particular, it is the flows in \(\mathcal{A}\) that cause the congestion so that we have no reason to blame the flows in \(\mathcal{B}\). However, when flows in \(\mathcal{A}\) experience severe packet losses, the source should realize that the network is congested and should not start new flows. Thus, flow set \(\mathcal{B}\) should not be generated because both \(\mathcal{A}\) and \(\mathcal{B}\) come from the same source (attackers).