Amplification and DRDoS Attack Defense – A Survey and New Perspectives

Fabrice J. Ryba∗, Matthew Orlinski∗, Matthias Wahlisch¨ ∗, Christian Rossow†, Thomas C. Schmidt‡ ∗ Freie Universitat¨ Berlin, Berlin, Germany, Email: {fabrice.ryba, m.orlinski, m.waehlisch}@fu-berlin.de † Saarland University, Saarbruecken, Germany, Email: [email protected] ‡ HAW Hamburg, Hamburg, Germany, Email: [email protected]

Abstract—The severity of amplification attacks has attacks, e.g., Slowloris [21] or TCP SYN floods [22], grown in recent years with recent attacks involving several unless their defenses are also applicable to amplification hundreds of Gbps attack volume. In this paper, we survey attacks. Generally, the adversary in amplification attacks the threat of amplification attacks and compare a wide targets vulnerabilities in Internet protocols and services selection of different proposals for preventing, detecting, to amplify the amount of attack traffic. The ease of per- and filtering amplification attack traffic. Since source IP spoofing plays an important part in almost all of the forming amplification attacks and greater understanding amplification attacks surveyed, we also survey state-of- of their effect has led to an increase of attacks in recent the-art of spoofing defenses as well as approaches to trace years. This is supported, e.g., by the OpenDNS Security spoofing sources. This work acts as an introduction into Lab that saw over 5,000 different amplification attacks many different types of amplification attacks and source every hour in 2014 [23], and by Rossow’s survey of IP address spoofing. By combining previous works into a amplification vulnerabilities [13]. single comprehensive discussion we hope to prevent redun- The most prominent form of amplification attack seen dant work and encourage others to find practical solutions in recent years abuses the lack of endpoint verification for defending against future amplification attacks. in the Internet Protocol (IP) in order to trick third-party servers into sending large amounts of data to victims. I.INTRODUCTION That is, attackers spoof source IP addresses [24] to hide Denial of Service (DoS) attacks against networks at- their identity and cause third-parties to send data to the tempt to make a system or an entire network unavailable victim as identified by the source address field of the IP for its intended purpose [1]. In some cases DoS attacks packet. This is also sometimes called reflection because cause a complete loss of Internet connectivity for the attackers “reflect” attack traffic off of benign services. victim [2]. The motivation for DoS attacks can be finan- As well as reflection, attackers sometimes strive to cial [3], [4], political [2], ideological [5], reputation [6], maximize the attack bandwidth sent to the victim by

arXiv:1505.07892v3 [cs.NI] 17 May 2016 [7], to test new techniques and prepare for larger attacks, using amplification. For example, many UDP-based pro- or purely for disruptive purposes [8]. tocols (such as DNS or NTP) that have a higher response A general overview of DoS attacks and defense strate- payload size than the requests can be abused to amplify gies can already be found in the surveys by Mirkovic the reflected attack traffic. Consider DNS, while DNS and Reiher [9], Douligeris and Mitrokotsa [10], and lookup requests are typically rather small, the responses more recently Zargar et al. [11]. Instead, this paper may be significantly larger, e.g., due to verbose informa- focuses on a particular type of DoS attack called an tion such as DNSSEC records. amplification attack (also called Distributed Reflective By combining reflection and amplification attackers Denial of Service (DRDoS) attacks [12], [13]) where the can generate attack traffic volumes which are signifi- attacker seeks to maximise the volume of attack traffic cantly higher than their uplink bandwidth [2], [4], [8], sent to the victim whilst minimising the volume of traffic [25]. Furthermore, not only single hosts may be affected they send to trigger the attack [14]–[20]. We will not by such attacks. Entire networks may struggle to cope discuss other low traffic volume and high impact DoS with the extra bandwidth and processing demands [25]. Section 1: Introduction from the past and discuss amplification attacks in great Section 2: Reflection and Amplification Attacks detail. We then describe methods to prevent amplification Previous Attacks Attack Models attacks in Section III. Then special attention is paid to Section 3: Preventing Amplification Attacks preventing reflection and IP spoofing in Section IV. We Alternative Architectures Lowering Amplification Factors Reducing Number of Amplifiers Response Rate Limiting UDP Sessions Filtering Spoofed Packets finish the discussion about the solution space in Sec- tion V by presenting approaches to detect and filter am- Section 4: Source IP Address Spoofing plification attacks. Finally, we conclude in Section VI. Monitoring Spoofing In The Wild Active Monitoring Passive Monitoring II.AMPLIFICATION ATTACKS Detecting and Filtering Spoofed Packets Flow Correlation This section provides a detailed introduction into the Validating Source Address Using Network Knowledge End-to-end IP Headers, e.g., TTL different techniques for amplifying attack traffic. We start Encryption Ingress and Egress Filtering Third-party Authentication Learning Flow Directions by giving a brief taxonomy and timeline of different Routing Tables types of amplificaiton attacks, and then we end the section by describing the techniques used in more detail. Tracing Spoofing Attacks Traffic Logs Packet Marking ICMP Traceback Link Testing

Section 5: Detecting Amplification Attacks and Filtering Attack Traffic A. Taxonomy and Historical Background Locations for Detecting and Filtering Attack Traffic There are many ways of amplifying the volume of Victim-end Source-end Reflectors/Amplifiers Distributed attack traffic in DoS attacks. In this paper we give Predicting Future Attacks special focus to amplification attacks which use UDP Game Therory Scan Detection based amplifying protocols and reflection. However, it is Section 6: Conclusions, ongoing projects, and future work important to be able to distinguist between the different types of amplificaiton attacks. Fig. 1. Categorisation of the amplification DDoS literature. 1) DNS Servers as Amplifiers: In 1999, AusCERT [27] warned about amplification attacks where attackers trick DNS servers into sending large Defending against this form of amplification attack amounts of data to spoofed IP addresses [24]. In 2000, is challenging for network operators. Firstly, the attack the CIAC warned of Distributed Denial of Service traffic blends in benign communication and may be (DDoS) attacks where attackers can send spoofed IP hard to distinguish from legitimate traffic. Secondly, packets from many different locations [28]. the attack packets received by victims are reflected by Today, DNS is widely used in amplification attacks many distributed benign third-parties such as open DNS because a 60 byte request from an attacker can easily resolvers, effectively hiding the attacker’s identity [26]. generate a 512 byte response [2], [8], [14]. Furthermore, In this survey paper, we systematically structure ex- DNS servers which support Extension mechanisms for isting research on amplification attacks to assist future DNS (EDNS) [29] can generate responses which are research in this direction. To the best of our knowledge, nearly 100 times larger than requests [13]. Some at- we are the first to categorize an research area that spans tackers even ensure large responses by creating domains almost 200 publications and has become an important specifically to use in amplification attacks [23]. problem both in academia and practice. To this end, we Any public DNS server which is configured to respond first compare various definitions and types of amplifica- to requests for hosts outside of their domain can be used tion attacks. With this foundation, we then systematize in amplification attacks. DNS servers that are configured preventive countermeasures, and particularly look at the to respond to all such requests are known as open DNS problem of (identifying and mitigating) IP spoofing. We resolvers. According to the Open DNS Resolver Project complete our survey with works that proposed reactive approximately 25 million open DNS resolvers currently countermeasures to defend against ongoing amplification “pose a significant threat” to the Internet [26]. It is also attacks. Our main contribution is thus a comprehensive not difficult to find enough open DNS resolvers to use survey of existing literature that until now was scattered. in amplification attacks. Rossow showed that it currently The rest of this paper is organised as shown in only takes 90 seconds to acquire a list of 100,000 open Figure 1. In Section II, we present prominent incidents DNS resolvers [13].

2 h eussata mlfir eas hyices the increase they traffic. broadcast because attack which of amplifiers volume routers as the act attacks requests the Smurf [35], in attacks Smurf and as their [36], known on hosts are ICMP the attacks the of These all receiving network. to routers requests the The broadcast the victims. requests to of source requests address the spoofing IP ICMP of prior whilst networks sending ways of example, address were broadcast other For attackers many volume. 1998 to traffic are attack there amplifying services, based UDP [33]. above by and disabled 4.2.7 be version should to and affect NTP upgrading not of does functionality Monlist core server. 600 the the previous access the to of addresses list in NTP IP a in generated returns command NTP which a traffic “monlist”, by 4,529 called of caused was using volume which attack CloudFlare huge 400Gbps attack the The nearly SNMP CloudFlare [25]. of MIT the servers peak the and a are [32], reached spoofing attack address based IP source [31]. and attack single was a it in traffic 2014 of October 54Gbps in generate and to [30], used 2014 January about in warning a SSDP amplifi- Emergency issued first Computer in (US-CERT) States Team spoofing Readiness United address The IP attacks. source cation with used been verifying packets. to of mechanism address in IP built source no the has because and protocol also stateless layer is is transport it the UDP as third-parties. traffic attackers from attack by used all come because will attacker receive track they to victim a the for attacking into third-parties ad- trick IP [24]. source victim to use spoofing described dress just attacks amplification

1998 Estimated attack traffic (Gbps) n ot hc epn orqet fe hyare they after requests to respond which hosts End Attacks: Fraggle and Smurf 3) UDP used that attacks DoS documented well Other has (SSDP) protocol based UDP another Recently, difficult very it makes also spoofing address IP Source Services: Based UDP Other 2)

AusCERT warns about DNS based amplification attacks 2001

DNS is regularly used in amplification attacks 2004 i.2 ieieo mlfiainatcsadrltdevents. related and attacks amplification of Timeline 2. Fig. AmplificationVaughn and Attacks Evron at present DEFCON DNS 14 2007 swl smisusing as well As h N based DNS The 2013 eb F Mar 300 300Gbps DNS attack against SpamHaus Apr 3 May 167 otso 04 hsi he ie oeta nthe in than more [34]. times 2013 three in last is the period This in same 2014. Gbps of 100 months over peaked 3 which SSDP and Gen, growing are amplification number. based in UDP and involv- reflection attacks However, ing configuration respectively. network SIP to better patches and by countered been largely Threat Growing a to Responding B. re- legitimate to responding [38]. from quests exchange them to proxies preventing amplification SIP and 2 of cause to type to up possible generated this is is Using it request attack [16]. extra one iteration proxies least at- are every SIP at loops to between and sent Fork used indefinitely are [38]. are requests SIP which where running loops” situations networks “fork VoIP by tack caused are al. an is attacks mentioned. amplification which already based have UDP packets, we the response in difference factor size and important this the request that account however large into between note take arbitrary to doesn’t important an definition is the essentially It on to [16]. messages number” of amplify number amplification can ”the an network where described covered. being [38] yet as al. not attack et have Shankesi 2009 we In which attacks as amplification request. amplifiers the are broadcast which attacks receive, routers Fraggle they the in than as hosts well data requests end more the CharGen much thus receive with same which the respond hosts at may networks End many [37]. of in requests time address CharGen example, broadcast send For the may to well. attacker an as attacks amplifiers Fraggle be may broadcast Prolexic reports a 167Gbps DNS attack

kmidtce o tak novn T,Char- NTP, involving attacks DoS 9 detected Akamai have attacks Loop Fork and Fraggle, Smurf, Today, et Shankesi by described attacks amplification The Loops: Fork 4) SNMP attack at MIT and Jun 2 Jul 70 Aug 100 ulct eusscnuigterresources their consuming requests duplicate 100Gbps DNS attack against GreenNet Sep Oct hr sas nte aeoyof category another also is There Nov Dec DERP claims responsibility for many attacks against the gaming industry 2014 eb F 400 CloudFlare reports a 400Gbps NTP attack Mar Oct Akamai54 reports a 54Gbps

SSDP attack TABLE I RECENT LARGE SCALE AMPLIFICATION ATTACKS AND THEIR PROPERTIES

Reference Year Amplification Protocol Peak Traffic Attacker Description Spoofed requests were directed to SNMP enabled devices on the MIT net- MIT [32] 2013 SNMP Unknown Unknown work which attacked devices outside the network. Attackers brought down GreenNet, a hosting company who’s customers in- GreenNet [2] 2013 DNS 100 Gbps Unknown cluding Privacy International and Zim- babwe Human Rights Forum. The attack targeted a real-time financial Prolexic [4] 2013 DNS 167Gbps Unknown exchange platform. Over 30,000 DNS servers were in- volved in the amplification attack. At- tackers also used SYN floods and pre- Spamhaus [8] 2013 DNS 300Gbps Cyberbunk fix hijacking to disrupt the Internet connectivity of Spamhaus and Project Honeypot. Attackers targeted game servers and A hacker group named streaming sites. Attacks against the PhantomL0rd [7] 2013 NTP 100Gbps DERP claimed respon- games industry are becoming increas- sibility on Twitter. ingly popular [34]. Latency increased all over Europe fol- lowing attack using 4,529 NTP servers. CloudFlare [25] 2014 NTP 400Gbps Unknown French hosting firm OVH also claimed to have seen an attack over 350Gbps at the same time. Many of the devices used in this attack Akamai [31] 2014 SSDP 54Gbps Unknown were home-based UPnP devices.

