Analysis of Traceback Techniques

Zombie3 Control Mechanism

Attacker

Zombie2 Zombie1

Victim’s Machine / Network

Fig 1: Attack Mechanism

Analysis of Traceback Techniques

Udaya Kiran Tupakula

Vijay Varadharajan

Division of ICS, Macquarie University North Ryde, NSW-2109, Australia {udaya, vijay}@ics.mq.edu.au

Abstract

Today’s Internet is extremely vulnerable to Distributed Denial of service (DDoS) attacks. There is tremendous pressure on the sites performing online business and ISP’s to protect their networks from DDoS attacks. Recently, several novel traceback techniques have been proposed to trace the approximate spoofed source of attack. Each proposed traceback technique has some unique advantages and disadvantages over the others. In this paper we will consider some of the novel traceback techniques and focus our discussion i) to raise some of the real time issues that can be addressed in the further research and ii) from the attackers perspective on how to generate DDoS attacks and remain untraced even if any of the traceback technique is deployed in the Internet. We will also demonstrate how attacks can be further amplified if ICMP traceback technique is deployed in the Internet and discuss techniques to minimise the additional attack traffic.. We believe that the networks tend to become complex and more vulnerable to DDoS attacks if some of the proposed traceback techniques are deployed in the Internet.

Keywords: Denial of Service, DoS, DDoS, Traceback.

1

Introduction

After a series of attacks that occurred in February 2000, there is increased threat of DDoS attacks in today’s Internet. Denial of Service (DoS) (CERT 2000, David More, Geoffery M. Voelker, and Stefan Savage 2001), is an attempt by attackers to prevent access to resources by legitimate users for which they have authorization. In the case of DDoS, an attacker compromises several hosts on the Internet. Often, these are weakly secured machines and they are broken into using well-known defects in standard network service programs and common operating systems. These compromised computers are referred to as zombies. The attacker then uses these compromised computers to launch coordinated attacks on victim machines. In figure 1, the attacker has already done a substantial amount of work in creating the

Copyright © 2006, Australian Computer Society, Inc. This paper appeared at the Fourth Australasian Information Security Workshop (AISW-NetSec 2006), Hobart, Australia. Conferences in Research and Practice in Information Technology (CRPIT), Vol. 54. Rajkumar Buyya, Tianchi Ma, Rei Safavi-Naini, Chris Steketee and Willy Susilo, Eds. Reproduction for academic, not-for profit purposes permitted provided this text is included.

zombies. So it is only a matter of few keystrokes for the attacker to launch a severe DDoS attack on the victim. It is clearly evident from the recent attacks (Ivan Arce 2004) that the attacker can create a severe DDoS attack by using innocent systems even without compromising them. The attacker takes to his advantage the known vulnerabilities in an operating system or database. In the case of DDoS attack, the victim can protect his network from the attack traffic at his network boundary, if he has some security tools like firewalls and intrusion detection systems to identify and prevent these attacks. Even if the victim can prevent the attack at his boundary, since all the available bandwidth is consumed by the malicious traffic, the victim cannot have access to other networks (Internet) and other legitimate hosts/networks do not have access to the victim’s network. This can have considerable impact on the sites performing online business.

Recently several schemes have been proposed (P.Ferguson and D.Senie 1998, SANS 2000, Alex C. Snoeren, Craig Partridge, Luis A. Sanchez, Christine E. Jones, Fabrice Tchakountio, Beverly Schwartz, Stephen T. Kent, and W. Timothy Strayer 2002, Allison Mankin, Dan Massey, Chien-Long Wu, S. Felix Wu and Lixia Zhang 2001, D. Song and A.Perrig 2000, Drew Dean, Matt Franklin and Adam Stubblefield 2001, Stefan Savage, David Wetherall, Anna Karlin and Tom Anderson 2000, Steven M. Bellovin 2001) on how to detect and prevent some of these types of attacks. Since traceback techniques have received considerable attention during recent times, in this paper, we will focus our discussion on some of the novel traceback techniques and raise some real time issues that can be considered in the further research.

The paper is organised as follows. We will start our discussion with the single packet IP traceback technique in section 2 and issues related to the single packet IP traceback technique in section 3. Section 4 gives an overview of the IP packet marking techniques and section 5 raises some of the real time issues related to IP packet marking techniques. Section 6 gives overview of ICMP traceback technique and in section 7 we discuss how an attacker can generate a DDoS attack and remain untraced even if ICMP traceback technique is deployed in the current Internet. We will also present a simple demonstration to support our arguments and discuss techniques to minimise the additional attack traffic. Section 8 concludes.

2

Single Packet IP Traceback

