Distributed Change-Point Detection of DDoS Attacks over Multiple Network Domains

Transcription

1 Distributed Change-Point Detection of DDoS Attacks over Multiple Network Domains Yu Chen, Kai Hwang, and Wei-Shinn Ku University of Southern California, Los Angeles, CA Abstract: Distributed denial of services (DDoS) attacks post a major threat to Internet security. This paper proposes a distributed system to detect flooding DDoS attacks at the earliest possible time. At the launching stage of a DDoS attack, some changes in traffic fluctuation are detectable at the router or gateway level. We develop a distributed change-point (DCP) detection architecture using change aggregation trees (CAT). This DCP scheme detects abrupt traffic changes across multiple network domains serviced by the same ISP or managed by the same organization. The early detection of flooding attacks enables timely countermeasures to minimize damages to the edge networks or to hot-spot victim systems serviced by the provider. Each network domain corresponds to a single autonomous system (AS). The AS domain is equipped with a CAT server to aggregate traffic change information detected at the routers. All CAT servers exchange flooding alert information to make global detection decision across multiple domains. To resolve the conflicts in security policies at different provider domains, a new secure infrastructure protocol (SIP) is developed to establish the trust among them. We report scalable performance results on implementing the DCP detection system over 16 domains in the DETER testbed. The simulated Internet setting reveals that 4 domains are sufficient to yield 98% detection accuracy of TCP SYN and UDP flooding attacks with less than 1% false alarms. By using ISP-controlled AS domains, the DCP system is proven scalable to 84 domains, which appeals to real-life deployment in the Internet environments. Key Words: Network security, DDoS attacks, change-point detection, Internet infrastructure, security protocols, Internet service providers, and overlay networks. Manuscript submitted to IEEE Transaction on Parallel and Distributed Systems, on August 14, The research work reported here was supported by National Science Foundation ITR Grant All rights reserved by the coauthors and publishers. The preliminary concept was presented in IEEE International Symposium on Collaborative Technologies and Systems (CTS 2006), Las Vegas, May 15-17, Corresponding author: Kai Hwang, USC Internet and Grid Research Lab, EEB 212, Los Angeles, CA kaihwang@usc.edu, Tel.: (213) , Fax: (213) August 13, 2006 Page 1 of 30

2 1. Introduction To defend against distributed denial of services (DDoS) attacks, we wish to achieve realtime detection of incurred network anomalies. Today s DDoS detection systems are mostly based on detecting the flooding consequences rather the causes of the traffic surges [7], [8], [18], [31], [41], [42]. Flooding consequences are displayed by congestions on communication links [27], overflow in half-open SYN queue [26], or imbalance between incoming and outgoing traffic on router ports [46]. Unfortunately, the damages have already done when these flooding consequences are observed. Thus, it is highly desired to detect the launching of DDoS attacks at the very early stage, instead of waiting for the flooding to become widespread. A comprehensive solution to DDoS attacks requires covering the global effects over the entire Internet. Obviously, the global-scale defense is too costly for a real-life implementation. Even the DETER project [4] can only emulate partial Internet activities on a controlled number of network domains. To implement an efficient defense system, we must leverage the network topology and use distributed traffic monitoring and detection. In other words, we have to build up a scalable DDoS defense system involving only a small number of provider network domains that are closest to the edge network attached to protected user group. In the sequel, we consider each autonomous system (AS) a single network domain, such as the core network of an ISP (Internet service provider). According to the ISO 3166 Report [20] on AS resource allocations, there are 34,998 AS domains reported in August Dimitropoulos et al. [13] identified that among these AS domains, 67.7% belongs to customer companies, organizations, or universities that run their own networks, 30.3% are ISP controlled domains, the remaining 2% are Internet exchange points (IXPs) or network information centers (NICs). Majority customer AS domains do not share their networks with competitors. Therefore, they are unlikely to take part in collaborative DDoS defense. However, it is possible to convince a small percentage, say 5% of the ISP-controlled domains to join collective effort in combating DDoS attacks. This amounts at most few hundreds of domains to form a consortium for collective DDoS defense. We will prove through statistical analysis that less than 84 AS domains working together would be sufficient to cope with most DDoS flooding attacks. At the early stage of a DDoS attack, the traffic changes are difficult to detect because very little fluctuations in traffic are observable. Monitoring the Internet traffic at August 13, 2006 Page 2 of 30