Figure 2 and Table I illustrate that the bandwidth used warning issued by US-CERT [33], and during a 13- in amplification attacks is also growing. In March 2013 week period in which Kuhrer¨ et al. reported a 92% drop an amplification attack was launched against Spamhaus in the number of vulnerable NTP servers [19]. As a [8]. The DNS based attack reached an estimated peak consequence we may need to reevaluate how we respond of about 300Gbps and was the biggest DoS attack ever to threats as they are discovered. For example, alerting recorded [39]. Nearly a year later and an even bigger system administrators about protocol vulnerabilities may attack reportedly reached a peak of 400Gbps by using prompt attackers to abuse the identified amplification NTP [25]. vectors. The attack traffic generated during the Spamhaus attack came from over 30,000 different DNS servers. C. Problem Description In order to guard against this and future attacks, they In this section we will provide high level descriptions deployed anycast routing and a distributed Content of the attacks and concepts seen so far. We will start by Delivery Network (CDN) [8]. Anycast involves BGP discussing the amplification factor of different attacks routers simultaneously advertising the same destination and go on to describe the building blocks of the most IP address so that attack traffic can be absorbed by common amplification attacks. many different data centers. However, relying on anycast 1) Amplification Factor: The amplification factor of and CDNs may be a short term solution, and it can an attack (X(P )) for a protocol (P ) is the ratio of the only prevent amplification attacks when amplifiers and total number of bytes in the amplified traffic (explicitly anycast routes are evenly distributed around the Internet. including headers, padding and payloads of all protocols The CloudFlare attack came 1 month after a “monlist” involved, such as Ethernet, IP, UDP or the application-

4 level protocol) and the number of bytes sent by the SYN requests to a reflector so that the reflector sends attacker (same calculation), as shown in Equation 1. SYN/ACK packets to the victim [41]. As well as the final destination as indicated by the number of response bytes(P ) spoofed source IP address, it is also possible for reflec- X(P ) = (1) number of request bytes(P ) tors and those that use them legitimately to be victims of reflection attacks. For example, in SYN flooding Our definition is slightly different from the one used attacks [42]–[47], the attacker floods a reflector with in [13], as we explicitly include all lower-level proto- spoofed SYN requests and changes the source IP address cols, whereas Rossow focused on the number of UDP of packets so they do not receive replies. The aim of payload bytes. Still, the amplification factors provided SYN flooding attacks is not to attack the final destination by Rossow [13] offer a convenient way of comparing indicated by the spoofed IP address, but to consume protocols and can help with prioritization. For example, enough resources at the reflector to make it unresponsive Rossow found that NTP had the highest amplification to legitimate traffic. The adversary can also attack multi- factor all of the protocols he tested. He found that if homed networks using reflectors. For example, if the attacks carefully select the NTP servers to maximize reflector is connected to the Internet by at least two their attack they can achieve an amplification factor uplinks, and the link between the reflector and the of 4670, which when compared to 64 for open DNS final destination offers significantly lower bandwidth resolvers shows us how urgent it is to update existing compared to the link between the attacker and reflector. NTP infrastructure. Then by carefully selecting a spoofed source address 2) Reflection: Many of the amplification attacks in which is reachable via the low bandwidth connection, the past were possible because the attacker can spoof the attacker can implement a DoS attack on this link. the address of the victim causing traffic to be “reflected” It is worth mentioning again, however, that not all by third-party servers, e.g., by open DNS resolvers [40] of the amplification attacks described in this paper use (see Section II-A). Figure 3 shows a reflection attack reflection, e.g., fork loop based attacks do not [16]. where an attacker (M) changes the source address in 3) Amplification: A key factor in amplification at- the request it sends to the reflector (R). Not knowing tacks is the ability of attackers to trigger responses which that the source address was spoofed, the reflector sends are significantly larger than the requests, either in terms its response to the final destination (D, i.e., the victim). of bytes or number of packets. Figure 4 describes the The key advantages of reflection attacks for the at- basic scenario without reflection where an attacker sends tacker are: (a) attackers hide their identity from D be- a request to an amplifier (A) which responds with a cause all traffic received by comes from third-parties; D higher volume of data than it receives. In this scenario (b) attackers can trigger attacks coming from different the amplifier, or the network between the attacker and geographic or topological regions of the Internet; and the amplifier, are the victim because they cannot cope (c) attackers do not receive responses and therefore do with the amplified traffic. The main advantage of such not risk using up their available download bandwidth. an attack is twofold. First, the adversary saves resources with respect to its network uplink. This is important in case of mobile scenarios. Second, discovering the trigger R of the attack is more challenging. In contrast to high volume flooding attacks, amplification triggers are hardly Request Response visible on frequently used uplinks, which complicates early detection. It is worth noting that the attacker model implies that the attacker is either capable to handle potential response M D traffic or that the attacker will not receive the response data. The latter follows directly in case of a successful Fig. 3. Reflection attack. An attacker (M) sends a spoofed request attack but can also be achieved by address renewals at to a reflector (R) which responds to the final destination (D). the attacker side. Pure amplification attacks will be of increased impor- One example of a DoS attack which uses reflection is a tance with the upcoming deployment of the Internet of TCP SYN/ACK attack, where an attacker sends spoofed Things (IoT). IoT networks are characterized by con-

5 strained devices with limited network capacity, typically sufficient uplink bandwidth to send requests to many connected via border routers to the Internet. Congesting amplifiers at the same time. Attackers can target more the path from some of the IoT devices to the gateway amplifiers, and further obscure the origin of attacks, by may lead to disconnecting the complete IoT domain. means of a botnet [17], [49]. The owners of bot-infected systems are unaware that Request their machines are being used in DDoS attacks. Alter- natively, in crowd-sourced DDoS botnets, participants M A willingly install attacking software on their machines, e.g., the Low Orbit Ion Cannon (LOIC) software [50]. Response Such volunteer botnets were used in Operation Payback to attack global companies, such as MasterCard, Visa, Fig. 4. Simple amplification attack. An attacker (M) sends a request and PayPal [5]. to an amplifier (A) which responds with more data than it received. Figure 6 shows one model of an amplification attack The response line is dashed in this instance to indicate that the attacker may not receive the response. using a botnet. In this example the attacker uses a controller (C) to send instructions to the botnet (B). The 4) Reflection and Amplification Together: All of the bots then send spoofed requests to amplifiers at similar amplification attacks seen in Table I combine reflection times, such that the bandwidth of B1...Bn accumulates. and amplification, a high level overview of these attacks is given in Figure 5. In this model an attacker (M) Requests Responses sends requests using the amplification protocol (P ) to A2 the amplifiers (A) but also uses reflection so that the amplifiers respond to the victim (V ). B1

A Command 2 C B2 A1 V Request Response

B3

Request Response M A1 V A3 Botnet B

1) Attacker sends 2) Amplifiers send Fig. 6. An attacker uses a controller ( ) to instruct a botnet ( ) to small requests to large and/or many C B amplifiers using responses to V simultaneously send spoofed requests to many amplifiers (A), causing the source IP Request Response saturating its amplified responses to be sent to the victim (V ). address of V. bandwidth. A3 6) Fraggle and Smurf Attacks: Fraggle and Smurf also use reflection and amplification, but their attacks Fig. 5. An attacker (M) sends spoofed requests to many amplifiers (A) causing amplified responses to be sent to the victim (V ). look slightly different from the model in Figures 5 and 6. Figure 7 shows a Smurf attack where M sends a request The volume of attack traffic which can be sent to V de- to the broadcast address of network (N), A acts as the pends on the accumulated available bandwidth between amplifier by duplicating the request, and the reflectors M and A1...An, the accumulated available bandwidth (R) send responses to the victim V . Fraggle attacks are between A1...An and V , and the amplification factor of similar to Smurf attacks but the requests are amplified P . Depending on the success of the attack, the volume even further by the end hosts that receive them. of traffic sent to the victim can result in a complete loss 7) Fork Loops: Fork loops are different to the reflec- of connectivity for the victim and their network. tion and amplification attacks because they rely on mes- 5) Amplification Attacks Using a Botnet: Most am- sages recursively being sent between SIP proxies [16]. plification attacks are launched from single origins [48] Yet fork loops have also been referred to as amplification and just appear to be distributed due to the large set attacks because they provide a way for an attacker to of amplifiers. However, a single attacker may not have amplify the number of requests they send to SIP proxies.

6 D. Discussion R1 1) M sends a single In this section we have described many different types request to the broadcast of amplification attacks. It is clear from our descriptions address of network N. Request Response that the attacks seen in Table I are very different from

Request Request Response Fraggle and Fork Loop attacks. M A R2 V Therefore, this survey will focus on the types of amplification attacks seen in Table I and as described in 2) A acts an emplifier Request Response Figures 5 and 6. The major advantages of amplification by broadcasting the request to R1, R2, and R3. attacks from an adversarial point of view are: 3) The reflectors • Attack traffic can be amplified beyond the attacker’s R3 send responses to Network N the victim. upload bandwidth. • The attacker remains anonymous by using reflection Fig. 7. Smurf attack. An attacker (M) sends a spoofed request to (IP address spoofing). the broadcast address of network (N). The amplifier (A) broadcasts • The attack traffic at reflectors and amplifiers can be the request to many reflectors (R) which respond to the victim (V ). very difficult to distinguish from legitimate traffic. • The attack complexity is rather low and it is thus relatively straightforward to get started with ampli- Figure 8 shows one example of what can happen when fication attacks even for the wide audience. two SIP proxies (L1 and L2) are not configured correctly and do not detect loops. It depicts the scenario described III.PREVENTING AMPLIFICATION ATTACK in [38] where a request for the user a@L1 is sent to In this section, we will describe preventative measures the proxy L1. In this example, L1 has two options for for the amplification attacks. For example, we discuss reaching a@L1 which are both located at L2. This causes preventative measures which amplifiers can use before L1 to fork the request and send two copies to a@L2 and responding to requests (e.g. response rate limiting), and b@L2 which also both fork the request to a@L1 and more radical approaches such as alternative content b@L1. The scenario is caused by misconfiguration and delivery systems [51]. We will discuss non-preventive n can potentially result in 2 duplicate requests created (i.e., reactive) countermeasures, such as detection and where n is the number of iterations. filtering, in Section V.

A. Alternative Internet Architectures

a@L1 Alternative Internet architectures such as Capability Based Architectures (CBA) [52], [53] or Content-Centric Networking (CCN) [51] may remove existing DoS vec- a@L2 b@L2 tors. For example, in CBA, senders must first obtain “permission to send” from the destination before sending packets. Anderson et al. [52] proposed that verification

a@L1 b@L1 a@L1 b@L1 points around the network ensure that the source has permission to send data to the destination. To obtain permission, Anderson et al. suggested that the source uses Request-To-Send (RTS) packets, which are routed a@L2 b@L2 a@L2 b@L2 a@L2 b@L2 a@L2 b@L2 between RTS servers to ensure the victim is not flooded. However, the problem with the CBA system from Anderson et al. [52], and the more recent TVA [53], ...... is that every packet must include some kind of extra Fig. 8. Fork Loops. In this example taken from [38] a single request “capability” information. Maintaining, exchanging, and spawns 2n duplicates where n is the number of iterations. checking capabilities creates a lot of extra overhead for networks, and the increased packet size may also increase fragmentation.

7 CCN will remove the possibility of DNS based am- predefined threshold2. This approach can be used to plification attacks simply because DNS is no longer re- detect flaws in protocols where the amplification factor quired. In CCN, ISPs can deploy content routers to cache at a single point might not seem significantly high, and data which many users request. However, CCN uses the it has been used to describe forking loops in SIP [16]. request/response paradigm in the form of “Interest” and C. Reducing the Number of Amplifiers “Data” packets, and it is currently unknown how resilient CCN would be to amplification attacks or new forms of Many amplifiers were used in the larger amplification DoS attacks. attacks. For example, over 30,000 separate open DNS resolvers were used in the Spamhaus attack (See Table I). B. Lowering Amplification Factors A number of projects listed in Section VI are attempting to bring misconfigured amplifiers to the attention of Alternative, to remain compatible with the current system administrators so that they can be patched or Internet design, is fixing the protocols that are vulnerable configured correctly. However, this relies on widespread to amplification. One such approach is to lower the cooperation between administrators who may not have amplification factors, e.g., by increasing the size of the the knowledge or the resources to update their servers. requests in vulnerable protocols. This would reduce the Another interesting point to make here is does the amplification factor, but also increase the traffic across Internet need so many public services such as DNS the Internet, which is not desirable. Moreover, it is servers? Perhaps more cooperation between network not reasonable to suggest that all protocols should be providers can lower the impact of amplification attacks amplification free. For example, it is quite reasonable to by lowering the number of amplifiers required to operate expect that request packets for large files are smaller or the Internet. fewer than the response. A more practical approach for lowering the amplifica- D. Response Rate Limiting tion factors may be to disable the redundant services that Moreover, amplifiers could also be configured to re- amplifiers offer. For example, Rossow showed that the spond to a limited number of request from each IP or Network Time Protocol (NTP) has the highest amplifi- network address within a given time frame. For example, cation factor out of the 14 UDP protocols he tested [13]. support for response rate limiting is easily applied to Kuhrer¨ et al. achieved a reduction of the amplification DNS when using newer versions of BIND. However, factor of NTP by disabling the NTP services with the rate response rate limiting protects against abuse of a highest request/response factors [19]. Since the services single amplifier and an attacker may simply choose to with the highest request/response factors do not affect use multiple amplifiers at a low request rate. It only the core capabilities of NTP, these extra services can be takes an attacker a short amount of time to look for disabled while still enabling time synchronization. a sufficient number of different amplifiers (less than a Next to NTP, many other protocols (e.g. DNS, Char- minute in some case [13]). Gen, SNMP) can be used for amplification attacks. E. Sessions for UDP Some DNS providers have recently started deprecating the DNS ANY request in response to the growing Many amplification attacks rely on stateless commu- threat of amplification attacks. One provider, CloudFlare, nication via the UDP protocol in order to send large now responds with the RCODE 4 “Not Implemented”1. amounts of data to spoofed IP addresses. Those amplifi- However, identifying and disabling services with high cation attacks are made more difficult if UDP-based pro- request/response factors takes time, and may result in tocols required sessions to be opened (similar to the TCP the loss of functionality for benign applications. three-way handshake) before large amounts of response One technique to reveal protocols which suffer from data can be transmitted. To counter this, one can include amplification attacks due to misconfiguration or bad session information in UDP packets. For example, clients design can be model checking [16]. By modeling the using the Steam query protocol have to request a 4- protocol using rewriting logic [54], a set of system byte challenge before they can request large amounts states can be generated and checked for amplification of information about a game server [55]. The client by comparing the cost of servicing requests against a has to append the challenge response to future requests. 2The cost in [16] is the number of duplicate packets generated by 1https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ SIP proxies