Snoeren et al. (2002) proposed a Source Path Isolation Engine (SPIE) that allows traceback of even a single packet within the single ISP domain. The idea behind this approach is to maintain the database of all the traffic at every router within the domain and to query the database to identify the approximate source of attack if the victim reports a malicious packet. The novelty of this technique is the minimisation of the storage overhead using bloom filters and storing only the digest of non-varying fields in the IP header (J.Postel 1981) and the first 8 bytes of payload, instead of storing the complete packet. The main advantage of this technique is the traceback of a single packet with the capability to deal with the compromised routers within the ISP domain.

The SPIE architecture in Figure 2 consists of a Data Generator Agent (DGA), which will be incorporated into the routers (both edge routers and transit routers) within the ISP. While forwarding the packets, the DGA masks the varying fields (TTL, Checksum, ToS and options field) of the IP header and calculates the digest of the remaining fields in the IP header and the first 8 bytes of the payload. The DGA stores the digest in a time-stamped table and periodically pages out the portion of the table to the SPIE Collection and Reduction Agents (SCAR). The SCARs monitor a group of DGAs and generate a periodic graph of the traffic path. The SPIE Traceback Manager

(STM) is connected to the victim IDS. When the victim IDS reports the attack by sending the malicious packet and the time of receipt, the STM queries each individual SCAR for the local attack patch. The STM assembles each individual attack path received from the SCARs, calculates the total attack path and updates it to the victim.

3

Issues in Single Packet IP Traceback

The authors argue for the single packet IP traceback since a single packet can cause considerable damage to some of the mission critical applications. Let us analyse the technique with regard to single-packet DoS attacks. The computation overhead on the routers is very high, since hashes of the packets have to be calculated at every router. As the current routers carry gigabits of data per second, the storage overhead is equally very high, since the database of all the traffic has to be maintained at every router. The implementation cost of this technique is also very high, since all the routers should be modified or additional devices should be placed at every router to support the single packet traceback.

First let us consider the limitations of the single-packet traceback technique by assuming that the technique is deployed within a single ISP domain. The scheme assumes that the attacker is aware of the traceback. In this case, the attacker can co-ordinate the attack in such a way that the attack packet originates from the compromised host that is located in another ISP domain. Considering the number of attacking tools available in the Internet, it is a very simple task for the attacker to compromise and generate the attack packet from a host that is located outside the victim’s ISP domain. In this case, the traceback is only effective in determining the ingress router of the ISP through which the attack packet entered the ISP domain. This traceback information will be of no use to the victim. For each attack packet generated by the attacker, multiple queries have to be initiated within the ISP domain to determine the approximate source of attack. If considerable attack packets are generated on one or more customers of the ISP, this can result in an increase in traffic within the ISP domain. Since the packets are stored at every hop and since the current routers carry gigabits of data per second, the proposed technique has severe limitations on the time period for which the database can be maintained. This has a severe time restriction on the victim to identify the malicious packet and request the SPIE Traceback Manager (STM) for traceback within the time period for which the database is maintained.

Now let us assume that this technique is universally deployed in all the ISP domains and discuss the issues related to this approach. Let us assume that the attacker and the victim are connected to the ISP 1 domain depicted in Figure 3. Since the attacker is aware of the traceback, she/he would co-ordinate the attack in such a way that the attack packet originates from the ISP domain which is multiple hops away from the ISP 1. Let us consider that the attacker initiates the attack packet from DGA DGA DGA DGA SCAR STM Victim IDS SCAR

Number of attacking systems, number of parallel paths, length of path

RT

Figure: 4 ISP X domain. Now in order to traceback this attack

packet, the victim has to quickly detect the attack packet and request its STM to traceback the approximate source of attack packet. The STM can initiate the traceback process only after proper authentication of the victim. The STM in ISP 1 will query all the SPIE Collection and Reduction Agents (SCAR) in its domain and determine the ingress edge router through which the attack packet entered its domain. Now this process should be repeated in all the upstream ISP domains from ISP 1 to ISP X.

If the traceback has to be initiated in the upstream ISP 2, the victim or the STM in ISP1 has to request the STM in ISP2 to initiate the traceback. This raises several issues as to who (the victim or the STM in ISP 1) should initiate the request and how authentication should be achieved for the traceback to be initiated in an inter-domain situation. This process can lead to DoS attacks on the STM in each ISP domain. Furthermore, this process has to be recursively repeated across multiple ISPs until the approximate source of attack can be identified with this technique. For this process to be effective in multiple ISP domains, it is a requirement that the database has to be maintained for extended time periods. Note that the single ISP itself has serious limitations on the time period for which the database can be maintained. Furthermore, for each attack packet generated, several queries have to be initiated in multiple ISP domains and this can lead to a greater increase in the Internet traffic. In addition to all these issues, it should also be noted that this technique only enables traceback of the single packet and is not capable of protecting the victim’s network from the single-packet attack. Hence we believe that it is efficient to deal with the single- packet attacks at the victim’s boundary by configuring specific security tools like firewalls.

4

IP Packet Marking Techniques

