Taming the Shrew Florin Dinu

Zheng Cai

COMP527 - Computer Systems Security Final Project Report December 6th, 2008

1

Introduction

Today, the Transmission Control Protocol (TCP) is by far the most used transport level protocol. Studies [1] showed that at least 80% of the traffic on the Internet uses TCP. With such widespread usage the problem of TCP security is as important as ever. In this project we look at two possible attacks on the TCP protocol and devise possible defenses against each of them. The first attack is the shrew attack. It was presented by Knightly and Kuzmanovic in [2]. It is a theoretical attack that can reduce or even nullify the throughput of TCP flows by creating congestion that closely matches the pattern of the TCP back-off algorithm. The second attack is the TCP Reset Attack. It consists in injecting RST packets into an open TCP connection with the goal of closing the connection. This is a practical attack which could affect BGP routers, or enables ISPs to throttle their customers’ p2p traffic.

2 2.1

The Shrew Attack Background

Shrew attacks are low-rate attacks that exploit the homogeneity of the TCP back-off algorithm. Shrew attacks use square UDP waves that send at very high rate for only a small amount of time, large enough to cause congestion. The shrew attack creates an initial congestion and then takes advantage of the deterministic TCP back-off pattern to make TCP flows experience congestion every time they retransmit. Specifically, if TCP experiences packet loss it times out and backs off for RTO (i.e Retransmission Time Out) seconds (initially set to 1) before retrying. If it encounters congestion again, it enters an exponential back-off phase in which the RTO value doubles with every unsuccessful retransmission. The goal of the shrew attack is to create congestion at every of those points. A shrew attack has the property of aggregating TCP flows with very different properties (e.g TCP variant, queue management algorithm, RTT size). This happens because once the flows encounter the initial congestion they will all use a very similar back-off algorithm. The authors show that if the shrew flow is perfectly synchronized with the TCP back-off pattern, it can throttle the legitimate TCP flows to nearly zero throughput. Even if this synchronization is not perfect the damage is still significant. An important property of shrew attacks is that they can easily bypass current router-based flow identification techniques. The reason for this is that routers use the average rate of a flow to infer malicious behavior. However, shrew flows have a low average rate because they send at high rate only for a small period of time. Distributed variations of the shrew attacks where multiple flows sending at an even lower rate aggregate their traffic to cause congestion have also been proposed.

2.2

Past Research

The first steps towards finding a solution for this attack where taken in [2] and [3]. Here the authors show that existing router-assisted mechanisms (RED-PD, CHOKe) for the detection of malicious flows can only stop shrew flows that send for unnecessarily long periods of time. An

end-point alternative that randomizes the initial RTO parameter is also considered. This solution, however, only slightly mitigates the severity of the attacks. It also exposes a fundamental trade-off in changing the TCP configuration. Parameters like RTO have been heavily tuned to maximize TCP performance. For example a value of 1 second for RTO has been found in [4] to maximize TCP throughput. Changing TCP parameters could result in a more robust defense against shrew attacks but this comes at the cost of decreased performance. A novel queue management technique has been proposed in [5]. It analyzes the burstiness of flows and stops any flows that exhibit a shrew-like pattern. However, this method cannot defend against distributed attacks since the per-flow bursts are smaller in size but aggregate over multiple shrew flows. Also, this method inherently has false positives since legitimate flows that exhibit shrew-like behavior can potentially exist. Other researchers have considered adding new capabilities to routers in an effort to thwart shrew attacks. [6] and [7] show that the packet arrival rate of TCP presents periodicity when analyzed in the frequency domain. This can be used to differentiate TCP flows from shrew flows. Collaborative versions of this idea in which multiple routers communicate and perform flow identification have also been presented in [8, 9, 10]. Since a lot of CPU time is needed to implement this idea, the authors have pushed forward the idea of including DSP chips in routers to speed up the computation. Hardware-based solutions like [11] have also been proposed. While we do agree that effective protection against shrew attacks can only be achieved at the router level, we feel that the past research has inherent limitations. There is no guaranteed elimination of false positives. Some of the solutions do not address distributed shrew attacks, however such attacks can be as detrimental as the single attacker versions. It is also not clear how difficult is it for an attacker to model his shrew flow to make it exhibit a legitimate looking frequency domain representation. We also feel that not enough thought has been given into the analysis of UDP flows. While it may be easier to distinguish TCP flows from shrew flows because of idiosyncrasies in TCP behavior the same cannot be said about UDP. However, the most important concern with these approaches is their reliance on router mechanisms that do not exist in practice. We feel this is an important limitation because substantial router hardware modification is notoriously difficult to realize due to prohibitive costs and lack of incentives.