3 individual flow level is cost prohibitive to cover all possible flows with the same source/destination IP and protocol. Meanwhile, the global traffic aggregated at wide-area network is tremendously large to perform real-time detection of network anomalies, effectively. To be cost-effective, we propose to monitor the traffic at a superflow level. A superflow contains all packets destined for the same network domain from all possible source IP addresses and applies various protocols such as TCP or UDP, etc. This level lies between the level of largescale aggregate traffic and individual traffic flows. This approach is inspired by the classless inter-domain routing (CIDR) idea [16]. All packets of a superflow have the same destination domain IP address. Motivated by the desire to have lightweight detection with low complexity [3], [9], [46], we propose a distributed change-point (DCP) detection architecture using a new mechanism, called change aggregation tree (CAT). The preliminary concept of CAT was first presented in CTS 2006 [11]. This CAT mechanism is designed at the router level for detecting abrupt changes in traffic flows. When a DDoS attack is launched, the routers can observe some changes in spatiotemporal distribution of traffic volumes at the router ports. The domain server uses the traffic change patterns detected at attack-transit routers to construct the CAT, which represent the attack flow pattern. Usually these changes in traffic flows present a directionality converging towards the victim. Random fluctuations incurred with legitimate traffic flows do not present such converging properties. On the DETER testbed [4], [12], we implemented the DCP scheme over 2 to 16 network domains. We carried out intensive experiments to evaluate the effectiveness of the CAT-based DCP scheme. Under flooding attacks, our scheme is capable of detecting the start of DDoS attacks quickly with high accuracy and low false alarms. The rest of this paper is organized as follows: Section 2 briefly reviews related works. Section 3 presents the principle of change detection methods and the algorithms for raising attack alerts in individual routers. The intra-domain CAT constructing algorithm is given in section 4. The inter-domain change detection algorithm is presented in section 5 along with a new secure infrastructure protocol (SIP). This protocol supports the inter-domain change aggregation operations. Section 6 reports the experiments setups and the performance results based on the DETER experiments. Section 7 discusses scalability issues and deployment limitations. Finally, we conclude with a summary of contributions and discuss further research work needed. August 13, 2006 Page 3 of 30

4 2. Related Work and Our Approach As shown by Fig.1, the DDoS attacker often exploits the huge resource asymmetry between the Internet and the victim systems. The flooding traffic is large enough to crash the victim machine by communication buffer overflow, disk exhaustion, or connection link saturation, etc. A plethora of defense and response mechanisms have been suggested in the past, including IP traceback [1], [25], [48], packet filtering [24], [34], [43], [45] and flood pushback [19]. More sophisticated DDoS attacks [10], [23], [47] have been also studied. Recently, researchers suggested choking DDoS flooding traffic by an offensive approach [42]. Figure 1. Traffic flow distribution of a typical DDoS flooding attack Different options exist regarding where the DDoS defense is deployed. MULTOPS [17] and D-WARD [29] suggested filtering or rate limiting on suspicious flows at the source end. The security managers often focus on protecting their own networks and choose a local detection approaches [7]. For instance, the COSSACK [33] and DefCOM [28] deploy detectors at the victim side and send alert to filter or to rate limiter located at the source side. Chen and Song [9] proposed a perimeter-based defense scheme for ISP to enable anti-ddos services to their customers. Their scheme relies on the edge routers to identify the flooding sources and use ratelimiting filters. Researchers also use change-point detection theory to detect abnormal Internet traffic caused by DDoS attacks [5], [35], [40], and [46]. Lacking accurate statistics to describe the prechange and post-change traffic distributions, nonparametric CUSUM schemes were developed for simplicity and low computational complexity [5]. These schemes monitor the short-term behavior shift from long-term behaviors. Once the cumulative difference reaches certain threshold, an attack alert is raised. August 13, 2006 Page 4 of 30

5 Researchers at University of Michigan [46] have suggested a centralized DDoS defense scheme to monitor the change points at the gateway level. They adopted the nonparametric CUSUM method to detect TCP SYN flooding attacks. Peng et al. [35] took a similar approach to monitoring the source IP addresses. Due to the source IP address spoofing, there are many new source IP addresses appeared during DDoS attack. It requires an offline database to keep track of IP addresses in normal traffic. Recently, Soule et al. [40] implemented a defense scheme that combines filtering and statistical methods. Under TCP SYN flooding, the difference between them is distinguished by a CUSUM algorithm [46]. Once the sum exceeds a certain threshold, the TCP SYN DDoS attack is detected. Some theoretical analysis was reported by Blazek, et al [5] to model change-point detection for DDoS defense In this paper, we propose a new distributed aggregation scheme based on change-point detection across multiple network domains. This paper is significantly extended from the preliminary concept presented in CTS 2006 [11]. We extend the architecture from single-domain detection to work over multiple network domains. All DETER experimental results are newly generated. Many previous distributed solutions assumed that networks are willing to cooperate in DDoS defense. This assumption is weakened by lack of trust-negotiation among them, because domains owned by different organizations may not cooperate due to policy conflicts. In fact, the victim-end solution may miss the chances of raising early warning of DDoS attacks at the upstream routers. Our distributed change-detection solution is meant to amend this inadequacy. We build up the cooperation among communicating networks by using a new secure infrastructure protocol (SIP) to resolve the security conflicts among them. This enables the building of an earlier DDoS defense system across multiple ISP domains. Our DCP scheme is capable of tracing back automatically, once the detection is successfully carried our. The global CAT tree covers all related network domains, where the anomalies are observed on the fly. 3. Framework of Distributed Change Detection The DCP scheme detects the start of DDoS flooding attacks by monitoring the abrupt traffic changes at distributed network points. Once a sufficiently large CAT tree is constructed which exceeds certain preset threshold value, a suspicious attack is declared. This section August 13, 2006 Page 5 of 30