Several IP packet marking techniques (D. Song and A.Perrig 2000, Drew Dean, Matt Franklin and Adam Stubblefield 2001, Stefan Savage, David Wetherall, Anna Karlin and Tom Anderson 2000) have been proposed in the recent years. One of the major difficulties associated with tracing a packet stream back to the source is that it requires cooperation of all the intervening ISP’s. This is

complicated by the potential use of indirection to conceal the true origin of an attack. The proposed schemes mark the 32-bit IP address of the router with their own techniques by overloading the 16-bit Fragment ID field of an IP packet (J.Postel 1981). The proposed techniques make the assumption that there would be a considerable amount of packets generated during an attack. They argue that a victim will be able to reconstruct the route the packets followed by combining a modest number of marked packets, though each marked packet represents only a sample of the path it has traversed. Since packets are probabilistically marked, the victim would need large number of packets to calculate the total path traversed by the attack traffic. Even if we assume that each packet is marked, it could take a considerable amount of time for the victim to calculate the path, as computation is needed to retrieve the 32-bit IP address of the marked router. In general, the time taken to reconstruct the path (RT) is dependent on the number of attacking systems, number of parallel paths and length of the path (D. Song and A.Perrig 2000). Figure 4 shows the characteristics of the traceback approaches. The number of false positives is also dependent on the number of attacking hosts, length of path and number of parallel paths.

Advantages of this approach include:

• The ability to trace route the approximate source of an attack even in the case of heterogeneous networks without the cooperation of ISPs.

• Retention of evidence for legal proceedings. • As path information is encoded within the packet

header, no additional traffic is generated with these techniques.

• Since the marking is done on some probability the overhead on the routers is less.

In general the proposed IP Traceback techniques have

atleast some of the following disadvantages:

• Packets are marked with some probability and moreover each marked packet represents only a part of the IP address of the marked router. So it consumes a lot of time to calculate the path traversed by the attack traffic.

• The reconstruction time and number of false positives is dependent on the number of attacking

ISP 1

ISP 2 ISP X

Fig 3: Multiple ISP Scenario

systems, length of the path and number of parallel paths.

• Packets are marked even if there is no attack. • Victim should have the map of all the upstream

routers.

• Victim should share a key with all the upstream routers.

• It cannot deal with the fragmented packets.

• For any packet marking technique to be effective, all ISPs should agree to deploy a similar packet marking technique in their respective domain.

5

Issues in Packet Marking Technique

In this section, we will focus our discussion on some of the real time issues that are related to IP packet marking techniques. Unless specified, the section deals with the traceback techniques in general.

5.1

Co-operation of ISPs

The authors of the traceback techniques claim that their technique is capable of tracking the approximate source of attack in heterogeneous networks without the co-operation of the ISPs. Even if the proposed technique is capable of tracking the attack source in heterogeneous networks, we believe that a fair amount of co-operation is needed between the ISPs, both for the deployment and for the functioning of traceback technologies. Up to the present day, no traceback technique has been proposed that deals with the interoperability between the traceback techniques. For a traceback technique to be effective, the same traceback technique should be deployed in all the ISP domains. That is, all the ISPs should agree to deploy a common traceback technique.

It should be noted that, even if most of the routers are capable of performing ingress filtering (P.Ferguson and D.Senie 1998), ISPs are not willing to perform ingress filtering, since it is an additional overhead on their routers. On the other hand, deployment of the traceback techniques requires modification to the router software since the marking is to be done in the fragment ID field. Upgrading the router software incurs additional costs for the ISPs. Even if the packets are marked on some probability, this can result in at least some additional overhead on the routers, depending on the traceback technique being used. So it is a major issue whether ISPs will be willing to bear the additional cost and overhead on their routers.

5.2

Problems with legal proceedings

Some proposals claim that one of the main advantages of the traceback techniques is to retain the evidence of attack so that the victim can initiate legal proceedings against the attacking sources. This is not entirely correct, because the calculated attack path is not accurate. The actual attack path is only a subset of the total calculated path. It should be noted that it was extremely difficult for a real-time DDoS victim (Steve Gibson 2001) to initiate

legal proceedings against that attacking sources, even when the attack was generated with the correct source address. With the traceback technologies, due to the high false positive rates, there is no strong evidence for the victim to initiate legal proceedings against the attacking source. If the victim initiates legal proceedings with the evidence captured from traceback techniques, the attacker can argue that it can be false positive or some compromised router could have fraudulently marked the packets. Even a small error that results in legal proceedings against an innocent client can cause additional financial losses for the victim. So the victim should be in a good position to differentiate between packets marked by the attacker and packets marked by benign and malicious routers, if legal proceedings against the attacker are to be successful.

5.3

Issues with fragments

