43KAI Toshifumi et al.

1 Introduction

Information-communications networkshave grown to become an integral part of thesocial infrastructure, and a variety of servicesare now provided over these networks. On theother hand, we have seen an increasing num-ber of incidents of attacks aimed at disruptingthese services. Typical examples include DoS(denial of service) and DDoS (distributedDoS) attacks. These attacks often use packetswith forged source IP addresses. Therefore, itis difficult for victims to track down the realsource of such an attack and to implementcountermeasures.

One method of locating the source ofattacks involves tracing the path of illegalpackets back to their source (Fig.1).

However, the Internet consists ofautonomous systems (ASs) such as ISP net-work, government networks, and other sys-tems managed under individual policies, and itis virtually impossible to perform tracebackacross several of these ASs under a singlemethod. It is thus considered necessary to exe-

cute traceback between ASs (inter-AS) andwithin each AS (intra-AS) in a hierarchicalmanner［1］［2］.

Various intra-AS traceback methods havebeen devised to date［3］-［7］, but each methodhas both advantages and disadvantages. Sometechniques have been proposed in which anumber of these methods are used in combina-tion［8］［9］, but the effectiveness of thisapproach has not been verified.

We researched mechanisms and combina-tions of existing intra-AS traceback methodsdesigned to capitalize on their relativestrengths and make up for their respectiveshortcomings［9］［10］, and devised a method

2-5 Efficient Traceback Method for Detect-ing Illegal Access

KAI Toshifumi, NAKATANI Hiroshige, SHIMIZU Hiroshi, SUZUKI Ayako, and TSUKAMOTO Katsuji

The amount of damage by illegal access is increasing with the spread of the Internet. Espe-cially the DoS (Denial of Service) and DDoS (Distributed DoS) attacks cause system down andoften have serious impacts on the society. Various attacker detection techniques have been pro-posed until now, of which characteristics in performance and easiness of implementation arediscussed in this paper. Based on the discussion, we propose hybrid traceback method thatsolves the drawbacks of the exiting techniques. Advantages of this proposed scheme to the exit-ing ones are clarified by some numerical models and experiment.

KeywordsTraceback, DDoS attacks, Illegal access

Fig.1 Traceback

44 Journal of the National Institute of Information and Communications Technology Vol.52 Nos.1/2 2005

that is superior to existing methods both interms of performance and practicality. Basedon this method, we then devised a new intra-AS traceback method that overcomes the dis-advantages of existing methods［11］. We alsodevised and proposed a new inter-AS trace-back method and verified its performancewhen used in conjunction with the intra-AStraceback methods［12］.

However, this paper reports only on thenewly devised intra-AS traceback methods,and does not deal with inter-AS traceback.First, we will evaluate the features of threeexisting traceback methods (the ICMP, mark-ing, and Hash approaches) currently consid-ered most effective. We then describe themethods (interlock and uTrace) we havedevised (our original methods) for the rapidtraceback of DDoS attacks that cannot beaddressed adequately with existing methods.Further, we propose new methods (Hybrid Iand II) consisting of our original methods andthe Hash approach. We then describe the supe-riority of our original methods based on com-parisons with existing methods in terms ofsuccess rates per traceback time and ease ofimplementation on a real network. We willalso discuss the traceback performance of thenew methods under high-traffic conditions.

2 Existing methods

Table 1 shows three typical IP tracebacktechnologies and examples of implementation.Each of these methods consists of tracebackdata-acquisition modules mounted on routers(or external devices) and a traceback terminalthat collects traceback information from thesemodules to identify packet paths.

2.1 ICMP method(1) Overview

The ICMP method samples packets with acertain probability and generates specialICMP packets called “iTrace packets” to sendtraceback information on these packets to thetraceback terminal.

As a specific example of implementationof the ICMP method, we will describe theiTrace-II approach we developed throughmodifications to iTrace［3］. To increase thesampling rate while keeping network load low,iTrace-II generates an iTrace packet that cansend several sampled packets at once. Table 2shows the operational procedure of iTrace-II.When the traceback terminal collects a speci-fied number of iTrace packets from all routerson the attack path, the traceback operation issuccessful.

(2) FeaturesiTrace-II can send a fairly large amount of

traceback information at once through thegeneration of special packets.

2.2 Marking scheme(1) Overview

In a marking scheme, each module writestraceback information directly to sampledpackets, instead of generating special packetsfor traceback. This represents a major differ-ence from the ICMP method.