8 However, attackers may be able to use responses from attacks shows that it is still a problem today. Recent session initialisation exchanges for amplification attacks estimates state that it is still possible to send spoofed IP so long as they can open new sessions for the same packets from about 20% of the Internet [58]. The next victim with many amplifiers, and can also eavesdrop on section will discuss spoofing in more detail and discuss the victims Internet traffic to see responses. some of the methods proposed to defend against it. A downside to session hardening UDP protocols is that it increases the packet sizes (and, depending on IV. SOURCE IPADDRESS SPOOFING the implementation, requires additional packets for a An inherent requirement for amplification attacks in handshake), which conflicts in particular in resource- practice is IP address spoofing. UDP and IP have no constraint and real-time contexts. It may also add latency built-in mechanism to determine if the source address is to the initial request to open a sessions. The most spoofed, so amplifiers reply to the spoofed address in- challenging aspect of session hardening existing UDP- stead of the original sender. Using spoofing for malicious based services is compatibility with existing clients. In purposes was first discussed in 1989 [24], and a detailed order to prevent amplification attacks session support analyses of the problem was carried out by Heberlein and would have to be universal, and upgrading may cause Bishop in 1996 [61], and again by Dunigan in 2001 [62]. problems with legacy systems. Since then there have been many other surveys related to spoofing which we have summarized in Table II. These F. Differentiating Bots From Humans surveys can be broadly categorized as either focusing on Also Completely Automated Public Turing tests to tell spoofed packet detection/filtering [63], [64], or tracing Computers and Humans Apart (CAPTCHAs) [56] would the attacker [65]–[68]. prevent attackers from using certain services in DoS Chen and Yeung [43] also define three common IP attacks. While successful to defend against application- spoofing techniques which all have different purposes, level DoS attacks, CAPTCHAs are not successfully random spoofing, subnet spoofing, and fixed spoofing. In used in practice against amplification attacks, and we random spoofing, the attacker randomly generates source name them for completeness only. Consider, for example, addresses for the attacking packets. This technique is DNS, where lookups are often caused by a user visiting a often used in TCP SYN flood attacks [22] where the website. If such DNS requests required that a user com- destination of replies are not relevant to the success of pletes a CAPTCHA, then it would be harder for attackers the attack but the attacker still wants to obscure their to use open DNS resolvers for attacks. However, this identity. In subnet spoofing the attacker will choose a may delay a users access to information and complicate source address in its own subnet, which can help to legitimate automated services which use DNS. With this avoid some countermeasures such as ingress filtering, but in mind, Oikonomou [57] attempted to model human limits the number of possible victims. Fixed spoofing is behavior so that servers can automatically distinguish the form of spoofing which is most commonly used in between requests from bots and requests from humans. amplification attacks. This is where the attacker chooses There is another problem with only replying to re- the IP address of a single victim to be the source address quests from humans, and that is that many legitimate on the spoofed packets, meaning that replies will be sent automated processes need to make requests for infor- to the victim and not the attacker(s). mation over the Internet. These processes are prevented We will start this section by discussing the techniques from accessing services secured by a CAPTCHA or other used to monitor spoofing and to map networks which do bot detection mechanisms. not guard against it. Later we will (a) survey the contri- butions listed in Table II in a single concise discussion, G. Filtering Spoofed Packets and (b) significantly extending the discussion to include In most amplification attacks the attacker sends re- new approaches. This will involve categorizing spoofing quests with the spoofed IP address of the victim. Fil- defenses as being for either packet filtering or traceback, tering spoofed packets is considered one of the most as shown in Figure 9. effective countermeasures against amplification and other DoS attacks [19], [58]–[60]. However, in 2005 the MIT A. Monitoring Spoofing In The Wild ANA Spoofer Project showed that around 25% of ASes There are two techniques which are being used to look allowed spoofed IP packets to be sent out of their net- at spoofing on the Internet. Active monitoring attempts work, and the ability of attackers to launch amplification to send spoofed packets and monitor the replies, while

9 TABLE II SURVEY PAPERS FOR FILTERING SPOOFED IP PACKETS AND 1) Active Monitoring: The MIT Spoofer Project [58] DETECTING ATTACKERS. measures how susceptible the Internet is to IP spoof- ing. To achieve a high coverage they have created and Survey Name Papers Covered distributed an application which volunteers can install. Detecting Spoofed Packets [69] [70]–[72] The application sends several spoofed UDP packets to IP Spoofing Defense: An Intro- [73]–[88] a server controlled by the project. The application then duction [63] connects to the server using legitimate means to deter- On the State of IP Spoofing De- [69], [73], [75], [76], [81], mine which packets were received or lost. The results fense [64] [82], [85], [86], [89]–[106] of the MIT Spoofer Project have shown that about 25% DDoS: Survey of Traceback [71], [76], [90], [107]–[117] of ASs are currently vulnerable to IP spoofing. Daily Methods [66] statistics are also available on their website [131]. A Survey of IP Traceback [110], [113], [118]–[121] Mechanisms to Overcome Kuhrer¨ et al. [19] leverage the fact that some DNS Denial-of-service Attacks [67] proxies do not correctly change the IP addresses when A Survey on Packet Marking [90], [110], [111], [113], forwarding DNS packets to test if their AS allows IP and Logging [68] [115], [118], [120]–[128] spoofing. They found 2,063 ASes that allow spoofed On IP Traceback [65] [42], [70], [104], [107]– traffic by detecting if DNS replies have a different source [111], [113], [129], [130] IP addresses than the destination of the initial request.

The disadvantage of their approach is that it relies on networks which have open DNS resolvers that do not Peer-to-Peer Validating change the source IP address on responses. However, Encrypting Source IP Packets their approach does not depend on the distribution of Addresses volunteers like the Spoofer Project, and the researchers Third-Parties were largely free to choose which networks to investigate Detecting Flow and Filtering Correlation due to the many available open DNS resolvers. Spoofed Packets Routing Tables 2) Passive Monitoring: An orthogonal question to IP Headers see who is spoofing, is to measure how much Internet Using Network Topology Ingress Filtering traffic is actually being spoofed. The UCSD Network and RPF Telescope from CAIDA [59] is attempting to answer Spoofing Learning this question by monitoring traffic which is sent to Defenses Directions darknets. A darknet is an address-space which is routable Using Traffic Logs but where no traffic is expected to be sent, i.e., the addresses are not allocated. Monitoring traffic to darknets Packet Marking can be used to spot attacks, scans of the Internet, and ICMP misconfiguration of machines. Traceback Traceback

Input To explain how a darknet can be used to detect spoofed Debugging packets we will briefly describe the steps of a TCP- Controlled Link Testing SYN flooding attack [22]. When an attacker is using Flooding spoofing for a TCP-SYN flooding attack and randomly Tunneling chooses a source address for the spoofed packets, there using IPSec is a chance that the address is in the address space Fig. 9. A categorization of source IP address spoofing defenses. of the darknet. As a consequence, the victim of the attack will response to the spoofed addresses, and the SYN/ACK packets from the victim will appear as traffic to the darknet. These SYN/ACK packets are known as passive monitoring requires analyses of Internet traffic, backscatter, and since the darknets are supposed to cause e.g, NetFlow data. In the following two subsections we no traffic, backscatter is assumed to be the result of examples of both approaches. spoofing once misconfiguration has been ruled out.

10 B. Validating the Source IP Address that datagrams can not be fragmented. It is also not clear how big MASK labels are, and if they will fit in There is no built in mechanism in the Internet Protocol the 16-bit ID field. Furthermore, MASK appears to be which can prevent spoofing. Its function is simply to susceptible to eavesdropping attacks as MASK labels are provide best effort delivery of datagrams [132]. Never- not exchanged securely and are also sent in plain text in theless, over the next two subsections we will discuss subsequent packets. various techniques which can be used to filter spoofed Another example is the Source Address Validation packets. In this section we will concentrate on methods Architecture with Host Identity Protocol (SAVAH) [136], which use some form of authentication to validate pack- which can filter spoofed packets at the edge of local net- ets as they arrive and filter those which are not validated. works. It requires that all end-hosts and gateway routers In the next section we will look at more probabilistic support the Host Identity Protocol (HIP) [137], [138]. methods. SAVAH filters spoofed packets by requiring senders 1) End-to-End Address Verification: There are many replace the source IP address of packets with a hash. end-to-end methods with which peers can attempt to The hash is created using the contents of each packet validate the source IP address of packets. For example, and a key agreed previously when the sender joined the probes can be used to provoke responses from the source network. This is cryptographically stronger than [133] address to see if it sent the packet [46]. However, so long as the key was exchange securely. However, this packet loss means that some probes may be lost, and approach degrades performance of the network rapidly other unpredictable behaviour in the Internet means that due to the processing overheads of hashing every packet. probing cannot guarantee that the packet was spoofed. 2) Encryption: An overall more secure approach than Additional information embedded in packets and appending validation data to packets is to encrypt all IP which can be validated using a peer-to-peer network has packets. Using encryption between peers would not only been used to authenticate the source IP address [75], prevent most spoofing attacks, but it also has the added [84], [97], [103], [133], [134]. This information can be benefit of all Internet traffic being secure by default [94]. unique between two peers, and may also have a time One suitable mechanism by Gilad and Herzberg provides limit associated with it. The literature also uses different relatively lightweight encrypted communication [47]. terminology to refer this data. Common notations are However, the computational overheads and extra traf- “cookie” [97], [98], [135] or “key” if the data is used in fic caused by encrypting all IP traffic is currently im- cryptographic functions [75], [103], [136]. practical, and would also conflict with IoT scenarios Whilst the basic principle of using end-to-end methods using constrained devices. Nevertheless, encryption can to validate the source IP address is the same, all of the be used in select cases such as communication with proposals have their own strengths and weaknesses. For amplifiers. example, large “puzzles” sent by servers may themselves 3) Third-party Authentication: Sometimes it is not be used in amplification attacks [98], and there are ad- desirable for routers and end-points to use end-to-end ditional processing and space overheads associated with address verification, or negotiate keys and encrypt pack- generating and stamping “passports” that are appended to ets because of the additional processing and latency packets [103]. Some of these overheads can be lowered, overheads. Using extra third-parties which are usually for example, if only routers at the edge of networks not involved in packet forwarding offers a way of add data to, and validate, packets. However, this implies authenticating packets which can potentially lower the cooperation between network operators to install new extra processing demands placed on routers and end- functionality at the edges of their networks when the points [45], [139]–[141]. benefits to them may not outweigh the extra costs. For example, Gonzalez et al. [140] proposed that Lu et al. [133] proposed Multi-purpose Anti-Spoofing routers should send copies of packets to a “judge” Key (MASK) where packets are tagged with MASK la- (the trusted third-party). The judge should know the IP bels which are unique between the source and destination addresses serviced by the routers in order to make a routers. At first, MASK labels are exchanged using a decision whether or not the packet is spoofed, and the TCP connection. Then, MASK labels can be included judge can also query routers in the absence of data. in subsequent packets by overwriting the ID field in the Noureldien et al. [45], [141] suggested that authenti- IP header. However, MASK needs to be evaluated in cation servers in local networks can be used to determine more realistic scenarios. Overwriting the ID field means if TCP-SYN packets are spoofed. They propose that

11 all packets that exit a network are inspected by an paths between the source and destination of spoofed authentication server. An authentication server can also packets. One interesting idea is to use Ant Colony check incoming packets with the authentication server at Optimisation (ACO) algorithms to find these paths [147], the source network. This approach can lower processing and to collect TTL values which can be used to filter overheads for some hosts in the network but it does spoofed packets. not address concerns about additional latency and traffic It is even possible to filter spoofed packets by de- volume. tecting what operating system a remote host is using, i.e., by estimating the initial TTL of packets [91], [93]. C. Flow Correlation However, filtering spoofed packets based on the TTL Flow telemetry can help to identify anomalies in and other fields does not guard against spoofing attacks network traffic by inspecting statistical information of where the attacker can manipulate the values in the IP traffic that is aggregated by source and destination ad- header. dresses/ports. Kreibich et al. proposed to inspect asym- 2) Ingress Filtering and RPF: Filtering IP packets metries in packet counts per flow direction to find reflec- with spoofed addresses can be achieved using knowl- tion attacks from the victim’s perspective [142]. Rossow edge of the IP addresses allocated by the upstream or proposed to leverage volume asymmetries to identify downstream networks [73], [100], [148]. Ingress filtering amplification attacks, both from the amplifier’s and vic- filters incoming packets. In contrast, egress filtering tim’s perspective [13]. Related methods that target non- filters packets which are exiting the network. amplification attacks aim to detect TCP-SYN flooding Ingress filtering (BCP 38) is sometimes implemented attacks by observing unbalanced SYN and SYN-ACK at the periphery of the Internet to stop packets with packet flows [43], [44], [113], [121], [143], [144]. spoofed addresses being routed by edge routers [73]. However, not all network operators implement BCP D. Filtering Spoofed Packets Using Network Topology 38. Ingress Access Lists are also typically maintained Almost all of the filtering methods seen so far come manually, and having outdated or misconfigured lists can with a high cost in terms of additional latency, traffic prevent legitimate or allow spoofed traffic [102]. volume, and/or processing at routers. In this section we Unicast Reverse Path Forwarding (uRPF) is an imple- will discuss methods which can lower the overheads mentation of BCP 38 and uses forward routing informa- by using what information is already known about the tion to filter spoofed packets [83]. Incoming packets are structure of the Internet. For example, some IP addresses checked against a routers Forwarding Information Base are not meant to be used outside of local networks. (FIB) to ensure that packets are only forwarded if they Packets with private IP addresses (e.g., 192.168.1.1) come from the interface which is on the router’s best should not be routed, as Network Address Translation path to the source address. uRPF also has a “loose mode” (NAT) [145] at the source network should have changed where it can check the source addresses packets without the source address of the packet. taking the interface into account. This allowed uRPF More generic methods of detecting spoofed packets, to be used on routers with multiple links to multiple as discussed next, are probabilistic because the Internet ISPs [83]. is both dynamic and complex. However, some of these 3) Learning Directions: Routers can record informa- approaches also include a mechanism to determine if a tion from incoming packets in order to filter traffic which packet was actually spoofed following detection. comes from unexpected directions [74], [78]–[80], [89], 1) Using IP Headers: One way with which spoofed [106]. The Source Address Validity Enforcement (SAVE) packets can be filtered without using additional band- protocol [104] is one example where routers can learn width is to analyze information present in the IP headers. the expected incoming interface for a source address in If the legitimate values for a source IP address is known, order to authenticate subsequent packets. then spoofed packets which do not have the correct The approach proposed by Wu et al. [89] is called information can be identified and filtered. Source Address Validation Architecture (SAVA). To pre- For example, spoofed packets can be filtered if their vent IP spoofing in a local network, SAVA routers bind hop count does not match what is known about the the source IP address and MAC address to a specific topology of upstream routers. This information can be switch port. The next step is to filter packets at the Intra- estimated using the Time To Live (TTL) field in the IP AS level. This is done by associating source addresses header [85], [99], [146]. However, there may be many with the incoming interface. The last step, filtering