In general, the packet marking techniques use the fragment ID field in an IPv4 packet to mark the packets for traceback purpose, since fragments constitute only 0.22 % of the total Internet traffic. Once deployed, traceback is a continuous process and there is more probability for all the hosts in the Internet to receive packets that are marked in the fragment ID field. There is no procedure to differentiate between packets that are fragments and packets that are marked in the fragment ID field for traceback purposes. Added to this complication, some DoS attacks use fraudulently marked fragmented packets. So there should be a procedure for the victim to differentiate packets that are real fragments, packets that are marked for traceback purposes and packets that are malicious fragmented packets.

5.4

Modifications to the existing architecture

In addition to the changes required to the routing infrastructure to support IP traceback, there is a need for further changes in the complete architecture. For example, the end hosts and security tools in the Internet should be modified to support IP traceback. If the end hosts are not modified to support IP traceback, they will process the packet as fragments. If security tools are not modified to support IP traceback, they can identify the fragments as malicious fragmented packets and generate false alarms. This can incur huge costs.

5.5

Incremental deployment

Let us now consider the situation where a single router in the Internet is modified to support an IP traceback technique with incremental deployment. This router marks the packet with traceback information with some probability. The marked packet can be destined to any host in the Internet. The end host will consider the packet as a fragment, if it is not capable of identifying that the packet is actually marked for traceback purposes. Hence all the hosts in the Internet should be modified to identify the packets that are marked for traceback purposes. To support incremental deployment, we require that the packet marking techniques should differentiate between packets marked for traceback and actual fragmented packets.

5.6

Problem with routes

Several routing protocols such as BGP, EIGRP, IGRP, OSPF, IS-IS and RIP are used to route the packets in the current Internet architecture. Each routing protocol uses different metrics to calculate the best path to a particular destination. The traceback techniques assume that routes between the attacking source and the victim are fairly stable. This condition may not hold true in all the cases and it is dependent on the routing protocols. For example, the RIP protocol only chooses the route with minimum hop count as the best/shortest route for a particular destination. Even in the case of RIP, we should note that there can be equal paths for a particular destination and the packet may take any of the routes to that particular destination. The advanced routing protocols such as OSPF, EIGRP and IS-IS calculate the shortest path based on several parameters such as hop count, time delay, bandwidth, load-balancing between equal paths and load-balancing between unequal paths. In the case of DDoS there will be a sudden burst of traffic. This burst of data can cause the packets to be routed through different routes. Due to the advanced routing protocols, the packets can take different paths depending on parameters such as time delay and load-balancing between the routes. It has been observed (S.Deshpande, M.Thottan and B.Sikdar 2004) that BGP instabilities occur during the time of DDoS attack. So we believe that the routes may not be stable within a small time interval of time and the traceback techniques should also consider the routing protocols used in the Internet architecture.

5.7

Increase in the Internet traffic

In some cases the packet marking techniques can also result in the generation of additional traffic in the Internet. For example, let us assume that a TCP packet is marked for traceback purposes by a particular router and destined to the actual host. Since there is no procedure for the end host to differentiate whether the packet is a fragment or marked for traceback purposes, the end host can assume the packet to be a fragment and can wait to receive other fragmented packets. This can delay the transmission of the acknowledgement from the end host to the actual source. If the sending source does not receive the acknowledgement within the specified time, this can lead to the retransmission of one or more packets, depending on the size of the window. Several errors can occur and lead to retransmission of a greater number of packets if the packet marking technique overwrites the actual fragmented packets.

5.8

Motivation of the attacker and future

DoS/DDoS attacks

If we observe the trend of DDoS over a period of time, we see that the attacker is ready to do any amount of additional jobs to generate a more severe DDoS attack. The series of attacks that occurred in the year 2000 shows the motivation of the attacker to exploit the limitations in the current Internet architecture to bring down any of the major sites which have advanced security tools deployed at their end to identify and prevent the attacks. Every day,

several automated attack tools that can ease the generation of DDoS are being released. In spite of global research and huge investment from commercial vendors and government, the security tools are unable to keep up with the pace of the attack tools. In addition to the increased gap between security technologies and attack tools, the current security tools have become so complex that the attacker is able to generate DoS attacks by exploiting the limitations or features in the security tools. Even if a proposed technique has several advantages, it is important to recognise that the attacker is only interested in exploiting the disadvantages of the proposed technique to create more severe DDoS attacks. Let us now examine how the attacker can exploit the limitations and generate DDoS attacks if some of the traceback techniques are deployed in the Internet.

Some traceback techniques show that for each attack path with distance d, the number of packets required to reconstruct the path can be calculated by ln(d)/q(1-q)d-1 . Since the proposed traceback techniques assume that the attacker is aware that she/he are being traced, the attacker just needs to send packets of less than ln(d)/q(1-q)d-1, where d is the distance from the attacking source to the victim. The attacker can perform a traceroute (see Figure 6) to find the distance between the attacking source and the victim and then calculate the number of attack packets that can be generated on the victim’s machine and remain untraced.