2.3

Our Solution

In this project we look at possible end-host based solutions. We are looking for solutions that can be readily implemented using existing technologies. Specifically we analyze the extent to which legitimate TCP flows can compete with shrew flows for bandwidth. We discuss an end-host method for inferring shrew-based congestion. Ideally, after inferring the existence of a shrew attack using this technique the end-host can choose to continue sending using a large window size after the congestion has conceded. The insight behind this approach is that the TCP window needs to be set to a low value when this helps reduce congestion. However, in the shrew attack case congestion is caused mostly by the misbehaving flow. Also in the period between shrew bursts there is enough bandwidth available, potentially the same amount as before congestion started so there is no need for the TCP flows to use their congestion avoidance algorithm and perform a slow start. Our approach can also defend against distributed shrew attacks because we don’t look at flows in particular but rather on the resulting congestion as a whole.

2.4

Congestion Detection

Most implementations of TCP rely on dropped packets to infer congestion. We argue that this is not a reliable approach. Packets can also be dropped as a result checksum errors. Firewalls drop packets that violate their security policies. Wireless networks can drop packets for various reasons unrelated to congestion [12]. For example there could be transmission errors on the wireless links, or packets could get lost because their recipients are mobile nodes. Mobile nodes could perform handoffs between different cells and this could lead to delays and packet loss. Another problem is that inferring packets drops takes time equal to the value of the retransmission

2

timer in the worst case. This is a significant delay and the information about congestion is no longer up to date. Packet loss can also inferred from the receipt of three duplicate ACKs but this depends on the position of the lost packet in the TCP window, the severity of the congestion and also on the successful transmission of ACKs. For all these reasons we believe that dropped packets are not enough to make informed decisions about the level of congestion in the network. Instead, we focus our attention on Explicit Congestion Notification (ECN). The initial ECN proposal was presented in [13] while later refinements have been discussed in [14, 15]. ECN is a method for routers to unambiguously inform end-hosts about imminent congestion by marking packets. It uses the ECN-Capable (ECT) and Congestion Experienced(ECN/CE) bits in the IP header and the ECN-Echo bit in the TCP header. ECN must be used in combination with a queue management algorithm (e.g. RED) that decides when and how to mark the packets. Typically, such an algorithm starts probabilistically marking packets when a certain threshold (queue occupancy) has been reached. As a response, ECN aware TCP flows should respond by reducing their window and their transfer rate. ECN is already supported by a large number of both router and end-host operating systems [16]. Studies have shown that although there is a solid deployment base, ECN is not yet popular. [17] discovered that in 2004 only 2.1% of the servers were ECN-capable. Subsequent studies have tried to provide incentives for ECN acceptance [18]. With our project we also hope to add another entry to this list.

2.5

Using ECN Against Shrew Attacks

