CS244 ’16: Low-rate TCP-targeted Denial of Service Attacks

Name: Sunkyu Lim, Jia-Han Chiam SUNetID: limsk1, jiahan

 

1. Goals

 

A Denial of Service attack (DoS) is an attempt to make network resources unavailable to its intended users. Most DoS attacks are executed by flooding the victim with packets, so that the latter is unable to process service other legitimate flows. This type of naive DOS attack, however, is relatively easy to detect and mitigate with the advent of modern firewalls and detection systems. In A. Kuzmanovic and E.W. Knightly’s paper Low-Rate TCP-Targeted Denial of Service Attacks, authors describe a new way of perpetrating a denial of service attack using a single low rate TCP flow, by exploiting TCP retransmission mechanism.

The TCP protocol has a specific algorithm that it uses to set the retransmission timer, and when a packet is dropped, it decreases the flow rate to near zero during the retransmission. By increasing the flow rate to the maximum for short period of time, it is possible for an attacker to induce packet drops in other TCP flows. If the attacker periodically increases the flow rate to the maximum with a correctly chosen period, the attacker can successfully reduce other TCP’s flow rate to near zero.

2. Motivation

While most DoS attacks focus on increasing the volume and number of attack streams, (e.g. a Distributed DoS attack), this paper suggests a novel method of conducting a DoS attack with a single low rate flow.

The, authors exploit the retransmission algorithm specified by the TCP protocol to accomplish their attack. This suggests that a naive implementation of the transportation protocol can be a security vulnerability. In this manner, the paper brings the attention to another aspect of TCP congestion control of security.

3. Results

The paper conducted experiments to prove that the low rate attack is not merely theoretical but can actually be demonstrated in practice. The authors started with a simple experiment with a single victim flow, and then created more complex setups involving several flows with different variants of RTT, peak rate, and TCP congestion control algorithms. Their scheme successfully executed DoS attacks inside those topologies.

 

The authors also succeeded in executing their DoS scheme over the Internet, proving that the attack can be feasibly carried out against real-world, Internet-connected machines.

4. Subset Goal

Our team tried to reproduce the results of section 5.1 and 5.2.1 of the paper, where authors create an experimental setup involving several TCP flows and carries out their proposed attack scheme. In 5.1, the model has 5 long-lived TCP flows with homogeneous RTTs and authors executes their DoS attack. In 5.2.1, the setup has 20 long-lived TCP flows with heterogeneous RTTs. In the first experiment, authors successfully reduce aggregated throughput to nearly 0. On the second part, authors discover that their attack behaves like a high-RTT pass filter; as low-RTT flows suffer from the attack more severely than high-RTT flows.

5. Subset Motivation

We wanted to reproduce results which can show us that suggested attack scheme can really work in the real world. However, it is nearly impossible to set up the experimental envi- ronment with the real world Internet, so we decide to reproduce the results of experimental model. Among several such results, results of 5.1 and 5.2.1 actually show applicability of the attack, while others focus more on specific parameters of the attack flow. Therefore, we select 5.1 and 5.2.1 as our reproduction targets.

6. Subset Results

We set up a Mininet installation on an EC2 server and wrote a script to re-create the exper- imental setup in Mininet. This script reads a configuration file which specifies the number of hosts used in the topology and the propagation delay of each host to a server. The basic topology has two switches; one connected to server, and one connected to other hosts and attacker. The link used to connect two switches will act as a bottleneck link. We then wrote a script to produce the actual attack stream by sending out datagrams rapidly for a short period.

To verify that our setup was functioning properly, we tested a simple single-host experimental model. Since our TCP stack did not have the minimum RTO configured to exactly 1 second, there was some discrepancy between our results and the paper’s, but we managed to reproduce the attack scenario (i.e. decrease the throughput of innocent stream to near 0) by adjusting the inter-burst period of attack stream.

To reproduce the actual subset results, we then wrote configuration files for the experimental setups used to generate Figures 6 and 7. We also wrote a shell script to run the experiment several times with various inter-burst periods for Figure 6, and to run the experiment with homogeneous flows with different RTTs for to generate Figure 7. All our datapoints were obtained using the average of 5 runs. We used matplotlib to display our results.

The above graph is our attempt at replicating Figure 6 in the original paper. The authors tested the effectiveness of DoS attack on several TCP flows of same RTT. They tried several DoS flows with different inter-burst period, and could identify two null points at 500ms and 1s. It matches their hypothetical result that DoS attack would succeed if the inter-burst period evenly divides 1 second. We managed to reproduce the result with our experimental setup. In our replication of Figure 7 above, we can identify two null points at 500ms and 1s. At each point, the aggregated throughput is only about 10% of a maximum link bandwidth, while we see much better throughput at other points. Interestingly, however, we get much higher throughput than the paper does at inter-burst periods of 600ms∼900ms.

This is our attempt at replicating Figure 7 in the original paper. The paper showed that flows with shorter RTTs were more badly affected by the attack than flows with longer RTTs. We consider ourselves partially successful at reproducing this result. We had a large spike in throughput at RTT=376ms that was not present in the paper and we were unable to diagnose the cause of it. Removing that specific RTT from our experimental mix merely resulted in the spike shifting to a flow with a neighboring RTT. We also saw significant decreases in throughput at all RTT regimes, although the relative decrease in throughput for low RTT flows was indeed higher than the decrease in throughput for high RTT flows. This is not obvious from our figure (it is much more visually apparent in Figure 7 of the original paper), but if we plot the ratio of DOS/no DOS throughput we see an increasing trend (excluding the anomaly at 376ms).

7 Extension

We tried to extend our reproduction space to Figure 8 as we succeed to create flexible experimental model. We run the experiment with various burst length, and here is the result.

We could reproduce almost identical result with the paper. We could see near-linear decrease in aggregated throughput as we increase the burst length of DoS attack.

We also tried to run the experiment while turning on F-RTO. We can turn on F-RTO by modifying Linux environment variable. We run the same experiment to reproduce the result of Figure 6 with F-RTO option. Here is the result.

We expected a large difference from our original result but we got the similar result. However, we could see increased throughput at the null points, as aggregated throughput is about 20% of a maximum link bandwidth.

 

8 Challenges

Linux by default configures the TCP protocol differently from the setup described in the paper. Firstly, the minimum RTT is not set to 1 second. We used ‘ip route change’ command to change minimum RTT of the protocol. Secondly, since FRTO is used by default, we also needed to disable FRTO by setting the environment variable of ‘net.ipv4.tcp frto’ to 0. Our first attempt at generating the attack stream involved ‘iperf3’ on UDP mode, but since we could not create a burst less than a second with this tool, we were forced to manually create the stream by sending out datagrams rapidly for a short period.

9 Platform

We ran our experiments on a Mininet installation on an EC2 server. This was a more performant option than a virtual machine, and the EC2 setup has the advantage of being easily reproducible in the short term, at least until Amazon decides to tweak their EC2 instance offerings.

10 Readme

1. Setup an Amazon EC2 Ubuntu instance (we used an m4.xlarge instance) and ssh into it
2. sudo apt-get update
3. sudo apt-get install git
4. git clone https://github.com/limsk1/CS244_PA3.git.
5. cd CS244_PA3
6. chmod 755 install.sh
7. sudo ./install.sh (install the necessary packages)
8. sudo ./run.sh (run the experiments)
9. ./plot.sh (generate the graphs 5-1.png, 5-2-1.png, 5-2-1_2.png, 5-2-2.png, and 5-2-1-frto.png)