The time required for traceback is exponentially dependent on the number of attacking sources. For example, D. Song and A.Perrig (2000) have shown that with just 30 attacking sources, some of the packet marking techniques requires 1013 seconds to reconstruct the path traversed by the attack traffic. The recent attacks involved hundreds and thousands of attacking sources. In this case, the traceback itself requires several days and the computational overhead at the victim is extremely high. The authenticated packet marking scheme (D. Song and A.Perrig 2000) can ensure that even a compromised router cannot mark the IP packet by forging the markings of other legitimate routers. This technique enables the victim to detect if a compromised router tampers the markings of other legitimate routers. Even if this scheme can detect the markings that are forged/ tampered, we should note that these packets are not suitable for traceback purposes.

6

ICMP Traceback Technique

Earlier, there was ongoing work in the IETF on ICMP traceback technique (Steven M. Bellovin 2001) as a possible DDoS solution. Though the working group is currently inactive, we believe that a detailed analysis on the proposed technique could be of some importance. In this approach (Steven M. Bellovin 2001), when forwarding packets, routers send an ICMP traceback message to the destination with a low probability (say, 1/20,000). The ICMP traceback packet includes the identity of the router, the contents of the packets, and information about the adjacent routers. During the time of attack, after receiving a considerable number of traceback

messages, the victim can identify the approximate source of the attack by tracing the total path traversed by attack traffic with the information received in the ICMP traceback packets. In order to trace the route, the victim should compare and find a match between the received attack traffic/packets with the ICMP traceback messages to determine the routers through which attack traffic has traversed. After receiving a considerable number of ICMP traceback packets, the victim can trace the chain of routers through which the attack traffic has traversed and find the approximate source of attack. The technique also proposed to use some security protocols to authenticate the ICMP traceback messages.

Advantages of this technique include:

• The ability to trace route the approximate source of an attack in heterogeneous networks without the co-operation of ISPs.

• There will be more number of packets to the victim in the case of DDoS attacks. So there is more probability for the victim to receive a greater number of ICMP traceback messages compared to other destinations.

• This approach has little overhead at the routers, since ICMP packets are generated on very low probability.

• It simplifies the process for legal proceedings since the victim has evidence of the attack packet and

ICMP traceback messages confirming that the

attack packets originated from a particular attacking source/network.

Disadvantages of this technique include:

• ICMP packets are generated even if there is no attack.

• The same technique should be deployed in all the ISPs.

• This technique generates additional traffic in the Internet.

• Some sites do not allow ICMP packets through their networks. So the victim may not receive the ICMP traceback messages.

• Since ICMP traceback messages are generated on very low probability, the victim should receive a large number of attack packets in order to trace the path traversed by the attack traffic.

• DDoS floods can be generated with the ICMP traceback messages itself.

• The authentication scheme for the ICMP traceback messages can be an overhead at the routers and this may lead to some form of DoS attacks.

7

Issues in ICMP Traceback Technique

Even if the approach has many advantages, the attacker is only interested in exploiting the vulnerabilities in the technique to create a more severe DDoS attack. It should be noted that the attack traffic originates from the

zombies (innocent sources which are actually compromised and remotely controlled by the attacker) but not directly from the attacker’s machine. So only the zombies will be liable for legal proceedings.

Let us look at how an attacker can use to her/his advantage the limitations present in the ICMP traceback technique to generate DDoS attack without leaving any evidence of the attack and remain untraced. We will start with a brief discussion on some of the related topics.

7.1

Reflection/Smurf attack

We will present a brief discussion on the reflection/smurf DDoS (CERT 1998) attack in this section and propose a variant of the attack in Section 7.3 assuming that the ICMP traceback technique is deployed in the Internet. Three different parties are involved in the case of a reflection attack: the attacking source, the intermediary and the victim. There can be a number of attacking hosts in case of a smurf attack. The innocent intermediary could be a single machine or an entire network and the intermediary machine/network itself can be a victim of the attack. The victim can also be a single machine or the entire network.

The attacker spoofs her/his source address with that of the victim and sends a flood of ICMP echo requests to an individual machine or a broadcast address (intermediary machine/network). Since the source address of the attack traffic is spoofed with the address of the victim, all the machines that receive this request will send a reply message to the victim’s machine. This can result in a severe reply flood at the victim’s machine/network. Hence a single attacking/compromised host can cause considerable damage to the victim by making use of the innocent intermediary hosts in the Internet.

7.2

Time to Live

When two sources communicate, it is observed that a packet may make up to 32 hops to reach any destination in the present Internet. The TTL (time to live) counter in the IP header is used to limit the lifetime of the packet. TTL is an 8-bit field which is supposed to count time in seconds, allowing a maximum lifetime of 255 seconds for a packet. In practice TTL just counts hops. Whenever a router forwards a packet, the TTL is supposed to be decremented on each hop. If the packet is queued for a long time in the router then the TTL can be decremented multiple times within a single hop. This process is used to eliminate the looping of packets due to corrupted routing tables. If the TTL field value becomes zero, the router has to discard the packet. If the packet cannot reach the destination before the TTL expires, then the router at which the TTL expires will generate an “ICMP time exceeded” message to the source host. The “ICMP time exceeded” message is to inform the source that there is severe congestion or that the timer values are being set too low.

