Low Rate TCP-Targeted DoS Attack

Overview

The following contains a brief documentation about the implementation of Low Rate TCP-Targeted DoS Attack in ns-3 (Network Simulator) as described in the paper titled "Low-Rate TCP-Targeted Denial of Service Attacks (The Shrew vs. the Mice and Elephants)" by Aleksandar Kuzmanovic and Edward W. Knightly. You can find the source code here. The results of our experiment on ns-3 have been shared on this page.

Steps

• Initially, the following topology is set-up.



• The legitimate sender runs a TCP Bulk Send application (simulating an actual TCP transfer).
• The attacker node runs a UDP On Off application (simulating the periodic bursts).
• The receiving node just has a TCP and UDP sink running to receive the segments/datagrams.
• Once the link and node parameters are defined, and the topology is set up, the start and stop times of the applications and the frequency of the attacker bursts must be defined.
• The frequency of the attacker bursts can be varied by setting the 'OnTime' and 'OffTime' attributes of the OnOff Helper. The attack gives the best results at OnTime = 0.25s and OffTime = 0.75s.
• All the applications except the Bulk Send application start at time t = 0. The Bulk Send application on the sender node will start at a time equal to the OffTime of the UDP On-Off application on the attacker. This is because the UDP OnOff application is initially in the Off state. This makes sure that both the sender and attacker effectively start at the same time.
• The data rate for the attacker application must be set so that it saturates the bottleneck link in the duration that it is on (OnTime).

Explanation

DoS attacks can be detected by counter-DoS mechanisms such as CouldFlare due to their high data rate. Here, we simulate a 'Low-Rate TCP targetted DoS attack' which is harder to detect as compared to the traditional DoS attacks.
These low-rate DoS attacks make use of the TCP congestion control's Retransmission TimeOut (RTO) functionality to reduce communication between a sender and a receiver. Instead of flooding the network with continuous or large traffic, as in a normal DoS attack, we 'time' these floods such that they congest the network right when the TCP sender retransmits when there is a packet loss. This will lead to the sender waiting for another RTO period, after which this flood repeats again. These bursts have a data rate just sufficient enough to congest the bottleneck link that is present between the sender and the receiver. Since the bursts take place for a very small duration, the average data rate isn't expected to reach a value that can be detected.
Hence by carefully timing these attack bursts, we can evade counter-DoS mechanisms, and at the same hinder communication between the TCP sender and receiver.

Note the way the current RTO value changes. In the TCP used, that is, TCP New Reno, RTO value is expected to double everytime a lost packet is retransmitted. That is, assume as a certain point of time, it has RTO value equal to that of minRTO value, that is, 1 second. Then the subsequent RTO values for every packet retransmitted will be 2,4,8,16 ..so on. However once, an acknowledgement is successfully received RTO value is set back to the value calculated by the formula:

RTO = max(minRTO,SRTT + max(G,4*RTTVAR))

where minRTO is decided by the type of TCP and the system the TCP runs on, SRTT refers to Smoothed Round-Trip Time (calculated from measured RTT) and RTTVAR refers to Round-Trip Time Variation.

One way to launch a very successful attack is to time the attacker bursts at the exact time the sender is about to send some packets. The animation above shows a similar scenario.