12 spoofed packets at inter-AS level, involves adjacent ASes packets [151], whereas an attack victim might want to exchanging address blocks so that packets from other know which network the attack originated from. ASes can be filtered. In amplification attacks, the victim receives attack However, these methods do not perform well during traffic from amplifiers. Thus, the traffic facing the victim legitimate changes to the Internet’s structure or when is not spoofed. Instead, spoofing detection and tracebacks there are multiple paths between two routers [74]. To needs to be performed at the amplifiers, possibly with the counter this problem these methods can consider multi- help of amplification honeypots [48]. ple valid interfaces per source address at the cost of lower filtering accuracy. Mirkovic et al. [74] proposed dropping It is also important to realize that the traceback can some TCP packets which originate from new interfaces. only be used to identify the source of spoofed packets. Under normal circumstances these packets should be Detecting the individuals involved requires many out- retransmitted and the operation of the Internet is not band techniques such as monitoring the chat networks severely compromised. However, this approach does not used by cyber criminals. Furthermore, tracing becomes help with combating amplification attacks which are inherently difficult in case of distributed attack sources, perpetrated using UDP or where the attacker retransmits such as DDoS botnets. attack packets. 4) BGP and Routing Tables: BGP is responsible 1) Using Traffic Logs: Tracing spoofed packets back exchanging routing information between ASes. As a to the attacker can be done by analyzing traffic flow result, many papers have proposed that BGP can also data collected by routers [113], [121], [144]. With log- be used to help filter spoofed packets [76], [77], [105], based traceback there is always the potential to trace e.g., by adding anti-spoofing information to BGP update a single packet [143], and to trace attackers who use messages [81] using packet marking techniques such as reflection. However, these methods often require that Pi which we talk about in Section IV-E2. traffic data is either collected or stored by routers [107]. One way to use BGP routing tables to filter This comes with many practical difficulties such as ad- spoofed packets is to use Distributed Packet Filtering ditional hardware costs, as was the case with the original (DPF) [76], and its extensions Inter-Domain Packet proposal by Snoeren et al. [113], which requires Source Filters (IDPF) [77], [105] and Extended IDPF [134]. Path Isolation Engine (SPIE) routers in place of existing Using IDPF a router examines BGP routing tables to routers. One solution to replacing existing routers is to check if it is on the optimal path between the packet’s use tap devices which eavesdrop on traffic [152]. Finally, source and destination. However, this approach suffers one can lower the amount of storage required to trace from the same security flaws as BGP because there is no attackers by using hashes [121]. built-in mechanism to check the integrity and source of 2) Packet Marking: The idea of packet marking is BGP messages [149]. To improve the security of BGP to record the path which packets follow into the pack- and thus IDPF, Dawakhar et al. have suggested using ets [71]. Early packet marking schemes appended the IP Credible BGP [150]. addresses of routers into packets [71], [119]. However, E. Tracing the Attacker the four addition bytes needed to represent an IPv4 address and the large number of hops quickly adds to the Next to detecting and filtering spoofed IP packets, size of packets. Song and Perrig suggested reducing the an orthogonal challenge is to trace the actual source amount of space required by encoding addresses using of spoofed traffic [65]. Such tracing is useful, not only hashing and a map of upstream routers [111]. Yaar et to stop attacks as they are happening by filtering the al. discussed ways to lower the space needed by using attack traffic at the source (thus saving the resources at shorter identifiers than IP addresses [82]. However, ap- upstream networks), but also so that the perpetrators can pending data unnecessarily to packets is still undesirable be prosecuted and further attacks prevented. because it can increase fragmentation. To address this Tracing spoofed packets is difficult because of limited problem some packet marking schemes also suggested access to external routers and the the high overheads overloading IP header fields [71], [86], [88], [90], [111] involved. The existing traceback vary in their objective and only encoding the addresses of edge routers [87]. and where they are applied. For example, an adminis- trator of a local network might want to know which Savage et al. introduced Probabilistic Packet Marking MAC address or interface is being used to send spoofed (PPM) to reduce size and processing overheads of packet

13 marking even further [71], [110]3. PPM can be used 3) ICMP Traceback: Bellovin et al. proposed iTrace to identify network path(s) traversed during an attack where routers send ICMP messages to the destination so long as the victim receives sufficient marked pack- address of packets they forward so that the destination ets. Dong et al. [154] designed a single-bit-per-packet can see the path which the packet followed [109]. ICMP scheme. However, Adler [92] noted that there is a trade- traceback can also be probabilistic in that the chance off between the number of bits allocated to PPM and the of a router generating an ICMP message is small, thus number of packets that must be received by the victim. lowering overheads in a similar way to PPM [129], [158], Duwairi et al [155] proposed a hybrid PPM and data [159]. Mankin et al. improved iTrace with “intention- storage method called Distributed Linked-List Traceback driven” traceback after they noticed that the chance of (DLLT). The “store, mark, and forward” operation used a router picking an attack packet close to the attacker by DLLT requires a “marking field” in each packet is much smaller than closer to the victim for certain big enough to store a single IP address, and a data DoS attacks [129]. Wang and Schulzrinne also proposed structure on each router in which to store information a new ICMP message which can be used in ICMP about forwarded packets. Any router which marks a traceback for reflection attacks [160]. packet must first store the address in the marking field 4) Link Testing: Link testing is the systematic testing (if there is one) along with a packet identifier, then the of intermediary links between routers, such as imple- router is free to write its address in the marking field mented via input debugging [107], DECIDUOUS [70], before forwarding the packet. A linked list is inherently or controlled flooding [108], as described next. created using this operation because the address in the Input debugging attempts to determine from which marking field points to the previous router, which has upstream router an attack is coming from by recursively a record of where it received the packet from, and so generating attack signatures to distinguish malicious on. However, its difficult to trace attacks with multiple packets from normal traffic. However, attack signatures attack sources [127]. To counter this, Song and Perrig that only match malicious traffic are difficult to create. looked at the security of markings and proposed using Good attack signatures match only attack traffic and a time-released key chains to authenticate them [111]. only little to no legitimate traffic [107]. Li et al. [12] proposed an efficient packet marking The Intruder Detection and Isolation Protocol scheme specifically for reflection attacks called Authen- (IDIP) [72] describes an architecture which also uses ticated Deterministic Packet Marking (ADPM), which is attack signatures and can be used for link testing and an extension of the approach proposed by Belenky et attack mitigation. In IDIP a single Discovery Coordinator al. [156]. ADPM assumes that all routers are capable of sends trace messages to other IDIP enabled devices. The matching request and response packets and that routers trace messages contain a description of the event, i.e., adjacent to reflectors cooperate to copy packet markings an attack signature, using the Common Intrusion Spec- from the request packets to the replies. ification Language (CISL) [161]. IDIP devices which Dean et al. phrase packet marking as a polynomial receive trace messages reply with report packets. The reconstruction problem and encodes path information as Discovery Coordinator can then decide what action to points on polynomials [90]. Chen and Lee also extended take, including instructing other IDIP devices to block their work to target reflection attacks [157]. They did this attack traffic for a short amount of time [72]. by requiring reflectors copy packet markings from the Another link testing method uses IPSec [162]–[164] request packets to the replies. This enables the victim to to trace the network from where a spoofed packet trace paths to the attacker using less than 4,100 packets, originated. For example, the DECIDUOUS implemen- but it may be possible to combine logging at routers tation [70] creates secure tunnels between itself and up- and PPM to achieve traceback with a smaller number of stream routers until it finds the network from where the marked packets [120] attack is coming from. However, DECIDUOUS needs A drawback of most packet marking schemes is that to have a complete overview of the network topology they rely on routers to maintain and update the markers. to choose routers with which to tunnel. Furthermore, In case routers drop or do not extend the marks, packet DECIDUOUS has high processing and traffic overheads marking becomes significantly less effective. caused by setting up and tearing down secure tunnels. Controlled Flooding is a link testing method which 3Shokri et al. [153] had a similar idea 6 years later and called it floods each upstream router with packets. This technique Dynamic Marking. needs the knowledge of the topology of the Internet.

14 Thus, a map of the Internet is obtained before link test- al. [11] classifies DoS defenses into two categories: (i) ing [108]. The purpose of flooding upstreaming routers network/transport-level, and (ii) application-level. They is to determine if the attack traffic affected. If the attack also sub-categorized DoS defenses based on their de- traffic is disturbed significantly when sending traffic to ployment location: (i) source, (ii) destination, (iii) net- a router then it is assumed that this particular router is work, and (iv) distributed/hybrid. one forwarding attack traffic. However, in this survey we are concerned specifically with amplification attacks, and we observed that it is also F. Discussion possible to defend against amplification attacks at the We have surveyed approaches to defend against spoof- amplifiers. Therefore, we have have split amplification ing. However, there are also more theoretical works in attack defenses into the following location categories this area. For example, given a graph of the network described in Figure 10: (i) at the victim’s network, (ii) at topology and a set of firewall rules for each node, San- the source network(s), (iii) a single unspecified location tiraveewan and Permpoontanalarp proposed a methodol- in cases where the authors have not been clear about ogy which can check to see if spoofing is possible [165]. the deployment location, (iv) distributed, and (v) at the With all of these defenses, it may be confusing as amplifier(s). In cases where the amplifier itself is the to why spoofing is still a problem. There are many target of an amplification attack, defenses will be limited practical and economic reasons. Many of the proposals to source-based and amplifier-based defenses. incur extra latency, traffic volume, computation, and/or storage overheads. Others are expensive to implement, as they require new hardware or staff to maintain them. Amplifier AS Finally, it is not clear how well the methods will perform A with only limited deployment [76], and what rewards x x they offer to early adopters [81]. Amplifier Defences We have seen that it is to difficult to prevent spoofing x or trace the attackers in reflection/amplification attacks x without considerable investment and cooperation by the x different network operators. Therefore, we have to look x x for other ways of detecting and mitigating amplification attacks as soon as possible. The next section will address x x this topic in more detail. Source AS Victim AS V. DETECTINGAND MITIGATING AMPLIFICATION ATTACKS The preventative measures described in Sections III M V and IV are effective defences against amplification at- tacks. Nevertheless, we have seen that they cannot al- Source Defences Victim Defences ways be relied upon. So the defences described in this Distributed Defences section are to be used when preventative measures fail. Fig. 10. Locations for defending against amplification attacks. Defending against amplification attacks involves at- Routers are marked x. tack detection and attack mitigation, e.g. packet filtering or black holing. Attack detection is easier to perform It is also important to note that not all of the DoS de- near to the victim because traffic flows resemble a funnel fenses surveyed by Chang and Zargar et al. are applicable with many attackers sending packets to a single loca- to amplification attacks. The most devastating attacks we tion [11]. In contrast, attack mitigation is best performed described in Section II originated from multiple sources, closer to the source to save the resources of the victim and combined both traffic amplification and reflection. and upstream networks. Therefore, in this section, we will discuss the defenses Chang [42] explained that DoS defenses can be in Table III which include new proposals that specifically located at four areas: (i) the victim’s network, (ii) target amplification attacks, but we will also include the victim’s ISP network, (iii) further upstream net- some older proposals which can part-defend against works, and (iv) attack source networks. Zargar et amplification attacks, e.g., defenses against reflection.

15 TABLE III METHODS FOR DETECTING AND PREDICTING AMPLIFICATION ATTACKS.SOMEOFTHESEPROPOSALSALSOINCLUDENOVEL TECHNIQUES WHICH AIM TO IDENTIFY AND FILTER ATTACK PACKETS.

Method and References Description Location Time Before During

Attack pattern correlation [166] Tries to detect reflection attacks by correlating the arrival Victim X rate of packets at the victim with known attacks.

Missing request packets [15], [167]– Attempt to match incoming responses to previously sent Victim X [170] requests.

History-based IP Filtering (HIP) [171] Attempts to filter packets during periods of high congestion Victim X which come from previously unseen addresses.

Comparing incoming and outgoing pack- Uses protocol specific knowledge to predict the number Source X ets at source networks (D-WARD) [172], of expected responses, e.g., replies to ICMP requests. Can [173] also rate limit attacks at the source.

Comparing the volume of incoming and MULTOPS [174] and TOPS [175] Unspecified X outgoing traffic [174], [175]

Detection with Information Sharing Aimed at TCP based reflection attacks, but reflectors Reflectors / X (DIS) [176] collaborate to improve the accuracy of attack detection. Amplifiers Similar collaboration could potentially improve attack de- tection at amplifiers.

PacketScore [177] Routers score packets, and communicate with a central Distributed X server for a global view and filter packets with a high score.

Repetitive packet sizes [178] Monitoring DNS packet sizes as well as the number of Distributed X packets across multiple routers. Suspicion is based on thresholds calculated using real data from the GEANT network.

Comparing payload bytes of request and Analysed NetFlow data to detect pair-flows where the Distributed X response packets [13] response payloads are larger than the request payloads (a similar idea to that which is used in MULTOPS and TOPS). Limited to 14 UDP protocols.

Comparing payload bytes of request and Combines techniques from Rossow [13] (comparing re- Distributed X response packets, plus compare packet quest and response sizes) and Huistra [178] (similar packet sizes of requests [20] sizes between requests).

Aggregate-based Congestion Control Looks for high bandwidth aggregates (collections of pack- Distributed X (ACC) [179] ets sharing the same destination address). Uses pushback (also used in [180]) to instruct upstream routers to rate- limit flows.

Spoofing protection for amplifiers [135] Specific to amplification attacks. This method detects Distributed X spoofed packets which do not have the correct session key provided by the amplifier for the source address.

AD and PAD [181], and TRACK [182] A congested victim instructs upstream routers to use packet Distributed X marking in order to trace the attack and then requests they filter the traffic. These methods may need to be updated for amplification attacks to take reflection into account.

Game theory to predict attacks [183] It is possible to study the motivation of attackers and the n/a X security of the Internet to predict attacks.

Darknets to detect scans [13], [184]– Monitoring darknet traffic can detect random scans for Distributed X [186] amplifiers such as those seen before the Spamhaus at- tack [186].