7.3

A new DoS/DDoS technique

In order to generate a severe DDoS attack on the victim’s machine, it was assumed in some of the traceback

Zombie V 2 R1 R2 R3 R7 V 1 R6 R5 R4 1 2 3 4 Figure: 5

techniques that the DDoS attacks are possible only if the attacker can generate the attack traffic with a TTL value which is equal to or greater than the number of hops from the attacking source to the destined victim. This is true to some extent, because if the TTL value is less than the required number of hops, the TTL of the attack packet will expire before it reaches the victim and the victim will not even notice the attack. In this case, the router at which the attack traffic TTL expires will generate an “ICMP time exceeded” message to the attacking source.

Now, let us assume that the ICMP traceback technique is deployed in the Internet and discuss how a DDoS attack can be generated. As discussed earlier, there will be hundreds and thousands of attacking sources (zombies) in the case of DDoS attacks. To keep it simple, let us initially consider a DoS attack with a single zombie, as shown in Figure 5. In Figure 5, Rn are routers, Vn are victims. In this scenario, the main aim of the attacker is to create a DoS/DDoS attack on as many systems as possible and remain untraced without leaving any evidence of the attack traffic. Now let us discuss how many attacks are possible with a single attacking source in this scenario.

Let us consider that the attacker wants to primarily create an attack on the victim V1 and on additional systems (V2 and R5/V3) if possible. First the zombie can trace route the path to the victim it wants to attack, say V1. The trace-route command gives the complete path from the zombie to the victim. Let N denote the number of hops from the zombie to the destination. Now the zombie can generate a flood of traffic (ICMP, TCP, UDP etc) in such a way that the TTL of the attack traffic expires before it reaches the destined victim. This can be achieved by setting the TTL value of the attack traffic with a value less than N. Now, since the TTL of the attack packets expire before it reaches the victim, the attack traffic generated by the zombie will not reach the victim V1. In doing so the zombie is successful in consuming the bandwidth available for the victim V1 at the routers and

there will be no evidence of the attack packet at the victim’s end since the attack packets expire before reaching the victim. If the zombie floods the victim V1 with different types of attack traffic with spoofed source addresses, this can cause congestion at the routers in between the zombie and the victim. Since the flood is generated with different types of attack (TCP, UDP and ICMP) traffic, this can lead to undifferentiated congestion at the routers and the routers will start dropping the packets. This dropping can also result in dropping of the good packets from good sources (not shown in Figure 5) to the victim V1. Maximum effect can be achieved by setting the TTL value of the attack traffic with N-1. Since no attack packet has actually reached the victim, the victim (security tools at the victim’s end like firewalls and intrusion detection systems) will not even notice the attack and there is no evidence of attack at the victim’s end. This type of attack traffic is represented as step 1 in Figure 5 where the TTL of the attack traffic expires at the router R5. The router where the TTL of the attack traffic expires will generate an “ICMP time exceeded” packet to the zombie. If the zombie sends the initial attack traffic by spoofing its source address with the innocent source address of V2, then all the ICMP time-exceeded messages will be sent to the victim V2. In Figure 5, if we assume that the TTL value of the attack traffic (generated in step 1) expires at router R5 then the router R5 will generate an ICMP time-exceeded-message to the victim V2. This type of attack traffic is represented as step 2. The number of ICMP time-exceeded packets to the victim V2 from the router R5 will be equal to the number of attack packets generated by the zombie.

Since we have assumed that the ICMP traceback technique is deployed in the Internet and since the attack traffic in step 1 is destined to the victim V1, there is more probability for the routers R1, R2, R3, R4 to generate ICMP traceback messages to the victim V1. The number of ICMP traceback messages that can be generated to the victim is proportional to the total attack traffic generated by the zombie and the length of the path from the zombie to the victim. Even if the generation probability of ICMP traceback messages is less at the routers, it should be noted that we have only considered an attack with a single zombie. In the case of DDoS, several hundred zombies may be involved in the generation of this kind of attack traffic. Since a greater number of (attack) packets are generated to the victim, the probability of each router sending an ICMP traceback message to the victim V1 is also high, and this can have a considerable effect on the victim V1 network. So the victim V1 will notice an ICMP traceback message flood from the routers. This type of attack traffic is shown in step 3. Now, because of the ICMP time-exceeded flood messages generated at router R5 in step 2, there is more probability for all the routers in between router R5 and victim V2 to generate ICMP traceback messages to the victim V2. This type of attack traffic is shown in step 4. Note that the attacks in step 3 and in step 4 are represented by dotted line to show that these attacks are due to the deployment of the ICMP traceback technique in the Internet. However, it should be noted that the ICMP traceback messages generated in step 4 are very helpful to the victim V2 to trace back the