As a typical example of implementation,we will describe AMS-II［5］. Table 3 showsthe operation of this method. When the trace-

Table 1 Existing traceback methods

Table 2 Operation of iTrace-II

45KAI Toshifumi et al.

back terminal (featuring a router map) collectshash values (restored from fragments) from allrouters on the attack path, the traceback opera-tion is successful. Note that a path confirma-tion threshold must be reached at all routers.

(2) FeaturesThe marking scheme does not place load

on the network due to the generation of spe-cial packets for traceback. Therefore, it is pos-sible to perform traceback fairly rapidly evenif the volume of packet flow per attack termi-nal is low, as in the case of DDoS attacks.

2.3 Hash method(1) Overview

Unlike the two methods above, the Hashmethod uses the traceback terminal to queryrouters actively. In the case of SPIE［6］, a typi-cal implementation of this method, routerssave hash values on all in-transit packets, andthe traceback terminal queries these routers ona packet basis.(2) Features

Since routers save hash values for allpackets, it is possible to trace back single-packet attacks with high accuracy.

2.4 Disadvantages of existing methods

Table 4 lists the range of traceable attackpacket flow volumes and disadvantages of theexisting methods.

In consideration of network load, theICMP method is recommended for use at alow sampling rate (1/20,000). This methodcan perform traceback only when tens of thou-sands of attack packets are sent.

The marking scheme requires that thetraceback terminal always features an accuraterouter map. Since the module at each routeralters the ID field of IP headers, this schemecannot adapt to an environment in which frag-ments are generated. These factors render itconsiderably difficult to adopt this scheme inactual networks.

In the Hash method, it is necessary toexchange dozens of query packets per tracedpacket. Therefore, this method is not suitablefor traceback of attacks involving a high vol-ume of packets. In addition, each routerrequires a fairly large amount of memory tosave the hash values.

3 Newly devised methods

Combining the ICMP and Hash methods,we devised an interlock method with a perfor-mance comparable to that of a markingscheme against multiple-packet attacks. In aprevious paper［10］, we proposed a Hybrid Imethod consisting of this interlock methodand ordinary Hash methods. Later, we deviseda UDP (uTrace) method that alone provideshigher performance than the marking scheme.We then combined this method with the Hashmethod to arrive at the Hybrid II method. Inthis section, we describe these new methods.

Table 3 Operation of AMS-II

Table 4 Comparison of existing methods

46 Journal of the National Institute of Information and Communications Technology Vol.52 Nos.1/2 2005

3.1 Hybrid I method3.1.1 Configuration of Hybrid I

Upon occurrence of a multiple-packetattack, Hybrid I will perform traceback by theinterlock method, which consists of the ICMP(iTrace-II) and Hash (SPIE) methods; when asingle-packet attack occurs, Hybrid I will per-form traceback using the Hash method alone.These two modes, selected according to thetype of attack, operate independently. Sincewe have already described the Hash method,the following sections will introduce anoverview and features of the interlock method. 3.1.2 Overview of interlock method

iTrace-II and SPIE modules are mountedon each router, but these two modules do notinterfere with each other within the router. Nofunctional changes have been made to existingmodules. The traceback terminal receivespackets from iTrace-II and queries SPIE.

Upon reception of a traceback requestfrom the IDS (intrusion detection system) orthe network administrator when an attackoccurs, the traceback terminal will check sam-pled iTrace packets sent from the routers forattack packets. If attack packets exist, the ter-minal will use SPIE to immediately trace thesepackets back to their source.3.1.3 Features of interlock method

In the interlock method, iTrace packetstrigger SPIE to execute traceback. It is possi-ble to locate the attack path if the attack pack-ets are sampled by at least one router on thepath. Therefore, this method is faster thaniTrace-II, which cannot identify the attackpath until the attack packets are sampled by allrouters on the path.

3.2 Hybrid II method3.2.1 Configuration of Hybrid II

When a multiple-packet attack occurs,Hybrid II will use the uTrace (UDP) method;when a single-packet attack occurs, Hybrid IIwill use the Hash method alone, as in the caseof Hybrid I. The following sections describethe uTrace method.3.2.2 Configuration of uTrace

A uTrace module is mounted on each

router. This module checks in-transit packetsto select those that match the characteristics ofthe intended packets, writes traceback infor-mation to a UDP packet (called a “uTrace”packet) as in the case of iTrace-II, and sendsthe packet to the traceback terminal. The ter-minal, on the other hand, sends a tracebackrequest message that includes the characteris-tics of the intended packets and receivesuTrace packets from the routers. Based on thetraceback information written to the uTracepacket, the terminal selects the next router towhich it will send the traceback request mes-sage.3.2.3 Operation of uTrace