Honeypots to detect scans and at- Honeypots can take the place of amplifiers and are a Amplifiers XX tacks [13] powerful way of detecting scans and amplification attacks. They also require careful configuration so they do not cause harm to the victim.

16 A. Victim-end Defenses neighboring routers to the victim will then be forwarded to this IP addresses (or more precisely to the MAC Despite attack detection and packet filtering being address), and finally discarded at IXP layer-2 ingress separate objectives, many proposals attempt to do both switches. near the victim. Detecting attacks at the victim’s network may be Kambourakis et al. [15], [167] proposed a DNS Am- ineffective because bandwidth may have already become plification Attacks Detector (DAAD) which logs outgo- saturated, or the volume of traffic is too much to process. ing DNS requests and incoming responses in lookup This means that automated responses for filtering packets tables at the victim’s network. Responses are matched or alerting upstream routers to throttle traffic may not to outgoing requests and responses that don’t match function correctly. In order to avoid this problem, another requests are flagged as suspicious. The authors also possible location for detecting and filtering amplification propose that the DAAD should be able to alter firewall attacks is at the source network. rules to filter packets. However, amplification attacks do not only misuse DNS as we described in Section II. So B. Source-end Defenses a more general detection method is desirable. Source-end defenses are desirable because they can Tsunoda et al. [169] proposed a general method for stop attack traffic before it gets to upstream routers. matching request and response packets at a single point However, source-end detection and filtering techniques between the amplifier and the victim, e.g., at the vic- may not be an effective defense against amplification tim’s gateway router. They later extended their work attacks because: (i) the source of the attack can be dis- with mathematical analysis and additional experimental tributed, meaning that the solutions need to be deployed results [170]. However, in order to correctly identify on all networks, (ii) it can be difficult to differentiate the responses for each request, a router needs to record between legitimate and attack traffic if each attacker only the source and destination addresses, protocol field, sends a few requests, and (iii) there is no immediate application headers, etc. for every request it forwards. incentive for network providers to deploy source-end This requires memory-intense management operations. detection and filtering techniques because it is unclear A partial solution to this problem is to use Bloom what benefit it offers their customers. filters to efficiently store requests and check them against One example of a scheme proposed to work at the incoming response packets [168]. attack source is by Mirkovic et al. [172], [173]. They History-based IP Filtering (HIP) [171] attempts to proposed D-WARD specifically to detect DoS attacks filter packets during periods of high congestion which which involve spoofed packets or high traffic volumes. come from previously unseen addresses. It does this by They monitor both inbound and outbound traffic flows at adding addresses to a table during normal operation, and the source network, and compare them with flow models uses a sliding window to remove expired addresses. derived from normal traffic. The authors also note that an Wei et al. [166] proposed using traffic pattern corre- attacker will not reduce its outbound traffic even when lation to look for patterns which are out of the ordinary, notified of congestion at the victim, so D-WARD can rate or which match known attack patterns. The advantages limit suspected source addresses at upstream routers. of using traffic pattern correlation and HIP for attack detection, are that they are lightweight and protocol C. Distributed Defenses independent. However, methods to detect attacks based Victim-end and source-end defenses tend to be de- on previous behavior can struggle to distinguish between signed to run in isolation on a single machine, e.g., at attacks and unexpected bursts in legitimate traffic (flash a border router between networks. However, detecting crowds) [187]. Furthermore, an attacker that knows these and filtering amplification attacks at a single point in the defenses can “train” the victim before the attack [171]. Internet is problematic because of asymmetric routing, After an attack has been identified, traffic can be and the fact that attacks are distributed. This means dropped before it enters the victim network by in- that in order for isolated defenses to be effective, all strumenting the control plane. A common approach is inbound and outbound paths in the Internet should be blackholing of IP prefixes or host addresses at Internet symmetrical, and all networks should support the new Exchange Points (IXP) [188]. In this case, a border router defenses. of the victim network signals a specific next hop for the Amplification attacks are distributed threats against addresses under attack, using BGP updates. Traffic from many potential victims, and as a result they require

17 distributed defenses. Some distributed defenses also detected specifically by monitoring DNS packet sizes can detect and filter attacks after a victim has been as well as the number of packets across multiple taken offline by the attack and cannot use automated routers [178]. Huistra’s method is split into two parts. methods which use the affected connections to alert The first (which can also be used to detect attackers) upstream routers [13], [20], [177], [178]. It is even focuses on detecting IP addresses generating a suspicious possible to detect and filter DoS attacks with limited number of similar sized DNS requests. Suspicion is deployment of a distributed protocol alongside legacy based on thresholds calculated using real data from the equipment/protocols [189]. GEANT network [178]. The second part can be used to Kim et al. [177] proposed PacketScore which uses detect the victim, and looks at the number of large DNS a DDoS Control Server (DCS) to collate reports from packets sent to a single IP address. routers across the Internet. Routers with special reporting Rossow’s analysis and detection of amplification at- capabilities, called Detecting-Differentiating-Discarding tacks is similar to Huistra’s but is not limited to a single Routers (3D-R), mark suspicious packets with a “score” protocol [13]. Instead, he focused on 14 UDP protocols which reflects how likely they are to be involved in an which allow amplification. By analyzing traffic samples attack. The 3D-Rs then filter packets based on a variable taken from routers belonging to a single ISP, Rossow was score threshold provided by the DCS, which varies the able to detect 15 real life amplification attacks against threshold depending on the current load at the victim and multiple victims by comparing sent and received bytes. the score distribution of attacking packets. Based on the work by Rossow, Bottger¨ et al. [20] Mahajan et al. proposed attack detection at victims in developed a protocol-agnostic approach to detect ampli- terms of “aggregate” flows, and proposed using push- fication attacks. They introduce the following detection back mechanisms to filter flows at upstream networks criteria, which are independent of a specific network whenever a link experiences sustained severe conges- service, but base on the assumption that attackers reuse tion [179]. In pushback, the congested router asks up- attack requests: (i) similar packet size among all requests stream routers which are involved in the flow aggregate (and responses), (ii) similar payload among all requests to rate limit traffic flows [179], [180]. (and responses), (iii) an increased amount of ICMP Chen and Park [181] proposed an Attack Diagnostic unreachable messages, and (iv) incorrect TTL values. (AD) system in which DoS attacks are detected near to They found that the first two criteria are most suitable the victim, and packet filtering is executed close to the for amplification detection. attacker. AD also combines some familiar techniques; packet marking (Section IV-E2) is used for traceback, D. Defenses At Reflectors/Amplifiers and an approach similar to pushback is used to alert the Rossow and Huistra also showed that it is possible source networks. Similarly, TRACK combines packing to detect open DNS resolvers that have been abused in marking with packet filtering [182]. However, AD and amplification attacks by analyzing traffic data collected Track are currently not suitable defenses for amplifica- by routers in a similar way as mentioned in the previ- tion attacks because their traceback methods will only ous subsection, but from an amplifiers perspective [13], trace back to the amplifier, but not to the actual attacker. [178]. It is also possible to detect amplification attacks by Another approach for filtering spoofed packets, which analyzing traffic flow data collected by multiple routers. was specifically designed to defend against amplification Usually these methods require data from locations be- attacks, requires that session tokens are sent along with tween the source and the amplifier, as well as data from requests to amplifiers [135]. This requires that the first between the amplifier and the victim [13], [20], [178]. time a request is received from a new address, the However, it is not required to have data from between amplifier replies with a unique session token which the the attacker and amplifier simply to detect DDoS attacks. sender should include in all future requests. Yu et al. [187] proposed using flow correlation to detect Including the same session token in all requests has DDoS attacks, but unlike the correlating method pro- low processing overheads but adds to the size of each posed by Wei et al. [166], Yu’s method can distinguish packet. Furthermore, it is prone to eavesdropping if attacks from flash crowds. This was possible because session tokens are not encrypted. If the attacker can it has access to data collected by multiple routers in a eavesdrop on the victims Internet traffic then they can “community network”. also agree new session tokens with amplifiers the victim Huistra showed that amplification attacks can be has not yet contacted.

18 Peng et al. [176] focused on TCP based reflection It is also possible to detect scans for amplifiers which attacks and used mechanics which might also improve may act as a warning for future attacks. For example, the accuracy of detection at amplifiers. Their method darknets (also known as blackholes) are unused IP ad- monitored the cause of packets instead of just counting dress spaces on the Internet. Since the IP addresses in them. In their proposal, reflectors monitor incoming TCP darknets are supposed to be unused, any traffic to or from RST packets and monitor those which have a corre- a darknet is a sign of either scanning, misconfiguration, sponding SYN/ACK state for the outgoing connection. or malicious intent [190]. RST packets indicate that the reflector received a spoofed Fachkha et al. [184]–[186] looked at 1.44TB of traffic SYN packet from an attacker and sent a SYN/ACK to data for a /13 address block of darknet IPs 4, and found the victim, at which point the victim has replied with 134 separate incidents which they claimed may have a RST packet. Peng et al. suggested that collaboration been amplification attacks. between reflectors can be used to improve the accuracy However, Fachkha et al. may have detected scans for of attack detection. Once an attack has been detected, open DNS resolvers rather than actual attacks. To explore their system sends a warning to all other participating this idea we can look at Tables 7 and 8 in [186] to see reflectors instructing them to stop the attack. the incidents they detected. Specifically, they detected 2 large events (February 19th and March 18th) with E. Defenses at Single Unspecified Locations very high packets per minute. March 18th is interesting Not all DoS attack defenses are designed with a partic- because it is the same day as the Spamhaus attack [8]. ular location in mind, or the location was not explicitly However, this looks like a horizontal IP scan because it specified. This is problematic because the challenges targets 50,257 separate IPs with 1 packet each, which is vary among locations. indicative of a horizontal scan rather than an attack. We can also take a closer look at the Spamhaus MUlti-Level Tree for On-line Packet Statistics (MUL- incident by using Figure 6 of [186], which shows the TOPS) [174] is one example where a router somewhere packets per hour going to the Darknet monitored by on the Internet is used to compare the volume of in- Farsight Security: coming and outgoing traffic to look for DoS attacks. However, if MULTOPS is used on central routers which • The first spike we are interested in is at 337 hours, th route packets for many different addresses, then the tree which is on the 14 of March. This is shortly data structure it relies on will consume a significant before the Spamhaus attack which was reported by th amount of resources. In fact, MULTOPS itself can be CloudFlare as taking place on March 18 [8]. targeted by memory exhaustion attack [174], [175]. • The second interesting data spike at 385-409 hours Tabulated On-line Packet Statistics (TOPS) [175] im- is also before the attack. th proves on the accuracy of MULTOPS by taking into • The graph for the 18 of March (the day of the account the protocol being used, and also improves attack) is one of the quietest periods shown. efficiency by using fixed length tables instead of trees. • The next spike they detect is at 517 hours, which This makes TOPS suitable for use on busy links [11]. is 3 days after the attack. Both MULTOPS and TOPS assume that legitimate in- By referencing what we know about the Spamhaus coming and outgoing traffic is proportional [175]. How- attack [8], we suggest that the information presented by ever, this is not always the case, e.g., when streaming Fachkha et al. [186] shows horizontal scans for open video. Attackers may also try to counteract MULTOPS DNS resolvers which may be related to the Spamhaus and TOPS by trying to balance incoming and outgoing attack. Furthermore, attackers are unlikely to waste band- data volumes during an attack [11]. width sending speculative requests to unknown IPs when they can try to maximise the impact of an attack by only F. Predicting Future Attacks sending requests to known amplifiers. This supported by the quiet period observed by Fachkha et al. on March It is desirable to know about DoS attacks before they 18th. happen. To this end, Fultz et al. [183] proposed using a Finally, to support defenses and monitor attacks, one game theoretical approach to predict DDoS attacks. They can set up amplification honeypots that emulate protocols found that attackers only launch attacks if defenders have not invested in adequate protection or if penalties, e.g, 4The data was provided to Fachkha et al. by Farsight Security monetary costs and risks of being caught are low. https://www.farsightsecurity.com/.

19 TABLE IV that are vulnerable to amplification abuse. Honeypots INITIATIVES TO IDENTIFY AMPLIFIERS can be used to log scanning activity and report attacks that abuse them. In addition, Kramer¨ et al. show that Reference Description honeypots can be used to derive signatures of attack Open Resolver Scans for open DNS resolvers and provide an traffic, such as domains abused in DNS requests [48], Scanning automated system to notify affected networks. which is useful for detecting future attacks. Project [191] Open DNS Scans for open resolvers and allows to query G. Discussion Resolver for such resolvers in a certain IP address range. Project [26] Most of the defenses described in this section focus on Measurement Maintains a list of DNS servers that are known amplification attack detection and filtering at the victim Factory [192] to serve as globally accessible open resolvers. or by using distributed algorithms. Amplification attack Open NTP Scans for NTP servers in IPv4 which can be defenses at the source networks are more desirable, but Project [193] used in an amplification attack. it is unlikely that defences specific to a single attack, e.g., amplification attacks, will be implemented in the short-term and on a large scale. can mitigate attacks even when the victim has gone off- One contribution of this paper is to survey the defenses line and is unable to take counter-measures itself. How- currently available for amplifiers and to make some ever, these methods require more collaboration between suggestions for future directions. We found that this area network providers than is currently the case [11]. has had relatively little attention compared to defenses at routers, but by adopting one of the approaches detailed More research is required to close the attack vectors in Section III it may be possible for amplifiers to prevent which are being used in amplification attacks, e.g, clos- amplification attacks from happening in the first place. ing open DNS resolvers, patching NTP servers, and pro- moting ingress filtering. A number of ongoing initiatives VI.CONCLUSIONS aim at tackling these issues, as summarized in Table IV.