attacking source R5. If the attack in step 1 is generated with a random TTL which is less than or equal to N-1, then the traceback messages generated in step 4 will not be of any use to the victim V2.

In addition to all these, the router R5 is also a victim of DoS attack, since it has to generate an ICMP time-exceeded message for each packet where the TTL expires at that point. It can be argued that attacks on victim V2 can be prevented by deploying ingress filtering at router R1 but it should be noted that traceback techniques are proposed to traceback the approximate source of attack in case of spoofed source addresses. If ingress filtering is deployed, we believe that there is no need for traceback technologies. We should note that the attacks generated in step 1 and step 2 can occur even if the ICMP traceback technique is not deployed in the Internet. The additional traffic generated in step 3 and step 4 is due to the deployment of the ICMP traceback technique. However there is one more interesting point, which is to be observed in this scenario. Even in the case of deployment of the ICMP traceback technique, there is no evidence of the attack traffic generated in step 1 at the victim V1, since no attack packet has actually reached the victim V1. So the victim cannot initiate legal proceeding on the zombie and hence the purpose of the ICMP traceback technique is defeated.

If these attacks are to be prevented, then the routers should be modified to store the packets so that the traceback can be performed from the router at which the TTL expires. This is not a feasible solution, because even if router R5 is configured to log the expired TTL packets, it will not have any evidence of the attack because i) all the attack traffic has spoofed source address of the victim V2; and ii) since the packets are actually destined to victim V1, all the ICMP traceback messages are actually sent to victim V1 (instead of router R5). Further, configuring the routers to log these packets can lead to different types of DoS attacks on the routers. If any of the other packet marking techniques were deployed this would not cause the attacks shown in steps 3 and 4, but the attacks shown in steps 1 and 2 can still happen and the attacking source can remain untraced.

In addition to the attack traffic generated in step 3, victim V1 can also receive traceback messages due to the good traffic sent to it. This is not shown in Figure 5. Further, the attacker/zombies can send faulty traceback messages. Similarly, the victim V2 can also receive the ICMP traceback messages due to the good traffic, attack traffic and the fraudulent ICMP traceback messages from the attacker. Even if the ICMP traceback technique uses some form of authentication for the ICMP traceback message packets, there are several challenges that are to be addressed. Some modifications to the ICMP traceback technique have also been proposed (Allison Mankin, Dan Massey, Chien-Long Wu, S. Felix Wu and Lixia Zhang 2001). Here ICMP messages are generated only when the intrusion detection system (deployed by the victim) intends to receive the traceback messages by setting the intention to receive a bit. This requires modification to the BGP protocol. Even if this technique is deployed, the attacker just needs to send a fraudulent intention to

receive ICMP traceback messages and the remaining process is the same.

7.4

A simple demonstration

In this section, we will present a simple demonstration to illustrate that DoS floods can be easily generated even without compromising any computers in the Internet. We will consider a real-time scenario to show how vulnerable the sites performing online business are to these DoS/DDoS attacks. A Windows machine has been used to demonstrate this scenario on one of the commercial server.

We started with tracing the route from our machine to the commercial server using the ‘tracert’ command (“tracert xyz1.com”) in the command prompt. Figure 6 shows the output of this command. From the figure, it can be seen that the commercial server is 15 hops away from our machine (attacking source) and now we also know the complete path from our machine to the commercial server. We have generated a ping flood in such a way that the TTL was configured to expire at the 13th hop router. This is achieved by typing “ping xyz.com – i 13 –t” in the command prompt. Figure 7 shows the output of this command.

The option –t is enabled in this case so that our machine will continuously ping the victim server until it receives the stop command. From the ping statistics in Figure 7, it is clear that the number of “TTL expired” packets received is equal to the number of ping packets sent. Now, if we spoof our source address with some other valid 32-bit IP address, all the “TTL expired” reply packets will be destined to the source address with which we have spoofed our own source address.

As shown in Figure 8, we have spoofed our source address with a valid 32-bit IP address (180.122.200.219) and generated the traffic. Since we have spoofed our machine’s source IP address, we cannot get the DNS information from the DNS server. So we had to type “ping ipaddress –i 3 –t” instead of typing “ping xyz.com – i 3 –t”. In this case, the reply message will be destined to the source with which we have spoofed our IP address. This is a very simple scenario. In this scenario, a ping flood will not be generated using the complete processing power of our machine and the effect of the ping (attack) traffic is negligible on the routers or on the forged source address. Several attacking tools are readily available (CERT 2000) with which an attacker can generate the traffic/packets with the required parameters in the IP header and by completely utilising the processing power of the compromised machine. Since the ICMP traceback technique is not yet deployed, here we have not demonstrated how ICMP traceback messages are generated.