Figure 2 shows an overview of the uTraceoperation. To start traceback, the tracebackterminal needs to have information on thecharacteristics of the intended packets and theIP address of the victim terminal’s immediaterouter. The characteristics data includes proto-col numbers and port numbers of higher-levelprotocols. The traceback terminal receivesthese data items from the IDS or networkadministrator and follows the steps below toexecute traceback:

(Step 1) Transmission of traceback requestmessages

The traceback terminal sends a tracebackrequest message (Traceback Request 0) to aspecified router. This message includes infor-mation on the characteristics of the intendedpackets, the terminal’s IP address, a request

Fig.2 Overview of uTrace operation

47KAI Toshifumi et al.

ID, the requested number of uTrace packets,and an effective period for the request. (Step 2) Transmission of uTrace packets

After receiving the traceback request mes-sage from the terminal, the router will monitorall in-transit packets until the end of the effec-tive period of the request, and will select pack-ets (P1, P2) that match the characteristics ofthe intended packets. The router will thenwrite traceback information to a uTrace packetand send this packet to the terminal.(Step 3) Selection of next router

When receiving the uTrace packet, thetraceback terminal will add the IP address of arouter (R2, R3) (located immediately before thecurrent router) to the traceback list. If thisaddress has not been added to the traceback list,the terminal will send traceback request mes-sages (Traceback Requests 1, 2) to that address.

Each time attack packets are detected, thetraceback terminal can collect traceback infor-mation from the routers sequentially (from thevictim terminal’s immediate router to theattacker terminal’s immediate router) throughrepetition of the above steps.

4 Performance evaluation

We established mathematical models todetermine performance of individual trace-back methods and compared the new andexisting methods.

4.1 Evaluation modelsTo compare performance of individual

traceback methods quantitatively, we used theevaluation models described in Sections 4.1.1through 4.1.5 below.4.1.1 Traceback

In computer forensics, the goal is to locatethe path of attack packets in addition to identi-fying the attacker (terminal). In this paper,“traceback (attack detection)” refers to thelocation of both the attacker terminal and thepath of attack packets.4.1.2 Environmental conditions

The evaluation models are based on theassumption that evaluation is performed in an

environment in which ideal IDSs and net-works are used. An “ideal IDS” would be ableto isolate attack packets accurately from non-attack packets, and would issue an alert uponoccurrence of an attack. An “ideal network”would not be subject to any communicationsdelays, congestion, or packet losses.

The volume of normal traffic flow is suffi-ciently high so that it is possible to ignore adelay in sending sampled packets to the trace-back terminal when the iTrace-II or interlockmethod is used.4.1.3 Attacks

The traceback methods mentioned in thispaper are not affected by the actual data con-tained in the packets. The volume of attackpacket flow (packets/sec) is therefore the onlyvariable parameter on the attacker side. 4.1.4 Network

To render evaluation as simple as possible,we selected an S-branch tree as the attackpath. The necessary parameters included thenumber of tree branches (S) and the hop countbetween the attacker and victim terminals. Allend nodes of this tree are attacker terminals.4.1.5 Path confirmation threshold

The traceback terminal only trusts infor-mation that has been collected in excess ofthis threshold value. The larger the value, thehigher the accuracy; however, with larger val-ues more time is required for traceback.

4.2 Mathematical modelsTable 5 lists common symbols and values

employed in our mathematical models. Weused “fb” (number of successes, number of tri-als, and success rate) as a binomial distribu-tion function.

Table 5 List of symbols used in math-ematical models

48 Journal of the National Institute of Information and Communications Technology Vol.52 Nos.1/2 2005

4.2.1 Mathematical models of existingmethods

Equations 1 and 2 below show the rela-tionships between traceback time and accura-cy in the ICMP method (iTrace-II) and mark-ing scheme (AMS-II) described in Section 2,respectively. Note that Equation 1 does notallow for a delay in combining and sendingsampled packets.

Eq. 1

Eq. 2

4.2.2 Mathematical models of inter-lock method

In the interlock method, if at least one ofthe routers on the attack path sends iTracepackets, it becomes possible for SPIE to iden-tify the entire attack path. Therefore, the trace-back success rate can be expressed by Equa-tion 3, which does not depend on the numberof attacker terminals or the network topology.

