Embed Size (px)
Citation preview
CICADAS: Congesting the Internet with Coordinated AndDecentralized Pulsating Attacks
Yu-Ming keNational Taiwan University
Chih-Wei ChenNational Taiwan University
Hsu-Chun HsiaoNational Taiwan University
Adrian PerrigETH Zurich
Vyas SekarCarnegie Mellon University
ABSTRACT
This study stems from the premise that we need to breakaway from the“reactive”cycle of developing defenses againstnew DDoS attacks (e.g., amplification) by proactively inves-tigating the potential for new types of DDoS attacks. Ourspecific focus is on pulsating attacks, a particularly debili-tating type that has been hypothesized in the literature. Ina pulsating attack, bots coordinate to generate intermittentpulses at target links to significantly reduce the throughputof TCP connections traversing the target. With pulsatingattacks, attackers can cause significantly greater damage tolegitimate users than traditional link flooding attacks. Todate, however, pulsating attacks have been either deemedineffective or easily defendable for two reasons: (1) they re-quire a central coordinator and can thus be tracked; and (2)they require tight synchronization of pulses, which is difficulteven in normal non-congestion scenarios.This paper argues that, in fact, the perceived drawbacks
of pulsating attacks are in fact not fundamental. We developa practical pulsating attack called CICADAS using two keyideas: using both (1) congestion as an implicit signal for de-centralized implementation, and (2) a Kalman-filter-basedapproach to achieve tight synchronization. We validate CI-CADAS using simulations and wide-area experiments. Wealso discuss possible countermeasures against this attack.
Keywords
DDoS attack; pulsating attack; distributed and decentral-ized coordination; Kalman filter
1. INTRODUCTIONDistributed Denial-of-Service (DDoS) attacks continue to
be a major threat and have been evolving in both scale andsophistication [1]. As such, the defense community has beenconstantly playing “catch up”with attackers in this rapidly-changing attack landscape; e.g., in the last two to threeyears alone, new vectors like traffic amplification, the useof IoT devices as bots, and the targeting of core links have
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from [email protected].
ASIA CCS ’16, May 30-June 03, 2016, Xi’an, China
c© 2016 Copyright held by the owner/author(s). Publication rights licensed to ACM.ISBN 978-1-4503-4233-9/16/05. . . $15.00
DOI: http://dx.doi.org/10.1145/2897845.2897866
emerged [2,12,26]. Our work stems from the premise that tobreak out of this “catch up” game, it behooves the researchcommunity to proactively explore novel DDoS attacks thatare stealthier and more destructive than ever before.
In this paper, we specifically focus on a class of DoS/DDoSattacks referred to as pulsating attacks [9, 14, 17, 25]. Theseattacks target specific Internet links and can be more harm-ful than simple brute-force flooding, because they can ef-fectively suppress legitimate flows by sending only intermit-tent bursts. For example, a series of carefully-crafted peri-odic pulses on a network link can deceive TCP flows overthe same link to infer an extended period of congestion,thus forcing legitimate flows to repeatedly enter the time-out state.
To date, however, large-scale pulsating DDoS attacks havebeen mostly considered an academic curiosity because of twoperceived limitations that either render the attack imprac-tical or enable simple defenses:
• Centralized coordination. The adversary has to coor-dinate distributed bots such that their traffic streams addup to the desired waveform that resembles intermittenthigh-volume bursts at the target link, as Figure 1 illus-trates. Prior work requires central coordination [8,24,34]and thus sacrifices resiliency and stealth, as this coordi-nator becomes a single point of failure for the attack.
• Inaccurate delay estimation. To produce the desiredpulsating waveform, bots need to coordinate with eachother so that their attack packets arrive at the target syn-chronously. Unfortunately, synchronizing clocks of hun-dreds of thousands of bots is difficult in a wide-area set-ting. To make matters worse, time synchronization itselfis insufficient because the main challenge here is estimat-ing the delay from each bot to the target link. Priorwork assumes the delays remain unchanged throughoutthe course of an attack and estimates the delay values viaa one-time measurement at the beginning of an attack.Due to the dynamic nature of Internet traffic, especiallyduring attacks, bots fail to synchronize when relying onone-time measurements or even periodic measurements ina naıve way (see wide-area experiments in § 5).
This paper indicates that it is possible to achieve decen-tralized pulsating attacks that are resilient to the delay vari-ability introduced during attacks. Our proposed DDoS at-tack coordination mechanism, called CICADAS, builds ontwo key ideas.
• Using congestion as an implicit coordination signal: Tosynchronize bots without a central controller, we propose
1
that bots use instants of congestion at the target link as acommunication signal to synchronize among themselves.Using congestion for covert communication has two ad-vantages. First, the signal can be observed by every bot.Second, because the same signal is critical to importantnetworking protocols such as TCP congestion avoidance,defenses that attempt to interfere with the signal are ren-dered inapplicable.
• Control-theoretic approach for accurate delay estimation:To compensate for the delay variations to the target link,we design a feedback-based attack stream regulation algo-rithm that dynamically adjusts the phase and magnitudeof each attack stream based on previous RTT measure-ments (i.e. the feedback). Applying a control theoryconcept, the algorithm can accurately estimate the at-tack sending time such that bots collectively generate adesired waveform at the target link.
Using simulations and real-world experiments, we con-firm that CICADAS can successfully implement a decen-tralized pulsating attack. Particularly, our Internet-wideexperiments show that with n bots and each bot sending200ms-length and r-magnitude bursts, it can reliably gener-ate 145ms-length and 0.9nr-magnitude bursts on the targetlink with high probability, and the normalized throughputof the co-existing TCP flows is reduced to 0.3. In contrast,bots fail to synchronize when relying on one-time measure-ments. When using periodic measurements in a naıve way,bots are sensitive to delay variations and can only gener-ate 60ms-length and 0.9nr-magnitude bursts. We explorepotential countermeasures to CICADAS in § 6.This paper makes the following contributions:
• Highlighting the challenges of achieving decentralized pul-sating attacks on the Internet.
• Designing a novel decentralized coordination method thatuses congestion as a signal for implicit communicationamong bots, such that no centralized controller is needed.
• Adopting a control-theoretic framework that allows a botto accurately compensate for delay variations by dynam-ically adjusting the phase and magnitude of its attackstream.
• Evaluating the practicability of CICADAS using bothsimulations and Internet-wide experiments. The resultsconfirm that CICADAS can successfully synchronize botswith high probability, whereas other approaches may beunstable or fail to synchronize.
2. BACKGROUNDIn this section, we review 1) pulsating DoS attacks and
2) pulsating DDoS attacks using a central controller. Wethen discuss the challenges of executing pulsating attacks ina distributed and decentralized fashion.We use the term pulsating attack to describe a class of
(D)DoS attacks that send only intermittent bursts insteadof flooding. They typically exploit network protocol specifi-cations and thus can effectively reduce the availability of thevictim service. As opposed to direct flooding, the pulsatingattack is stealthy and destructive due to the low averagesending rate and high damage-to-cost ratio.
T
R
+d3
d1
d2
L
= ?
Desired waveform on target linkDistributed attack str eams
Figure 1: An illustration of distributed pulsatingattacks. The desired waveform consists of periodichigh-volume bursts of period T , burst length L, andburst magnitude R. Before the attack streams arriveat the target link, they experience dynamic delays(i.e., d1, d2 and d3) introduced by network elements.
Pulsating DoS. The Shrew attack [14] is an attack thattargets TCP and exploits the homogeneity of the minimumRetransmission Time Out (minRTO) in TCP. At a highlevel, the Shrew attack aims to cause short-term link conges-tion whenever legitimate TCP flows retransmit, which de-ludes them into inferring an extended period of congestion,cutting their sending rates down to almost zero. Because ofthe homogeneity of minRTO, which implies that flows ex-periencing simultaneous packet loss would likely retransmitat the same time, Shrew attacks can cause severe damageby sending a carefully crafted rectangular-wave DoS streamwhose period approximates the minRTO (e.g., one second)and duration approximates the maximum Round-Trip Timeof victim flows (e.g., 200 milliseconds). Worse yet, the an-alytical result of the Shrew attack shows that randomizingthe minRTO parameter cannot fully mitigate this attack.
The RoQ attack [9] aims to degrade system performancerather than completely disable the service (the latter typ-ically being the goal of DoS), and its effectiveness can beevaluated by the ratio between damage and cost. The RoQattack can be implemented in a similar way to the Shrewattack: the attacker directs a periodic waveform to a tar-get link in order to destabilize the adaptation process ofthe system, thereby preventing the system from converg-ing to a stable state where performance is usually opti-mized. One well-known adaptive protocol is the Additive-Increase-Multiplicative-Decrease (AIMD) algorithm used inTCP congestion avoidance. The difference between theShrew and RoQ attacks is that the Shrew attack exploitsthe timeout mechanism of TCP and aims to cause thoroughdenial of service, while the RoQ attack does not target aspecific mechanism or protocol and degrades system perfor-mance by maximizing the ratio between damage and cost.
Pulsating DDoS using a centralized controller.Several works propose using a centralized controller to syn-chronize distributed attacks. Guirguis et al. [8] presenteda distributed RoQ attack that obtains an unfair share ofbandwidth on a target link. However, they assume a con-troller for DDoS coordination without specifying many de-tails. Zhang et al. [34] studied the possibility of disruptingBGP with pulsating attacks. In their distributed version,bots are required to synchronize with a centralized controllerthat can observe all attack paths and is close to the targetlink, so as to reduce the impact of delay variance on timesynchronization. Before the attack starts, each bot sends atimestamped packet to the controller, which then instructsthe bots when to start the attack based on the time differ-ence. However, it is difficult to accurately predict dynamic
2
delays based on one sampled time difference, especially whenthe delay variance increases dramatically during attacks.
Challenges of distributed and decentralized pulsat-ing attacks. It is natural to extend pulsating attacks toa distributed and decentralized setting, where multiple botmachines collectively create the periodic attack waveformwithout central controllers. A distributed pulsating attackis more lethal than its predecessor because it is capable ofachieving a higher peak rate, thus making it possible to tar-get high-capacity backbone links. A decentralized pulsatingattack is more robust against takedown operations target-ing the command and control servers. However, as men-tioned above, one critical research challenge of constructingthis type of pulsating attack is coordinating distributed botssuch that their traffic streams can add up to the target wave-form resembling intermittent high-volume bursts at the tar-get link. While the adversary could attempt to synchronizethe clocks of all bots and predict the delay from each bot tothe target link, the delays are difficult to predict accuratelydue to the dynamic nature of Internet traffic.
3. CICADAS ATTACK OVERVIEWIn this section, we provide a high-level workflow of the
CICADAS attack and highlight the key technical challenges.Before this, we formally specify the adversary’s goals.
3.1 Goals and RequirementsWe envision an intelligent adversary that wants to cause
network congestion at a specific network link by inducing apulsating traffic volume waveform on this link. We assumethat the adversary has chosen the link through out-of-bandmechanisms and through a combination of Internet topologymaps [10–12].1 As such, our focus in this paper is on thepulsating mechanism rather than the target selection.The goal of the attack is to orchestrate n bots to synthe-
size a traffic stream of period T , burst length L, and burstmagnitude R at the target link, as shown on the right handside of Figure 1. Typical values are T = minRTO = 1second, L ≈ maxRTT = 200 ms, and R is slightly higherthan the capacity of the target link to overflow the routerqueues [14].As discussed earlier, there are two high-level requirements
for the attack to be effective in practice. It should (1) re-quire no central coordination point, and (2) achieve tightcoordination despite high network delay variations.
3.2 CICADAS IntuitionThe first-order goal of CICADAS is to coordinate the be-
havior of the bots in a decentralized manner and with min-imal assumptions on the Internet status, such as delay vari-ances. Here, the key insight behind CICADAS is that con-gestion at the target link can itself act as a“signal flare” thatevery bot can observe (e.g., through packet loss and delay)and synchronize with. Specifically, each bot infers the extentof congestion based on the variations in observed latency.Based on this insight, CICADAS can be viewed as a
1One potential concern is early congestion, when the attacktraffic congests a non-target link before reaching the tar-get link. We assume that the adversary can avoid this onthe chosen link via out-of-band bandwidth estimation tech-niques [10], similar to prior work [12].
Send Probe Packets
Estimate Instants of
Congestion
Probe req
Probe reply
Instants of Congestion
Traffic on
target link
Noise
Congestion Detector(if STATE = LURK or ATTACK)
Attack Generator(if STATE = ATTACK)
Basic Random TCP
embedding
Attack flow
Figure 2: CICADAS adjusts the attack streambased on the estimated instants of congestion, whichis inferred from RTT measurements.
feedback-based attack stream regulator installed on each bot,as Figure 2 illustrates:
• Congestion Detector estimates instants of conges-tion at the target link based on observed RTTs.
• Attack Generator uses these estimations to regulatethe attack stream, so that distributed attack streamscan aggregate to periodic pulses at the target link with-out the help of a centralized online controller.
3.3 CICADAS WorkflowGiven the insight above, we will describe the end-to-end
workflow of CICADAS that has three conceptual stages:BOOTSTRAP, LURK, and ATTACK (Figure 3). That is,the CICADAS feedback loop can be intuitively viewed as astate machine that transitions between these three states.We describe the bot actions in each state below.
BOOTSTRAP In the BOOTSTRAP phase, each botreceives attack parameters, including the target link andtarget waveform (i.e., attack period, burst length, and burstmagnitude). For instance, this bootstrapping may happenas part of the bot recruitment phase or other kinds of mal-ware payload distribution schemes. At the end of this phase,the bot is not required to send any traffic. The bots maymove to the LURK state (see below) at a predeterminedtime or when the estimated size of the botnet has passed athreshold [13,19]. Note that bots can enter the LURK stateat different times; no time synchronization is needed.
LURK A bot in the LURK state stealthily monitors thetarget link via periodic Round-Trip Time (RTT) probing.Once congestion is sensed (e.g., high RTT is observed withhigh confidence), the bot switches to the ATTACK state.That is, each bot considers the first congestion at the targetlink as a signal for activating the attack stream. It is possi-ble that legitimate/transient congestion at a non-target linkfalsely triggers a subset of the bots. CICADAS is designedto be resilient to such congestion. We will discuss this casein detail in § 6.
ATTACK During the ATTACK state, a bot starts send-ing pulses that it hopes will contribute to periodic conges-tion at the target link. In addition, the bot adjusts the phaseand magnitude of the next pulse based on the observationsof past congestion so as to improve the level of coordination
3
BOOTSTRAP LURK ATTACK
attack failed
Congestion
detected
Begin during a
pre-configured
time period
Reset
Figure 3: CICADAS’s state machine view.
between bots and increase the severity of congestion at thetarget link. If a sufficient number of bots are triggered by thesame congestion, the target link is anticipated to start peri-odically experiencing severe attack-induced congestion with-out any further legitimate congestion, as legitimate flows arethrottled by the attack. If the attack coordination fails (i.e.,there is a lack of severe congestion for an extended periodof time), then the bot returns to the LURK state.
3.4 Practical ChallengesGiven this high-level workflow, two key challenges remain
to making CICADAS practical. They are addressed in § 4.
1. How can we obtain a reliable feedback signal to detectinstants of congestion at the target link with stealthyprobe packets? Sending Ping packets at a high ratewill raise suspicion.
2. How can we adjust an attack stream to improve co-ordination among bots? In particular, the challengeis eliminating noises introduced by dynamic networkdelays, the sampling of congestion signal, etc., and thenoise filter should be able to learn from past observa-tions to improve the results.
4. DETAILED ATTACK DESIGNAs depicted in Figure 2, CICADAS’s control loop consists
of two main modules: Congestion Detector (activated in theLURK and ATTACK phases) and Attack Stream Generator(activated in the ATTACK phase).
4.1 Limitations of Strawman ApproachesWe present two strawman approaches to Congestion De-
tector. The impracticality of these approaches motivate ourdesign using a control-theoretic approach for accurate con-gestion estimation.
Strawman: Estimate the sending time based on aone-time measurement at the beginning, and thensimply send the attack bursts every T slots. Attacksynchronization is likely to fail in this case because first, ifthe one-time measurement is inaccurate, there is no way tocorrect it later; second, even if the one-time measurement isvery accurate at that moment, network delays can changeover time (especially during attacks), and therefore there isno guarantee that the attack bursts can still arrive at thesame time later.
Strawman: Send probe packets periodically but onlyuse the latest measurement for estimation. Eachbot sends an attack burst at Tc + T , where Tc is the timeat which the latest congestion is observed. This approach isbetter than the first, but is sensitive to noise (mainly due todynamic delays). Thus, bots take a longer time to convergeand may be more unstable than in our scheme.
Essentially, we desire a filter to remove noise introducedby network delays and sampling errors, and the filter’s ca-pability should improve as measurements are collected, sothat the degree of bot coordination can be improved pro-gressively. Feedback-based control loops can achieve thisby taking past measurements into account for estimation,and the Kalman filter is example of this. Our evaluation(presented in § 5) confirms that using the Kalman filter sig-nificantly outperforms the above two strawman approaches.
4.2 Congestion DetectorThe congestion detector, as illustrated in Figure 2, per-
forms two tasks: sending probe packets to monitor conges-tion on the target link, and estimating when congestion oc-curs at the target link based on the probe packets.
Sending probes Each bot sends probe packets to thedestination at a frequency higher than 1
L, where L is the
burst length (e.g., 200ms). This ensures that any congestionlasting longer than L can be sensed. Alternatively, the botcan send out each probe probabilistically, such that with ahigh probability, more than a threshold number of bots willsense the same burst. To improve stealthiness, CICADASuses custom probe packets that are sent only between bots.Such probe packets are indistinguishable and consume a neg-ligible amount of bandwidth (e.g., about 2.2 KB/s, whenthe probe packet size is 44 Bytes and probes are sent every20 ms), and thus will likely stay under the radar withoutcausing any alarm.
If the coordination succeeds, we expect to see periodicpulses (approximately every T units of time) in the RTTmeasurements. These measurements are smoothed out us-ing statistical methods such as a simple moving average com-puted over the past few RTT samples.
Predicting next congestion event Taking the RTTmeasurements as the input, we now explain how to identifythe instants of congestion. More specifically, we would liketo know when the kth congestion occurs at the target link.
z(k) denotes the observation of the kth congestion andx(k) denotes the true state of the kth congestion. We firstdescribe how to obtain z(k) based on the probing results,and then formalize the relationship between z(k) and x(k),so that we can approximate x(k) based on the observed z(k).
Obtaining z(k): To obtain z(k), CICADAS focuses ondetecting the beginning (called the on-edge) and the end(called the off-edge) of each congestion event.
Let OnEdge(i), OffEdge(i), and Cong(i) denote the in-dicators of probe i’s correspondence to on-edge, off-edge, andcongestion, respectively. Intuitively, an on-edge is detectedby probe i if the ith RTT value is higher than a thresholdThon and probe i − 1 did not experience congestion. Anoff-edge is detected if the ith RTT value is lower or equal toanother threshold Thoff and probe i − 1 experienced con-gestion. Probes between a consecutive on-edge and off-edgethus correspond to congestion, as illustrated by Figure 4.Formally,
OnEdge(i) = ¬Cong(i− 1) ∧ (rtt(i) > Thon) (1)
OffEdge(i) = Cong(i− 1) ∧ (rtt(i) ≤ Thoff )
Cong(i) = (Cong(i− 1) ∧ ¬OffEdge(i)) ∨OnEdge(i)
For example, the threshold values can be set such thatThon = Thoff = RTT . Since we expect to see the du-
4
Time
RTT
avgRTT
OnEdge OffEdge
Cong
Figure 4: An example of on-edge and off-edge.
ration of malicious congestion to be approximately L, thecongestion detector removes inadequately long congestion,e.g., < L/2, after being triggered. If multiple congestionevents are observed within T , the detector keeps only themost “powerful” congestion, where the power is quantifiedby the average RTT during the period of congestion.After the removal, the instant of the kth congestion, z(k),
is set to the sending time of the probe packet thatcorresponds to the kth on-edge. Next, we use the Kalmanfilter to eliminate network noises embedding in the observedstate of congestion z(k); the true state of congestion x(k)can then be estimated by z(k).Approximating x(k) from z(k) using Kalman filter:
Since we know that the target link will be congested approx-imately every T units of time when the attack succeeds, wecan model x(k) as a linear dynamical system:
x(k) = x(k − 1) + T + v(k) (2)
z(k) = x(k) + w(k),
where v(k) is the process noise (i.e., the noise introducedby imperfect synchronization in our case) and w(k) is theobservation noise (i.e., noise due to delay variation).This basic linear model provides us with a solid founda-
tion to solve this congestion prediction problem. Althoughthis formulation may be too simplified to capture the com-plex interactions between the network and bots, using sim-ulations and Internet-wide experiments, we show that thisbasic model performs well for the purpose of coordinatingattack streams. Given the model of the system, the Kalmanfilter performs the prediction and update recursively for eachnew observation.Let x(k|k′) be the estimate of x(k) given observations
z(k′), z(k′ − 1), · · · , z(0). Further, let P (k|k′) quantify theaccuracy of the estimate x(k|k′):
x(k|k − 1) = x(k − 1|k − 1) + T (3)
P (k|k − 1) = P (k − 1|k − 1) + V (k),
and the bot updates x and P for each new observation z(k):
x(k|k) = x(k|k − 1) +Kg(k)(z(k)− x(k|k − 1)) (4)
Kg(k) =P (k|k − 1)
P (k|k − 1) +W (k)
P (k|k) = (1−Kg(k))P (k|k − 1),
where Kg(k) is called the Kalman gain, and V (k) and W (k)are the covariances of v(k) and w(k), respectively. In prac-tice, we can estimate the covariances using advanced tools,such as Autocovariance Least-Squares, or by calculating thevariance of RTT via probing. The Kalman gain controls howmuch we should trust the new observation over the current
estimate. Hence, the new estimate, x(k|k), is a weightedsum (determined by the Kalman gain) of the new observa-tion and the current estimate.
In summary, using the Kalman filter, each bot predictswhen the kth congestion will occur and sends a burst duringthe predicted instants of congestion, i.e., during intervals
[x(k|k − 1), x(k|k − 1) + L). (5)
4.3 Attack Stream GenerationThere are many ways to combine n individual flows into
the desired waveform. For example, there are three possiblemethods for generating individual attack streams: Basic,Random, and TCP Embedding. The latter two can be usedto enhance the stealthiness of the attack.
Basic In the Basic method, each bot contributes a pulse ofduration L and magnitude R/n to the predicated congestioninterval derived in Eq. 5. This can be easily generalizedto cases where each bot sends bursts of duration L/∆ andmagnitude ∆·R
n.
Random The periodic nature of the pulsating attack sug-gests defense in the frequency domain [6, 17]. Althoughsuch approaches are often resource-intensive and it is unclearwhether they can be applied to detect individual pulsatingflows, the CICADAS adversary may still desire to obscurethe periodic patterns for increased stealthiness.
The Random method probabilistically schedules a burstfor each predicted congestion interval (Eq. 5), such that theexpected value of the instantaneous rate at any point dur-ing an on-phase is R+ǫ
n, where R is the magnitude of bursts
at the target link, and n is the number of attack streams.The value of ǫ is set to ensure that the instantaneous rateof n attack streams is higher than R with high probabil-ity. The details of the parameter selection can be found inAppendix A.1.
TCP embedding So far, we have described how to at-tack using unresponsive flows (e.g., UDP) that do not re-spond to congestion. Here, we present a novel techniquecalled TCP Embedding, which allows bots to attack a tar-get link and obtain an unfair share of bandwidth using re-sponsive flows (e.g., TCP). This method not only enhancesthe stealthiness of CICADAS but also allows CICADAS tocarry on the attack even when the TCP and UDP flows aresegregated.
A flow is responsive if it faithfully adjusts its sending rateaccording to the TCP congestion control algorithm. Sincebots know roughly when a link will be unobstructed (i.e.,during the off-phases), the idea behind leveraging responsiveTCP flows is that they can reliably increase the sendingrates by sending packets during off-phases. In doing so, theresulting attack flow will be indistinguishable from a long-lived TCP flow that gradually increases its sending rate andhappens to send traffic bursts during severe congestion fromtime to time. The details of how to construct such attackstreams are presented in Appendix A.2
5. EXPERIMENTTo examine whether CICADAS can successfully orches-
trate a distributed pulsating attack without a centralizedcontroller, we conduct extensive experiments on both theInternet and the ns-3 simulation platform.
5
5.1 Evaluation MetricsWe consider three metrics for quantifying the effectiveness
of a distributed pulsating attack.
Differential Time of Arrival A majority of attackpackets arriving at the target link within a short time win-dow is a direct indicator of synchronization. Formally, wedefine the Differential Time of Arrival (∆TOA) as:
∆TOA(m,α) = min1≤k≤n
[Tm(k + αn)− Tm(k)] (6)
where Tm(k) is the arrival time of the kth bot (in temporalorder) in the mth period, α is a parameter quantifying “ma-jority”, and n is the number of attack streams. For instance,∆TOA(m, 75%) = 0.1s means that at the mth period, 75%of attack streams are arriving within 0.1 seconds. (The ar-rival time of an attack stream in the mth period is definedas the arrival time of the first packet in an attack streamwithin this period.) Thus, a smaller ∆TOA value implies amore tightly synchronized attack.
Closeness of Synchronization The closeness of syn-chronization is defined as the average ∆TOA(m,α) over con-secutive time periods in one run:
closeness of sync(m1,m2) =
m2∑
i=m1
∆TOA(i, α)
m2 −m1, (7)
where m1 and m2 specify a given range. To focus on thesteady state behavior, we will set m1 to larger than 0 in ourevaluation.
Normalized Throughput Apart from the synchroniza-tion of attack streams, the destructiveness of DDoS attackscan also be evaluated by the normalized throughput of co-existing legitimate flows.
5.2 Internet-wide ExperimentsTo show the feasibility of CICADAS in realistic settings,
we conduct Internet-wide experiments using 64 geographi-cally distributed machines, as summarized in Figure 5.
Oregon: 4
San Francisco: 2Fremont: 4
California: 4Dallas: 2Atlanta: 4
Virginia: 4
Newark, NJ: 4New York: 2
São Paulo: 2
Ireland: 4
London: 4
Amsterdam: 2
Frankfurt: 6
Singapore: 8
Sydney: 4
Tokyo: 4
Target
Figure 5: The locations and the number of machinesused in our experiments.
Methodology We carefully design our experiments suchthat we can evaluate our DDoS coordination mechanismwithout affecting other services or inadvertently triggeringthe alarms of existing detection systems.The bot machines reside in several cloud infrastructures,
including Amazon EC2, DigitalOcean and Linode. Such aplacement not only ensures that the inter-bot traffic canexperience realistic delays, but also reduces the impact onindividual cloud platforms. Each machine is either a bot-
sender or a bot-receiver, and sends packets to each other ata very low rate to avoid flooding the Internet.
For monitoring ease, the target link is represented by alocal machine under our control that performs three tasks:
• Forwarding packets between bot-senders and bot-receivers. Bot-senders and bot-receivers exchangepackets via the target link, and NAT (Network AddressTranslation) is set on our machine for forwarding.
• Monitoring packets for deriving metrics of interest.
• Limiting the bandwidth of the target link such thatbots can saturate the target link without disturbingother co-existing flows on the path. We use tc (trafficcontrol) to constrain the bandwidth on the target.
In our experiments, each bot spends the first 10 secondsestablishing a baseline of RTT before sending attack pack-ets, and stops at 200s. The probing rate is 3KB/s and anattack burst is 20KB for each bot.
5.3 Results of Internet ExperimentsFirst, one experiment instance is used to show how
well the attack streams synchronize. Figure 6 illustratesthe differential time of arrival ∆TOA(m,α) for one exper-iment when α is 75% and 90%. This result shows thatattack streams are synchronized after about 25 seconds.∆TOA(m, 75%) is less than 40ms and ∆TOA(m, 90%) is lessthan 60ms for most of the time periods. This indicatesthat the burst generated at the target link is about 160ms(= 200−40) in length and 75% of the maximum attack ratein magnitude; it can also be seen as 140ms (= 200 − 60) inlength and 90% of the maximum attack rate in magnitude.
0 50 100 150 200 2500
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2
Time (sec)
Diff
eren
ce o
f arr
ival
of a
ttack
ing
pack
ets
(sec
)
90% pairs of bots75% pairs of bots
Figure 6: Differential time of arrival in one run.
We then investigate whether CICADAS can successfullycoordinate bots with high probability. Figure 7 illustratesthe cumulative distribution vs. the closeness of synchroniza-tion for 100 experiment instances. The results show that, in90 out of 100 instances, the closeness of synchronization isless than 37ms and 54ms for α = 75% and 90%, respectively.
CICADAS uses a feedback-based control loop to estimatethe true state of congestion, and the Kalman filter serves asone example throughout the paper. To understand whetherusing Kalman filters is more effective than straightforwardapproaches, we substitute the Kalman filter in CICADASwith two other methods for comparison:
6
0.025 0.03 0.035 0.04 0.045 0.05 0.055 0.06 0.0650%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Closeness of synchronization
Rel
ativ
e cu
mul
ativ
e fr
eque
ncy
90% pairs of bots75% pairs of bots
Figure 7: Relative cumulative frequency with mul-tiple experiments.
• No Feedback: a one-time measurement. When botsobserve the first congestion after establishing a base-line of RTT , bots start attacking periodically at timesfirst congestion time + mT , where m is mth periodand T is the length of one period.
• Simple Feedback: a simple Kalman filter with theKalman gain fixed to 1. That is, the bot estimates thetrue state of congestion based solely on the most recentobservation. In other words, x(k|k) = z(k) when botsupdate the true state of congestion x.
0 50 100 150 2000
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Time (sec)
Nor
mal
ized
thro
ughp
ut
Normalized throughput
Figure 9: Normalized TCP throughput of 10 runs.
We run 100 instances for each method. For the No Feed-back method, the closeness of synchronization is consistentlyhigher than 200ms, which indicates failed synchronization.Figures 8(a) and 8(b) compare the results for the SimpleFeedback and the Kalman Filter methods. In both figures,CICADAS (with the Kalman filter) outperforms the SimpleFeedback method, as it is more likely to achieve lower valuesregarding the closeness of synchronization.to show that CICADAS can obtain an unfair share of
bandwidth, we use the scp command to download a largefile via the target link and examine its throughput. Figure 9shows the normalized TCP throughput of 10 experiments.Once the bots were synchronized, the normalized through-put was effectively reduced to 0.3.
5.4 Simulation
The ns-3 simulator allows us to investigate how well CI-CADAS can synchronize attack streams under different net-work conditions by changing corresponding parameters.
Methodology Since our goal is to test the sensitivity ofvarious network conditions, we use a simple dumbbell topol-ogy with attack and TCP flows sharing a bottleneck link.Realistic topologies are tested in our Internet experiments.
Attack traffic consists of two types of packets: probe pack-ets and burst packets. Each bot starts sending probe packetsat roughly the same time. Once started, probe packets aresent periodically (default is 20 ms) to measure the RTT at afine time granularity. The link delays are randomly selectedat the beginning of a simulation.
5.5 Simulation ResultsSimilar to Figures 6 and 7, we first inspect the level of
synchronization in one simulation instance, which allows usto cross-check the results of the Internet-wide experimentsand simulations.
Figure 10(a) shows the differential time of arrival for onesimulation instance. In this setting, we consider 10 legit-imate TCP flows sharing the bottleneck link with 20 at-tack streams in a dumbbell topology. ∆TOA(m, 75%) and∆TOA(m, 90%) are less than 20ms for most of the time pe-riods, which means that the burst length can be as wide as180ms (= 200− 20).
Figure 10(b) shows the cumulative distribution versus thecloseness of synchronization for 100 simulation instances.The results show that in 90 out of 100 instances, the close-ness of synchronization is less than 17ms and 24ms for α =75% and 90%, respectively.
The level of synchronization is generally higher in the sim-ulation than in the Internet-wide experiments because thenetwork delays in the simulation are fixed, whereas delaysfluctuate a lot in the real network.
After confirming that CICADAS can effectively coordi-nate multiple attack streams, we study what factors affectthe degree of coordination. We measure the closeness ofsynchronization for 1) different probe intervals, 2) differentranges of start times, and 3) different numbers of bot pairs.
5.5.1 Probe Interval
The closeness of synchronization can also be affected bythe probing interval. As can be seen in Figure 11(a), thecloseness of synchronization increases with the probe inter-val. There is a trend that the closeness of synchronizationincreases with the probe interval. This result confirms thata small probe interval provides bots with fine-grained infor-mation, resulting in a high degree of coordination. As theprobe interval grows, each bot obtains fewer RTT samplesper congestion, therefore making it difficult to differentiateattack-induced congestion from noise.
5.5.2 Bot start time range
Figure 11(b) shows the closeness of synchronization versusthe range of start time of bots. We set the value m1 =50 in (7), because some bots start later and need time tosynchronize. This result confirms that bots do not need tostart at exactly the same time. On the other hand, whenCICADAS attacks are in progress, bots can join the attackat a later time.
5.5.3 Number of bot pairs
7
0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0.18 0.20%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Closeness of synchronization
Rel
ativ
e cu
mul
ativ
e fr
eque
ncy
Kalman FilterSimple Feedback
(a) 75% pairs of bots
0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0.18 0.20%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Closeness of synchronization
Rel
ativ
e cu
mul
ativ
e fr
eque
ncy
Kalman FilterSimple Feedback
(b) 90% pairs of bots
Figure 8: The closeness of synchronization using different delay estimation methods. The No Feedbackmethod failed constantly and thus its results were not depicted here.
10 20 30 40 50 60 70 800
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2
Time (sec)
Diff
eren
ce o
f arr
ival
of a
ttack
ing
pack
ets
(sec
)
90% pairs of bots75% pairs of bots
(a) Differential time of arrival with one simu-lation on ns-3.
0 0.01 0.02 0.03 0.04 0.05 0.060%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Closeness of synchronization
Rel
ativ
e cu
mul
ativ
e fr
eque
ncy
90% pairs of bots75% pairs of bots
(b) Relative cumulative frequency with mul-tiple simulations on ns-3.
Figure 10: Simulation results.
Figure 11(c) shows the closeness of synchronization versusthe number of bot pairs. CICADAS can reliably synchronizebots regardless of the size of the botnet.
5.6 Summary of EvaluationThe results of the wide-area Internet experiments confirm
that CICADAS can effectively synchronize attack streamsdespite dynamic delays, whereas prior approaches cannot.The ns-3 simulation results confirm that CICADAS can re-liably synchronize bots under different network conditions.
6. DISCUSSION
Congestion at non-target links There are two ques-tions related to congestion at non-target links.First, how does CICADAS react to transient congestion
occurring at non-target links? Ideally, CICADAS shouldtreat this type of congestion as noise, since CICADAS in-tends to regulate an attack stream based on the instants ofcongestion at the target link. To understand how such noisecan be eliminated, we first note that our congestion detectoris tuned to detect severe congestion only once it leaves theLURK state. Congestion of inadequate length or intensitywill be filtered out quickly. Hence, we can minimize inter-
ference by legitimate congestion at non-target links, whichtypically has a short duration and small magnitude.
Second, will CICADAS cause congestion at non-targetlinks? Similar to prior work [12], CICADAS can avoid caus-ing malicious congestion at non-target links by estimatinglink capacity using existing bandwidth estimation tools [29].
Non-target congestion caused by an aggregate of legiti-mate and attack traffic will also be viewed as noise.
The above observation is confirmed by our Internet-wideexperiments: In these experiments, bots may be triggeredby congestion at non-target links and send bursts lasting for0.2s during the next period. These bots either cause a slightcongestion in a short period of time at the target link andcreate a cascading effect in the following time periods, orcause no effect on the target link.
Path change During a CICADAS attack, the communi-cation path between bots may change. Such a path changemay affect the observed delays and thus decrease the level ofsynchronization among bots in the short term. In the longterm, CICADAS’s feedback mechanism can help bots grad-ually converge toward the strongest attack force. If quickrecovery is desired, the bot that detects a path change (e.g.via traceroute) can switch back to the BOOTSTRAP stateand re-synchronize with the other bots.
8
10 20 30 40 50 60 70 80 90 1000
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
probing interval (ms)
Clo
sene
ss o
f syn
chro
niza
tion
90% pairs of bots75% pairs of bots
(a) Probe interval versus closeness ofsynchronization.
[0, 0) [0, 5) [0,10) [0,15) [0,20) [0,25) [0,30)0
0.005
0.01
0.015
0.02
0.025
0.03
range of start time (sec)
Clo
sene
ss o
f syn
chro
niza
tion
90% pairs of bots75% pairs of bots
(b) Start time versus closeness of syn-chronization.
12 20 28 36 44 52 60 68 76 84 92 1000
0.01
0.02
0.03
0.04
0.05
0.06
Number of bot pairs
Clo
sene
ss o
f syn
chro
niza
tion
90% pairs of bots75% pairs of bots
(c) Number of bot pairs versus closenessof synchronization with large queue.
Figure 11: Simulation results.
Trigger signal During the LURK state, a bot is triggeredby the first observable congestion. In the absence of conges-tion, bots themselves can create triggers. For instance, botscan send normal TCP traffic to each other, since the TCPflow aggregate will naturally exhibit saw-tooth-like patterns,which saturate the link from time to time.It is possible that bots may be triggered by different con-
gestion instances on the target link due to their differentstart times, and thus attack at different times in the follow-ing period. However, once triggered, bots will converge overtime as they observe similar congestion signals.
Potential countermeasures CICADAS is designed tocircumvent common DDoS detection mechanisms becausebot traffic in CICADAS is legitimate-looking: bots send low-volume traffic to each other using real IP addresses. More-over, by design, the temporal pattern of the CICADAS at-tack is observable only at the target link, thereby renderingthe redirection-based cloud traffic scrubbing service unus-able. To mitigate such a stealthy DDoS attack, there needsto be support for DDoS-resilient Internet architectures [5]and efficient flow monitoring algorithms running at eachrouter. However, none of these is easy to do with respect todesign and deployment. As a proof of concept, we presenta metric called Disturbance Ratio, by which a router canaccurately distinguish legitimate flows and pulsating attackflows. The precision and recall rates are promising, but itremains to be seen how to compute such a metric at line ratewithout keeping per-flow state at routers. Countermeasuredetails can be found in Appendix B.
7. RELATED WORKThe most closely-related work is reviewed in § 2. This
section briefly reviews other DDoS attack and defense tech-niques. We refer interested readers to survey papers [20,23,33] for comprehensive studies.To mitigate DDoS, existing solutions typically aim to
throttle flows that exhibit characteristics such as spoofedIP addresses [4,7,16], undesired by destinations [31,32], anddisproportionate bandwidth share [15, 18, 22, 28]. However,the CICADAS attack appears legitimate to many detectionalgorithms since it can be performed by low-volume inter-bot traffic using real IP addresses. The periodic patternof pulsating attacks is a distinguishing characteristic withregard to attack detection [6, 17]. However, existing detec-
tion algorithms are too resource-intensive to be performedon routers.
The crossfire attack [12] aims to cut off a region from theInternet by flooding a few critical links that connect thetwo. To achieve this, algorithms are proposed for select-ing the target links and attack paths. While our work alsotargets network links instead of end servers, it focuses ondesigning an attack coordination mechanism and thus is or-thogonal to the crossfire attack. In Temporal Lensing [25], asingle attack source uses paths with different latencies suchthat a flooding attack is transformed into a pulsating at-tack with a higher peak against the victim endhost. Itslatency estimation relies on existing DNS infrastructure andan assumption that there are always DNS resolvers topolog-ically close to end points. However, this assumption maynot hold when the target is an intermediate network linkrather than an endhost, and this approach may become lesseffective as more and more open DNS resolvers are closing(http://openresolverproject.org/).
8. CONCLUSIONRecent DDoS threats (e.g., amplification attacks and
flooding core links) pose new research challenges for provid-ing available communication in critical network infrastruc-tures. The increased sophistication and impact of DDoS at-tacks motivates the study of future attack trends. This workfocuses on the practicability of a new type of DDoS attack,referred to as the pulsating attack, which is considered pow-erful but has not yet been observed in a real-world setting.To show that it is possible to overcome the perceived limita-tions of pulsating attacks, we develop a novel attack coordi-nation mechanism called CICADAS, which enables bots tosynchronize with each other with no central controller in ahighly dynamic network. Moreover, CICADAS coordinatesbots in the temporal domain and can work in conjunctionwith other DDoS mechanisms that coordinate bots in thespatial domain [12, 30] or temporally concentrate one floodinto high-peaked pulses [25].
Acknowledgments
This work was supported in part by the Ministry of Scienceand Technology, Taiwan, under Grants MOST-103-2218-E-002-034-MY2 and MOST-104-2218-E-001-002.
9
9. REFERENCES[1] ATLAS Q2 2015 Global DDoS Attack Trends.
http://www.slideshare.net/Arbor Networks/atlas-q2-2015final.
[2] Spike DDoS Toolkit Threat Advisory. https://www.stateoftheinternet.com/resources-web-security-threat-advisories-2014-multi-platform-botnet-spike.html.
[3] M. Allman, V. Paxson, and E. Blanton. TCPCongestion Control. RFC 5681 (Draft Standard),Sept. 2009.
[4] K. Argyraki and D. R. Cheriton. Active InternetTraffic Filtering: Real-Time Response toDenial-of-Service Attacks. In Proceedings of USENIXATEC, 2005.
[5] C. Basescu, R. M. Reischuk, P. Szalachowski,A. Perrig, Y. Zhang, H.-C. Hsiao, A. Kubota, andJ. Urakawa. SIBRA: Scalable Internet BandwidthReservation Architecture. In Proceedings of NDSS,2016.
[6] Y. Chen and K. Hwang. Collaborative detection andfiltering of Shrew DDoS attacks using spectralanalysis. Journal of Parallel and DistributedComputing, 66(9):1137–1151, Sept. 2006.
[7] P. Ferguson and D. Senie. Network Ingress Filtering:Defeating Denial of Service Attacks which employ IPSource Address Spoofing. RFC 2827 (Best CurrentPractice), May 2000. Updated by RFC 3704.
[8] M. Guirguis, A. Bestavros, and I. Matta. BandwidthStealing via Link-Targeted RoQ Attakcs. InProceedings on Communication and ComputerNetworks, 2004.
[9] M. Guirguis, A. Bestavros, and I. Matta. Exploitingthe Transients of Adaptation for RoQ Attacks onInternet Resources. In Proceedings of IEEE ICNP,2004.
[10] N. Hu, L. Li, Z. Mao, P. Steenkiste, and J. Wang.Locating Internet bottlenecks: Algorithms,measurements, and implications. SIGCOMM Comput.Commun. Rev., 34(4):41–54, 2004.
[11] M. S. Kang and V. Gligor. Routing Bottlenecks in theInternet: Causes, Exploits, and Countermeasures. InProceedings of ACM CCS, 2014.
[12] M. S. Kang, S. B. Lee, and V. D. Gligor. The CrossfireAttack. In Proceedings of IEEE Symposium onSecurity and Privacy, 2013.
[13] D. Kostoulas, D. Psaltoulis, I. Gupta, K. Birman, andA. Demers. Decentralized Schemes for Size Estimationin Large and Dynamic Groups. In Proceedings ofIEEE International Symposium on NetworkComputing and Applications, 2005.
[14] A. Kuzmanovic and E. Knightly. Low-RateTCP-Targeted Denial of Service Attacks: the Shrewvs. the Mice and Elephants. In Proceedings of theACM SIGCOMM, 2003.
[15] Y. Kwok, R. Tripathi, Y. Chen, and K. Hwang.HAWK: Halting Anomalies with Weighted ChoKingto Rescue Well-Behaved TCP Sessions from ShrewDDoS Attacks. Networking and Mobile Computing,3169(August):1–10, 2005.
[16] X. Liu, A. Li, X. Yang, and D. Wetherall. Passport:Secure and Adoptable Source Authentication. InProceedings of USENIX/ACM NSDI, 2008.
[17] X. Luo and R. Chang. On a New Class of PulsingDenial-of-Service Attacks and the Defense. InProceedings of NDSS, 2005.
[18] R. Mahajan, S. Floyd, and D. Wetherall. ControllingHigh-Bandwidth Flows at the Congested Router. Inproceedings of IEEE ICNP, 2001.
[19] L. Massoulie and E. L. Merrer. Peer Counting andSampling in Overlay Networks: Random WalkMethods. In Proceedings of ACM PODC, 2006.
[20] J. Mirkovic and P. Reiher. A Taxonomy of DDoSAttack and DDoS Defense Mechanisms. ACMSIGCOMM Computer Communication Review,34(2):39–53, 2004.
[21] M. Motiwala, M. Elmore, N. Feamster, andS. Vempala. Path splicing. In Proceedings of ACMSIGCOMM, 2008.
[22] R. Pan, L. Breslau, B. Prabhakar, and S. Shenker.Approximate Fairness Through Differential Dropping.ACM SIGCOMM Computer Communication Review,33(2):23, Apr. 2003.
[23] T. Peng, C. Leckie, and K. Ramamohanarao. Surveyof Network-Based Defense Mechanisms Countering theDoS and DDoS Problems. ACM Computing Surveys,39(1), Apr. 2007.
[24] P. Ramamurthy, V. Sekar, A. Akella,B. Krishnamurthy, and A. Shaikh. Remote Profiling ofResource Constraints of Web Servers Using Mini-FlashCrowds. In Proceedings of USENIX ATC, 2008.
[25] R. Rasti, M. Murthy, and V. Paxson. TemporalLensing and its Application in Pulsing Denial ofService Attacks. In Proceedings of IEEE Symposiumon Security and Privacy, 2015.
[26] C. Rossow. Amplification Hell: Revisiting NetworkProtocols for DDoS Abuse. In Proceedings of NDSS,2014.
[27] A. Stavrou and A. D. Keromytis. Countering DoSattacks with stateless multipath overlays. InProceedings of ACM CCS, 2005.
[28] I. Stoica, S. Shenker, and H. Zhang. Core-StatelessFair Queueing: A Scalable Architecture toApproximate Fair Bandwidth Allocations inHigh-Speed Networks. IEEE/ACM Transactions onNetworking, 11(1):33–46, Feb. 2003.
[29] J. Strauss, D. Katabi, and F. Kaashoek. Ameasurement study of available bandwidth estimationtools. In Proceedings of ACM SIGCOMM IMC, 2003.
[30] A. Studer and A. Perrig. The Coremelt Attack. InProceedings of ESORICS, 2009.
[31] A. Yaar, A. Perrig, and D. Song. SIFF: A StatelessInternet Flow Filter to Mitigate DDoS FloodingAttacks. In Proceedings of IEEE Symposium onSecurity and Privacy, 2004.
[32] X. Yang, G. Tsudik, and X. Liu. A TechnicalApproach to Net Neutrality. In Proceedings ofHotnets-V Workshop, 2006.
[33] S. T. Zargar, J. Joshi, and D. Tipper. A Survey ofDefense Mechanisms Against Distributed Denial ofService (DDoS) Flooding Attacks. IEEECommunications Surveys and Tutorials,15(4):2046–2069, 2013.
[34] Y. Zhang, Z. M. Mao, and J. Wang. Low-Rate
10
TCP-Targeted DoS Attack Disrupts Internet Routing.In Proceedings of NDSS, 2007.
APPENDIX
A. ADVANCED ATTACK STREAM GEN-
ERATORSThis appendix describes the construction of seemingly-
innocuous attack flows that are randomized and responsiveto congestion, thus improving the stealthiness of the attack.
A.1 RandomWe say that time t is during an on-phase if t ∈
[x(k|k − 1), x(k|k − 1) + L) for some k, where x(k|k − 1) isderived from Eq. 3; otherwise, t is in an off-phase.The randomized attack stream generator probabilistically
schedules a burst for each on-phase, such that the expectedvalue of the instantaneous rate at any time point during anon-phase is R+ǫ
n, where R is the magnitude of bursts at the
target link, and n is the number of attack streams. Thevalue of ǫ is set to ensure that the instantaneous rate of nattack streams is higher than R with high probability.To achieve this, for each x(k|k−1), the generator selects p
(0 ≤ p ≤ 1), y1 (y1 ∈ N+), and y2 (y2 ∈ N, 0 ≤ y2 < y1) uni-
formly at random. This parameter selection process repeats
until (R+ǫ)y1np
≤ rmax, where rmax is the maximum instan-taneous rate of an attack stream. Then with probability p,
the generator sends traffic at rate (R+ǫ)y1np
during interval
bk =
[
x(k|k − 1) +y2y1
L, x(k|k − 1) +y2 + 1
y1L
)
.
Analysis Let R(t) be the instantaneous rate of n attackstreams at time t, and r(t) the instantaneous rate of a gen-erator at time t. We derive the probability of R(t) ≥ R.When t is in an on-phase, the expected value of r(t) is
E[r(t)] = Pr[send burst] · Pr[t ∈ bk] ·(R+ ǫ)y1
np
= p ·1
y1·(R+ ǫ)y1
np=
R+ ǫ
n.
Since each generator selects parameters independently and0 ≤ r(t) ≤ rmax, we obtain
Pr[R(t) < R] = Pr[n · r(t) < R]
= Pr[n · r(t) < E[n · r(t)]− ǫ]
< exp
(
−2n2ǫ2
n · r2max
)
= exp
(
−2nǫ2
r2max
)
. (8)
Eq. 8 is derived based on Hoeffding’s inequality. Hence,for all δ ∈ (0, 1], the randomized attack stream generator
ensures that Pr[R(t) ≥ R] ≥ 1− δ if ǫ ≥ rmax
√
− ln δ2n
.
Attack cost The cost of introducing this randomizationtechnique (in terms of the increase in attack traffic per timeunit per bot) is ǫL
nT, which is negligible for typical values of ǫ,
L, n, and T . In sum, to ensure that the instantaneous rateof randomized attack streams R(t) is higher than R withhigh probability, each bot only has to send at an averagerate slightly higher than R
nduring each on-phase.
A.2 TCP embedding
We describe how to execute a DDoS attack using respon-sive TCP flows. The key idea is that since bots know roughlywhen the link will be unobstructed (i.e., during the off-phases), they can reliably increase their sending rates bysending packets during off-phases.
TCP increases its congestion window (cwnd) when no con-gestion is sensed. As the congestion window limits the max-imum number of unacked segments, the sending rate is ap-proximately the size of the congestion window divided bythe RTT, i.e., cwnd
RTT. While the actual TCP implementa-
tions vary, and numerous suggestions have been made toimprove the performance of TCP, our proposed mechanismcan work with any TCP variants in principle. Hence, we con-sider the following standardized specification for illustrationpurposes. reader unfamiliar with TCP congestion control isreferred to RFC 5681 [3].
When the congestion window (cwnd) is smaller than theslow start threshold (ssthresh), TCP is in the slow startphase, where it exponentially increases the congestion win-dow to probe for available bandwidth. In the slow startphase, the value of cwnd is doubled per RTT, or incrementedby 1 Maximum Segment Size (MSS) per non-duplicate ACK.When cwnd ≥ ssthresh, TCP enters the congestion avoid-ance phase, where cwnd is incremented by 1 MSS per RTT
(or incremented by MSS2
cwndper non-duplicate ACK) [3]. Upon
a timeout, cwnd is reset to 1 MSS and ssthresh is set tomax{FlightSize/2, 2 MSS}, where FlightSize is the size ofall unacked segments in bytes.
Analysis. Suppose each bot sends cwndMSS
segments perRTT during off-phases until cwnd = x. Then during anon-phase, the bot sends a burst of magnitude x
RTTand du-
ration RTT . If some packets in the burst are dropped dueto congestion, cwnd is reset to 1 MSS and ssthresh to x
2.
Assume no congestion experienced by cover traffic, the min-imum number of periods before restoring cwnd to x is:
∆burst =
⌈
minRTO + (timeSS + timeCA) ·1
T − L
⌉
,
where timeSS and timeCA are the time elapsed in the slowstart phase and congestion avoidance phase, respectively.The current timeout value is minRTO, as the bot can ensureno repeated timeouts for the same packet. Since cover trafficis sent only during off-phases (which account for T − L outof T time per period), the total time is divided by T − L.Furthermore, based on the TCP specification, we can derivethat timeSS = RTT · max{log2
x2·MSS
, 1} and timeCA =RTT ·min{ x
2·MSS, xMSS
− 2}.
Attack cost. We quantify the increase in cost with re-spect to the amount of cover traffic. Given that each botsends cwnd
MSSsegments per RTT during off-phases, how much
cover traffic does each bot need to send before reaching acongestion window of size x? When no packet loss occursduring off-phases, the average number of segments per sec-ond is bounded:
avg rate ≤ max {avg rate SS, avg rate CA}
= avg rate CA =0.75x
RTT ·MSS.
B. POTENTIAL COUNTERMEASURESWe discuss potential countermeasures against CICADAS.
11
0 20 40 60 80 100 1200
50
100
150
200
250
300
350
400
450
Time (sec)
traf
fic r
ate(
Kby
tes/
s)
traffic
(a) Traffic on the router.
0 20 40 60 80 100 1200
1
2
3
4
5
6
7
8
9
Time (sec)
Rat
io
botuser
(b) Router detection with one experi-ment.
0 20 40 60 80 100 1200
1
2
3
4
5
6
7
8
9
10
Time (sec)
Rat
io
botuser
(c) Router detection with 10 experi-ments.
Figure 12: Countermeasure preliminary results.
Throttle disturbing flows. As CICADAS aims to max-imally disturb the communication of other flows while re-maining stealthy, we can ideally define a new flow metricthat quantifies the level of flow disturbance to other flows,and then throttle flows with a high disturbance value.Following this line of thought, we observe that if a flow
accounts for a larger share of traffic during congestion, theflow is likely to be an attack flow. (A legitimate flow, on theother hand, should slow down during congestion or at leastbehave consistently regardless of congestion.) Hence, when arouter sees periodic patterns as in Figure 12(a), it can gathertraffic statistics during congestion (i.e. the peaks) and non-congestion (i.e. the valleys) for further analysis. Specifically,we define the Disturbance Ratio of flow i as follows:
ratio(i) =c(i)
C/nc(i)
NC, (9)
where C and NC are the number of bytes received by therouter during congestion and non-congestion, respectively.Similarly, c(i) and nc(i) are flow i’s traffic (in bytes) re-ceived by the router during congestion and non-congestion,respectively. If a flow’s disturbance ratio is greater than 1,it means that the flow contributes more to the overall traf-fic (in terms of percentage) during congestion than duringnon-congestion. As a result, a flow is classified as maliciousif its disturbance ratio > 1.As a proof-of-concept, we implement this method on a
local machine (which serves as the target link), and run 10pairs of bots and 10 normal TCP flows. Attacks start from0s to 100s and the TCP flows start from 0s to 110s. Therouter computes ratio(i) every 10 seconds.Figures 12(b) and 12(c) show the Disturbance Ratio vs.
time by running one and 10 experiments, respectively. Thered dots represent users and the blue crosses represent bots.In Figure 12(c), the precision is > 90% during the first 20seconds and increases to 100% in the subsequent 80 seconds.The recall is > 90% all of the time. Note that in the contextof our study, precision means the proportion of detected ma-licious flows to all detected flows, and recall is the proportionof detected malicious flows to all malicious flows.Although our proposed method has high precision and
recall, a practical solution would require computing such ametric in an efficient manner. In the future, we aim to devisean efficient one-pass algorithm that computes disturbanceratios at line rate without keeping per-flow state at routers.
Disrupt CICADAS coordination. Another possibledefense strategy is to explicitly disrupt the coordination ofbots in CICADAS. For example, routers could attempt torate limit probe packets, as our simulations show that the at-tack becomes less effective as the probe interval gets higher.However, since CICADAS can employ a custom probe proto-col rather than the standard Ping utility, the probe packetsare indistinguishable from other packets. As a result, sucha simple rate limiter would fail to limit CICADAS’s probepackets. Routers could also try to inject noise to the con-gestion signal – RTT and packet loss – which a bot relies onfor regulating the attack stream. However, increasing end-to-end latency and packet drop rate is undesirable for manynetwork applications.
Route around congested links. A promising gen-eral defense is multipath routing. Multipath communicationcan offer dramatic availability improvements, as legitimatesenders can avoid maliciously-flooded links by switching be-tween paths [21,27]. A multipath protocol may be more re-silient against link flooding if it supports fine-grained pathselection; however, fine-grained path selection may actuallygrant too much power to bots. For example, these bots couldconstruct loopy, lengthy paths that consume disproportion-ate amount of network bandwidth, jeopardizing the welfareof legitimate senders. In other words, multipath communi-cation can be a double-edged sword that hurts benign flowsin some adversarial environments. Thus, further research isrequired to study how much multipath protocols can helpmitigate DDoS attacks and improve network availability.
12