1

For the sake of anonymity, we have specified this as xyz.com although it was carried out on a real site with permission.

Figure: 7

Figure: 8 Figure: 6

7.5

Minimising the additional traffic

Let us discuss some techniques on how to minimize attacks generated in step 1 and step 2 as shown in figure 5. In the first instance, to prevent traffic with spoofed source address, ingress/egress filtering should be deployed at the edge routers of the ISP/customer networks. To route the packets to the destination, each router maintains a routing table, which maintains the known destinations and the number of hops to the particular destinations. In addition to the ingress/egress filtering, during routing, each router should check the packet has a TTL value greater than or equal to the number of hops stored in the routing table.

1. At every router

2. For each Packet P from source S to destination D 3. If TTL >= number of hops for D, route P 4. Else drop P and send an error message to S. This type of filtering should be performed on all the routers between the source S to destination D because it is to be noted that routers may decrease the TTL by a value more than 1 in case of congestion. This type of filtering has very high overhead at routers because all the packets have to be checked for the minimum TTL value at all the routers. Since ingress/egress filtering is also deployed all the error messages generated in step 4 in the above algorithm will be destined to the actual attacking source. An alternative approach to minimize the overhead on the routers is to check the packet for minimum TTL value only when the router picks the packet on some probability to send an ICMP traceback message to the destination. If the selected packet has a TTL value less than the required number of hops to the destination, the router should not send an ICMP traceback message to the destination D. This feature is already supported in the existing routers. In this case only the attack traffic generated in step3 in figure 5 can be prevented.

1. At every router

2. For packet P from source S to destination D picked on probability 1/20000

3. If TTL >= number of hops for D, route P and send ICMP traceback message to D.

4. Else drop P and send an error message to S.

8

Conclusion

In this paper, we have presented a detailed analysis on some of the recently proposed traceback techniques. We have raised several issues so as to enable further research and analysed the traceback techniques from the attacker point of view. We have discussed how the attacker can generate DoS/DDoS attacks and remain untraced if some of the traceback techniques are deployed in the Internet. We have discussed several examples to support our arguments. We have shown a simple demonstration to show how easily DoS/DDoS attacks can be generated without being traced even if ICMP traceback technique is deployed in the current Internet. We have also discussed a new technique to minimise the attack traffic generated due to the implementation of ICMP traceback technique.

We believe that the networks tend to become complex and more vulnerable to DDoS attacks if some of the proposed traceback techniques are deployed in the Internet.

9

References

Alex C. Snoeren, Craig Partridge, Luis A. Sanchez,Christine E. Jones, Fabrice Tchakountio, Beverly Schwartz, Stephen T. Kent, and W. Timothy Strayer (2002): Single-packet IP traceback. IEEE/ACM Transactions on Networking (ToN), 10(6).

Allison Mankin, Dan Massey, Chien-Long Wu, S. Felix Wu and Lixia Zhang (2001): On Design and Evaluation of Intention-Driven ICMP Traceback. Proc. of 10th IEEE International Conference on Computer Communications and Networks.

V.Gill, J.Heasley and D.Meyer (2004): The generalized TTL security mechanism. RFC 3682.

CERT (1998): CERT advisory CA-1998-01 Smurf IP Denial-of-Service Attacks

.http://www.cert.org/advisories/CA-1998-01.html CERT (2000): CERT advisory CA-2000-01

denial-of-service developments.

http://www.cert.org/advisories/CA-2000-01.html. D. Song and A.Perrig (2000): Advanced and

Authenticated Marking Schemes for IP Traceback. Technical Report UCB/CSD-00-1107, University of California, Berkeley.

David Moore, Geoffrey M. Voelker and Stefan Savage (2001): Inferring internet denial -of-service activity. Proc. of the 10th USENIX Security Symposium. Drew Dean, Matt Franklin and Adam Stubblefield

(2001): An Algebraic Approach to IP Traceback. Proc. of the NDSS.

Stefan Savage, David Wetherall, Anna Karlin and Tom Anderson (2000): Practical network support for IP traceback. Proc. of the ACM SIGCOMM Conference, pages 295-306.

Steven M. Bellovin (2001): ICMP Traceback Message. Internet Draft.

Steve Gibson (2001): The Strange Tale of the Denial of Service Attacks on GRC.COM.

http://www.grc.com/dos/grcdos.htm.

S.Deshpande, M.Thottan and B.Sikdar (2004): Early detection of BGP Instabilities resulting from Internet Worm Attacks. Proc. of the IEEE Globecom, Dallas, Texas, USA.

Ivan Arce (2004): More Bang for the Bug: An Account of 2003’s Attack Trends. IEEE Security & Privacy, Volume 2, Pages 66-68.

J.Postel (1981): Internet Protocol. RFC 791.