Eq. 3

4.2.3 Mathematical model of uTraceThe uTrace method does not depend on

probability. The trace operation succeeds aftera sufficient time has elapsed to enable acquisi-tion of the required traceback information.This period lasts from the start of tracebackuntil the passage of attack packets in anamount equal to hop count H + (path confir-mation threshold - 1). Therefore, the relation-ship between traceback time and accuracy canbe expressed by Equation 4.

where

Eq. 4

4.2.4 Comparison based on math-ematical models

To compare performance of tracebackmethods against DDoS attacks, we determined

the minimum volume of attack-packet flowper attacker terminal (packets/sec) that can betraced back by each method with a tracebacktime of 10 seconds. We considered a certainvolume to be “traceable” if the success ratewas 95% or higher. Table 6 lists conditionsother than the volume of attack packet flow.This set of conditions is equivalent to a DDoSattack in which the number of attacker termi-nals (SH) is 1,024 and the total volume ofpacket flow (ASH) is 10,240 packets/sec.Table 7 shows the performance of tracebackmethods determined based on the respectivemathematical models.

We compared the performance of thesemethods under identical conditions. The inter-lock and AMS-II methods can trace back one-tenth the volume of attack-packet flow ofiTrace-II. On the other hand, uTrace can per-form traceback of less than one-hundredth ofthe iTrace-II volume. These methods do nothave an upper limit to the traceable volume ofpacket flow per attacker terminal; in otherwords, they can trace back attack packet flowno matter how large the flow is. Therefore,uTrace can trace back a wider range of attacksthan other methods.

Table 6 Parameters of evaluation models

Table 7 Traceable volume of attackpacket flow

where

where

49KAI Toshifumi et al.

4.3 Test-bed experiments 4.3.1 Experiment procedure

To verify uTrace performance, we con-ducted experiments on a test bed using theconfiguration shown in Table 8. We deter-mined a fixed attack packet flow volume perattacker terminal (50 packets/sec) and variedthe hop count from the attacker terminal to thevictim terminal: three, five, 10, 15, and 20.The SYN flood attack type was used, with apath confirmation threshold of two. We mea-sured the time to complete traceback. We test-ed traceback 60 times with each hop count,and compared the average traceback time withtheoretical figures.

4.3.2 Experimental resultsTable 9 shows the results of experiments

with different hop counts. We confirmed thatactual measurement and theoretical valueswere nearly the same on an attacker-terminalbasis. The actual detection time was shorter(quicker) than the theoretical time. This isbecause the theoretical calculations are basedon the assumption that an ideal IDS is used,and therefore, the first packet goes through therouter not immediately but rather 1/50 (0.02)sec. after the start of traceback. Incidentally,differences were noted between the mathemat-ical model and actual experiments on a testbed in terms of network delay time, process-ing time at the traceback terminal and routers,and TCP ACK response from the victim ter-minal subject to SYN flood attack. The exper-imental results show that these factors havelittle impact on traceback time.

5 Discussion

5.1 Performance of proposed methodsAs described in Section 4.2.4, uTrace fea-

tures higher performance than the AMS-II andinterlock methods. Like the ICMP method,uTrace poses no difficulties in particular ininstallation. Table 10 summarizes these points.

As seen in this table, the Hybrid II methodconsists of the UDP (uTrace) and Hash meth-ods; in combination, these methods providehigh traceback performance against varioustypes of attacks.

5.2 Operation under high-traffic con-ditions

With a high volume of network trafficflow, uTrace modules on routers may misssome attack packets and traceback speed maydecrease due to the delay in message transmis-sion between the traceback terminal androuters. We thus conducted two sets of experi-ments to test these eventualities.

Firstly, we studied the probability of gen-

Table 8 Test-bed configuration

Table 10 Comparison of new and exist-ing methods

Table 9 Results of experiments with differ-ent hop counts

50 Journal of the National Institute of Information and Communications Technology Vol.52 Nos.1/2 2005

eration of uTrace packets with a high volumeof router traffic. When we forwarded onepacket/sec of attack traffic and 25,000 pack-ets/sec of background traffic between therouters (RedHat Linux 7.3, Pentium 3.0 GHz,memory: 1.0 GB), a uTrace module missed51.33% of the attack packets, and this percent-age of uTrace packets failed to be generated.However, in addition to the uTrace modulesoftware that runs on routers, we have alreadydeveloped a dedicated uTrace system that canbe installed in parallel with the network usinga network processor. Conducting the sameexperiment using this system, we were able toconfirm that the uTrace module misses noattack packets even with 50,000 packets/sec ofbackground traffic.