After experiencing packet loss TCP usually sets its windows size to a value of 1 or 2 and performs a ”slow start”. In the case of shrew congestion this only leads to a suboptimal utilization of the available bandwidth. On the other hand, ECN notifications usually allow a TCP end-host to gradually decrease the size of their window until congestion passes. The result is that ”slow start” is not performed and the TCP throughput increases compared to the scenario where ECN is not used. Using this insight we look at how ECN by itself can help mitigate the severity of shrew attacks. To be able to utilize ECN information a TCP flow needs to send enough packets so that some of them will get marked. Thus, TCP flows that continually send data (e.g. FTP flows) will benefit more from our approach. We focus on this case. Most of the simulations from [2] use the same types of flows. Active queue management techniques like RED probabilistically mark packets when a certain minimum threshold has been reached. The probability increases all the way to 100% when a maximum threshold is reached. Generally, the probability is proportional to the rate of the TCP flow. While initially not all the flows will have their packets marked, a shrew flow is designed to eventually completely fill the router queue. Therefore, at some point all packets will be marked and all flows in the network will get ECN information. A pattern typical for congestion is shown in Figure 1. The saw-like appearance is caused by TCP flows reacting to packet drops or ECN notification in order to avoid congestion. Subsequently, they try to consume as much bandwidth as possible. This cycles continues indefinitely. The root of this behavior is the well behaved nature of TCP flows. However, shrew flows are not well behaved. They do not respond to any signals from the network, and continue sending packets at the same rate. Therefore we expect a shrew-based congestion to look totally different. We pictured the expected representation of shrew congestion in Figure 2. Note that it has periods of continuous high congestion. In our tests we look if we can distinguish between these two types of congestion based on the arrival rate of packets marked with ECN bits.

2.6 2.6.1

Evaluation Methodology

We perform ns-2 simulations to analyze the effect of ECN on shrew congestion. We also analyze if the ECN information can be used to detect congestion. The starting point is the code from 3

queue size (packets) 100.0

80.0

60.0

40.0

20.0

0.0 10.0

15.0

20.0

time (sec)

Figure 1: Oscillations in Queue Size

Figure 2: Expected Shrew Congestion [19] that contains the scripts used for the initial paper on shrew attacks. We modified the scripts and ran them on a version of ns-2 on which ECN was enabled. We use a default version of RED as a queue management algorithm. 2.6.2

Results

We first evaluate the effect of using ECN on the TCP throughput of a flow under attack.We use the dumbbell topology from [2] with a bottleneck link of 1.5Mb. A shrew flow sends 2.5Mbps of traffic using a burst of 30 and respectively 150ms. Figure 3 and Figure 4 show the results for these two scenarios using a comparison between a flow that uses ECN and one that does not. The figures plot the TCP throughput against the period between consecutive shrew bursts. Obviously, the smaller the gap between attacks, the bigger is the impact on the TCP performance. In the 150ms case there is virtually no difference between the ECN-enabled and the ECN-disabled scenario. This is because the congestion is long enough that even using ECN, a flow decreases its congestion window all the way to 1 or 2 and subsequently uses ”slow start”. However, the 30ms case presents almost a 10% improvement when the frequency of shrew bursts is high. The reason is that 30ms is not enough to cause ECN-enabled flows to shrink their congestion window all the way. Consequently, after the congestion, the TCP flows continue using 4

Figure 3: Upper-With ECN, Lower-No ECN @ 30ms Burst Length a larger window and the overall TCP throughput is higher. In the next experiment we check if shrew-based congestion can be inferred from the arrival pattern of ECN marked packets. We start 10 TCP-enabled flows and along with a shrew flow in one scenario. In the other scenario the ten flows compete only with each other for network resources. The resulting pattern are showed in Figure 5. We can see that there are actually less ECN-marked packets received in the shrew-attack scenario because after the queue fills, the congestion stops packets from arriving at the router and getting marked. 2.6.3

Conclusion

In conclusion, our experiments showed that ECN can indeed increase TCP throughput to as much as 10% in some cases. However, its main use remains as a method for signaling rather than describing congestion. Because it cannot always provide a continuous of information from the router to the end hosts.

3 3.1

Protection against RST Attacks Background

The RST (reset) bit in a TCP packet header is used to signal error conditions detected by TCP. For example, the arrival of a data packet for which no connection is open would generate a TCP RST packet. Similarly, the arrival of a TCP segment with an inappropriate sequence number, or the arrival of a SYN ACK packet for which no SYN had been initiated, would also trigger a TCP RST packet to be sent. The RST packet provides the way for a TCP endpoint to indicate that serious errors have occurred within the network, and the current connection needs to be closed, 5