This paper discusses the current state of the art of REFERENCES research proposals for detecting, preventing, and tracing amplification attacks. As part of this, we have also [1] M. Handley, E. Rescorla, and IAB, “Internet Denial-of- surveyed defenses against source IP address spoofing, Service Considerations,” RFC 4732 (Informational), Internet Engineering Task Force, December 2006. [Online]. Available: which is essential for amplification attacks. http://www.ietf.org/rfc/rfc4732.txt We have concluded that preventing source IP spoofing [2] T. Brewster, “Cyber Attacks Strike Zimbabweans is the effective way of defending against amplification Around Controversial Election,” August 2013. [On- attacks. However, spoofed packets can still be sent from line]. Available: http://www.techweekeurope.co.uk/workspace/ zimbabwe-election-cyber-attacks-123938 large parts of the Internet. So we need effective methods [3] J. Leyden, “US Credit Card Firm Fights DDoS Attack,” to detect and filter DoS attack packets as close to the September 2004. [Online]. Available: http://www.theregister. source as possible. co.uk/2004/09/23/authorize ddos attack/ [4] Prolexic, “Prolexic Stops Largest-Ever DNS Reflection Another subject for future work is to assess the de- DDoS Attack ,” May 2013. [Online]. Available: http: fenses we have covered against one another using a wider //www.tinyurl.com/prolexic-167gbit list of empirical criteria, e.g., monetary cost, accuracy, [5] A. Pras, A. Sperotto, G. Moura, I. Drago, R. Barbosa, R. Sadre, memory overheads, levels of inter-AS cooperation, etc. R. Schmidt, and R. Hofstede, “Attacks by Anonymous Wik- iLeaks Proponents not Anonymous,” 2010. Zargar et al. [11] surveyed the metrics used to asses DoS [6] M. Calce and C. Silverman, Mafiaboy: How I Cracked the defenses and discussed their categorization in some of Internet and Why It’s Still Broken. Viking, 2008. these terms. However, a more detailed study on individ- [7] D. Takahashi, “Hackers Attack Dota 2 and League ual defenses is crucial because all of the proposals we of Legends Servers in Quest For One Game Livestreamer,” December 2013. [Online]. Available: surveyed come with their own strengths and weaknesses. http://tinyurl.com/PhantomL0rd-drdos Some of which may not be obvious, and it is important [8] I. M. Prince; CloudFlare, “The DDoS That Almost for system administrators to be able to weigh up their Broke the Internet,” March 2013. [Online]. Available: http: options in a concise and meaningful way. //blog.cloudflare.com/the-ddos-that-almost-broke-the-internet [9] J. Mirkovic and P. Reiher, “A Taxonomy of DDoS Attack Promising amplification attack defences appear to be and DDoS Defense Mechanisms,” ACM SIGCOMM Comput. distributed DoS detection and filtering algorithms, which Commun. Rev., vol. 34, no. 2, pp. 39–53, Apr. 2004.

20 [10] C. Douligeris and A. Mitrokotsa, “DDoS Attacks and Defense [29] J. Damas, M. Graff, and P. Vixie, “Extension Mechanisms for Mechanisms: Classification and State-of-the-art,” Computer DNS (EDNS(0)),” IETF, RFC 6891, April 2013. Networks, vol. 44, no. 5, pp. 643 – 666, 2004. [30] US-CERT, “UDP-based Amplification Attacks,” 2014. [11] S. Zargar, J. Joshi, and D. Tipper, “A Survey of Defense [Online]. Available: https://www.us-cert.gov/ncas/alerts/ Mechanisms Against Distributed Denial of Service (DDoS) TA14-017A Flooding Attacks,” Communications Surveys Tutorials, IEEE, [31] Akamai, “SSDP Reflection DDOS Attacks,” vol. 15, no. 4, pp. 2046–2069, 2013. 2014. [Online]. Available: http://www.prolexic. [12] Y. Li, Q. Wang, F. Yang, and S. Su, “Traceback DRDoS com/kcresources/attack-report/attack report q214/ Attacks,” Journal of Information & Computational Science, Prolexic-Q22014-Global-Attack-Report-A4.pdf vol. 8, pp. 94–111, 2011. [32] MIT, “2013-05-16 SNMP Amplification Attack,” May 2013. [13] C. Rossow, “Amplification Hell: Revisiting Network Protocols [Online]. Available: http://tinyurl.com/MIT-drdos for DDoS Abuse,” in Proc. of NDSS. Internet Society, 2014. [33] US-CERT, “NTP Amplification Attacks Using CVE-2013- [14] R. Vaughn and G. Evron, “DNS Amplification 5211,” 2014. [Online]. Available: https://www.us-cert.gov/ Attacks,” March 2006. [Online]. Available: http: ncas/alerts/TA14-013A //crt.io/DNS-Amplification-Attacks.pdf [34] Akamai, “The State of the Internet [security],” September [15] G. Kambourakis, T. Moschos, D. Geneiatakis, and S. Gritzalis, 2014. [Online]. Available: http://www.stateoftheinternet.com/ “A Fair Solution to DNS Amplification Attacks,” 2nd Inter- resources-web-security-2014-q4-internet-security-report.html national Workshop on Digital Forensics and Incident Analysis [35] CERT Advisory, “Smurf IP Denial of Service Attacks,” (WDFIA 2007), pp. 38–47, 2007. 1998. [Online]. Available: http://www.cert.org/advisories/ [16] R. Shankesi, M. AlTurki, R. Sasse, C. A. Gunter, CA-1998-01.html and J. Meseguer, “Model-checking DoS Amplification for [36] S. Kumar, “Smurf-based Distributed Denial of Service (DDoS) VoIP Session Initiation,” in Computer Security–ESORICS. Attack Amplification in Internet,” in Proceedings of the Second Springer, 2009, pp. 390–405. International Conference on Internet Monitoring and Protec- [17] M. Anagnostopoulos, G. Kambourakis, P. Kopanos, tion. IEEE, 2007. G. Louloudakis, and S. Gritzalis, “DNS Amplification [37] A. Householder, A. Manion, L. Pesante, G. Weaver, and Attack Revisited,” Comput. Secur., vol. 39, pp. 475–485, Nov. R. Thomas, “Managing the Threat of Denial-of-service 2013. Attacks,” 2001. [Online]. Available: http://resources.sei.cmu. [18] X. Ye and Y. Ye, “A Practical Mechanism to Counteract edu/library/asset-view.cfm?assetid=52481 DNS Amplification DDoS Attacks,” Journal of Computational [38] R. Sparks, “Addressing an Amplification Vulnerability Information Systems, vol. 9, pp. 265–272, 2013. in Forking Proxies,” 2006. [Online]. Available: https: [19]M.K uhrer,¨ T. Hupperich, C. Rossow, and T. Holz, “Exit from //tools.ietf.org/html/draft-ietf-sip-fork-loop-fix-00 Hell? Reducing the Impact of Amplification DDoS Attacks,” [39] T. Brewster, “Prolexic CEO: Biggest Cyber Attack Ever in Proc. of the 23rd USENIX Security Symposium. USENIX Was Built on Lies,” April 2013. [Online]. Available: Assoc., 2014. http://tinyurl.com/pr4j42d [20] T. Bottger,¨ L. Braun, O. Gasser, F. von Eye, H. Reiser, and [40] T. Rozekrans, M. Mekking, and J. de Koning, “Defending G. Carle, “DoS Amplification Attacks – Protocol-Agnostic Against DNS Reflection Amplification Attacks,” University of Detection of Service Abuse in Amplifier Networks,” in 7th Amsterdam, Tech. Rep., February 2013. International Workshop on Traffic Monitoring and Analysis [41] V. Paxson, “An Analysis of Using Reflectors for Distributed (TMA), vol. 9053. Springer-Verlag, 2015, pp. 205–218. Denial-of-service Attacks,” ACM SIGCOMM Comput. Com- [21] R. R. Hansen, “Slowloris,” 2009. [Online]. Available: mun. Rev., vol. 31, no. 3, pp. 38–47, Jul. 2001. http://en.wikipedia.org/wiki/Slowloris (software) [42] R. Chang, “Defending against flooding-based distributed [22] W. Eddy, “TCP SYN Flooding Attacks and Common denial-of-service attacks: A tutorial,” Communications Mag- Mitigations,” RFC 4987 (Informational), Internet Engineering azine, IEEE, vol. 40, no. 10, pp. 42–51, Oct 2002. Task Force, August 2007. [Online]. Available: http://www. [43] W. Chen and D.-Y. Yeung, “Defending Against TCP SYN ietf.org/rfc/rfc4987.txt Flooding Attacks Under Different Types of IP Spoofing,” in [23] D. Cornell, “DNS Amplification Attacks,” March 2014. International Conference on Networking, International Con- [Online]. Available: https://labs.opendns.com/2014/03/17/ ference on Systems and International Conference on Mobile dns-amplification-attacks/ Communications and Learning Technologies. IEEE, April [24] S. M. Bellovin, “Security Problems in the TCP/IP Protocol 2006. Suite,” ACM SIGCOMM Comput. Commun. Rev., vol. 19, [44] S. H. D. Nashat, Xiaohong Jiang, “Detecting SYN Flooding no. 2, pp. 32–48, Apr. 1989. Agents under Any Type of IP Spoofing,” in IEEE International [25] M. Prince, “Technical Details Behind a 400Gbps Conference on e-Business Engineering. IEEE, October 2008, NTP Amplification DDoS Attack,” Feb 2014. pp. 499–505. [Online]. Available: http://blog.cloudflare.com/ [45] M. O. H. N. A. Noureldien, “Block Spoofed Packets at Source technical-details-behind-a-400gbps-ntp-amplification-ddos-attack (BSPS): A Method for Detecting and Preventing all Types [26] “Open Resolver Project,” April 2015. [Online]. Available: of Spoofed Source IP Packets and SYN Flooding Packets at http://openresolverproject.org Source: A Theoretical Framework,” in Second International [27] AusCERT, “Domain Name System (DNS) Denial of Service Conference on the Applications of Digital Information and (DoS) Attacks,” August 1999. [Online]. Available: http: Web Technologies. IEEE, Aug 2009, pp. 579–583. //www.securityfocus.com/advisories/1727 [46] L. Kavisankar and C. Chellappan, “A Mitigation Model for [28] P. J. Criscuolo, “Distributed denial of service - trin00, tribe TCP SYN Flooding with IP spoofing,” in International Con- flood network, tribe flood network 2000,” Technical Report ference on Recent Trends in Information Technology (ICRTIT). CIAC-2319, Department of Energy-CIAC (Computer Incident IEEE, June 2011, pp. 251–256. Advisory Capability), Tech. Rep., 2000.

21 [47] Y. Gilad and A. Herzberg, “LOT: A Defense Against IP [65] A. Belenky and N. Ansari, “On ip traceback,” Communications Spoofing and Flooding Attacks,” ACM Trans. Inf. Syst. Secur., Magazine, IEEE, vol. 41, no. 7, pp. 142–153, 2003. vol. 15, no. 2, pp. 6:1–6:30, Jul. 2012. [66] A. John and T. Sivakumar, “DDoS: Survey of Traceback Meth- [48] L. Kramer,¨ J. Krupp, D. Makita, T. Nishizoe, T. Koide, ods,” International Journal of Recent Trends in Engineering, K. Yoshioka, and C. Rossow, “AmpPot: Monitoring and vol. 1, no. 2, pp. 241–245, May 2009. Defending Amplification DDoS Attacks,” in Proceedings of [67] S. Vincent and J. I. J. Raja, “A Survey of IP Traceback Mech- the 18th International Symposium on Research in Attacks, anisms to Overcome Denial-of-service Attacks,” Proceedings Intrusions and Defenses, November 2015. of the 12th International Conference on Networking, VLSI and [49] M. Feily, A. Shahrestani, and S. Ramadass, “A Survey of Bot- Signal Processing, pp. 93–98, 2010. net and Botnet Detection,” in Proceedings of the 2009 Third [68] R. Jain and P. A. Meshram, “A Survey on Packet Marking International Conference on Emerging Security Information, and Logging,” International Journal of Computer Science and Systems and Technologies. IEEE, 2009. Information Technologies (IJCSIT), vol. 4, no. 3, pp. 426–429, [50] Praetox, “LOIC - A Network Stress Testing Application.” 2013. [Online]. Available: http://sourceforge.net/projects/loic/ [69] S. J. Templeton and K. E. Levitt, “Detecting Spoofed Packets,” [51] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. in DARPA Information Survivability Conference and Exposi- Briggs, and R. L. Braynard, “Networking Named Content,” in tion, 2003, April 2003, pp. 164–175. Proceedings of the 5th International Conference on Emerging [70] H.-Y. Chang, R. Narayan, S. F. Wu, B. Vetter, X. Wang, Networking Experiments and Technologies. ACM, 2009, pp. M. Brown, J. Yuill, C. Sargor, Y. F. Jou, and F. Gong, “DecId- 1–12. UouS: Decentralized Source Identification for Network-Based [52] T. Anderson, T. Roscoe, and D. Wetherall, “Preventing Internet Intrusions,” in Integrated Network Management. IEEE, 1999, Denial-of-service with Capabilities,” Computer Communica- pp. 701–714. tion Review, vol. 34, no. 1, pp. 39–44, 2004. [71] S. Savage, D. Wetherall, A. R. Karlin, and T. E. Anderson, [53] X. Yang, D. Wetherall, and T. Anderson, “TVA: A DoS- “Practical Network Support for IP Traceback,” in Proc. of limiting Network Architecture,” Networking, IEEE/ACM ACM SIGCOMM. ACM, 2000, pp. 295–306. Transactions on, vol. 16, no. 6, pp. 1267–1280, 2008. [72] D. Schnackenberg, K. Djahandari, and D. Sterne, “Infras- [54] J. Meseguer, “Rewriting Logic and Maude: A Wide-Spectrum tructure for Intrusion Detection and Response,” in DARPA Semantic Framework for Object-Based Distributed Systems,” Information Survivability Conference and Exposition, vol. 2, in Formal Methods for Open Object-Based Distributed Systems 2000, pp. 3–11. IV. Springer US, 2000, vol. 49, pp. 89–117. [73] P. Ferguson and D. Senie, “Network Ingress Filtering: De- [55] Valve, “Steam Master Server Query Protocol,” 2015. feating Denial of Service Attacks which employ IP Source [Online]. Available: https://developer.valvesoftware.com/wiki/ Address Spoofing,” IETF, RFC 2827, May 2000. Master Server Query Protocol [74] J. Mirkovic, N. Jevtic, and P. Reiher, “A Practical IP Spoof- [56] S. Kandula, D. Katabi, M. Jacob, and A. Berger, “Botz- ing Defense Through Route-Based Fltering,” University of 4-sale: Surviving organized ddos attacks that mimic flash Delaware, CIS department, Technical Report, CIS-TR, 2006. crowds,” in Proceedings of the 2nd conference on Symposium [75] A. Bremler-barr and H. Levy, “Spoofing Prevention Method,” on Networked Systems Design & Implementation – Volume 2. in Proc. IEEE INFOCOM, 2005, pp. 536–547. USENIX Association, 2005, pp. 287–300. [76] K. Park and H. Lee, “On the Effectiveness of Route-based [57] G. Oikonomou and J. Mirkovic, “Modeling human behavior Packet Filtering for Distributed DoS Attack Prevention in for defense against flash-crowd attacks,” in IEEE International Power-law Internets,” ACM SIGCOMM Comput. Commun. Conference on Communications. ICC’09. IEEE, 2009, pp. 1– Rev., vol. 31, no. 4, pp. 15–26, Aug. 2001. 6. [77] Z. D. X. Yuan and J. Chandrashekar, “Controlling IP Spoofing [58] R. Beverly and S. Bauer, “The Spoofer Project: Inferring the through Interdomain Packet Filters,” in Dependable and Se- Extent of Source Address Filtering on the Internet,” USENIX cure Computing, IEEE Transactions on, vol. 5. IEEE, March SRUTI: Steps to Reducing Unwanted Traffic on the Internet 2008, pp. 22–36. Workshop, pp. 53–59, Jul. 2005. [78] T. Ohtsuka, F. Nakamura, Y. Sekiya, and Y. Wakahara, “Pro- [59] D. Moore, C. Shannon, D. J. Brown, G. M. Voelker, and posal and Efficient Implementation of Detecting and Filtering S. Savage, “Inferring Internet denial-of-service activity,” ACM Method for IP Spoofed Packets,” in International Conference Trans. Comput. Syst., vol. 24, no. 2, pp. 115–139, 2006. on Information and Communication Technology. IEEE, [60] J. Mauch, “SNMP DDoS: The Vulnerability You Might Not March 2007, pp. 327–330. Know You Have,” http://seclists.org/nanog/2013/Aug/132, Au- [79] J. Li, J. Mirkovic, T. Ehrenkranz, M. Wang, P. Reiher, and gust 2013. L. Zhang, “Learning the Valid Incoming Direction of IP [61] L. T. Heberlein and M. Bishop, “Attack Class: Address Packets,” Computer Networks, vol. 52, no. 2, pp. 399–417, Spoofing,” in Proc. of the 19th National Information Systems 2008. Security Conference, 1996, pp. 371–377. [80] C. A. Shue, M. Gupta, and M. P. Davy, “Packet Forwarding [62] T. Dunigan, “Backtracking Spoofed Packets,” 2001. [Online]. with Source Verification,” Comput. Netw., vol. 52, no. 8, pp. Available: http://www.epm.ornl.gov/∼dunigan/oci/back.ps 1567–1582, Jun. 2008. [63] L. Soon, M. Othman, and N. I. Udzir, “IP Spoofing Defense: [81] H. Lee, M. Kwon, G. Hasker, and A. Perrig, “BASE: An An Introduction,” International Conference on Computing & Incrementally Deployable Mechanism for Viable IP Spoofing Informatics (ICOCI09), 2009. Prevention,” in Proc. of the 2nd ACM ASIACCS. ACM, 2007, [64] T. Ehrenkranz and J. Li, “On the State of IP Spoofing pp. 20–31. Defense,” ACM Trans. Internet Technol., vol. 9, no. 2, pp. [82] A. Yaar, A. Perrig, and D. X. Song, “Pi: A Path Identification 1–29, May 2009. Mechanism to Defend against DDoS Attack,” in Proc. of IEEE Symposium on Security and Privacy. IEEE, 2003.

