Impact of denial of service solutions on network quality of service

SECURITY AND COMMUNICATION NETWORKSSecurity Comm. Networks 2011; 4:1089–1103

Published online 26 July 2010 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/sec.219

RESEARCH ARTICLE

Impact of denial of service solutions on networkquality of serviceScott Fowler1∗, Sherali Zeadally2 and Naveen Chilamkurti3

1 Adaptive Communications Networks Research Group, Aston University, Aston Triangle, Birmingham, U.K.2 Department of Computer Science and Information Technology, University of the District of Columbia, Washington DC, U.S.A.3 Department of Computer Science and Computer Engineering, La Trobe University, Melbourne, Victoria 3086, Australia

ABSTRACT

The Internet has become a universal communication network tool. It has evolved from a platform that supports best-efforttraffic to one that now carries different traffic types including those involving continuous media with quality of service(QoS) requirements. As more services are delivered over the Internet, we face increasing risk to their availability given thatmalicious attacks on those Internet services continue to increase. Several networks have witnessed denial of service (DoS)and distributed denial of service (DDoS) attacks over the past few years which have disrupted QoS of network services,thereby violating the Service Level Agreement (SLA) between the client and the Internet Service Provider (ISP). Hence DoSor DDoS attacks are major threats to network QoS. In this paper we survey techniques and solutions that have been deployedto thwart DoS and DDoS attacks and we evaluate them in terms of their impact on network QoS for Internet services. Wealso present vulnerabilities that can be exploited for QoS protocols and also affect QoS if exploited. In addition, we alsohighlight challenges that still need to be addressed to achieve end-to-end QoS with recently proposed DoS/DDoS solutions.Copyright © 2010 John Wiley & Sons, Ltd.

KEYWORDS

MPLS; RSVP; DiffServ; QoS; denial of service; DoS; DDoS; protocol; performance; security

*Correspondence

Scott Fowler, School of Engineering and Applied Science, Aston University, Aston Triangle, North Wing, Electronic Engineering,Birmingham, B4 7ET, U.K.E-mail: [email protected]

1. INTRODUCTION