Secondly, we placed a bottleneck on thenetwork to constrict bandwidth, sent uTracepackets and background traffic exceeding thebottleneck bandwidth, and studied the rate ofpacket loss. We discovered that when trafficflow is twice the bottleneck bandwidth, therate of uTrace packet loss becomes nearly50%.

These results suggest that without ade-quate measures, traceback speed will decreaseunder high-traffic conditions. However, byattaching the dedicated uTrace system andexchanging uTrace packets and traceback

request messages through the dedicated line, itis possible to avoid the effects of traffic and toperform traceback as predicted under themathematical models.

6 Conclusions

Based on the evaluation of typical existingtraceback methods, we devised hybrid meth-ods and demonstrated their superiority overexisting methods. We then tested these newmethods using actual PC routers on a test bedto verify performance.

Although this paper dealt only with intra-AS traceback methods, we have also devised anew inter-AS traceback method, and havealready verified its performance in test-bedevaluations when used in conjunction with thehybrid methods.

Acknowledgements

This research was carried out based on theResearch and Development on Security ofLarge-Scale Networks project commissionedby the National Institute of Information andCommunications Technology. We would liketo express our gratitude to NICT for its guid-ance and support.

References01 K. tsukamoto et al., “A consideration on Traceback over inter-ASes”, IEICE General Conference, Mar.

2004 (in Japanese)

02 M. Oe et al. “An Inplementation and Verification of a Hierarchical Architecture for IP Traceback”, IEICE

Transaction on. Communications. Vol. J86-B, No. 1 pp. 1486-1493 Aug. 2003. (in Japanese)

03 S. Bellovin, “ICMP Traceback Message”, InternetDraft:draft-bellovin-itrace-00. txt, submitted Mar. 2000.

04 S. Savege, D.Wtherall, A. Karlin, and T. Anderson, “Practical Network Support for IP Traceback”, Pro-

ceedings of Sigcomm 2000, Aug. 2000, Stockholm, Sweden

05 D. Song and A. Perrig, “Advanced and Authenticated Marking Schemes for IP Traceback”, Proc. IEEE

INFO-COM, April 2001.

06 Snoeren AC, Partridge C, Sanchez LA, Jones CE, Tchakountio F, Kent ST, and Strayer T, “Hash-Based

IP Traceback”, Proc. of the ACM SIGCOMM 2001 Conf. San Diego, Aug. 2001.

07 A. Hayakawa et al. “FUSEI AKUSESU HASSHINGEN TUISEKI SISUTEMU NI OKERU TUISEKI JIKAN NO

HYOUKA”, IPSJ 64th General Conference, Mar. 2002. (in Japanese)

08 R. Yamada et al. “The Design and Implementation of The Hybrid Traceback Scheme for Finding True

51KAI Toshifumi et al.

Source of Packets”, IPSJ DSM2003, Jan. 2003. (in Japanese)

09 N. Fukuda et al. “Research and Development for Traceback System in Large-Scale Networks”, IEICE

General Conference, Mar. 2004. (in Japanese)

10 T.Kai et al. “Traceback Method for Searching Attackers Transmitting Packets with False Source IP

Addresses”, IPSJ DPS-WS 12th, Dec. 2004. (in Japanese)

11 T. Kai et al. “Efficient Traceback Method for Detecting DDoS Attacks”, IPSJ CSEC 27th, Dec. 2004. (in

Japanese)

12 T. Kai et al. “Inter AS Traceback Method for Detecting DDoS Attacks”, IPSJ CSEC 28th, Mar. 2005. (in

Japanese)

KAI Toshifumi

Advanced Technologies DevelopmentLaboratory, Matsusita Electric Works,Ltd.

Networks Security

SHIMIZU Hiroshi, Dr. Agr.

General Manager, New Business Plan-ning Office, Matsusita Electric Works,Ltd.

Networks Security

NAKATANI Hiroshige

Senior Engineer, Advanced Technolo-gies Development Laboratory, Matsusi-ta Electric Works, Ltd.

Networks Security

SUZUKI Ayako

Core Network Business Headquarters,NTT Advanced Technology Corp.

Networks Security

TSUKAMOTO Katsuji, Ph.D.

Professor, Kogakuin University Dept.of Computer Engineering

Multimedia Communication,NetworkSecurity