Figure 4: Upper-With ECN, Lower-No ECN @ 150ms Burst Length or re-established. The RST bit could also be set in a SYN-ACK packet, when the receiving side wants to reject the connection request immediately without letting the originating side wait for a timeout. In addition, because the overhead of managing TCP connections in a TIME WAIT state can be very large [20, 21], sometimes servers have to choose to reset connections that have been idle for a long period of time. In other word, RST is necessary for TCP. However, TCP RST packet has been used inappropriately in recent years. According to the study in [22], some web servers (e.g. Microsoft Internet Information Server) or some web browsers (e.g. Microsoft Internet Explorer 6.0, still widely in use because of Windows XP) abnormally use RST packet to close a TCP connection, instead of performing the standard FIN handshakes. Moreover, RST packets make TCP connections vulnerable. Attackers can spoof and inject fake TCP RST packets into existing TCP connections, to create denial of service attacks. Applications and protocols that require lengthy sustained connections are most vulnerable. For example BGP is vulnerable as it relies on a persistent TCP session being maintained between peers. If the connection gets terminated, it then takes time to rebuild routing tables and remote routers may experience ”route flapping”. A router that is constantly losing its connection and causing route flapping on other BGP routers will eventually suffer route dampening, or suppression. As BGP is used on a large number of border routers, this could have a significant impact on a large number of users. Some ISPs also use RST packets to reset client connections (e.g. p2p connections). Although in this case the result is not as critical as the BGP, it still severely affects user experience. We argue that, there should be stronger protection mechanisms against spoofed RST packets to prevent RST attacks.

3.2

Vulnerability Analysis

The mechanism in TCP that decides whether a packet is valid is based on source/destination, address/port pairs and sequence number. However, the source and destination addresses, and

6

Figure 5: ECN Arrival Pattern the destination port can easily be known, because commonly they are public information (such as BGP where the attacker could assume the destination port of 179). According to [23] the source port is not even pseudo-randomly selected today. Moreover, ephemeral source ports are not actually selected from the full 16-bit range, but a smaller subset range. The sequence number is 32 bit long, which could potentially take a long time for the attacker to guess using a brute force approach. However, because of the sliding window mechanism of TCP, the chance of guessing a valid sequence number is greatly increased. For example, with a 64512 window size, the attacker only needs to generate 66576 packets. Even with a commonly used smaller window size of 16384, it still only requires 262143 packets. With today’s CPU power and network bandwidth, this is completely practical. In addition, if the attacker can eavesdrop the connection, he will know all the information to spoof a valid RST packet, without guessing. We argue that, there should be a better mechanism which can protect TCP connections from fake RST packets, while at the same time with minimum effect on the current TCP behavior.

3.3

Protocol Design

The key idea of our design is to establish a shared secret between the two parties of a TCP connection. Only RST packets with a valid shared secret will be accepted, and fake ones will be dropped. We have considered the public/private key authentication, but it will bring major modification to TCP and make TCP more complicated. Instead, we use the Diffie-Hellman algorithm to exchange shared secret between the two parties, over an unencrypted channel. In a nutshell, the Diffie-Hellman algorithm works as follows: 1. Alice and Bob agree on a number g (normally 2 or 5), and g is assumed to be known by all attackers. 2. Alice picks a random natural number a, a large prime number p, and sends both p and A = g a mod p to Bob. 3. Bob picks a random natural number b and sends B = g b mod p to Alice. Bob also compute Ab mod p as the shared secret key. 4. Alice gets B and computes B a mod p as the shared secret key. Now both Alice and Bob have the shared secret key, which the attacker cannot know even if he can eavesdrop p, A and B. Then Alice and Bob can verify a RST packet by checking whether it contains a valid shared secret key. 7