6 presents the principles behind the DCP system. In this section, change detection is conducted at individual router. In next two sections, we will extend the DCP scheme across network domains. 3.1 Distributed Change Detection System Figure 2 presents the system architecture of the DCP scheme. The system is deployed over multiple AS domains. There is a central CAT server in each domain. The system detects the traffic changes, aggregates detected changes, and collects alerts over collaborative CAT servers. Routers are in charge of attack detection and raising alert, whereas the CAT servers aggregate distributed alerts. The root of the CAT is located at the last-hop domain server. Each tree node corresponds to an attack-transit router (ATR). Each tree edge corresponds to a link between the attack-transit routers. The CAT servers at different domains could form an overlay network or communicate with each other through virtual private network (VPN) channels or an overlay network. The router monitors the incoming and outgoing traffic flows at its input and output ports. Periodically, each router reports the traffic status to the CAT server in its domain. If a router observes abrupt traffic variations, which are far above the historical average, an alert message is sent to the CAT server. The server is responsible to construct the CAT tree for the entire domain. The CAT server also exchanges CAT information with other domain severs. (a) Multi-domain defense system (b) Inter-domain communications via VPN tunnels or overlay network atop the CAT servers Figure 2. Distributed change detection of DDoS flooding attacks over multiple asynchronous systems (AS) or multiple AS domains. In the sequel, AS domains and ISP core networks are used interchangeably. The CAT detection scheme does not need to specify an absolute threshold on traffic volume. The detection is done by checking the number of nodes (routers) raising the alerts from the CAT subtree. August 13, 2006 Page 6 of 30

7 Figure 3 illustrates how a CAT subtree is constructed at a single domain server. Figure 3(a) shows a flooding attack launched from 4 zombies, the routers along the routing path to the victim detect abnormal surge of traffic at their I/O ports. They report the suspicious flows with the involved upstream and downstream routers to the CAT server. Using Algorithm 2 in section 4, the server constructs a CAT rooted at the end router R0 in Fig. 3(b). The server recursively scans through all upstream routers to construct the tree. The CAT presents a traffic-flow tree pattern rooted at the router connected to the edge network, where the victim is attached. With sufficient exchange of alert information from related domains, the system can detect the DDoS flooding attack at very early launching stage, before the superflows reaching the victim network. (a) Traffic pattern of a DDoS flooding attack (b) CAT subtree rooted at router R0 Figure 3. An illustration of change aggregation tree (CAT) constructed at the end router (R0) connected to the victim system. 3.2 Change-Point Detection Principles In change-detection problems, if pre-change and post-change distributions are known, the CUSUM statistic has been suggested to solve the problem [5]. We adopt a non-parametric approach for its simplicity. Let t 1, t 2,., t m be discrete time instants and x(t m, i) be the number of packets received by a router during time slot m at port i. The historical estimate average number of packets X ( t m, i) is defined iteratively by: X ( t, i) = (1 α ) X ( t 1, i) + α x( t, i) (1) m where 0 < α < 1 is an inertia factor showing the sensitivity of the long-term average behavior to the current traffic variation. Higher α implies more dependence on the current variation. We define below S in (t m, i) as the deviation of input traffic from the average at time slot t m. S ( t, i) = max{0, S ( t 1, i) + x( t, i) X ( t, i)} (2) in m in m m m m m August 13, 2006 Page 7 of 30

8 The subscript in indicates that this is the statistics of the incoming traffic. While a DDoS flooding attack is being launched, the cumulative deviation is noticeably higher than the random fluctuations. Since S in (t m, i) is sensitive to the changes in the average of the monitored traffic [5], we measure the abnormal deviation from historical average as follows. Let deviation from average (DFA) is the ratio of such an attack indicator. The incoming traffic DFA is defined below at time t m and at port i: DFAin ( tm, i) = Sin ( tm, i) X ( tm, i) (3) If the DFA exceeds a router threshold β, the measured traffic surge is considered a suspicious attack. The threshold β measures the magnitude of traffic surge over the average traffic value. This parameter is preset based on previous router use experience. In a monitoring window of 100 ms to 1 s, a normal superflow is rather smooth due to statistical multiplexing of all independent flows heading for the same destination [21]. If there is no DDoS attack, we expect a small deviation rate far below β. In section 6, we will discuss the impact on the performance of the CAT detection scheme, when β is chosen between 2 β 5. Let τ be the earliest time when a router detects abnormal deviation in traffic volume. This time instant is formally defined below: τ = min{ t m : Sin( tm, i) / X ( tm, i) β} (4) For outgoing traffic, we define y(t m, i) as the number of packets in time t m leaving at port i and Y ( t m, i) be the historical average number of leaving packets. Similarly, we have: Y ( t, i) = (1 α ) Y ( t 1, i) + α y( t, i) (5) S out m m m ( t, i) = max{0, S ( t 1, i) + y( t, i) Y ( t, i)} (6) m out All above equations are used to specify the change-detection algorithms in subsequent sections. 3.3 Change Detection at a Single Router Each router monitors traffic variations and counts the packet number within each monitory window at each I/O port. We use the term traffic pattern to refer to the combination of traffic surges at all I/O ports of a router. In general, a router with m-input ports and n-output ports may encounter 2 m+n possible traffic patterns. The height of the black boxes in Fig.4 signifies the magnitude of traffic volume at the relevant I/O links. The raised block height indicates a surge detected and the lower height stands for normal traffic flow. m m m August 13, 2006 Page 8 of 30