The Internet has become a universal communication net-work tool. It has evolved from a platform that used to supportprimarily best effort (BE) traffic to one that is now deliv-ering all kinds of traffic types (including those involvingcontinuous media traffic such as audio and video. The sup-port of multimedia traffic on the Internet has been an activetopic of research because of their stringent quality of ser-vice (QoS) requirements such as bandwidth, delay, etc. Itremains a significant challenge to support traffic with QoSrequirements and simultaneously enable secure transmis-sions of such traffic types. It is difficult to overcome thischallenge since the Internet is very susceptible to attackssuch as denial of service (DoS) and distributed denial ofservice (DDoS) attacks. Indeed, the goal of DoS or DDoSattacks is to reduce the availability of network resourcessuch as CPU or buffers, resulting in the disruption of ser-vices provided to legitimate sources. Consequently, DoSand DDoS attacks affect network QoS and violate Service

Level Agreement (SLA) between the client and the InternetService Provider (ISP). Such attacks are major threats tonetwork QoS [1,2].

Recent security research has focused a lot on privacyor authentication. Many networking security systems andmechanisms are designed to provide more secure infras-tructures, such as firewalls, authentication and authorizationprotocols, packet filtering, source identification and cryp-tographic algorithms. These security methods require extrastorage or computational resources, and the resulting lim-ited resources become easy targets for DoS attacks [3].

DoS attacks cannot be simply addressed using traditionalsecurity approaches with or without the above mentionedstorage or computational resource issues [3]. For example,the Internet Key Exchange (IKE) protocol used for keyestablishment and Security Associations (SAs) parameterused by IPsec are susceptible to DoS attacks (Figure 1) [3,4]since the server has to create states for SA and computesDiffie-Hellman exponential generation [2,4]. It is worth not-ing that in Figure 1 the Certificate from the client is never

Copyright © 2010 John Wiley & Sons, Ltd. 1089

Impact of denial of service solutions S. Fowler, S. Zeadally and N. Chilamkurti

Figure 1. Internet key exchange (IKE) certificates model.

sent, resulting in the Server waiting for a response or re-initialization of the IKE exchange certificates. Accordingto the latest data publicly available from Carnegie Mellon’sCERT� Coordination Center report [5], 21% of organiza-tions which responded to the survey reported that financialloss caused by electronic crimes (e-crimes) had increasedover the year (2007). Among the e-crimes, 49% of theorganizations had experienced DoS attacks, which is thefifth most common e-crime after malicious code crimes,unauthorized access, spam email and spyware [5].

This work demonstrates that DoS/DDoS attacks aremajor threats to network QoS. Although several reviewpapers have provided various taxonomies of DoS/DDoSattacks, the impact of such attacks on QoS has not reallybeen studied and investigated. Indeed, it remains a signif-icant challenge to ensure and maintain network QoS ofdifferent types of traffic while maintaining secure networkinfrastructures. In this context, the main contributions ofthis work are as follows:

� Many kinds of defensive measures have been pro-posed to thwart DoS/DDoS attacks. However, manyof these defensive techniques do not take into accountthe effects they have on network QoS delivery. In thiswork, we investigate recently proposed DDoS solu-tions and we systematically evaluate their impact onnetwork QoS.

� In addition to the overview of the each defensive tech-nique based on their effectiveness on the security, wewill extensively discuss on how it may counteract QoSprovision.

� The vulnerabilities of QoS protocols: Several QoSapproaches and protocols have been proposed andimplemented to support Multimedia over networks.Among them, several traffic engineering technologiesincluding Multi-Protocol Label Switching (MPLS),Differentiated Services (Diffserv), and ReSourceReserVation Protocol (RSVP) have gained wideacceptance. These protocols, however, are prone toDoS/DDoS attacks. Therefore, we will summarizeeach QoS protocol and thoroughly describe its vul-nerability to DoS/DDoS attack.

The rest of this paper is organized as follows. Section2 describes elementary models of DoS and DDoS attacks.

Figure 2. Generic DoS model.

Section 3 presents five basic DoS attack strategies. In Sec-tion 4, various defense measures aimed at preventing DDoSattacks and their effects on network QoS are presented.In Section 5, we identify DDoS attacks that can exploitvulnerabilities of various QoS protocols. In Section 6, wepresent future works. Finally, in Section 7 we make someconcluding remarks.

2. BACKGROUND ON BASICDOS/DDOS MODELS

According to the World Wide Web Security Consortium[6,7] ‘DoS is an attack designed to render a com-puter or network incapable of providing normal services’(Figure 2). DoS attacks accomplish this by attacking a tar-get computer’s (victim) network bandwidth or connectivity.With bandwidth attacks, the network is flooded with a highvolume of malicious traffic, resulting in all the available net-work resources to be consumed and legitimate user requeststo be denied.

The WWW Security Consortium also defines [6,7], ‘ADDoS attack as one that uses many computers to launch acoordinated DoS attack against one or more targets. Usingclient/server technology, the perpetrator is able to multi-ply the effectiveness of the DoS significantly by harnessingthe resources of multiple unwitting accomplice computerswhich serve as attack platforms’ (Figure 3).

There are two types of DDoS attacks that have emerged,the Handler-based and Internet Relay Chat (IRC)-based [8--11]. In the Handler-based model (Figure 4): A handleris a special program that can be deployed throughout theInternet. Each handler is capable of controlling multipleagents. An agent is a compromised system that is responsi-

1090 Security Comm. Networks 2011; 4:1089–1103 © 2010 John Wiley & Sons, Ltd.DOI: 10.1002/sec

S. Fowler, S. Zeadally and N. Chilamkurti Impact of denial of service solutions

Figure 3. Generic DDoS model.

Figure 4. Classical DDoS model.

ble for generating a stream of packets directed toward theintended victim. Sometimes, the terms ‘handler’ and ‘agent’are referred as ‘master’ and ‘daemon’ [8].

The IRC-based model (Figure 5) is similar to the Handler-based model, but instead of the Handler program an IRCcommunication channel is employed to link the client to thevarious agents. The use of an IRC communication channelallows an attacker to exploit ‘legitimate’ IRC ports to sendcommands to the various agents [8,9] making DDoS packetsmore difficult to be identified. In addition, the client doesnot need to keep a record of agents because it only has to logon to the IRC server and check an inventory of accessibleagents [8,9]. In an IRC-based DDoS attack architecture, theagents are often referred to as ‘Zombie Bots’ or ‘Bots’ [8].

One of the network architectures, namely, Peer-to-Peer(P2P), has been receiving a lot of attention recently. P2Penables a highly scalable, decentralized, and robust distri-bution service for live multimedia streaming applications(such as Skype used for voice or video) compared to the clas-

sical Client-Server network paradigm. P2P is also prone toDoS attacks. Typical DoS attacks [12,13] on a P2P include:(a) a peer stores and retrieves data repeatedly, (b) a peerjoins and leaves the P2P network rapidly, (c) a peer sendsunsolicited messages to other peers repeatedly, and (d) apeer disturbs the routing information of the P2P network.

3. BASIC DOS ATTACK STRATEGIES

DoS attack strategies can be divided up into five categories[7,8]. These five categories can be summarized as follows:

(1) Network Level: This type of attack is accomplishedby taking advantage of a bug(s), weaknesses in thesoftware, or trying to exhaust the hardware resourcesof the network. One example of an exploited net-work service is the Secure Socket Layer (SSL). TheCisco CSS 11 500 Series Content Services Switches[14] when configured with SSL termination serviceswere vulnerable to DoS attacks when processingmalformed client certificates.

(2) Operating System Level: Exploits the way the oper-ating system executes its protocol. An example isthe Ping of Death (or Ping Flood) [8,15]. The attackgenerates a large number of ICMP packets (ping) thatexceed the maximum size of 65 535 bytes. The victimreceives the ping in fragments and starts reassem-bling the packet. Unfortunately, once the packet isreassembled, it is too big for the buffer and overflowsit, resulting in reboots or the system hanging.

(3) Application Level: A bug (running on the targethost (victim)) is exploited at the application level toconsume the victim resources. By exploiting bugsvia an application, this attack allows an intruderto disrupt services by causing excessive process-ing on the target host. One such example of thisis the finger bomb attack which redirects the fin-ger command to remote sites. In the use of fingerusername@@@@@@host1 [16], the @ causes the

Figure 5. IRC DDoS model.

Security Comm. Networks 2011; 4:1089–1103 © 2010 John Wiley & Sons, Ltd. 1091DOI: 10.1002/sec


Figure 6. Transmission Control Protocol (TCP) three-way-handshaking attack.

finger to recursively finger the same machine (itself)repeatedly, thereby exhausting all of the resources onthe host.

(4) Attacks based on protocol features: This type ofattack takes advantage of the standard protocol char-acteristic. For example IP spoofing is used to gainunauthorized access to computers by imitating atrusted host IP address. Another attack is Synchro-nization (SYN) Flooding which takes advantage ofa flaw in such away that hosts implement the TCPthree-way handshake. When host B receives the SYNrequest from a malicious host, host B must keeptrack of the partially opened connection in a ‘lis-ten queue" for at least 75 s. The malicious host canexploit the small size of the listen queue by sendingmultiple SYN requests to host B, but never replyingto the SYN & ACK messages that host B sends back(Figure 6). By doing so, host B’s queue is quicklyfilled up, leading to rejection of new connectionsuntil a partially opened connection in the queue iscompleted or the timeout has been reached.

(5) Data Flooding: Attempts to oversaturate the band-width or host by generating huge volumes of traffic.

4. DEFENSE TECHNIQUESAGAINST DOS/DDOS ATTACKS

There are many kinds of defensive measures that have beenproposed to thwart DoS/DDoS attacks [3,17--60]. However,these methods have not considered the impact on networkQoS. In this section, we discuss several defense techniquesagainst DoS/DDoS and their impact on the QoS deliveryover the network.

4.1. Egress/ingress filtering

Filtering is the process of separating traffic that can bedefined as invalid or inappropriate for a specific part of thenetwork. This filtering will take place at the entry and/or exitpoints of the network. In other words, egress/ingress filter-

ing is effective in blocking packet with a spoofed† sourceaddress [3,38,39].

While egress/ingress traffic filtering drastically reducesthe success of spoofing, there are potential problems whensupporting QoS along with the filtering mechanism.

First, egress/ingress filtering does not preclude anattacker from using a forged source address of anotherhost within the permitted prefix filter range. As a result,on large-scale backbone networks with complex topol-ogy, egress/ingress filtering has difficulty differentiatingbetween incoming traffic and outgoing traffic. Therefore,the use of filtering is not very scalable, and this unscalabil-ity can affect support for large-scale QoS. Scalability is notan issue when we need to handle only QoS traffic inside theegress/ingress filtering. However, when QoS methods needto be applied outside egress/ingress filtering, QoS traffic andDoS attacks have to be differentiated so that QoS traffic tobe recognized as legitimate traffic. Second, networks withfiltering routers do not allow a mobile host to send pack-ets directly from the foreign network to the correspondentnode using its home address as the source address. To bemore specific, traffic to the mobile node is tunneled, buttraffic from the mobile node is not tunneled. This results inpackets from the mobile node which have source addressesthat do not match with the network where the station iscurrently attached [61]. To accommodate the filtering con-straint, reverse tunneling was proposed to establish a correctreverse tunnel from the care-of-address of the mobile nodeto the home agent [62]. This reverse tunnel enables pack-ets to be sent from the mobile node to its home agent. Thepacket is then forwarded to the correspondent node after de-tunneling. Unfortunately, this causes triangular routing inthe reverse direction and it makes current route optimizationtechniques become unidirectional or asymmetric [63]. Forasymmetric traffic, filtering methods require extra lookupsat the router table (on the source address), which in turnresults in an increase in delay for QoS traffic.

To take full advantage of egress/ingress filtering technol-ogy (spoof prevention, compatibility to currently availableprotocols, routers, and network infrastructure), we need toinvestigate how to apply it while simultaneously satisfy-ing multiple QoS requirements. Thus, methods to reducedelays, such as the best possible distribution of filters, ratherthan simply increasing filters in a large scale network needsto be studied, especially in relation to QoS traffic.

4.2. Firewall

Firewalls provide a defense mechanism that relies on a well-defined boundary between the inside of the network domainand the outside network domain. Thus, firewalls mediate thepassage of information. While firewalls can be very valuableif employed properly, but they are limited in their ability

† A DoS attack in which packets are made to appear to originate froma system other than the one they really originated from.



to protect a network [17,40]. Firewalls will become lesseffective over time as users tunnel protocols through them,allowing for inadequate security on the tunnel endpoints.Hence a DDoS attack will be able to target an end nodesupporting QoS. If the tunnels are encrypted, there is no wayfor the firewall to censor the tunnel or DDoS attacks [17].

To defend against the SYN flooding attack, a firewall maywork as a proxy for TCP connection requests. It may alsoact as a TCP connection request monitor that sends a thirdmessage to the destination host to release its resources [3].Unfortunately, a firewall requires a significantly higheramount of processing time than routing [64,65]. Process-ing time increases as the rule set increases in lengthand complexity [66]. As a result, a firewall can easilybecome a bottleneck and also becomes susceptible to DoSattacks [3,41,66]. These attacks merely delay or preventlegitimate packets from being processed for legitimate con-nections, such additional delays degrade the QoS of trafficongoing connections. Robust efficient methods are neededto improve firewall performance for QoS traffic when sub-jected to security threats.

4.3. Honeypots

Honeypot act as a decoy by being placed on a network to beattacked so that we can monitor how the network is beingcompromised from an attack [42,67]. Usually it consistsof a computer that looks as if it is part of a network butlimits the attacker’s access to the entire network since it isactually isolated from the network. A honeypot is intendedto entice an attacker to install either handler(s) or agentcode(s), which enables the honeypot to track the behaviorof handler or agent before it presents a problem for thenetwork [68]. The issue with honeypots is how they can bedeployed to detect, identify, and capture attacks and whetherthe honeypot should be placed inside or outside of a firewall.Given that honeypots are only capable of handling attacksdirected to themselves, sophisticated attackers can easilyavoid honypots deployed at fixed locations on the network[69]. In other words, they can even attack network QoS withlittle effort by simply evading the location where honeypotsare deployed.

4.4. IP traceback

IP traceback methods provide the victim the capability toidentify the actual true source of the packets causing the DoSattacks [19]. Given the complexity of the current Internet,it is difficult for the victim to determine the actual source ofthe attack because the attacker routinely counterfeits its IPsource address (spoofing). IP traceback is an important con-cept for restoring and averting re-occurrences of an attack,particularly when an attacker spoofs (counterfeits) its IPsource address. Simply discovering the attacker might seemlike a narrow goal, but the essential clues it provides mayhelp discover the actual attacker [20]. The challenge of IPtraceback is to find an effective and scalable way to trackthe sources of an IP packet. Hence the IP traceback shouldminimize time that routers spend on tracking and the stor-age that is used to keep the tracking information. In thissection, we discuss four popular IP traceback methods andevaluate them according to how they can affect networkQoS.

4.4.1. IP traceback by packet marking.

This approach lets the routers insert additional informa-tion into an IP packet so that the victim is able to deduce thepath the traffic has taken (Figure 7). Consideration of therobustness of this method needs to be addressed. For exam-ple, when the packet marking is not secure or inadequate,an attacker can generate false packet markings (also calledspoofed marking) [18,70]. This spoofed marking resultsin the victim receiving several false paths, and the vic-tim becomes unable to determine who is the attacker. Tomake this method more effective, it is necessary to reducethe packet size unless we have downstream fragmentation.A drawback with downstream fragmentation, however, isthat it increases the number of packets into the network.These packets lead to increased network traffic which in turnwill affect network QoS. If a larger packet size is allowedinstead, it introduces an increase in latency, also affectingnetwork QoS. Furthermore, packet marking has to be fastenough to allow for real-time packet marking. Otherwise,we will likely experience additional delays which will alsoimpact QoS.

Figure 7. Packet marking.



Another proposal to minimize the router overheads isProbabilistic Packet Marking (PPM) [19,70]. This methodincludes operations such as node append, probabilistic nodesampling, and edge sampling. PPM does not incur anystorage overhead with routers and the marking procedure(checksum update) can be easily and efficiently executed atcurrent routers. Unfortunately, PPM is not scalable. Whenthere are 25 or more attacking sources, path rebuilding takesconsiderable amount of time [71]. Therefore, for real-timetraffic with QoS requirements this is not a desired solution.

4.4.2. IP traceback by logging.

One solution for tracking an attacker is to log packets atvarious key routers throughout the Internet and use data-mining methods to extract information to form a path ofthe attacker [20]. This solution appears appealing becauseit allows for precise analysis of the attacker. However, itrequires a large amount of processing and storage overheadto save the various logs. Sharing the log information amongvarious ISP, presents a problem of legal issues and pri-vacy concerns. Probabilistic sampling and compression willreduce the various logs, but these methods present consider-able demands on the network resources [20]. One loggingmethod proposed is Source Path Isolation Engine (SPIE)[21,44]. SPIE only hashes relevant portions of a packet inan efficient memory structure by means of bloom filters.Overlay methods also aim to decrease the log, but it presentsa burden on network resources such as bandwidth, process-ing capability from the establishment and maintenance oftunnels [18].

4.4.3. IP traceback by hashing.

To distribute the overhead throughout the network, hash-based IP traceback [21,45] has been proposed. This methodconsists of the following components: Data GenerationAgents (DGAs), SPIE Collection and Reduction Agents(SCARs), and SPIE Traceback Manager (STM). DGA isapplied to each router with bloom filters so that everyrouter deterministically logs some information about eachpacket traversing the router. SCAR is responsible for onearea of the network and is linked to all DGAs inside ofits area. The STM is responsible for dealing with the vic-tim’s requests and assembling the path information fromthe various SCARs (Figure 8).

When the victim’s Intrusion Detection System (IDS) rec-ognizes features of the attacking packets, the IDS will reportthese features back to the STM (Figure 8). The STM for-wards the request to the appropriate SCARs. The variousSCARs in the STM area collect the data logged by eachrouter having a DGA. Next, the SCAR reconstructs theattack path inside its area and submits the path reconstruc-tion result back to the STM. The drawback of SPIE is that itincurs heavy computational calculations, distributed man-agement, and storage overheads [18]. The computationalburden is also distributed over the network (SCARs andSTM) and a high communication burden is placed on the

Figure 8. SPIE (Source Path Isolation Engine).

network bandwidth. Since the victim is affected by the highcommunication overheads, its QoS will also suffer as aconsequence.

4.4.4. IP traceback by ICMP.

The Internet Engineering Task Force (IETF) proposedan ICMP (Internet Control Message Protocol) tracebacktechnique [23,43] called iTrace as a possible DDoS solu-tion. With this approach, when forwarding packets, a routercopies the contents of the packet to a specific type of ICMPtraceback message containing information about either theadjacent upstream or downstream routers, or both adjacentupstream and downstream routers. Based on this informa-tion, the ICMP traceback message is forwarded towards thesame destination as the original packet. An ICMP tracebackmessage to the destination is generated for every 20 000packets (Figure 9). The ICMP traceback packet includesthe identity of the router, contents of the packet, and infor-mation about the adjacent routers. During an attack, afterreceiving a considerable number of traceback messages,the victim can identify the approximate source of the attackby tracing the entire path taken by the attacker from theinformation received in the ICMP traceback packets.

The basic idea with this scheme is that every router sam-ples one of the packets with low probability (e.g., 1/20 000)by copying contents of the packet into a special ICMPtraceback (also called iTrace) message. The ICMP messageincludes information about the adjacent routers along thedestination path (Figure 9). However, there is an assump-tion that all ICMP packets are allowed. In fact, it is not thecase. Some sites do not allow ICMP packets through theirnetworks, so the victim may not receive the ICMP trace-

Figure 9. ICMP-based traceback.



back messages. This would result in no or partial path forthem to use to identify the attacker. The fact that ICMPtraceback messages are generated at very low frequency(1/20 000) (with a high probability of being rejected atsome sites) would cause a degradation in network QoS.This is because in order to accumulate enough informationto trace the path of the attacking traffic using the ICMPtraceback messages, the victim should receive a fairly largenumber of attack packets. If all the packets traveling overthe network are attack packets, a victim needs to receiveat least 19 999 attack packets to obtain one ICMP trace-back message. Considering the fact that ICMP packets arenot allowed sometimes, the actual number of attack packetsreceived will take a long time to reach 20 000. By the timeenough ICMP traceback messages would have been gen-erated, the QoS of ongoing network services would havealready been degraded.

It should be noted, if each DDoS slave only contributesa small amount of attack traffic, then the probability for anearby router picking the right attack packet can be verysmall [22]. The routers closer to the victims tend to havemore iTrace messages (or ICMP traceback messages) for-warded to them because most of the attack traffic has beenaggregated. The victim probably will get many ICMP trace-back messages from the neighboring routers but very fewattackers [20,22]. A method proposed to address this prob-lem is called intention-driven ICMP traceback [22]. Theproposed method adds intelligence to the marking process.This means that the data obtained for path reconstructionmay be promptly determined by the victim [18]. This isaccomplished by explicit information supplied by the rout-ing table, in which a decision module would select thekind of packet to use next to generate an ICMP tracebackmessage [20].

Even with the above proposed method, there are sev-eral attacks on different paths with dissimilar lengths. Asa result, simply using a predetermined marking probabilityof 1/20 000 for all paths may seriously degrade the networkperformances [18,20].

4.5. Pushback by aggregate-basedcongestion control

The Aggregate-based Congestion Control (ACC) methodwas introduced to identify and regulate an aggregate trafficstream at a single router by means of a pushback mecha-nism. The primary goal of ACC is to protect the networkand the rest of the traffic from severe congestions causedby high-bandwidth aggregates [55,56]. A router implement-ing ACC monitors its level of congestion (Figure 10). Whena host is not the attacker, it decreases its transmission rate.ACC adds rate-limiting functionality to routers for detectingand dropping suspicious packets. When the router discoverssustained severe congestion, it tries to identify the aggre-gate(s) responsible for such congestion, using either drophistory or random samples. With this method, the pushbackmechanism begins only when congestion occurs. Actually,

Figure 10. Aggregate-based congestion control.

the upstream routers will be notified by the pushback requestmessage to limit the number of packets destined to thevictim to let other legitimate traffic move because the down-stream routers will drop those packets later anyway. Theconcept of pushback usually uses the destination prefix asa congestion signature to distinguish and protect the legit-imate traffic within the aggregate. The goal is to identifythe malicious connections by examining the destination IPaddresses of the dropped packets [46,55].

When a host decreases its transmission rate, the num-ber of packets dropped will decrease, resulting in the hostbeing regarded as a legitimate user. If a large portion ofthe dropped packets are identified as having the same IPaddress, these packets are considered to belong to the DDoSattack and their shared destination IP address is used as theattack signature. Once the malicious traffic is identified, theproposed solution is to block the malicious traffic [72--75].Unfortunately, the pushback cannot distinguish betweengood and bad traffic going to the destination, and willdrop them equally [57,76]. This could result in the legit-imate multimedia traffic being taken for malicious traffic.For instance, those packets from hosts that are close to theattackers would also be punished whether they belong toBE or multimedia traffic.

4.6. Authentication

Authentication has long been used in networks todefend against various attacks. For example, IP Security(IPSec) [77] provide services such as data source authen-tication, data integrity, confidentiality, protection againstreplay attack, data privacy, access control, and end-to-endsecurity for IP packets by means of establishing sharedkeys between the source and destination. Hence, variousauthentication protocols (e.g., IPSec) are used to verifythe identities of the communicating parties. The integra-tion of authentication protocol to effectively resist networkDoS attacks and other types of common attacks have beenproposed [24--29,47].

Authentication based on the public-key infrastructureis computationally expensive. Cryptographic operationsoften involves extensive computations such as the modu-lar exponentiation. Even with the use of cryptography inauthentication to protect against DoS attacks, it is likelyto cause fragmentation (due to the packet changing in size)causing an increase the traffic load on the bandwidth [78,79]



Figure 11. Basic CenterTrace model.

which will affect network QoS. When public-key basedauthentication is applied, the computation complexity ofencryption/decryption consumes time and power [78]. Thetransmission and encryption/decryption of credentials canaffect several QoS parameters such as delay, call droppingprobability, and throughput [78,79].

4.7. Statistical analysis

Instead of defending against DDoS attacks by means ofauthentication, another method proposed for defendingagainst DDoS attacks is statistical analysis [30--34,58].

Statistical methods use the characteristic of the packetheader such as IP address or Time-to-Live (TTL) for sta-tistical calculations. Based on the statistical calculation andmeasurement, packets which are considered to be attackpackets are dropped. Such methods preclude the trafficdistinctiveness that are naturally constant with standard net-work processes [31,34]. As a result, when a DDoS attackoccurs, based on the traffic distinctiveness and standardnetwork processes, irregular traffic distinctiveness will beconsidered to be illegitimate traffic, resulting in the ille-gitimate traffic to be dropped by the filter that guards thevictim’s network [80]. An example of the usage characteris-tic of the packet is hop-count filtering [32,48]. This methodrelies on the TTL field in an IP packet to provide informationon the number of hops between the source and destinationthat are stored in a table with its respective IP address. Whenan IP packet is received and there is an inconsistency with itshop count and the value stored in the previously built table,the IP packet will be dropped. These methods depend heav-ily on assumptions of traffic characteristics and probabilisticmethods. Sophisticated hackers may use IP addresses withrelevant hop count, making this defense strategy altogetherineffective. Furthermore, these methods consider only BEtraffic ignoring QoS traffic. For QoS, the traffic characteris-tics or the state where the network is in should be considered.

For example, when congestion occurs on the network, QoStraffic may be routed to less congested paths, resulting in thenumber of hops being altered. When calculating statisticsof packet attributes, additional latency may be introducedif the calculation is complex resulting in taking more timeand power. An end-to-end coordination of QoS traffic isrequired for statistical calculations of QoS traffic.

4.8. Overlay networks

An overlay network is an isolated virtual network deployedover an existing network. It is a collection of varies hosts(originator of the packet sources), routers, and tunnels.Tunnels are network paths in the underling network, pro-viding links in the overlay network. Overlay networks havereceived a lot of interest for addressing DoS attacks becauseof link-testing (or hop-by-hop tracing) [20,59,60,81]. Link-testing is done by testing network links between routers inorder to identify the source of the attacker. A link-testingmethod that uses overlay networks is called CenterTrack[35] (Figure 11). With this method, a particular router calleda Tracking Router (TR) or a group of TRs are used for inputdebugging [18,49]. The input debugging allows the networkadministrator to decide on incoming network links for spe-cific packets [18]. The TR is directly connected to eachingress‡ and egress§ edge router of the protected networkthrough tunnels. Once the attacker is detected, TR is ableto locate the ingress router of the attacker traffic flow sincethe ingress edge router may be seen as only one hop awayfrom the TR [18]. However, CenterTrack imposes an over-head management load on the network resources such asbandwidth and processing capability, due to establishmentand maintenance of tunnels. This management overhead

‡ Ingress: is the entry point (label edge router) into the overlay network.§ Egress: is the exit point (label edge router) into a network.



degrades the network QoS. CenterTrack can determine theingress edge router being attacked, but unfortunately, it isincapable of identifying the path only belongs to its domain[18]. Therefore, it is not very scalable as the local domainincreases. Scalability in the network is important for QoS,otherwise, QoS method would only work for certain situa-tions.

A malicious user may send spoofed packets in order toattack the defense of a node, or can inject attacking trafficto the overlay network. To avoid such problems, anotheroverlay network called Secure Overlay Service (SOS) wasproposed. The SOS architecture utilize intensive filteringand anonymity (‘secret servlets’) [36,37]. A secret servletnode computes keys for well-known hash functions basedon the site’s IP address. One example is secure overlayaccess point (SOAP), which is a delegated router allowinga packet to enter the overlay only after its identity is vali-dated [50,82]. Hence, the packets must be authenticated andauthorized by the SOS architecture before traffic is allowedto traverse through the overlay network to the end user.SOS therefore uses a combination of secure overlay tunnel-ing, routing via consistent hashing, and filtering. However,the insensitive filtering introduces latency and increases thetraffic delays [37]. The exchange of keys consumes time andpower which affects many QoS parameters such as delayand throughput.

4.9. Network forensics

The use of Network Forensics against DDoS attacks isbriefly summarized in this section. Network forensics mon-itor network traffic and determine if an anomaly exists inthe traffic, and if so, whether the anomaly can be an attack.With the use of custom-made sniffers and scripts, skilledprogrammers can design a technique to identify the DDoSattacks. An example of the use of forensics to other areasincludes load balancing and throttling [82]. By applyingload balancing, ISP providers can increase the networkbandwidth of QoS connections which can prevent QoS frombeing affected by a DDoS attack. However, the drawbackof such an approach is that QoS will be degraded if theattack occurs before the maximum bandwidth is achieved.Throttling is a method to control the bandwidth that anetwork application can use. During throttling, incomingtraffic is adjusted to acceptable levels that can be managedto the server. This technique may be utilized to mitigateDDoS attacks. Nonetheless, currently available technolo-gies cannot always distinguish between legitimate trafficfrom malicious traffic correctly. Further studies are neededto investigate the impact of a practical implementation ofthis method.

Other methods which have been applied in forensic anal-ysis include traceback, event logs, packet sniffers, filtering,and firewalls [81,83]. We have already discussed variouschallenges associated with these approaches in the previoussections.

5. QOS PROTOCOLVULNERABILITIES PRONE TODOS/DDOS ATTACKS

Multimedia support over networks has been extensivelystudied over the last decade. Several QoS approaches andprotocols have been proposed and implemented. However,very few of these proposed approaches have been incor-porated into commercial products. Consequently, thesetechniques have not been widely deployed. However, thereare some traffic engineering technologies that have gainedwide acceptance namely, MPLS, DiffServ and RSVP. In thissection, we discuss possible DoS attacks that can exploitsome of the vulnerabilities of these QoS protocols.

5.1. MPLS

To support QoS over IP networks, Traffic Engineering (TE)has introduced MPLS. MPLS is being widely deployed inthe Internet backbone [84]. In MPLS, the packet forwardingprocess is done by means of label swapping. Since labelsare short and have fixed length, MPLS can achieve highefficiency compared to conventional IP routing where thelongest prefix matching is used [84]. Similar to IP spoofingattacks, where an attacker fakes the source IP address of apacket, it is also theoretically possible to spoof the label ofan MPLS packet [51,85], assuming the MPLS core networkmay be trusted. However, one should not assume that thecore MPLS network will provide a level of security andintrusion invisibility [85]. As the core network is part of theend-to-end QoS path, protection against an insecure core isalso required. An example of the vulnerability of MPLS toDoS attacks was revealed by Cisco MPLS router [86].

It is important to prevent theft of services from an ISP.Therefore, a cryptographic protocol to protect MPLS headerneeds to be investigated. For the usage of cryptographicprotocol, it is necessary to ensure that the protocol willnot interfere with the QoS provided by an ISP on MPLSnetwork. For example, addition of 128 bits to each MPLSheader will result in the header becoming four times larger.This would add more processing delay for each packet. Fur-thermore, the key exchange algorithm also needs to be awareof the computation burden it imposes since this also affectsQoS [85].

Standard secure protocols (e.g., IPSec), operate at layer3 (compared to MPLS which operates at layer 2). Many ofthe MPLS network designs require the exchange of labeledpackets. This creates opportunities for a third party to intro-duce labeled packets, which, if correctly crafted, might beassociated with certain Virtual Private Networks (VPNs)on MPLS networks and could effectively introduce falsepackets into a VPN [85]. The design of a Security LabelDistribution Protocol (LDP) is an open issue for futurestudy [85]. In particular, is defense of privacy or authen-tication against DoS attacks require further investigation.

Various attacks can also be launched on layer 2 proto-col technologies (for instance, Address Resolution Protocol



Figure 12. Basic ReSource ReserVation Protocol (RSVP) model.

(ARP) attacks). Since LDP uses the ARP to establish a LabelSwitched Path (LSP), ARP spoofing allows an attacker toredirect traffic between two routers through the device of theattacker. As a result, the attacker gains access to all packetsbetween the two routers [85]. When many Label Switch-ing Routers (LSRs) share a common layer 2 network, athird party can inject packets into such networks. The labelforwarding method used in MPLS is affected by the vul-nerability of MPLS to DoS attacks such as label spoofing,traffic insertion, and disabling of the ingress. This, in turn,results in the degradation of MPLS labels fast forwardingand ultimately degrades the network QoS.

5.2. ReSource ReserVation Protocol (RSVP)

RSVP [87] was engineered to accomplish the creation andmaintenance of distributed reservation states across a setof multicast or unicast delivery paths. The RSVP methodallows the reservation of bandwidth for a path from thesender to the receiver that meets the traffic QoS require-ments. To establish an explicit route computed by constraintbased routing, as well as to reserve resources along thatroute for QoS, some kind of path set up signaling is needed.RSVP communicates with two basic types of messages,PATH and RESV (Figure 12). PATH messages flow from asender to the receiver. Upon receipt of the PATH messagefrom the sender, the receiver sends an RESV message inreturn and reserves network resource for the path. Main-taining an RSVP path requires the retransmission of refreshmessages. The establishment and maintenance of an RSVPpath use IP datagrams to transport messages between peers,which is based on UDP instead of TCP. Without TCP, apeer must handle the loss of distribution messages by itself.RSVP is a signaling mechanisms, which does not con-tain methods to verify that request to conforms to resourceallocation policies (which makes RSVP vulnerable to DoSattacks) [52,88] before admitting a flow and allocating theresources contained in the RSVP message.

For authorization and identification of the sender orreceiver, one might consider the use of public key cryptogra-

phy. The use of public-key-based authentication techniquesis, however, still considered to be too heavy-weight (com-putationally and from a bandwidth perspective) to be usedfor per-flow signaling [89]. It also requires a substantialamount of processing and memory requirement which candeplete resources available for QoS traffic.

The attacker can potentially intercept or drop all or someof the reservation messages (such that the QoS reserva-tion ones) and channel establishments can be maliciouslydelayed in a persistent way [89]. When RSVP is communi-cating with PATH (a PATH message is sent from the senderalong the data path and stores the path state in each nodealong the path) and a RESV (a RESV message is sent fromthe receiver to the sender along the reverse data path), anattacker can prevent RESV messages from being sent. Asa result, PATH messages will be sent again, thereby creat-ing additional traffic on the network which will likely affectQoS of ongoing traffic.

5.3. Differentiated services (DiffServ)

DiffServ networks provide QoS guarantees by policing traf-fic using a fixed number of pre-existing classes. DiffServ isa scalable method for providing QoS to multimedia traffic.DiffServ supports three different per hop behavior (PHB)as it transport traffic. These PHB traffic flows are expe-dited forwarding (EF), assured forwarding (AF), and BE.There are methods which have been explored to defendagainst DoS attacks while maintaining QoS by using Diff-Serv [53,54,90--92].

References [91,92] proposed resource isolation for TCPACK, ICMP, TCP-SYN messages. When a packet arrives,it determines the type of traffic (BE, EF or AF). Next, thepacket is divided into an UDP aggregate and a TCP aggre-gate (Figure 13). The TCP message carries data or controlsegments (ICMP, ACKs, SYN, etc). Traffic flows are iso-lated and the core is not affected by connection attacks (forexample TCP-SYN attacks). However, the problem withthis approach is that once the connection is attacked, it willprevent other connections from being set up. In addition,



Figure 13. Proposed DoS with DiffServ.

this method does not address the issue when the attack ison QoS traffic flows in AF or EF classes.

Another method proposed is differential packet filtering[90]. In this method, traffic conditions for each incomingpacket are considered safe, normal, or risky according toa continuously updated history table of trusted IP sources.When an attack occurs, some of the risky IP packets aredropped. Next, some of the safe and normal IP packetswill be downgraded or discarded. The differential packetfiltering is a probabilistic method used to determine riskypackets. Unfortunately, it is possible that some of the legit-imate traffic would also be dropped. Such packet loss isunacceptable for QoS traffic. This method also relies on his-tory tables which further intensify the amount of processingand storage overhead required to save history tables.

DiffServ uses the type of service (ToS) field in IPv4 andthe Traffic Type field in IPv6 to identify the QoS of traffic.A malformed packet may set the optional field to some fakeQoS format. As a result DiffServ will exhaust processingto determine whether it is a malformed packet or an actualQoS packet [68]. DiffServ also identifies traffic based on IPaddresses. Therefore it is susceptible to another type of DoSattacks, called IP address attack. In an IP address attack,the packet has the same source and destination IP address[68]. As a result, it confuses the network/operating systemresulting in a network or user operating system to crash[68] and it in turn will affect the QoS of network services.Generally, IP addresses of QoS packets are not protectedwith encryption because of the high processing overheadsassociated with encryption/decryption, and the exchange ofsecurity keys also consumes time and power which will inturn affect QoS.

6. FUTURE WORK

The task of mitigating DoS and DDoS attacks and theconfiguration of QoS requirements on networks should betransparent to end-users. This is a highly desirable goal, butmuch work remains to make it a reality. As pointed out inthis paper, several issues involved in supporting seamless

security with end-to-end QoS support need to be addressed.Among those issues include:

Authentication: Data integrity, confidentiality, privacy,and end-to-end security are important to prevent routinginformation from being compromised. Authentication willaffect the QoS performance. Thus, it needs to be simpleenough not to affect QoS traffic, but advanced and sophis-ticated enough to protect against DoS/DDoS attacks.

Logging: Whether it is used for statistical analysis, trace-back, or filtering, considerations on how many loggingtables and how much information need to be addressedbecause they affect the amount of storage required to storesuch information. Since network storage resources are lim-ited, smaller logging tables are required. Having log tablesrecord information make them also prone to attacks fromintruders.

Complex computations (whether statistical analysis orkey exchange) consume time and power to validate theidentity of the user. This issue needs to be addressed infuture works. If unnecessary computations are performed,QoS will be affected because resources are used instead toperform such tasks. Any new security method should notincrease the size of original packet nor have complex controlmessage exchange.

Changing the size of packet, which could result in thepacket being fragmented, or having complex signaling pro-tocols, which takes time to process, will cause greaterdelays for QoS traffic due to the decrease in bandwidthbecause of the additional traffic load and processing over-heads required. While the network is congested, controlmessages sent from the defensive agents may be droppedor lost. This presents a problem as control messages haveto be arrived safely for most QoS traffic.

MPLS: As mentioned in the previous section, we shouldnot assume that the core MPLS network will provide a highlevel of security and intrusion invisibility‖ [85]. Since thecore network is part of the end-to-end QoS path, protectionagainst an insecure core is required. The use of crypto-graphic protocol with MPLS and current secure protocols(such as IPSec) are particularly important areas of focus inthe future.

Cryptographic protocols are used to prevent theft of ser-vices. It is necessary to ensure that such protocol will notinterfere with the QoS on an MPLS network.

Standard secure protocols (such as IPSec) operate at layer3 and not at layer 2 as MPLS does. Thus, MPLS architec-tures require the exchange of labeled packets informationwhether it is forwarding a label or establishing a LSP.This may enable a third party to introduce labeled pack-ets, which, if correctly crafted, could effectively introducefalse packets into a VPN [85]. A secure Label DistributionProtocol (LDP) remains an open issue for future investiga-tions [85].

‖ Similar to IP spoofing attacks, where an attacker fakes the source IPaddress of a packet, it is also theoretically possible to spoof the label ofan MPLS packet.



Traceback: To accomplish IP traceback, we need to reachthe host where the attack originated. It is not easy to tracepackets through firewalls because the last-traced IP addressmight be the firewall’s address. Another drawback to theusage of traceback systems is that generally traceback meth-ods require changing the network, as well as adding routerfunctions and changing packets. Guidelines for dealing withtracing back an attack packet through various networks areneeded because it infringes on the privacy of those cus-tomers paying for QoS services as well as those not payingfor QoS. To promote traceback methods with QoS support,their effects on QoS traffic should be taken into account. Inaddition, further consideration need to be given to the useof information about an attacker’s source identified by IPtraceback.

DiffServ: DiffServ provides QoS guarantees by policingthe traffic as it enters the network. This is done by classifyingand conditioning traffic to conform to a specific behav-ior aggregate based on the SLA between the source andthe DiffServ provider into a fixed number of pre-existingclasses. An attacker may be able to obtain better serviceby modifying the DiffServ field or by injecting packets tothe DiffServ classes. A DoS attack will occur when themodified or injected traffic depletes the resources availablefor forwarding packets. Hence, ingress nodes are the pri-mary line of defense against DoS attacks. Ingress nodesmust condition all inbound traffic to ensure that the DiffServcodepoints are acceptable. Packets found to have unaccept-able codepoints must be either discarded or must have theirDiffServ codepoints modified to acceptable values beforebeing forwarded. An important instance of an ingress nodeis that any traffic-originating node in a DiffServ domain isthe ingress node for that traffic, and must ensure that all traf-fic coming from it carries acceptable DiffServ codepoints.The proposed countermeasure should be combined withother security protocols if both QoS guarantee and securityassurance are required. This technique allows the DiffServnetwork to distinguish valid traffic from malicious traffic.

RSVP: RSVP is a signaling mechanisms, which doesnot contain methods to verify the request to conform toresource allocation policies [52,88] before admitting theflow and allocating the resources contained in the RSVP.This, as a result, makes RSVP vulnerable to DoS attacks.For authorization and identification of the sender or receiver,one might consider the use of public key cryptography.The use of public-key-based authentication techniques is,however, still considered to be too heavy-weight (compu-tationally and from a bandwidth perspective) to be usedfor per-flow signaling [89]. It requires a significant amountof processing and memory requirement and will result infragmentation thereby allowing DoS attacks. Trade-offsbetween performance and security have been a recurrenttheme. As signaling messages are transmitted at a low rate,the protection of these messages is usually not a prob-lem. For an RSVP router, even a high volume of messagesdoes not cause performance problems due to the efficiencyof the keyed message digest routine [89]. It is dynamickey management that is computationally more demanding,

especially when it comes to scalability. Since RSVP doesnot state a particular key exchange protocol, it is hard toapproximate the effort needed to create the required secu-rity associations. Furthermore, the number of key exchangesto be triggered depends on security policy issues and theauthentication mode used by the key exchange protocol.Hence the greater the security applied to RSVP, the greateris the impact on the QoS performance delivered by RSVP.Thus, the security method used in conjunction with RSVPneeds to be simple enough so as not to affect the QoS traf-fic, but robust as well to provide protection against possibleDoS attacks.

7. CONCLUSION

There are many kinds of defensive measures that have beenproposed to reduce the possibility of DoS/DDoS attacks.However, these security techniques have given little con-sideration to the performance impact they have on networkQoS. We provided an overview of several defense mecha-nisms against DoS/DDoS and we evaluated their impacton the QoS delivered by the network. In addition, wealso discussed and presented vulnerabilities associated withpopular QoS protocols that have been proposed (some ofwhich are already widely deployed in current networks)that are prone to DoS/DDoS attacks. Each of the DoS/DDoSdefense mechanisms described in this work has its own lim-itations when it comes to their impact on network QoS.DoS/DDoS attacks can seriously affect QoS traffic, therebybreaking the SLA between the client and the ISP. Hence,DoS/DDoS attacks are major threats to network QoS. Itis our hope that the results of this work will motivateresearchers and designers to investigate novel, comprehen-sive DoS/DDoS solutions that not only protect networksand systems but are also able to be deployed in actual net-working environments with negligible impact on networkQoS. Such solutions will lead to adaptable, secure networksystems that can also efficiently support end-to-end QoS.

REFERENCES

1. CERT� Coordination Center. CERT� Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks,May 2006. Available online at: http://www.cert.org/advisories/CA-1996-21.html

2. Luo H, Shyu M. The protection of QoS for multimediatransmission against denial of service attacks. IEEE Inter-

national Symposium on Multimedia, December 2005.3. Wang B-T, Schulzrinne H. Analysis of denial-of-service

attacks on denial-of-service defensive measures. IEEE

GLOBECOM, December 2003; 1339–1343.4. Aiello W, Bellovin S, Blaze M, et al. Efficient, DoS-

resistant, secure key exchange for internet protocols.ACM Conference on Computer and Communications

Security (CCS), November 2002.



5. Carnegie Mellon’s CERT� Coordination Center.2007 E-CrimeWatch SurveyTM Summary of Findings.Available online at: http://www.cert.org/archive/pdf/ecrimesummary07.pdf

6. Stein L, Stewart J. The World Wide Web Security FAQ.Available online at: http://www.w3.org/Security/Faq/

7. Douligeris C, Mitrokotsa A. DDoS attacks and defensemechanisms: classification and state-of-the-art. Elsevier

Computer Networks 2004; 44(5): 643–666.8. Karig D, Lee R. Remote denial of service attacks and

countermeasures. Department of Electrical Engineering,Princeton University, Technical Report CE-L2001-002,October 2001.

9. Houle K, Weaver G, Long N, Thomas R. Trends in denialof service attack technology, May 2007. Available onlineat: http://www.cert.org/archive/pdf/DoS trends.pdf

10. Carnegie Mellon’s CERT� Coordination Center.Types of Intruder Attacks, May 2007. Available onlineat: http://www.cert.org/present/cert-overview-trends/module-4.pdf

11. Carnegie Mellon’s CERT� Coordination Center.Current Vulnerabilities and Attack Methods, May2007. http://www.cert.org/present/cert-overview-trends/module-5.pdf

12. Hamai T, Fujii M, Watanabe Y. ITU-T recommendationson peer-to-peer (P2P) network security. IEEE Interna-

tional Symposium Autonomous Decentralized Systems,March 2009.

13. ITU-T Recommendation X.1161. Framework for securepeer-to-peer communications to be published.

14. CIAC, Information Bulletin. Q-029: Cisco 11500 Con-tent Services Switch SSL Malformed Client CertificateVulnerability. Available online at: http://ciac.llnl.gov/ciac/bulletins/q-029.shtml

15. Kenney M. Ping of Death. Available online at:http://www.insecure.org/sploits/ping-o-death.html

16. Internet Security Systems (ISS). Finger bomb recur-sive request. Available online at: http://xforce.iss.net/xforce/xfdb/47

17. Bellovin S, Schiller J, Kaufman C. Security Mechanismsfor the Internet. RFC3631, December 2003.

18. Zhiqiang G, Ansari N. Tracing cyber attacks from thepractical perspective. IEEE Communications Magazine

2005; 43(5): 123–131.19. Savage S, Wetherall D, Karlin A, Anderson T. Network

support for IP traceback. IEEE/ACM Transactions on

Networking 2001; 9(3): 226–237.20. Aljifri H. IP traceback: A new denial-of-service deter-

rent. IEEE Magazine Security & Privacy 2003; 1(3): 24–31.

21. Snoeren A, Partridge C, Sanchez L, et al. Single-packet IPtraceback. IEEE/ACM Transactions on Networking 2002;10(6): 721–734.

22. Mankin A, Massey D, Wu C, Wu S, Zhang L. On designand evaluation of intention-driven ICMP traceback.IEEE International Conference on Computer Commu-

nication and Networks (ICCCN), October 2001; 159–165.

23. Bellovin S, Leech M, Taylor T. ICMP Traceback Mes-sages. IETF 2003. http://www3.ietf.org/proceedings/03jul/I-D/draft-ietf-itrace-04.txt

24. Lee M, Fung C-K. A denial-of-service resistant public-key authentication and key establishment protocol. IEEE

International Performance, Computing, and Communi-

cations Conference, April 2002; 171–178.25. Choi S. Denial-of-service resistant multicast authentica-

tion protocol with prediction hashing and one-way keychain. IEEE International Symposium on Multimedia,December 2005; 701–706.

26. Pietro R, Durante A, Mancini L. A reliable key authen-tication schema for secure multicast communications.International Symposium on Reliable Distributed Sys-

tems, October 2003; 231–240.27. Saxena A, Soh B. Distributed denial of service attacks

and anonymous group authentication on the Internet.International Conference on Information Technology and

Applications (ICITA), July 2005; 460–464.28. Sangpachatanaruk C, Khattab S, Znati T, Melhem R,

Mosse D. Design and analysis of a replicated elusiveserver scheme for mitigating denial of service attacks.Elsevier Journal of Systems and Software 2004; 73(1):15–29.

29. Khattab S, Sangpachatanaruk C, Moss D, Melhem R,Znati T. Roaming honeypots for mitigating service-leveldenial-of-service attacks. IEEE International Confer-

ence on Distributed Computing Systems (ICDCS), March2004; 328–337.

30. Mirkovic J, Prier G, Reiher P. Attacking DDoS at thesource. IEEE International Conference on Network Pro-

tocols (ICNP), September 2002; 312–321.31. Feinstein L, Schnackenbzrg D, Balupari R, Kindred

D. Statistical approaches to DDoS attack detection andresponse. IEEE DARPA Information Survivability Con-

ference and Exposition, April 2003; 303–314.32. Jin C, Wang H, Shin K. Hop-count filtering: an effective

defense against spoofed DoS traffic. ACM International

Conference on Computer and Communications Security

(CCS), October 2003; 30–41.33. Peng T, Leckie C, Ramamohanarao K. Protection from

distributed denial of service attacks using history-basedIP filtering. IEEE International Conference on Commu-

nications (ICC), May 2003; 482–486.34. Kim Y, Lau W, Chuah M, Chao J. Packetscore:

statistics-based overload control against distributeddenial-of-service attacks. INFOCOM, March 2004;2594–2604.



35. Stone R. CenterTrack: an IP overlay network for trackingDoS floods. Usenix Security Symposium, August 2000.

36. Keromytis A, Misra V, Rubenstein D. SOS: an archi-tecture for mitigating DDoS attacks. IEEE Journal on

Selected Areas of Communications (JSAC) 2004; 22(1):176–188.

37. Keromytis A, Misra V, Rubenstein D. SOS: secure over-lay services. ACM SIGCOMM, August 2002.

38. Maiolini G, Cignini L, Baiocchi A. Adaptive optimiza-tion of packet filtering devices performance ensuringa conflict-free network configuration. IEEE INFOCOM

Workshops, April 2008.39. Malliga S, Tamilarasi A, Janani M. Filtering spoofed

traffic at source end for defending against DoS/DDoSattacks. IEEE International Conference on Computing,

Communication and Networking (ICCCNET), December2008.

40. El-Atawy A, Al-Shaer E, Tran T, Boutaba R. Adaptiveearly packet filtering for defending firewalls against DoSattacks. IEEE INFOCOM, April 2009.

41. Salah K, Sattar K, Sqalli M, Al-Shaer E. A probing tech-nique for discovering last-matching rules of a networkfirewall. IEEE International Conference on Innovations

in Information Technology, December 2008.42. Das V. Honeypot scheme for distributed denial-of-service

attack. IEEE International Conference on Advanced

Computer Control, January 2009.43. Goodrich M. Probabilistic packet marking for large-scale

IP traceback. IEEE/ACM Transactions on Networking

2008; 16(1): 15–24.44. Andreou M, Moorsel A. Logging based IP traceback in

switched ethernets. ACM EUROSEC: Proceedings of the

1st European Workshop on System Security, March 2008.45. Sung M, Xu J, Li J, Li L. Large-scale IP trace-

back in high-speed Internet: practical techniques andinformation-theoretic foundation. IEEE/ACM Transac-

tion on Networking 2008; 16(6): 1253–1266.46. Priescu I, Nicolaescu S. Design of traceback methods for

tracking DoS attacks. IEEE International Association of

Computer Science and Information Technology—Spring

Conference, April 2009.47. Zheng L, Zhang Y. An enhanced IPSec security strategy.

IEEE International Forum on Information Technology

and Applications, May 2009.48. Wang H, Jin C, Shin K. Defense against spoofed IP traf-

fic using hop-count filtering. IEEE/ACM Transaction on

Networking 2007; 15(1): 40–53.49. Tupakula U, Varadharajan V, Pandalaneni S. DoS-

TRACK: a system for defending against DoS attacks.ACM Proceedings Symposium on Applied Computing,March 2009.

50. Zhao F, Peng X, Zhao W. Multi-tier security featuremodeling for service-oriented application integration.

IEEE/ACIS International Conference on Computer and

Information Science, June 2009.51. Lakshminarayanan K, Adkins D, Perrig A. Secur-

ing user-controlled routing infrastructures. IEEE/ACM

Transaction on Networking 2008; 16(3): 549–561.52. Fu X, Schulzrinne H, Tschofenig H, Dickmann C,

Hogrefe D. Overhead and performance study of thegeneral internet signaling transport (GIST) protocol.IEEE/ACM Transaction on Networking 2009; 17(1):158–171.

53. Kompella R, Singh S, Varghese G. On scalable attackdetection in the network. IEEE/ACM Transactions on

Networking 2007; 15(1): 14–25.54. Luo H, Shyu M-L. Differentiated service protection of

multimedia transmission via detection of traffic anoma-lies. IEEE International Conference on Multimedia and

Expo, July 2007.55. Mahajan R, Bellovin S, Floyd S, Ioannidis J, Paxson V,

Shenker S. Controlling high bandwidth aggregates in thenetwork. ACM SIGCOMM Computer Communication

Review 2002; 32(3): 62–73.56. Ioannidis J, Bellovin S. Implementing pushback: router-

based defense against DDoS attacks. Internet Society

Symposium on Network and Distributed System Security,February 2002.

57. Yang X, Wetherall D, Anderson T. TVA: A DoS-LimitingNetwork Architecture. IEEE/ACM Transactions on Net-

working 2008; 16(6): 1267–1280.58. Kim S, Reddy A. Statistical techniques for detecting traf-

fic anomalies through packet header data. IEEE/ACM

Transactions on Networking (TON) 2008; 16(3): 562–575.

59. Xie L, Zhu S. Message dropping attacks in overlaynetworks: attack detection and attacker identification.Transactions on Information and System Security (TIS-

SEC) 2008; 11(3): 1–30.60. Walters A, Zage D, Rotaru C. A framework for mit-

igating attacks against measurement-based adaptationmechanisms in unstructured multicast overlay networks.IEEE/ACM Transactions on Networking (TON) 2008;16(6): 1434–1446.

61. Ferguson P, Senie D. Network ingress filtering: defeatingdenial of service attacks which employ IP source addressspoofing. RFC2827, May 2000.

62. Montenegro G. Reverse tunneling for mobile IP.RFC3024, January 2001.

63. Wu C-H, Cheng A-T, Lee S-T, Ho J-M, Lee D-T. Bi-directional route optimization in mobile IP over wirelessLAN. IEEE Semiannual Vehicular Technology Confer-

ence, September 2002; 1168–1172.64. Qiu L, Varghese G, Suri S. Fast firewall implementations

for software-based and hardware-based routers. ACM

SIGMETRICS, June 2001; 344–345.



65. Suri S, Varghese G. Packet Filtering in high speednetworks. Symposium on Discrete Algorithms, January1999; 969–970.

66. Benecke C. A parallel packet screen for high speednetworks. IEEE Computer Security Applications Confer-

ence, December 1999; 67–74.67. Spitzner L. Honeypots: Tracking Hackers. Addison-

Wesley Longman publishing Co. Inc: USA, 2002.68. Specht S, Lee R. Distributed denial of service:

taxonomies of attacks, tools and countermeasures.International Conference on Parallel and Distributed

Computing Systems, September 2004.69. Khattab S, Sangpachatanaruk C, Mosse D, Melhem R,

Znati T. Roaming honeypots for mitigating service-leveldenial-of-service attacks. IEEE International Conference

on Distributed Computing Systems, September 2004.70. Ehrenkranz T, Li J. On the state of IP spoofing defense.

ACM Transactions on Internet Technology (TOIT) 2009;9(2): 1–29.

71. Song D, Perrig A. Advanced and authenticated markingschemes for IP traceback. INFOCOM, April 2001; 878–886.

72. Ahn G, Kim K, Jang J. MF (minority first) schemefor defeating distributed denial of service attacks. IEEE

International Symposium on Computers and Communi-

cation (ISCC), June–July 2003.73. Geng X, Whinston A. Defeating distributed denial of

service attacks. IT Professional 2000; 2(4): 36–42.74. Yau D, Lui JCS, Liang F, Yam Y. Defending against

distributed denial-of-service attacks with max-min fairserver-centric router throttles. IEEE/ACM Transactions

on Networking 2005; 13(1): 29–32.75. Ioannidis J, Bellovin S. Implementing pushback: router-

based defense against DDoS attacks. Internet Society

Symposium on Network and Distributed System Security,February 2002.

76. Fowler S, Zeadally S. Defending against distributeddenial of service (DDoS) attacks with queue traffic dif-ferentiation over micro-MPLS-based wireless networks.ACM/IEEE International Conference on Systems and

Networks Communications, October 2006.77. Kent S, Atkinson R. Security architecture for the internet

protocol. RFC2401, November 1998.78. Gupta V, Gupta S, Chang S, Stebila D. Performance

analysis of elliptic curve cryptography for SSL. ACM

Workshop on Wireless security (WiSE), September 2002;87–94.

79. Alexander D, Arbaugh W, Keromytis A, Muir S, Smith J.Secure quality of service handling: SQoSH. IEEE Com-

munications Magazine 2000; 38(4): 106–112.80. Li Q, Chang E-C, Chan M. On the effectiveness of

DDoS attacks on statistical filtering. INFOCOM, March2005.

81. Peng T, Leckie C, Ramamohanarao K. Survey ofnetwork-based defense mechanisms countering the DoSand DDoS problems. ACM Computing Surveys 2007;39(1): 1–42.

82. Champagne D, Lee R. Scope of DDoS countermeasures:taxonomy of proposed solutions and design goals for real-world deployment. IEEE International Symposium on

Systems and Information Security (SSI’2006), November2006.

83. Achi H, Hellany A, Nagrial M. Network securityapproach for digital forensics analysis. IEEE Interna-

tional Conference on Computer Engineering & Systems,November 2008.

84. Rosen E, Viswanathan A, Callon R. Multiprotocol labelswitching architecture. RFC3031, January 2001.

85. Behringer M. Analysis of the security of BGP/MPLSIP virtual private networks (VPNs). RFC4381, February2006.

86. CIAC, Information Bulletin. P-110: Crafted PacketCauses Reload on Cisco Routers. Available online at:http://ciac.llnl.gov/ciac/bulletins/p-110.shtml

87. Braden Ed, Zhang L, Berson S, Herzog S, JaminS. Resource ReSerVation Protocol (RSVP)—Version 1Functional Specification. RFC2205, September 1997.

88. Metz C. RSVP: general-purpose signaling for IP. IEEE

Internet Computing 1999; 3(3): 95–99.89. Tschofenig H, Graveman R. RSVP security properties.

RFC4230, December 2005.90. Tanachaiwiwat S, Hwang K. Differential packet filter-

ing against DDoS flood attacks. ACM Conference on

Computer and Communications Security (CCS), October2003.

91. Wang H, Shin K. Transport-aware IP routers: a built-inprotection mechanism to counter DDoS attacks. IEEE

Transactions on Parallel and Distributed Systems 2003;14(9): 873–884.

92. Haining W, Shin K. Layer-4 service differentiation andresource isolation. IEEE Real-Time and Embedded Tech-

nology and Applications Symposium, September 2002;67–78.


Impact of denial of service solutions on network quality of service

Documents

Transcript of Impact of denial of service solutions on network quality of service