Figure 6: Diffie-Hellman Algorithm One major part of our design is the integration of this algorithm into current TCP stack. Initially we wanted to use a simulator such as the ns2 simulator. But the ns2 simulator does not have a fully implemented TCP protocol, with exactly the RST packet handling part missing. Then we decided to modify the TCP stack in the Linux kernel. Figure 7 specifies our approach. We want to add the number p and A in the TCP SYN packet, add the number B in the TCP SYN-ACK packet, and add a shared secret key in a valid RST packet. Obviously we need to find enough space in TCP packets. Figure 8 shows a typical TCP packet. Although the Options fields seem tempting for our purpose of sticking in p and A/B, the Linux TCP stack is very complex in defining and handling different kinds of options in a TCP header. We cannot find a way to invent another kind of option, and add it to the TCP protocol. Then we considered the Urgent Pointer field, which is normally not used in the SYN, SYN-ACK or RST packets. But its limitation is that it is only 16 bit long, which means we can only have 65536 different shared secret keys. Finally we were able to put numbers in the data segment of a TCP packet, because usually SYN/SYN-ACK/RST packets contains no user data. In this case, the shared secret key can be much longer, such as 64 bit or 128 bit. But due to the limitation of our implementation of Diffie-Hellman algorithm (hard to find a very large prime number, and with Linux kernel 2.6.20 and gcc 4.2.3 only 64 bit mod operation is supported), our current shared secret key length is 32 bit (so are p, A and B). We argue that, with a 32 bit long shared secret key, it will take the attacker a considerable amount of time to guess the key using brute force.

3.4

Evaluation

In this section, we evaluate how TCP performance is affected by adding our new mechanism, and how hard it is to guess a shared secret key by brute force. We run our experiment on four machines with 3GHz CPU and 4GB memory, 100Mb NICs. We split the four machines into two groups. The two machines in group X are running an unmodified TCP stack, while the other two machines in group Y are running TCP with our added mechanism. First, we use iperf [24] to test the TCP throughput. We run iperf 10 times for each group, sending TCP traffic for 10 seconds using one connection. Group X gets a throughput of 94676 Kb/sec, while group Y gets a throughput of 94672 Kb/sec. Second, we let iperf open 200 connections in parallel, each of them transfer 8KB data, and we use the “time” command to get the time spent in the iperf process. In group X, iperf spends 63.3 ms in user mode and 81 ms in 8

a

Alice K

Bob

SYN (w/ A) SYN-ACK (w/ B)

b

K

ACK

DATA RST (w/ K) Verify K Figure 7: Modified TCP Protocol kernel mode. In group Y, iperf spends 63.2 ms in user space and 83.5 ms in kernel mode. From those results we can see that, our added mechanism which protects TCP from RST attacks only introduces negligible overhead to TCP. We also build a small TCP packet spoofer which generate RST packets, assuming that it already knows the right source/destination address/port. It guesses the sequence number and the shared secret key by brute force. It can generate about 15000 packets per second. Of course our implementation might not be optimal. In theory, with a bandwidth of 100Mb which is reasonable for a common attacker, assuming the TCP RST packet is 28 bytes long, the IP header is 20 bytes long, and the Ethernet header is 14 bytes long, an attacker can generate about 200000 packets in one second. Even in the case where the attacker can eavesdrop the connection, so that he can generate valid sequence number, guessing a valid shared secret key of 32 bit long by brute force takes about 21300 seconds, or 6 hours. This is already a big improvement over current TCP, with only negligible overhead. With longer shared secret key, it will be impossible for attacker to spoof a valid RST packet only by brute force. Of course the attacker can be smarter and more sophisticated in guessing the shared secret key, but this is beyond the scope of this report.

4

Limitations and Future Work

While we ultimately could not detect shrew-based congestion using ECN information, this is not because the congestion presents a different pattern but rather because the end-host did not receive enough information to based their analysis on. We still expect the congestion at router level to present the patterns that we described. Therefore, as future work we propose to look at how routers can infer shrew congestion based on the variation of their queue size. Since this is local information available to all routers, it should be enough to distinguish TCP-based congestion from congestion caused by awkwardly shaped UDP flows. Ultimately there might not be a way to differentiate shrew flows from normal UDP flows or UDP aggregates but the insight that UDP flows are responsible for the congestion could give the router enough information to protect TCP flows. Our RST attack protection mechanism is still vulnerable to man in the middle attack. The attacker can be a middle man in the TCP connection between Alice and Bob, having a shared secret with both Alice and Bob. Then the attacker can perform a RST attacks on either Alice or Bob. ISPs can perform the man in the middle attack to their customers, with additional 9

Figure 8: A Typical TCP Packet resources for handling connection establishment. We do not see any clear solution to this problem unless we use public/private encryption and authentication. Another limitation is that the shared secret key is only 32 bit long. In the future longer shared secret keys such as 128 or 160 bit keys would provide increased security.