9 All packets of a superflow must be homing towards the same destination network. Before entering the destination domain, the flow paths present a converging homing-tree pattern. Only at the destination domain, the superflow scatters packets towards a particular edge network specified by the destination IP address. There exist 16 possible traffic patterns fro a 2 х 2 router. For simplicity, we illustrate in Fig.4 only 4 basic traffic patterns at a 2 х 2 router with m = n = 2. The remaining 12 traffic patterns can be specified, similarly. a. Flow-through pattern: This traffic pattern is shown in Fig.4(a). The router forwards the entire traffic flow from an input port to a selected output port without subdividing or diverting the traffic to other outgoing port. b. Partial aggregation pattern: All the incoming flows are merged at one outgoing port i out, not all incoming flows contain traffic surges as shown in Fig. 4(b). c. Full aggregation pattern: The outgoing flow merges multiple incoming flows, all containing traffic surges exceeding the threshold β. This router is considered a merge point on the attacking path (Fig.4(c)). d. Scatter pattern: The incoming flow scatters at this router. This pattern is not part of a DDoS attack (Fig. 4(d)). This pattern is observed only in the destination domain. (a) Flow through (b) Partial Aggregation (c) Full Aggregation (d) Scatter Pattern Figure 4. Four basic traffic patterns of traffic changes at a 2 х 2 router I/O ports Another statistical parameter, deviation ratio (DR), is defined below to measure the ratio of incoming packets from port i in have propagated to output port i out. DR is the ratio of traffic deviations between the input and output ports. DR i, i ) = S ( t, i ) S ( t, i ) (7) ( in out out m out in m in August 13, 2006 Page 9 of 30

10 If DR > 1, the router amplifies the input deviation. This corresponds to a full surge of traffic volume. DR 1 implies the router merely plays the role of a forwarder. This phenomenon is observed in the partial surge at one input port. Meanwhile, the case of DR < 1 indicates that the incoming wave is scattered to multiple ports. It is not part of the convergence traffic of DDoS attacks. Therefore, by checking the DR value, a router determines whether the pattern is part of a CAT tree incurred with a DDoS attack. To be more precise, we specify a local detection algorithm for suspicious traffic pattern here. When a router detects that a DFA in exceeds the deviation threshold β, it calculates the deviation rate between the outgoing and incoming ports. If DR is close to one, the traffic aggregation pattern is considered suspicious. The router generates an alert message and reports the pattern to the CAT server. Otherwise, the router sends a regular status message indicating no anomaly observed. Essentially, the DR specifies how much the incoming traffic propagates through the router. This DR measure is directly related to the detection rate. Below is the pseudo code of Algorithm 1 for local change detection at the router level. Algorithm 1: Attack detection at router level Input: x(t, i) and y(t, i): Incoming and outgoing packets at time t and port I, respectively X ( t m 1, i ) : Historical average of packet arrivals up to time m-1 at port i Y ( t m 1, i ) : Historical average of outgoing packets up to time m-1 at port I Router detection threshold β based on past experience Output: Alert messages sent to the central CAT server. Procedure: 01: Update historical average of I/O packets in a flow 02: Calculate DFA in using Eq. (3) 03: If DFA in β Then Calculate DR using Eq. (7) 04: If DR 1.0 Then Suspicious pattern detected. Send out an alert message to CAT server. 05: Else Nothing suspicious. Send out a regular status message CAT server. 4. Construction of CAT Subtrees at Domain Servers This section describes the details of CAT subtree construction at each CAT server in a single network domain. Different subtrees are generated at different network domains. The global CAT tree is generated by merging all subtrees. While the flooding traffic merges at the victim end, the routers along the paths capture suspicious traffic patterns. In this section, we concentrate the subtree construction in a single network domain. Algorithm 2 specifies the subtree construction at a single domain CAT server. August 13, 2006 Page 10 of 30

11 The router also reports the ID of a superflow causing the traffic surge. Besides the number of upstream and downstream routers, the alert message provides the upstream and downstream router IDs. Since all routers are under the same authority and work cooperatively, each router knows their immediate neighbors connected through the ports. The alert message provides information for CAT server to include the routers in the CAT subtree. Table 1 summarizes the information carried in a typical alert message from an attack-transit router. Table 1. Information in an Alert Message Sent from a Router Parameter Brief Definition nd_id fl_id up_num dn_num up_id dn_id Router status The router ID, The superflow ID Number of upstream nodes Number of downstream nodes node ID of upstream node node ID of downstream node Suspicious attack or normal traffic Algorithm 2: CAT Subtree Construction in a Single Domain Server Input: Traffic alert messages received from all routers In the same AS domain Output: A data structure describing the CAT subtree constructed in this domain Procedure: 01: Read all suspicious patterns in and arrange them according to router ID 02: Start from the suspicious node with minimum ID R min 03: root R min 04: read the upstream node number up_num 05: read the downstream node number dn_num 06: node_number node_number + up_num : While up_num > 0 08: Read in one upstream node R up 09: Add R up as a leaf node 10: scan through its upstream nodes 11: up_num up_num 1 12: End While 13: While dn_num = 1 14: Read the downstream node R dn ; 15: root R dn 16: node_number node_number : Scan through other upstream nodes of new root; 18: dn_num dn_num of the new root 19: End While The major purpose of sending the flow status message is to report where the suspicious flows are captured. To indicate the location of a suspicious flow, the router identifier has to be sent. It is also mandatory to identify the superflow identifier of the n-bit prefix of the destination IP addresses. To construct the CAT, the status report provides the upstream and downstream router identifiers instead of router I/O port numbers. Since all routers are under the same ISP August 13, 2006 Page 11 of 30

12 authority and work cooperatively, each router knows their immediate neighbors. Using the reported status information, the domain server detects based on the CAT tree constructed. To clarify the control flow, this construction process is specified by a flowchart in Fig. 5. The output of Algorithm 2 is a single-domain CAT subtree similar to the one shown in Fig.3(b). The CAT tree is specified by a hierarchical data structure. The tree starts from the root node, which carries the superflow ID, the number of routers involved, root node ID, and the count of child nodes at the next level. The next level lists the pair of information {L1 node ID, count of children at next level L2}. This process continues until reaching the leave nodes of the tree. The CAT subtree is eventually sent to the CAT server of the destination domain. In Algorithm 2, the domain server constructs the CAT subtree based on collected status reports from the routers. Routers detected no attacks are not involved in the tree construction. Figure 5. Control flow in constructing the CAT subtree specified in Algorithm 2. Starting from the node R min with a minimum ID in Fig.5, the CAT server takes it as the root node. The server scans through upstream child nodes identified by up_id. This descendent search is performed iteratively until the leaf nodes are reached. If there is a downstream router R dn, we take router R dn as the new root and repeat the procedure. Meanwhile, the descendent search procedure is repeated for all upstream routers of root R dn. Then we check the downstream router of R dn and repeat the procedure until the downstream router is out of the domain boundary. August 13, 2006 Page 12 of 30

13 5. Merging CAT Subtrees from Multiple Domains This section describes the extension of the single-domain detection scheme to work on multiple network domains. After presenting the mechanism of cross-domain attack detection, we analyze the complexity of the global CAT tree growth. In addition, we introduce a new protocol that supports inter-domain communications, trust negotiation, and collaborative detection. 5.1 Global CAT Tree Construction at the Victim End In a DDoS flooding attack, the attacker often recruits many zombies distributed over the Internet. The flooding traffic may travel through multiple AS domains before reaching the edge network, where the victim is physically attached. Routers at the upstream domains observe the suspicious traffic flows earlier than routers at the downstream networks. Our DCP detection system was designed to have strong collaborations among all domain servers along the superflow paths. Algorithm 3 specifies the merge of CAT subtrees for detecting DDoS attacks across multiple network domains. Algorithm 3: Global CAT Tree construction and detection decision Input: CAT subtree description from participating domain servers, the server detection threshold θ. Output: The global CAT tree over multiple AS domains. Raise the alert for an imminent DDoS attack. Procedure: 01: Construct the local CAT sub-tree (Algorithm 2) periodically 02: Receiving sub-trees from other CAT servers 03: If local subtree exists, Then Check the superflow ID, 04: If this domain is the destination domain, Then Set distance r = 1 05: Merge subtrees from domains at distance r to the current global tree 06: r r+1 07: While { there are un-checked sub-trees }, generate the CAT profile 08: If CAT profile θ Then DDoS attack is detected and raise an alert 09: Else Check the root router position 10: If root router is connected to other domain 11: Then Sent the global CAT tree to the destination domain server 12: Else Raise an attack alert based on the global tree merged The CAT subtrees constructed at all traversed domains must be merged to yield a global CAT tree at the destination domain. The final declaration of a DDoS attack is the result of threshold detection using the global CAT tree. Not only the victim network launches appropriate countermeasures, but also some traceback actions are to be taken by all attack-transit routers along the superflow paths. The actions include dropping of suspicious packets or rate limiting against the flows. The global CAT tree shows the propagation pattern of flooding attack flows. August 13, 2006 Page 13 of 30

14 The leaf nodes are directly related to the zombies used. The height of the global CAT tree corresponds to the superflow hop count. Some highly distributed attacks may recruit hundreds of zombies, the global CAT tree may cover a wide area on the Internet. Therefore, we use the global CAT tree profile θ as a global detection threshold. The CAT profile indicates how many routers have observed abnormal traffic surges. Thus θ is an integer bounded by the domain size or by the number of ATRs. The tree width and height thus reveal the scope of the DDoS attack. Through experiments on DETER testbed, we obtain the global detection threshold value by training from some attack datasets. Theses threshold values have yielded the highest detection rate and lowest false positive rate during the training period. On receiving subtrees from upstream CAT servers, the CAT server in the destination domain builds the global CAT tree from its local subtree. Once the global CAT tree is formed, the server compares the CAT profile with the global detection threshold θ to decide on a DDoS attack. An alert is raised and necessary countermeasure is triggered, accordingly. Figure 6 shows an example network environment involving 6 AS domains. The victim system is located in the AS1 domain. Zombies are scattered widely in Internet outside the illustrated domains. By detecting abnormal traffic changes in each domain, the CAT server creates a CAT subtree locally at each domain using Algorithm 2. (a) DCD architecture over 6 domains (b) Merging 6 subtrees to yield a global CAT tree Figure 6. An example 6-domain global CAT tree construction environment Figure 6(b) shows three steps taken to merge the 6 subtrees generated by 6 CAT servers of 6 AS domain. All 6 subtrees are resulted from checking the packets belonging to the same superflow traffic destined for the same domain AS1. Five subtrees generated at AS 2, 3, 4, 5, and August 13, 2006 Page 14 of 30

15 6 at upstream domains are sent to AS1 at Step 2. Then, the concatenated CAT subtrees are connected to the downstream subtree at AS1. Thus the global CAT tree is finally rooted at the last hop router to an edge network R0 that is attached to the victim system. 5.2 CAT Tree Growth Complexity Analyses The complexity of the CAT growth is analyzed below based on Internet topology data available from open literature [20], [38]. Figure 7 illustrates the process of the CAT tree growth out of merging subtrees from closer to remote domains. Let r be the logical distance of an AS domain to the destination domain. The server checks the received subtrees in increasing order of distance r. The system merges the subtrees from ASs located in distance r = 1 first to form a partial global tree. Next, it merges the subtrees from domains at distance r = 2. The merging process repeats with distances r = 3, 4, until all subtrees are merged into a large global CAT tree. Figure 7 Merging CAT subtrees from nearby domains to outer domains to build the global CAT tree, where AS 0 is the victim destination domain We analyze below the complexity of global CAT tree growth at intra-domain and interdomain levels. The routers monitor traffic conditions and report anomalies to their domain CAT server, periodically. The local setting parameters α and β affect the size of the local CAT subtrees constructed at routers. Given a domain consisting of N routers, the number of alerts that CAT server receives is proportional to N. The passing-threshold CAT subtrees constructed (Algorithm 2) equal to the number of alerts received by the server. Therefore, the detection time is approximated by O(N) within each domain. Of course, different domain sizes (N) may end up with a variable subtree generation times. At the inter-domain level, the complexity of global CAT tree merging is highly dependent on the network topology. We treat the Internet as an undirected graph G of M nodes August 13, 2006 Page 15 of 30

16 and E edges. The diameter of the graph is denoted as δ. Siganos et al. [38] models the Internet neighborhood as an H-dimensional sphere with a diameter δ. H is the dimension of the network topology [15]. For example, H = 1 for a ring topology and H = 2 for a 2-dimensional mesh. Any two nodes are within the effective diameter, δ ef hops away from each other. Faloutsos estimated δ ef by the following expression: M 2 1 H δ ef = ( ) (8) M + 2E As of Feb. 28, 2002, the dimension of Internet was calculated as H = 5.7 in an average sense. The ceiling of this diameter δ ef is thus set to 6. Let NN(h) be the number of domains located at distance h from a typical domain in the Internet. Table 2 gives the domain distribution the probability of an AS domain residing exactly h hops away from a reference domain, and the exact number of domains in that distance range. Table 2. Internet Neighborhood Distribution based on Report in August 2006 [20] Hop Count, h Domain Distribution, p h 0.04% 8.05% 38.55% 38.12% 12.7% 2.25% 0.29% Domain Count, NN(h) 14 2,818 13,493 13,342 4, Although the actual number of Internet AS domains keeps increasing with respect to time, the Faloutsos reports [15] and [38], indicated that this AS distribution is pretty stable over time. This implies that a packet can reach almost all domains in the Internet by traversing through 6 hops. Therefore, we set the maximum hop count r max = 6 in Fig.7. Let p h be the probability of having AS domain located at distance h from the reference point. Therefore, the average number of domains used to build a global CAT tree is upper bounded by: r T NN ( h) (9) = max h= 1 p h Substituting the entries in Table 2 into Eq.(9), we obtain the expected domain count T = =11,097 domains used in various Internet applications. This domain count posts a loose upper bound on the expected number of ISP domains involved in building the global CAT tree. In reality, only a handful of the ISP-controlled AS domains may commit to defend DDoS attacks, collaboratively. On the conservative side, consider 5% of ISP AS domains are committed to August 13, 2006 Page 16 of 30

17 defend DDoS attacks, collectively. Thus the above upper bound could be reduced to only 168 ISP domains, provided that they all conform to the distribution in Table 2. Furthermore, as long as the partially merged CAT tree profile exceeds the detection threshold θ, the decision process can be ended much earlier. Our DETER experimental results (Section 6) suggest that at most 4 to 8 out of 16 domains will suffice to detect TCP SYN and UDP flooding attacks. Based on these 25% to 50% domain involvement, we find, on the average, that the DCP detection system can scale well to cover T 30.3% 5% (25% to 50%) = 42 to 84 domains in ISP controlled domains. The actual number of AS domains involved could be even fewer, if the whole defense system is built by collaboration among domains controlled by a single ISP or just by a handful of cooperative ISP companies. 5.3 Secure Infrastructure Protocol (SIP) Inspired by the ICMP protocol, we propose a new secure infrastructure protocol (SIP) that enables secure anomaly detection across multiple domains. The ICMP was used as a measure of error control when a network device or host requires reporting an error in datagram processing [36]. The SIP is designed as an integral part of IPv4 standard. The protocol and message formats can be easily extended to apply the proposed IPv6. SIP protocol supports packet scanning, filtering, and flow analysis functions at the router level in each domain. The protocol has three levels of communication as illustrated in Fig.8. Figure 8 Three levels of communication in using the SIP (secure infrastructure protocol) between two CAT servers in two autonomous systems. Three SIP levels support CAT server for trust negotiation and attack analysis. Inside each domain, the routers exchange information and report traffic anomalies detected locally to the domain server. At the inter-domain level, the CAT servers communicate with each other. Besides traffic monitoring, SIP supports many network-layer security functions. For example, the August 13, 2006 Page 17 of 30

18 detection and isolation of worms, DDoS attack detection, or offers support to a distributed intrusion detection systems (IDS) [6], [32]. SIP provides a secure information exchanging mechanism in a layer closer to the physical network. SIP is a lightweight protocol that is suitable for supporting Internet infrastructure security, where network-layer collaborations among the routers are desired. In addition of setting different security policies, ISPs may not want competitors to map on their networks. The available bandwidth limits requestor from joining the defense. The SIP addresses issues at the policy level far beyond authentication, authorization, or channel encryption. We adopted the trust negotiation of multilateral security suggested by Ryutov et al. [37]. Using their Gneric Authorization & Access-control (GAA) interface, SIP can help establish trust among AS domains and enter a collaborative DDoS defense system agreement. 6. Performance Results of DETER Experiments We verify the performance of the newly proposed DCP detection scheme with DDoS attack experiments on the 200-node DETER testbed [4], [12] at USC Information Sciences Institute. The experimental setting and performance results are reported below. 6.1 Experimental Setting on DETER testbed To evaluate the performance of the CAT-based DDoS detection system, we allow variations in network topology, background traffic, and attack generation. We adopt the real-life ISP topologies downloaded from the Rocketfuel Project at University of Washington [2]. We report below the DETER results on up-to-16 collaborative domains. Within each domain, we consider a typical configuration of 7 to 12 routers. Due to the limited nodes in DETER testbed, we choose the smallest ISP configuration topology from the Rocketfuel dataset. For example, 34 routers were simulated over 4 AS domains. The link bandwidth among the network domains was set at 100 MB/s. To generate the background traffic closer to reality, we use the OC48 trace dataset from the CAIDA project [30] to regenerate Internet traces using the Harpoon traffic generator [39]. To generate DDoS attacks, we use the toolkit Stacheldraht V4 [14]. Stacheldraht can generate ICMP and UDP, TCP SYN flooding and Smurf attacks. 6.2 Performance Metrics Used August 13, 2006 Page 18 of 30

19 The performance of our DCP detection scheme is evaluated with three metrics: detection rate, false-positive alarms, and system overhead. All metrics are measured under different attacks using TCP, UDP, and ICMP protocols. The detection accuracy is measured in three ways: the detection rate R d, is defined by: R d = a / n (10) where a is the number of DDoS attacks detected by our DCP system and n is the total number of attacks generated by the toolkit Stacheldraht during experimentation. Now consider the experiments on regular traffic containing no DDoS attacks. Let p be the total number of alerts raised by the CAT server out of m CAT trees constructed for normal traffic without any attacks during one monitory window. The false-positive rate is defined by: R fp = p / m (11) The ROC (receiver operating characteristic) curve shows the tradeoff between the detection rate and false-positive rate. Section 6.4 reports the detection accuracy measured under different detection thresholds. Another critical issue is the time overhead to detect the launch of DDoS attacks. The average detection time τ measures from the start of a DDoS attack to the time to raise the attack alarm. The monitory window should be greater than this detection time. 6.3 DETER Experimental Results To evaluate the effectiveness of the DCP detection scheme, we report the alerts raised at routers and analyze the CAT subtree properties. The DETER experiments choose the inertia factor α in the range (0.1, 0.5) and the router detection threshold β in the range (2, 5). A. Alert Magnitude vs. Router Threshold used We reveal the effects of choosing different values of the inertia factor α and router threshold β on the DCP system design. We used 34 routers divided into 4 ASs in the DETER testbed. When the traffic flow exceeds the router threshold β, the router raises the alerts. Otherwise, no alert is raised, if no anomaly is detected at router ports. Figure 9 compares the total numbers of alerts raised by the routers with SYN flooding compared with the cases of no attacks. More alerts are raised with attacks, compared with the cases of no attacks. The two left bars in Fig.9 in each group correspond to heavy-dependence on the past average traffic. Under attacks, the leftmost bars stay around 20 alerts, rather insensitive to August 13, 2006 Page 19 of 30

20 increasing threshold β. Without attacks, the second (gray) bars reduce from 12 to 5 alerts as β increases. This implies that β = 3.5 is a good choice to distinguish attacks from no attacks, when α is chosen as low as 0.1. The two right bars (fabric vs. black) are associated with the aggressive choice of a high inertia factor α = 0.3. The fabric bars with attacks are much higher than the black bars without attacks. For α 0.3 and β 3.5, the alert bars reduce to zero, meaning attacks and no attacks are no longer distinguishable. Figure 9. Total alerts raised plotted against the router threshold applied on 34 routers in 4 AS domains using a 500 ms monitory window B. The Global CAT Profiles Figure 10 plots the global CAT tree profile in terms of the number of ATRs involved. On the average, there are 20 router nodes (alerts) in the CAT subtree raised by actual attacks, compared with fewer than 5 nodes in the tree triggered by regular traffic without attacks. These results suggest an optimal router threshold β 3.5, when the inertia ratio α is chosen as low as 0.1. With 20 routers involved out of 34 routers available, the router utilization is 20/34 = 58%. Figure 10. Variations of the global CAT size over 4 AS domains in 500 ms monitory window August 13, 2006 Page 20 of 30

21 C. Effects of Monitory Window Size We report in Fig.11 the influence of monitoring window size on the total number of alerts raised in 4 AS domains. We find the optimal monitoring window size w to be 100 ms in DETER experiments. Figure 11 shows that 22 alerts are raised with attacks, compared with only 3 alerts (false alarms) from no attacks. The false positive alarms increase steadily with increasing window size. However, the number of 22 raised alerts from real SYN attacks stays about the same level for all window sizes monitored. Figure 11. The router alerts detected with and without DDoS attacks plotted against the monitoring window size We study below the detection accuracy of the DCP scheme under TCP SYN, UDP, and ICMP attacks with different packet rates. The reported results correspond to α = 0.1, β = 2.0, and w = 500 ms. In Stacheldraht [14], the UDP and ICMP packet rate for each individual zombie is adjustable through setting different UDP and ICMP packet sizes. The longer is the packet length, the lower is the packet rate. The TCP SYN attacks use fixed packet size of 64 bytes with a fixed packet rate. The maximum UDP and ICMP packet size is limited to 1024 bytes in Stacheldraht. We observed similar detection rate for TCP SYN and UDP/ICMP attacks with 128-byte packets. 6.4 Detection Accuracy vs. False-Positive Alarms The accuracy is reflected by having higher detection rate. The False positive alarms should be maintained as low as possible. Tradeoffs exist between these two measures. A. Detection Rate of DDoS Attacks Figure 12 plots the variances of the detection rate (Eq.7) with respect to different server detection threshold θ applied. The TCP SYN attack has the highest detection rate close to 100% August 13, 2006 Page 21 of 30

22 for θ 12. The low-rate UDP attacks have lower detection rate than that of TCP attacks. For UDP attacks have 512-byte packets, the detection rate can be kept above 80% with θ 9. As the packet size increases to 1024 bytes, the detection rate drops to zero when θ 7. These results suggest that in order to maintain high detection rate on TCP and UDP SYN attacks, we need to make θ rather low, such as θ = 5 and maximize the packet size to 1024 bytes. Figure 12. Effects of server threshold on the detection rate of 3 DDoS attack types. B. False-Positive Alarms Figure 13 plots the false positive alarm rate against the CAT server threshold θ. The CAT incurred by random fluctuation in normal traffic is much smaller. With a server detection threshold θ = 4, the false positive rate drops to less than 1%. However, the real challenge lies in the fact that highly distributed attacks may use low packet rates to escape from being detected [40]. Only after sufficient attack flows are merged, the deviation is detected by the routers. Hence, a lower threshold is mandatory to make the detection accuracy high with very low false positive rate as revealed in Fig.13. Figure 13. Effects of threshold on false-positive rate in detecting TCP SYN attacks C. The ROC Curve The ROC curve shown in Fig.14 reveals the tradeoffs between the detection rate and false positive rate under different attack types. Our DCP detection scheme achieves a detection rate as August 13, 2006 Page 22 of 30

23 high as 99% with less than 1% of false positive rate for high-rate DDoS attacks. All three curves in Fig.14 support this claimed advantage. Even for low-rate UDP attacks, our choice of low CAT threshold θ maintains a detection rate of 91% at a false-positive rate of 23%. This result proves the effectiveness of the DCP detection system. Figure 14. ROC curve showing the tradeoff between detection rate and false-positive rate 7. Scalability Analysis and Limitations The complexity of DDoS attack patterns keeps growing as new vulnerabilities and more sophisticated attack tools appear. To deploy a distributed security scheme in ISP core networks, the scalability is often related to the network size, domain number, data rate, link capacity, or router number involved. This section studies the scalability of the DCP scheme in terms of detection performance and system overhead experienced. Then we discuss flash crowd, security holes, and limitations of the DCP system. 7.1 Domain Scalability Analysis One advantage of cross-domain DDoS attack detection is its enlarged coverage area. For a small AS domain, it is rather difficult to distinguish normal traffic fluctuations from malicious flooding traffic. This is due to inadequate alert information collected locally. We have to use the CAT subtrees constructed by upstream domains to assess the earlier impact of the superflow traffic caused by the DDoS attack. Even before the target network is overwhelmed, an early warning could be raised. Through experiments on DETER testbed, we studied the effectiveness of cross-domain cooperation up to 16 AS domains. Figure 15 plots the detection rates of three DDoS attack types August 13, 2006 Page 23 of 30

24 against the number of domains involved. The detection rate becomes saturated after sufficient number of AS domains are involved. The results are obtained under the system settings: α = 0.1, β = 2.0, w = 500 ms, and θ = 5. Recall, we assumes 8 to 10 routers per domain in the DETER experiments. With a small AS domain containing 8 routers, θ = 5 implies that more than half of the routers are generating alerts as attack transits on the superflow path. Figure 15. Scalability of the distributed change-point detection system over increasing number of AS domains For 64-byte TCP SYN and UDP attacks, the optimal domain number is 4. For UDP 512- byte packets, the detection rate saturates at 8 domains. For UDP 1024-byte packets, again 4 AS domains would be sufficient. This implies only 25% (4/16) to 50% (8/16) of the participating domains would be sufficient to detect the DDoS attacks. With this proportion, we have assessed in section 5.2 the scalability of the DCP system to cover 42 to 84 ISP-controlled AS domains in fighting the TCP SYN and UDP flooding attacks, collectively. These numbers are manageable in real-life deployment of DCP system, considering the added monitoring burden of the routers and the role of the CAT server employed in each domain. 7.2 Other Options and Implementation Limitations It is a big challenge to discriminate DDoS attacks from fluctuation of legitimate traffic patterns, called flash events [7], [22]. When flash crowd happens, the CAT server creates a similar tree and could raise a false alarm. We suggest adding a few new features to separate the real DDoS attack traffic from the flash crowd. The idea is to check newly appeared source IP addresses. For each superflow, in addition to traffic volume, we need to monitor the distribution of source IP addresses. More new source IP addresses will appear in DDoS attacks than that in a August 13, 2006 Page 24 of 30