22 [83] Cisco Systems, “Unicast Reverse Path Forwarding Enhance- June 1995, updated by RFC 2644. [Online]. Available: ments For The Internet Service Provider — Internet Service http://www.ietf.org/rfc/rfc1812.txt Provider Network Edge,” Cisco, White Paper, 2005. [102] F. Baker and P. Savola, “Ingress Filtering for Multihomed [84] G.-F. Lv and Z.-G. Sun, “Towards Spoofing Prevention Based Networks,” RFC 3704 (Best Current Practice), Internet on Hierarchical Coordination Model,” in Proc. of Workshop on Engineering Task Force, March 2004. [Online]. Available: High Performance Switching and Routing (HPSR’07). IEEE, http://www.ietf.org/rfc/rfc3704.txt June 2007, pp. 1–6. [103] X. Liu, A. Li, X. Yang, and D. Wetherall, “Passport: Secure [85] H. Wang, C. Jin, and K. G. Shin, “Defense Against Spoofed IP and Adoptable Source Authentication,” in Proceedings of the Traffic Using Hop-count Filtering,” IEEE/ACM Trans. Netw., 5th USENIX Symposium on Networked Systems Design and vol. 15, no. 1, pp. 40–53, Feb. 2007. Implementation. USENIX Association, 2008, pp. 365–378. [86] A. Yaar, A. Perrig, and D. Song, “StackPi: New Packet [104] J. Li, J. Mirkovic, M. Wang, P. Reiher, and L. Zhang, “SAVE: Marking and Filtering Mechanisms for DDoS and IP Spoofing Source address validity enforcement protocol,” in IEEE IN- Defense,” IEEE Journal on Selected Areas in Communications, FOCOM, 2002, pp. 1557–1566. vol. 24, no. 10, pp. 1853–1863, 2006. [105] Z. Duan, X. Yuan, and J. Chandrashekar, “Constructing Inter- [87] Z. Gao and N. Ansari, “A Practical and Robust Inter-domain Domain Packet Filters to Control IP Spoofing Based on BGP Marking Scheme for IP Traceback,” Computer Networks, Updates,” in Proc. of IEEE INFOCOM, 2006, pp. 1–12. vol. 51, no. 3, pp. 732–750, 2007. [106] T. Ehrenkranz and J. Li, “An Incrementally Deployable Pro- [88] R. Chen, J.-M. Park, and R. Marchany, “A Divide-and- tocol for Learning the Valid Icoming Direction of IP Packets,” Conquer Strategy for Thwarting Distributed Denial-of-Service University of Oregon, Tech. Rep., October 2007. Attacks,” Parallel and Distributed Systems, IEEE Transactions [107] R. Stone, “Centertrack: An IP Overlay Network for Tracking on, vol. 18, no. 5, pp. 577–588, May 2007. DoS Floods,” in Proc. of the 9th conference on USENIX [89] J. Wu, G. Ren, and X. Li, “Source Address Validation: Ar- Security Symposium. USENIX Association, 2000, pp. 15– chitecture and Protocol Design,” in Network Protocols, 2007. 15. ICNP 2007. IEEE International Conference on. IEEE, 2007, [108] H. Burch and B. Cheswick, “Tracing Anonymous Packets to pp. 276–283. Their Approximate Source,” in Proc. of the 14th Conference [90] D. Dean, M. K. Franklin, and A. Stubblefield, “An Algebraic on Systems Administration (LISA 2000). USENIX, December Approach to IP traceback,” ACM Trans. Inf. Syst. Secur., vol. 5, 2000, pp. 319–327. no. 2, pp. 119–137, 2002. [109] S. Bellovin and M. Leech, “ICMP Traceback Messages,” [91] G. Taleck, “Ambiguity Resolution via Passive OS Fingerprint- February 2000. [Online]. Available: https://tools.ietf.org/html/ ing,” in Recent Advances in Intrusion Detection, ser. Lecture draft-ietf-itrace-00 Notes in Computer Science. Springer, 2003, vol. 2820, pp. [110] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, “Network 192–206. Support for IP Traceback,” IEEE/ACM Trans. Netw., vol. 9, [92] M. Adler, “Trade-offs in Probabilistic Packet Marking for IP no. 3, pp. 226–237, Jun. 2001. Traceback,” J. ACM, vol. 52, no. 2, pp. 217–244, Mar. 2005. [111] D. X. Song and A. Perrig, “Advanced and Authenticated Mark- [93] Fyodor, “Remote OS Detection,” 2006. [Online]. Available: ing Schemes for IP Traceback,” in Proc. of IEEE INFOCOM, http://nmap.org/book/osdetect.html vol. 2, 2001, pp. 878–886. [94] S. Kent and K. Seo, “Security Architecture for the [112] A. Belenky and N. Ansari, “Accommodating Fragmentation in Internet Protocol,” RFC 4301 (Proposed Standard), Internet Deterministic Packet Marking for IP Traceback,” in Proceed- Engineering Task Force, December 2005. [Online]. Available: ings of IEEE Global Telecommunications Conference, 2003, http://www.ietf.org/rfc/rfc4301.txt pp. 1374–1378. [95] R. Beverly, “A Robust Classifier for Passive TCP/IP Finger- [113] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones, printing,” in Proc. of 5th International Workshop on Passive F. Tchakountio, B. Schwartz, S. T. Kent, and W. T. and Active Network Measurement (PAM). Heidelberg Berlin: Strayer, “Single-packet IP traceback.” IEEE/ACM Trans. Springer, 2004, pp. 158–167. Netw., vol. 10, no. 6, pp. 721–734, 2002. [96] G. Taleck, “Ambiguity Resolution via Passive OS Fingerprint- [114] Y. Xiang, W. Zhou, and M. Guo, “Flexible Deterministic ing,” in Proc. of RAID. Springer, 2003, pp. 192–206. Packet Marking: An IP Traceback System to Find the Real [97] B. Berntein, “SYN Cookies,” 1996. [Online]. Available: Source of Attacks,” IEEE Transactions on Parallel and Dis- http://cr.yp.to/syncookies.html tributed Systems, vol. 20, no. 4, pp. 567–580, April 2009. [98] W. Feng, E. Kaiser, W. Feng, and A. Luu, “Design and [115] L. Zhang and Y. Guan, “TOPO: A Topology-aware Single implementation of network puzzles,” in INFOCOM 2005. Packet Attack Traceback Scheme,” in Securecomm and Work- 24th Annual Joint Conference of the IEEE Computer and shops. IEEE Press, September 2006, pp. 1–10. Communications Societies. Proceedings IEEE, vol. 4, March [116] S. Matsuda, T. Baba, A. Hayakawa, and T. Nakamura, “Design 2005, pp. 2372–2382 vol. 4. and Implementation of Unauthorized Access Tracing System,” [99] C. Jin, H. Wang, and K. G. Shin, “Hop-count Filtering: An in Proceedings of the 2002 Symposium on Applications and Effective Defense Against Spoofed DDoS Traffic,” in Proc. of the Internet. IEEE Computer Society, 2002, pp. 74–81. the 10th ACM CCS. ACM, 2003, pp. 30–41. [117] H. A. Alwis, R. C. Doss, P. S. Hewage, and M. U. Chowdhury, [100] T. Killalea, “Recommended Internet Service Provider Security “Topology Based Packet Marking for IP Traceback,” in Proc. Services and Procedures,” RFC 3013 (Best Current Practice), of the Australian Telecommunication Networks and Applica- Internet Engineering Task Force, Nov. 2000. [Online]. tions Conference (ATNAC). University of Melbourne, 2006, Available: http://www.ietf.org/rfc/rfc3013.txt pp. 224–228. [101] F. Baker, “Requirements for IP Version 4 Routers,” RFC [118] C. Gong and K. Sarac, “A More Practical Approach for Single- 1812 (Proposed Standard), Internet Engineering Task Force, Packet IP Traceback using Packet Logging and Marking ,” pp. 1310–1324, 2008.