References [1] K.-C. Lan, A. Hussain, and D. Dutta, “The effect of malicious traffic on the network,” in PAM 2003, La Jolla, April 2003. [2] A. Kuzmanovic and E. Knightly, “Low-rate tcp-targeted denial of service attacks (the shrew vs. the mice and elephants),” in ’in Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, August 2003. [3] A. Kuzmanovic and E. Knightly, “Low-rate tcp-targeted denial of service attacks and counter strategies,” in In IEEE/ACM Transactions on Networking, 14(4), August 2006. [4] M.Allman and V.Paxson, “On estimating end-to-end network path properties,” in ’in Proceedings of ACM SIGCOMM 2003, Vancouver, British Columbia, September 1999. [5] Y. C. K. Kwok, R. Tripathi and K. Hwang, “Hawk: Halting anomalies with weighted choking to rescue well-behaved tcp sessions from shrew dos attacks,” in the 2005 International Conference on Computer Networks and Mobile Computing (ICCNMC’05), Zhangjiajie, China, August 2005. [6] K. Yu Chen, “Spectral analysis of tcp flows for defense against reduction-of-quality attacks,” [7] K. H. Y. Chen and Y. K. Kwok, “Filtering of shrew ddos attacks in frequency domain,” in the First IEEE LCN Workshop on Network Security (WoNS), held in conjunction with the 30th Annual IEEE Conference of Local Computer Networks (LCN 2005), Sydney, Australia, Nov. 15-17, 2005.

10

[8] Y. Chen and K. Hwang, “A collaborative detection and filtering of shrew ddos attacks using spectral analysis,” in Journal of Parallel and Distributed Computing, Special Issue on Security in Grids and Distributed Systems, Vol. 66, Issue 9, September 2006. [9] K. H. Yu Chen and W.-S. Ku, “Collaborative detection of ddos attacks over multiple network domains,” in IEEE Trans. Parallel Distrib. Syst. 18(12): 1649-1662, 2007. [10] K. H. Yu Chen, “Collaborative defense against periodic shrew ddos attacks in frequency domain,” [11] H. Chen and Y. Chen, “A novel embedded accelerator for online detection of shrew ddos attacks,” in the 2008 IEEE International Conference on Networking, Architecture, and Storage (NAS’08), Chongqing, China, June 2008. [12] R. Cceres and L. Iftode, “A improving the performance of reliable transport protocols in mobile computing environments,” in IEEE Journal on Selected Areas in Communications, 13(5):850-857, June 1995. [13] S. Floyd, “Tcp and explicit congestion notification,” in ACM Computer Comm. Review, 24(5):10-23, 1994. [14] K. Ramakrishnan and S. Floyd, “A proposal to add explicit congestion notification to ip,” in RFC 2481, January 1999. [15] K. Ramakrishnan and S. Floyd, “The addition of explicit congestion notification to ip,” in RFC 3168, September 2001. [16] S. Floyd, “ECN Implementations.” http://www.icir.org/floyd/ecn.html#implementations. [17] J. P. A. Medina and S. Floyd, “Measuring the evolution of transport protocols in the internet,” in Tehnical report, June 2004. [18] A. Kuzmanovic, “The power of explicit congestion notification,” in ’in Proceedings of ACM SIGCOMM 2005, Philadephia, USA, August 2005. [19] “Shrew code.” http://www.cs.northwestern.edu/∼akuzma/rice/shrew/#Ns code. [20] M. Aron and P. Druschel, “Tcp implementation enhancements for improving webserver performance.” [21] P. Barford and M. Crovella, “Critical path analysis of tcp transactions,” IEEE/ACM Trans. Netw., vol. 9, no. 3, pp. 238–248, 2001. [22] M. Arlitt and C. Williamson, “An analysis of tcp reset behaviour on the internet,” SIGCOMM Comput. Commun. Rev., vol. 35, no. 1, pp. 37–44, 2005. [23] P. A. Watson, “Slipping in the window: Tcp reset attacks,” December 2003. [24] A. Tirumala and J. Ferguson, “Iperf.” http://dast.nlanr.net/Projects/Iperf.

11