Sungwon Yi, Xidong Deng, George Kesidis, and Chita R. Das

1. L1 L2 Cache CHALLENGES in handling unresponsive flows (c) 500 Conforming TCPs, 25 UDP, and 1 Unresponsive TCP (d) 1000 Conforming TCPs, 50 UDPs, and 1 Unresponsive TCP (a) 500 Conforming TCPs and 1 Unresponsive TCP (b) 1000 Conforming TCPs and 1 Unresponsive TCP Figure 4: Throughput Comparison of CHOKe, FRED, and HaDQ Conforming Flows Quarantined Flows (Not Identified) Quarantined Flows Dynamic Quarantine of Unresponsive TCP Sessions Sungwon Yi, Xidong Deng, George Kesidis, and Chita R. Das Department of Computer Science and Engineering, The Pennsylvania State University Abstract Detection Capability: Why HaTCh? Motivation • Impact of Single Unresponsive TCP In addition to unresponsive UDP traffic, aggressive TCP flows pose a serious challenge to congestion control and stability of the Internet. This paper considers the problem of dealing with such unresponsive TCP sessions that collectively constitute a Denial-of-Service (DoS) attack on conforming TCP sessions. We propose to use the recently proposed HaTCh scheme along with a small Content Addressable Memory (CAM) to dynamically detect and quarantine the unresponsive TCP flows in order to provide fair service to the conforming TCP users. The proposed scheme, called HaDQ, is based on HaTCh, which accurately estimates the number of active flows without maintenance of per-flow state. For sampling and detecting the high bandwidth flows, we exploit the advantage of a smaller, first-level cache of HaTCh since it isolates the aggressive, high-bandwidth flows from the rest. The high-bandwidth flows from the smaller cache are then moved to the quarantine memory and monitored to compute a fair drop probability. Simulation-based performance analysis indicates that by using a proper configuration of the monitoring period and the detection threshold, the proposed scheme can achieve a low false drop rate (false positives) of less than 0.1%. Most importantly, comparison with two prior schemes (CHOKe and FRED), which were proposed for handling unresponsive UDP flows, shows that HaDQ is more effective in penalizing the bandwidth attackers and enforcing fairness between conforming and aggressive TCP flows. • Unresponsive Flows • Detection (Sampling) Mechanisms • [INFOCOM03, Towsley] – impact of unresponsive flows on AQM performance • [ToN99, Floyd] – how unresponsive flows can cause fairness problem and congestion collapse Need for a router mechanism • Classical Sampling - require longer time • MULTOPS - require precise traffic statistics • RED-PD - Drop history grows O(N) • SRED • TCP/UDP Management Modern routers can easily discriminate between UDP and TCP packets. Thus, UDP can be effectively isolated from the TCP flows by diverting them to a small dedicated queue. (b) Average Hit Count (a) Packet Injection Rate Figure 3: Average Hit Count ☞ Partial solution for UDP problem!!! In Figure 3, the average hit count of each flow with SRED showed a similar value regardless of the packet injection rate. On the other hand, the average hit count in HaTCh clearly increased as the packet injection rate increased. * WC: Window Control, RTO: Retransmission Timeout • How to minimize per-flow state ? • How to identify unresponsive flows ? • How should a router react ? HaTCh Simulation Results • SRED • statistically estimated the number of active flows using a small memory, called zombie list (flow id, hit count) • used this number in indicating the severity of congestion • In HaTCh [CDC03], we Introduction • proved the consistency of the SRED estimator • developed a more robust and accurate dual-cache (RAM) mechanism, called Hash-based Two-level caChe (HaTCh) • Under HaTCh, high bandwidth flows are isolated from L2 cache resulting in higher hit count in L1 cache The unresponsive flows pose a serious challenge to Internet congestion control. Most of these unresponsive flows are UDP applications, which unlike their TCP counterpart, do not respond to network congestion. Thus, UDP flows can effectively shut out the responsive TCP flows by occupying almost the entire bandwidth and can ultimately lead to congestion collapse. Although several Active Queue Management (AQM) schemes has been proposed to handle the congestion, the effectiveness of these schemes still heavily relies on the voluntary use of the congestion control mechanism by the end-users. In addition to the UDPflows, TCP congestion control is vulnerable to the greedy users wishing to accelerate their download rates. Individual users can easily compromise TCP congestion control by deactivating or bypassing the slow-start in their work-station's TCP/IP stack or by spawning multiple parallel TCP sessions, a technique known as turbo-TCP. We view such activities by end-users as malicious denial-of-service (DoS) tothe population of standard TCP users. In the future, this activity is likely to spread and will pose a serous security concern. This paper presents a novel mechanism that dynamically detects, quarantines, and penalizes unresponsive TCP flows. Figure 1: HaTCh Architecture In Figures 4 (a) and (b), FRED showed slightly better protection of the standard TCP flows compared to CHOKe, but both the schemes failed to sufficiently penalize the unresponsive TCP flow. Under FRED, the single unresponsive TCP flow occupied 13% and 11% of the total bandwidth; these numbers significantly increased to 39% and 31%, respectively, under CHOKe. On the other hand, HaDQ precisely activated the punitive measures against the unresponsive TCP flow and enforced fair sharing of the available bandwidth in both cases. In Figures 4 (c) and (d), we added an UDP flow, whose injection rate is 16 times the fair sharing of the available bandwidth assuming that all the traffic is multiplexed in a queue. Under CHOKe and FRED, the UDP and unresponsive TCP flows again consumed significant amount of bandwidth, whereas HaDQ effectively enforced the fair bandwidth sharing. HaDQ (HaTCh-based Dynamic Quarantine) Arriving Packet • Dynamic Quarantine (DQ) • DQ mechanism is based on hit count associated with entries of L1 cache • TCP sessions whose hit counts exceed a threshold • will be “quarantined” in CAM. • Threshold is based on the TM device’s additional • processing ability for quarantined-but-not-yet-punished • flows. • To minimize false positives, actual bit rates of quarantined sessions are estimated by TM device. • Punitive measures applied to sessions based on • the fair share (C/N) of the link bandwidth. Search Quarantine Memory Pflow > 0 YES Found NOT Found NO Conclusions Drop Packet Calculate Drop Probability The proposed HaDQ scheme uses the hit count of L1 cache (in HaTCh) to dynamically detect and quarantine unresponsive flows (minimize per-flow state), estimates the fair sharing of available bandwidth (C/N)to identify the unresponsive flows, and enforces fair sharing of the available bandwidth between responsive and unresponsive flows. We are currently working on a WORM defense mechanism based on HaDQ. NO HaTCh FIFO Queue Figure 2: HaDQ Design and Control Flow • Note that turbo-TCP can be handled by HaDQ since all threads have the same session id. (Src-Dst address pair)