23 [119] T. W. Doeppner, P. N. Klein, and A. Koyfman, “Using Router [137] A. Gurtov, Host Identity Protocol (HIP): Towards the Secure Stamping to Identify the Source of IP Packets,” in Proc. of the Mobile Internet. John Wiley & Sons, 2008, vol. 21. 7th ACM CCS. ACM, 2000, pp. 184–189. [138] R. Moskowitz and P. Nikander, “Host Identity Protocol [120] B. Al-Duwairi and M. Govindarasu, “Novel Hybrid Schemes (HIP) Architecture,” RFC 4423 (Informational), Internet Employing Packet Marking and Logging for IP Traceback,” Engineering Task Force, may 2006. [Online]. Available: IEEE Trans. Parallel Distrib. Syst., vol. 17, no. 5, pp. 403– http://www.ietf.org/rfc/rfc4423.txt 418, May 2006. [139] H. Ishibashi, N. Yamai, K. Abe, and T. Matsuura, “A Pro- [121] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones, tection Method Against Unauthorized Access and Address F. Tchakountio, S. T. Kent, and W. T. Strayer, “Hash-based IP Spoofing for Open Network Access Systems,” in IEEE Pacific Traceback,” ACM SIGCOMM Comput. Commun. Rev., vol. 31, Rim Conference on Communications, Computers and signal no. 4, pp. 3–14, Aug. 2001. Processing, vol. 1. IEEE, 2001, pp. 10–13. [122] D. Yan, Y. Wang, S. Su, and F. Yang, “A Precise and [140] J. M. Gonzalez, M. Anwar, and J. B. Joshi, “A Trust-based Practical IP Traceback Technique Based on Packet Marking Approach Against IP-spoofing Attacks,” in Ninth Annual Con- and Logging.” J. Inf. Sci. Eng., vol. 28, no. 3, pp. 453–470, ference on Privacy, Security and Trust (PST 2011). IEEE, 2012. July 2011, pp. 63–70. [123] A. Belenky and N. Ansari, “IP Traceback With Deterministic [141] M. O. H. Noureldien A. Noureldien, “Block Spoofed Packets Packet Marking,” IEEE Communications Letters, vol. 7, no. 4, at Source (BSPS): A Method for Detecting and Preventing pp. 162–164, April 2003. All Types of Spoofed Source IP Packets and SYN Flooding [124] C. Gong and K. Sarac, “Toward a Practical Packet Marking Packets at Source: A Theoretical Framework,” International Approach for IP Traceback,” International Journal of Network Journal of Networks and Communications, vol. 2, no. 3, pp. Security, vol. 8, no. 3, pp. 271–281, 2009. 33–37, 2012. [125] M. T. Goodrich, “Probabilistic Packet Marking for Large-scale [142] C. Kreibich, A. Warfield, J. Crowcroft, S. Hand, and I. Pratt, IP Traceback,” IEEE/ACM Trans. Netw., vol. 16, no. 1, pp. 15– “Using Packet Symmetry to Curtail Malicious Traffic,” in 24, Feb. 2008. Proceedings of the 4th Workshop on Hot Topics in Networks [126] X.-J. Wang and X.-Y. Wang, “Topology-assisted Deterministic (Hotnets-VI), College Park, MD, USA, 2005. Packet Marking for IP Traceback,” The Journal of China [143] T. Korkmaz, C. Gong, K. Sara, and S. G. Dykes, “Single Universities of Posts and Telecommunications, vol. 17, pp. Packet IP Traceback in AS-level Partial Deployment Scenario,” 116–121, April 2010. IJSN, pp. 95–108, 2007. [127] K. Park and H. Lee, “On the Effectiveness of Probabilistic [144] M. Sung, J. Xu, J. Li, and L. Li, “Large-scale IP Traceback Packet Marking for IP Traceback under Denial of Service in High-speed Internet: Practical Techniques and Information- Attack,” pp. 338–347, 2001. theoretic Foundation,” IEEE/ACM Trans. Netw., vol. 16, no. 6, [128] T. Baba and S. Matsuda, “Tracing Network Attacks to Their pp. 1253–1266, Dec. 2008. Sources,” IEEE Internet Computing, vol. 6, no. 2, pp. 20–26, [145] K. Egevang and P. Francis, “The IP Network Address Mar. 2002. Translator (NAT),” RFC 1631 (Informational), Internet [129] A. Mankin, D. Massey, C.-L. Wu, S. F. Wu, and L. Zhang, “On Engineering Task Force, May 1994, obsoleted by RFC 3022. Design and Evaluation of ”Intention-Driven” ICMP Trace- [Online]. Available: http://www.ietf.org/rfc/rfc1631.txt back,” in Computer Communications and Networks, 2001. [146] K. Ali, M. Zulkernine, and H. S. Hassanein, “Packet Filtering Proceedings. Tenth International Conference on. IEEE, 2001, Based on Source Router Marking and Hop-Count,” in LCN. pp. 159–165. IEEE Computer Society, 2007, pp. 1061–1068. [130] S. Lee and C. Shields, “Challenges to Automated Attack [147] N. Arumugam and C. Venkatesh, “A Dynamic Method to Traceback,” IT Professional, vol. 4, no. 3, pp. 12–18, May Detect IP Spoofing on Data Network Using Ant Algorithm,” 2002. IOSR Journal of Engineering (IOSRJEN), vol. 2, october 2012. [131] R. Beverly, “Spoofer project: State of ip spoofing,” November [148] P. Ferguson and D. Senie, “Network Ingress Filtering: 2014. [Online]. Available: http://spoofer.cmand.org/summary. Defeating Denial of Service Attacks which employ IP Source php Address Spoofing,” RFC 2267 (Informational), Internet [132] J. Postel, “Internet Protocol,” RFC 791 (Internet Standard), Engineering Task Force, January 1998, obsoleted by RFC Internet Engineering Task Force, Sep. 1981, updated by 2827. [Online]. Available: http://www.ietf.org/rfc/rfc2267.txt RFCs 1349, 2474. [Online]. Available: http://www.ietf.org/ [149] K. Butler, T. Farley, P. Mcdaniel, and J. Rexford, “A survey rfc/rfc791.txt of BGP security issues and solutions,” AT&T Labs Research, [133] X. Lu, G. L, P. Zhu, and Y. Chen, “MASK: An Efficient 2008. Mechanism to Extend Inter-domain IP Spoofing Preventions,” [150] J. Israr, M. Guennoun, and H. T. Mouftah, “Mitigating IP pp. 1745–1760, November 2008. Spoofing by Validating BGP Routes Updates,” International [134] G. Velmayil and S. Pannirselvam, “Detection and Removal Journal of Computer Science and Network Security (IJCSNS), of IP Spoofing through Extended-Inter Domain Packet Filter vol. 9, no. 5, pp. 71–76, May 2009. Architecture,” International Journal of Computer Applications, [151] C. L. Abad and R. I. Bonilla, “An Analysis on the Schemes vol. 49, no. 17, pp. 37–43, July 2012. for Detecting and Preventing ARP Cache Poisoning Attacks,” [135] F. Guo, J. Chen, and T. cker Chiueh, “Spoof Detection for in 27th International Conference on Distributed Computing Preventing DoS Attacks against DNS Servers,” in Proc. of Systems Workshops. IEEE, 2007, pp. 60–60. ICDCS. IEEE, 2006. [152] W. Strayer, C. Jones, F. Tchakountio, A. Snoeren, B. Schwartz, [136] D. Kuptsov and A. Gurtov, “SAVAH: Source Address Val- R. Clements, M. Condell, and C. Partridge, “Traceback of idation with Host Identity Protocol,” in Proc. of the First single IP packets using SPIE,” in DARPA Information Surviv- International ICST Conference on Security and Privacy in Mo- ability Conference and Exposition, 2003. Proceedings, vol. 2, bile Information and Communication Systems (MobiSec’09. April 2003, pp. 266–270. Springer, 2009, pp. 190–201.

24 [153] R. Shokri, A. Varshovi, H. Mohammadi, and N. Yazdani, sponse Packet Confirmation Mechanism,” Comput. Commun., “DDPM: Dynamic Deterministic Packet Marking for IP Trace- vol. 31, no. 14, pp. 3299–3306, Sep. 2008. back,” in 14th IEEE International Conference on Networks, [171] T. Peng, C. Leckie, and K. Ramamohanarao, “Protection vol. 2. IEEE, September 2006, pp. 1–6. from Distributed Denial of Service Attacks Using History- [154] Q. Dong, M. Adler, S. Banerjee, and K. Hirata, “Efficient based IP Filtering,” in Communications, 2003. ICC’03. IEEE Probabilistic Packet Marking,” in 13th IEEE ICNP. IEEE, International Conference on, vol. 1. IEEE, 2003, pp. 482– November 2005. 486. [155] B. Duwairi, A. Chakrabarti, and G. Manimaran, “An Efficient [172] J. Mirkovic, G. Prier, and P. Reiher, “Attacking DDoS at the Probabilistic Packet Marking Scheme for IP Traceback,” pp. Source,” in Network Protocols, 2002. Proceedings. 10th IEEE 1263–1269, November 2004. International Conference on. IEEE, 2002, pp. 312–321. [156] A. Belenky and N. Ansari, “On Deterministic Packet Mark- [173] ——, “Source-end DDoS Defense,” in Second IEEE Interna- ing,” Comput. Netw., vol. 51, no. 10, pp. 2677–2700, Jul. 2007. tional Symposium on Network Computing and Applications. [157] Z. Chen and M.-C. Lee, “An IP Traceback Technique Against NCA 2003. IEEE, 2003, pp. 171–178. Denial-of-service Attacks,” in Computer Security Applications [174] T. M. Gil and M. Poletto, “MULTOPS: A Data-structure for Conference, 2003. Proceedings. 19th Annual, Dec 2003, pp. Bandwidth Attack Detection,” in USENIX Security Sympo- 96–104. sium, 2001. [158] H. C. J. Lee, V. L. L. Thing, Y. Xu, and M. Ma, “ICMP [175] S. Abdelsayed, D. Glimsholt, C. Leckie, S. Ryan, and Traceback with Cumulative Path, an Efficient Solution for S. Shami, “An Efficient Filter for Denial-of-Service Bandwidth IP Traceback,” in Proc. of Information and Communications Attacks,” in Global Telecommunications Conference, 2003. Security, 5th International Conference, ICICS, vol. 2836. GLOBECOM’03. IEEE, vol. 3. IEEE, 2003, pp. 1353–1357. Springer, 2003, pp. 124–135. [176] T. Peng, C. Leckie, and K. Ramamohanarao, “Detecting [159] H.-W. Lee, M.-G. Kang, and C.-W. Choi, “PTrace: Push- Reflector Attacks by Sharing Beliefs,” in Proc. of IEEE back/SVM Based ICMP Traceback Mechanism against DDoS GLOBECOM, 2003, pp. 1358–1362. Attack,” in Computational Science and Its Applications - [177] Y. Kim, W. C. Lau, M. C. Chuah, and H. J. Chao, “Pack- ICCSA 2004, vol. 3043. Springer, 2004, pp. 302–309. etScore: A Statistics-Based Packet Filtering Scheme Against [160] B.-T. Wang and H. Schulzrinne, “An IP Traceback Mechanism Distributed Denial-of-Service Attacks,” Dependable and Se- for Reflective DoS Attacks,” in Canadian Conference on cure Computing, IEEE Transactions on, vol. 3, no. 2, pp. 141– Electrical and Computer Engineering, vol. 2, May 2004, pp. 155, 2006. 901–904. [178] D. Huistra, “Detecting Reflection Attacks in DNS Flows,” in [161] R. Feiertag, C. Kahn, P. Porras, D. Schnackenberg, 19th Twente Student Conference on IT, February 2013. S. Staniford-Chen, and B. Tung, “A Common Intrusion Spec- [179] R. Mahajan, S. M. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, ification Language (CISL),” 1999. and S. Shenker, “Controlling High Bandwidth Aggregates [162] R. Atkinson, “Security Architecture for the Internet Protocol,” in the Network,” Computer Communication Review, vol. 32, IETF, RFC 1825, August 1995. no. 3, pp. 62–73, 2002. [163] S. Kent, “IP Authentication Header,” IETF, RFC 4302, De- [180] D. K. Yau, J. Lui, F. Liang, and Y. Yam, “Defending Against cember 2005. Distributed Denial-of-Service Attacks with Max-Min Fair [164] ——, “IP Encapsulating Security Payload (ESP),” IETF, RFC Server-Centric Router Throttles,” Transactions on Networking 4303, December 2005. (TON), vol. 13, no. 1, pp. 29–42, 2005. [165] V. Santiraveewan and Y. Permpoontanalarp, “A Graph-based [181] R. Chen and J.-M. Park, “Attack Diagnosis: Throttling Methodology for Analyzing IP Spoofing Attack,” in Proc. of Distributed Denial-of-Service Attacks Close to the Attack the 18th International Conference on Advanced Information Sources,” in Proceedings. 14th International Conference on Networking and Applications, ser. AINA ’04. IEEE Computer Computer Communications and Networks. IEEE, 2005, pp. Society, 2004. 275–280. [166] W. Wei, F. Chen, Y. Xia, and G. Jin, “A Rank Correlation [182] R. Chen, J.-M. Park, and R. Marchany, “TRACK: A Novel Ap- Based Detection against Distributed Reflection DoS Attacks,” proach for Defending Against Distributed Denial-of-Service Communications Letters, IEEE, vol. 17, no. 1, pp. 173–175, Attacks,” Technical Report TR ECEO6-02. Dept. of Electrical January 2013. and Computer Engineering, Virginia Tech, 2006. [167] G. Kambourakis, T. Moschos, D. Geneiatakis, and S. Gritzalis, [183] N. Fultz and J. Grossklags, “Blue Versus Red: Towards a “Detecting DNS Amplification Attacks,” in Workshop on Crit- Model of Distributed Security Attacks,” in Financial Cryp- ical Information Infrastructures Security (CRITIS), vol. 5141. tography and Data Security. Springer, 2009, pp. 167–183. Springer, 2008, pp. 185–196. [184] C. Fachkha, E. Bou-Harb, and M. Debbabi, “Towards a Fore- [168] S. Di Paola and D. Lombardo, “Protecting Against DNS casting Model for Distributed Denial of Service Activities,” in Reflection Attacks with Bloom Filters,” in Proceedings of 12th IEEE International Symposium on Network Computing the 8th International Conference on Detection of Intrusions and Applications (NCA), August 2013, pp. 110–117. and Malware, and Vulnerability Assessment, ser. DIMVA’11. [185] ——, “Fingerprinting Internet DNS Amplification DDoS Ac- Springer-Verlag, 2011, pp. 1–16. tivities,” in 6th International Conference on New Technologies, [169] H. Tsunoda, Y. Nemoto, K. Ohta, and A. Yamamoto, “A Mobility and Security (NTMS), March 2014, pp. 1–5. Simple Response Packet Confirmation Method for DRDoS [186] ——, “Inferring Distributed Reflection Denial of Service At- Detection,” in Proc. of the 8th International Conference on tacks from Darknet,” Computer Communications, vol. 62, pp. Advanced Communication Technology (ICACT 2006), vol. 3. 59 – 71, 2015. IEEE Press, February 2006. [187] S. Yu, W. Zhou, W. Jia, S. Guo, Y. Xiang, and F. Tang, “Dis- [170] H. Tsunoda, K. Ohta, A. Yamamoto, N. Ansari, Y. Waizumi, criminating DDoS Attacks from Flash Crowds Using Flow and Y. Nemoto, “Detecting DRDoS Attacks by a Simple Re- Correlation Coefficient,” Parallel and Distributed Systems, IEEE Transactions on, vol. 23, no. 6, pp. 1073–1080, 2012.

25 [188] C. Dietzel, A. Feldmann, and T. King, “Blackholing at IXPs: and decline of ntp ddos attacks,” in Proceedings of the 2014 On the Effectiveness of DDoS Mitigation in the Wild,” in Conference on Internet Measurement Conference. ACM, Proceedings of PAM 2016, ser. LCNS, T. Karagiannis and 2014, pp. 435–448. X. Dimitropoulos, Eds., vol. 9631. Springer, 2016, pp. 319– [191] The Shadowserver Foundation, April 2015. [Online]. 332. Available: https://dnsscan.shadowserver.org/ [189] J. Mirkovic, M. Robinson, and P. Reiher, “Alliance Formation [192] The Measurement Factory, April 2015. [Online]. Available: for DDoS Defense,” in Proceedings of the 2003 workshop on http://dns.measurement-factory.com New security paradigms. ACM, 2003, pp. 11–18. [193] Network Time Foundation, April 2015. [Online]. Available: [190] J. Czyz, M. Kallitsis, M. Gharaibeh, C. Papadopoulos, M. Bai- http://openntpproject.org/ ley, and M. Karir, “Taming the 800 pound gorilla: The rise

26