Research Article Hybrid Single-Packet IP Traceback with Low Storage and High Accuracy

Transcription

1 e Scientific World Journal, Article ID 398, pages Research Article Hybrid Single-Packet IP Traceback with Low Storage and High Accuracy Ming Hour Yang Department of Information and Computer Science, Chung Yuan Christian University, No., Chung Pei Road, Chung Li City, Taoyuan County 33, Taiwan Correspondence should be addressed to Ming Hour Yang; Received 5 September 3; Accepted 3 December 3; Published 3 February 4 Academic Editors: Y. Huang and Y. Qi Copyright 4 Ming Hour Yang. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. Traceback schemes have been proposed to trace the sources of attacks that usually hide by spoofing their IP addresses. Among these methods, schemes using packet logging can achieve single-packet traceback. But packet logging demands high storage on routers and therefore makes IP traceback impractical. For lower storage requirement, packet logging and packet marking are fused to make hybrid single-packet IP traceback. Despite such attempts, their storage still increases with packet numbers. That is why RIHT bounds its storage with path numbers to guarantee low storage. RIHT uses IP header s ID and offset fields to mark packets, so it inevitably suffers from fragment and drop issues for its packet reassembly. Although the 6-bit hybrid IP traceback schemes, for example, MORE, can mitigate the fragment problem, their storage requirement grows up with packet numbers. To solve the storage and fragment problems in one shot, we propose a single-packet IP traceback scheme that only uses packets ID field for marking. Ourmajorcontributionsareasfollows:()ourfragmentedpacketswithtracingmarkscanbereassembled;()ourstorageisnot affected by packet numbers; (3) it is the first hybrid single-packet IP traceback scheme to achieve zero false positive and zero false negative rates.. Introduction With the rapid growth of the internet, various internet applications have been developed for different purposes. However, malicious users may launch distributed/denial of service (D/DoS) attacks to disrupt the service of a server. According to the number of attacking packets, D/DoS attacks can be categorized into flooding-based attacks and software exploit attacks []. In flooding-based attacks, adversaries wouldsendhugeamountofforgedsourcepacketstoexhaust victim s limited resources. As for software exploit attacks, attackersneedtofindhosts vulnerabilitiesandthenlaunch attacks with only a few packets, for example, Teardrop attacks and LAND attacks. Since most edge routers do not check a packet s origin address, it is difficult for core routers to recognize each packet s source address. These source IP addresses can be spoofed when an attacker wants to evade tracing. Therefore, how to locate the real source of impersonation attacks has become an urgent issue today. In order to trace the real source of flooding-based packets, packet-marking schemes use each packet s IP header to mark the packet s route. These schemes can be put into two categories, probabilistic packet marking (PPM) [ 7] and deterministic packet marking (DPM) [8 ]. Savage et al. propose a PPM scheme with edge sampling, which is called fragment marking scheme (FMS) [6]. However, collision of hashed pieces of routes can lead a FMS to the wrong origin of attacks. Hence, in order to lower the false positive rate and to reducethecomputationloadandtimeinpathreconstruction, Song and Perrig introduce an advanced marking scheme [3], and Yaar et al. propose FIT []. In their schemes, they reduce the attack packets that are required for path reconstruction with the help of the known network topologies. Besides, Liu et al. s dynamic probabilistic packet marking (DPPM) [5]and Paruchuri et al. s TTL-based PPM (TPM) [7] determine the probability of marking according to the number of hops in a route. This further decreases the number of packets required in their path reconstruction. But since most marked routers

2 The Scientific World Journal in DPPM and TPM are near the victim, it turns out their schemes need lots of packets to reconstruct an attack path. To improve this part, Tian et al. propose an adaptive probabilistic marking scheme [4]inwhicheveryrouteronthesamepath has equal marking probability. Belenky and Ansari s DPM traceback schemes [8, 9] only demand few packets for path reconstruction. But, their schemes require full compliance of every border router, and they are unable to deal with attacks from multiple sources. For this reason, Belenky and Ansari soon come up with a hash-based DPM []togetaroundsuch a problem. But they need to collect at least eight packets to rebuild an attack path. To trace the origins of software exploit attacks with only one packet, Snoeren et al. propose SPIE [] to digest the unchanged parts of a packet and use a bloom filter [] to log the digests. However, this scheme requires large storage and has false positives because their packet digests in each log table may have collision []. In order to lower the chance of collision, Zhang and Guan propose TOPO [3]. They try to use each upstream router s identifier to lower the false positive rate of SPIE. But this scheme still requires large storage for logging. Becauseofthehighstoragerequirementinlogging-based schemes, hybrid single IP traceback methods [4 7] have been proposed. Packet marking and packet logging are fused in these schemes to reduce the storage requirement of routers. Despite their efforts, their storage still grows with packet numbers. It means the routers must refresh logged data when the accumulated packet digests exceed the quota on each router. Therefore, when an intrusion detection system (IDS) detects an attack and follows these schemes tracking to a refreshedrouter slog,falsenegativesoccurintheirpath reconstruction. To deal with the storage problem in MRT [7] and MORE[6] and to prevent collision in log tables, M.-H. Yang and M.-C. Yang propose RIHT [8]. Its storage requirement is bounded by path numbers and its simulations, implemented on CAIDA s topology data [9], show that it requires only 3 KB for packet logging. Therefore, RIHT does not need to refresh its routers logged data; hence, no false negatives in its path reconstruction. MRT and RIHT use each IP header s ID and fragment flags and fragment offset as their 3-bit marking fields. But the fragment flag is used to judge whether a packet has been fragmented or not. If its value is modified by traceback schemes, a receiving end is not able to judge fragmentation. Besides, when a marked packet s size exceeds a router s maximum transition unit (MTU), the packet will be fragmented. When a router supports IPsec, it may need to add ESP s header to each packet. This increases the length of a packet and the chance of fragmentation. In fact, John and Tafvelln [] point out that 63% fragmented packets are ESP packets. With the high chance of fragmentation and modified values of the three fields, packet reassembly is difficult in the two schemes. Moreover, according to RFC 674 [], MRT s and RIHT s marked packets may be dropped. If the values writtenintheirfragmentoffsetarelargerthanthefield slimit, then the packet will be dropped. Despite the fact that current hybrid IP traceback schemes have been able to track single packet attacks and that RIHT has reduced the storage requirement to an extent that a router does not need to refresh its tracing logs, packet fragmentation and packet drop issues can still fail their path reconstruction. Therefore, we propose a new 6-bit hybrid single IP traceback scheme that uses only ID field of an IP header for our packet marking. Our major contributions include the following. (i) Our proposed scheme is the first to solve both the storage and the fragment problems. (ii) Our scheme passes the packet fragmentation check in RFC 674 because we do not need to overwrite fragment offset. (iii) We are able to reassemble fragmented packets before/after logging [8]. (iv) Zero false positive and zero false negative. In the following section, we survey related studies on Huffman codes, MRT, MORE, and RIHT schemes. Section3 details our traceback scheme. In Section 4, we run simulations to analyze the storage requirement and efficiency of path reconstruction in our scheme. We also compare it with existing hybrid IP traceback methods. Conclusion is drawn in Section 5.. Related Work Hybrid single packet IP traceback schemes, such as Huffman codes, MRT, MORE, and RIHT, use routers interface numbers, instead of node sampling or edge sampling, to mark a packet s route. Following a packet s route, these methods mark routers interface numbers on the packet s IP header. However,markingspaceisnotalwaysenoughforeveryrouter onaroute.so,thesemethodsintegratepacketlogginginto their marking schemes by allowing a packet s mark to be temporarily stored on routers. Since these schemes use interface numbers of routers for marking, they assume a router set R={R,R,...,R i,...,r y } comprising y routers in a network and require all the y routers support these schemes. Also, they use the router s degree as a parameter in their marking schemes. The degree of a router is the number of its interfaces, but it does not include the ports connected to local networks. Here, we use D(R i ) to denote router R i s degree. Besides, these schemes need to maintain an interface table on each router in advance. The table keeps R i s upstream interface numbers, which range from to D(R i ).WeuseUI r i (or UI i if there is no ambiguity) to denote R i s upstream interface number on route r. In the following paragraphs, routes and paths will be used interchangeably. In the marking process, each router has to put its UI i into the marking field. Usually the easiest way is to encode UI i with fixed-length coding. However, such approach does not use a packet s marking field efficiently if D(R i ) is not a power of two. Choi and Dai [5] proposeamarkingschemeusing Huffman coding to reduce the bits required for marking on a packet. It encodes UI i by Huffman coding according to the traffic of each interface. Their analysis shows their scheme has better performance when the traffic distribution for each

3 The Scientific World Journal 3 Host Marking field (8 bits) Fixed-length Huffman codes MRT and MORE RIHT Interface number Fixed-length Huffman codes on R Huffman codes on R 3 R 3 R 3 5 R R, D(R )=4 R, D(R )=5 R 3, D(R 3 )=6 Figure : Example of traceback schemes that mark router interfaces. interface is unequal. Malliga and Tamilarasi propose MRT [7], which uses a 3-bit marking field and Modulo/Reverse modulo Technique. They use mathematical methods to mark the marking fields. In their marking scheme, the new marking field = marking field D(R i )+UI i,whichiscomputedby the routers to which a packet is forwarded. In their path reconstruction, the old marking field = marking field D(R i ), whichiscomputedbytherouterstowhichapacketistraced back. The upstream interface number UI i =markingfield% D(R i ). In the calculation, % is the modulo operation. When the old marking field <D(R i ),theygettheloggedmarkfrom the router. And the reconstruction process is repeated. According to the analysis in RIHT, if MRT s marking field, after logging, is still on the adjacent downstream router, therouterwillbeidentifiedasaloggedoneduringtraceback. As a result, it cannot find correct information on the router and is unable to find the origin of an attack. To prevent such a problem when UI i =, RIHT modifies the formula of marking as new marking field = marking field (D(R i )+ ) + UI i +. In path reconstruction, the old marking field = marking field (D(R i )+). The upstream interface number UI i =markingfield%(d(r i )+). They also lower RIHT s storage requirement for logging to about 3 KB. As RIHT s log table does not need to be refreshed, it effectively reduces the false negative rate. Figure illustrates the marking process of each traceback scheme which marks interface numbers of routers. Suppose that a packet is delivered from Host to R, R,andthenR 3 sequentially. The marking field is initialized on R and then marked on R and R 3.AswecanseeinFigure, R receives R s packets from the upstream interface number and R 3 receives R s packets from the upstream interface number 5. In Huffman codes, R,andR 3 encode the interface numbers and 5 as and, respectively (see the grey cells in Figure ). Reversals of codewords, that is, and, are appended into the marking field. In path reconstruction, R and R 3 search the reversals of codewords to find the upstream routers. As RIHT has modified MRT, R computes the new marking field = 5 + = ( ). And R 3 computes the new marking field = = ( ). In path reconstruction, R 3 computes the upstream interface number = ( ) % 6 = 5, and the old marking field is /6 = ( ). R computes the upstream interface number = ( )%5=andtheoldmarkingfieldis 5= ( ). As for RIHT, R computes the new marking field = (5 + ) + + = ( ). And R 3 computes the new marking field = (6 + ) = ( ). In path reconstruction, R 3 computes the upstream interface number = ( )%(6+) =5,andtheoldmarking field is /(6 + ) = ( ). R computes the upstream interface number = ( )%(5+) =andtheold marking field is 5 = ( ). As mentioned above, since MRT and RIHT use ID and fragment offset for packet marking, they have difficulty in reassembling fragmented packets. When the value marked in fragment offset is larger than the value defined in RFC 674, the packet will be dropped by the routers. For these reasons, Malliga et al. propose a 6-bit hybrid traceback scheme called MORE, which only uses the 6-bit ID field for marking. Its logging and path reconstruction are identical to those in MRT. MORE turns the single log table into one table for each interface of a router. Such a change gives MORE smaller log tables and consequently prevents the insufficient marking space in a packet. But, since the scheme inherits MRT s loggingmethod,itisstillpossibleforitsmarkingfieldto be on the adjacent downstream router after logging. Then, the downstream router will be mistaken as a logged one and therefore lead their traceback to a wrong origin. Besides, like MRT and MORE, their storage requirements increase with packet numbers. It means when accumulated packet digests are larger than the quota of a router, especially when under flooding-based attacks, the router will refresh its logged data. Hence their path reconstruction fails [8]. 3. A 6-Bit Hybrid Single Packet Traceback Scheme In order to prevent packet fragmentation and insufficient storage for log tables, we propose a new hybrid IP traceback scheme that only uses the 6-bit ID field of an IP header; see Table. Further, our proposed marking scheme is able to pass the fragmentation check of RFC 674. The topology of our scheme is illustrated in Figure. A router can be connected to a local network or other routers,

4 4 The Scientific World Journal Table : IP header; Identification field is used for our packet marking. Bit offset Version Header length TOS Total length 3 Identification field Flag Fragment offset 64 TTL Protocol Header checksum 96 Source address 8 Destination address 6 Options 6 or 96+ Payload (first 8 bytes) R R 7 R 5 Victim R R 4 R 6 R 9 Host R 3 R 8 Legitimate traffic Attack path Link Attacker Figure : Network topology. or even both. A border router receives packets from its local network. A core router receives packets from other routers. For example, R 9 serves as a border router when it receives packets from Host. However, it becomes a core router when receiving packets from R 8. Here,weassumethatanyrouterR i has to satisfy the following assumptions. (i) R i is secure from attacks. (ii) A router creates an interface table and numbers the upstream interfaces from to D(R i ) in advance. (iii) A router knows whether a packet comes from a router or from a local network. (iv) This traceback scheme is viable on every router. The notations used in our scheme are listed in Notation Section. Our traceback scheme consists of two parts. The first includes marking/logging. The second deals with path reconstruction. The following subsections will detail the steps of our scheme. 3.. Marking and Logging. When a border router receives a packet from its local network, it sets the packet s marking field as zero and forwards the packet to the next core router. Therefore, when adversaries send attack packets with a forged path in the marking field trying to confuse our tracking, we can still locate their origin correctly. On the other hand, when acorerouterr i receives a packet P j, R i uses packet P j s mark, P j.mark, the incoming interface UI i, and the degree D(R i ) to compute a new marking field mark new =P j.mark (D(R i )+ ) + UI i +.Ifmark new does not overflow, the core router R i overwrites P j.mark with mark new and then forwards the packet to the next router. If mark new overflows,thecorerouter R i has to compute H(P j.mark) and insert P j.mark and UI i as a pair into a log table. Since the index of a single table is inevitably too long for 6-bit marking fields, we use multitables to store packets logs. Therefore, we need to determine which table to store first. As shown in Algorithm, wecomputehashvalueof the source IP of the packet H tab (P j.srcip) to choose a log table k. Also, we hash packet P j s mark to determine its index l=h idx (P j.mark).then,weinsertp j.mark and UI i as a pair into the lth entry of table k, thatis,ht l k. According to the value of HT l k,wehavecometotwosituations:theindexed entry is either empty or occupied. Case. If the indexed entry HT l k is null, R i writes P j.mark and UI i in HT l k,asshownintable. Case. IfHT l k is not empty, we compare the packet s mark P j.mark and interface number UI i with the logged value in HT l k. Case.. IfthevalueinHT l k matches the current packet s marking, it means the two packets have an identical route. So, R i does not need to log this packet. Case.. If the two do not match, it means collision of H idx (P j.mark). Hence,weusethequadraticprobingalgorithm [] tosearchp.mark and UI i in HT k.ifp.mark and

5 The Scientific World Journal 5 Input: P j,ui i begin () If P j comes from LAN () P j.mark = (3) else (4) mark new =P j.mark (D(R i )+)+UI i + (5) if mark new > then (6) Get table number k = HT tab (P j.srcip) (7) if HT k is full (8) Modify time field of HT k from [T k, T k )to[t k, T k ) (9) Create new log table HT k with time field [T k, T k ) () endif () l=h=h idx (P j.mark) () probe = (3) while not (HT l k == ø or HTl k == (P j.mark, UI i )) (4) probe++ (5) l=(h+c probe +c probe )%m (6) endwhile (7) if HT l k == ø then (8) HT l k.mark =P j.mark (9) HT l k.ui = UI i () endif () mark new = l (D(R i )+) () endif (3) P j.mark = mark new (4) endif (5) Forward the packet to the next router end Algorithm : Marking and logging scheme. Table : Log table HT k created at T s k, full at Tf k. [T s k, Tf k ) HT k Index Mark UI Source router l P j.mark UI i UI i are not found there, the core router inserts them as a pair into the table; see Algorithm.WeusepacketP and log table HT 3 in Figure 3(b) to exemplify our logging scheme when collision occurs. Next, we use the index l to compute a new mark mark new =l (D(R i )+)and overwrite the packet s P j.mark with the new mark. Then, the marked packet is forwarded to the next router. Figure 3 exemplifies how router R logs three packets P, P,andP 3, which have different upstream paths. The grey cells in Figure 3 show that the contents of R s log tables are modified after logging. When R receives a packet P whose mark is 73, that is, P.mark = 73, P enters R from the interface ; hence, UI =. According to our marking scheme, mark new = 73 (3 + ) + ( + ) = 985. Since the new mark is within 65535, the maximum size of a 6-bit field, R rewrites P s mark P.mark into mark new and forwards the packet to the next router R.AfterreceivingP from the interface (UI =), R computes a new mark for P,mark new = 743. Because the new mark is larger than 65535, R has to log the mark. First, it hashes the packet s source IP to get the table number k = H tab (P.srcIP) =, so the new mark will be logged into the log table HT.Then, it computes the table s index l=h idx (P.mark) =.AsHT is null, R logs P.mark and UI into HT ;seethegreycell of table HT in Figure 3(b). Last, it uses the entry s index l to compute a new mark: mark new = (3+)=4.Itoverwrites P.mark with mark new and forwards the packet to R 3. Figure 3(b) also helps to exemplify how we log a packet s mark if there is collision in a log table. When P arrives at router R s interface (UI = ), R computes a new mark for P,thatis,mark new = Because 6667 is larger than 65535, R computes k = H tab (P.srcIP) = 3 and l = H idx (P.mark) = 6.SinceHT 6 3 is not empty and the value of HT 6 3 is different from P.mark, we have to find another entry for logging in table HT 3. Here, we use quadric probing algorithm to find a new entry that is available for logging.

6 6 The Scientific World Journal P.mark = 73 R D(R )=3 P.mark = 466 R 4 P.mark = 985 P.mark = 6667 P 3.mark = 78 P R.mark =4 P.mark = R 3 D(R )=3 P 3.mark =4 D(R 3 )=4 3 P.mark =3 P.mark =3 P 3.mark = 3 R 5 P, P and P 3 logged on R R6 R 7 Traffic flow Path reconstruction Index Mark UI Source router (a) [T, T ) [T, T ) [T, T ) [T 3, T 3 ) R s HT R s HT R s HT R s HT 3 Index Mark Source router 37 Index Mark UI Source router (b) Index Mark UI Source router UI [T, T ) [T, T ) [T, T ) [T 3, T 3 ) R s HT Index Mark UI Source router [T, T ) R s HT Index Mark UI Source router R s HT R s HT R s HT 3 Index Mark UI Index Mark UI Index Mark UI Source router 373 Source router Source router (c) Figure 3: (a) Traffic flow of packets P, P,andP 3.(b)RouterR s log tables. (c) Generating a new HT when R s HT is full. Then, we find the new entry s index l = ( )% 8=5.Hence,R inserts P.mark and UI as a pair into HT 5 3 ;seethegreycellsofht 3 in Figure 3(b). Last, we use Figure 3(c) as an example to show how we insert a mark into a log table when the table is full. Because we hash a packet s source IP to choose a log table, we do not balance the logging load of each table. Instead, we create our log tables in a two-dimensional way. All log tables are in one dimension. If a table is filled up, we create a new one and put the old one in another dimension. As shown in Figure 3(c),

7 The Scientific World Journal 7 at first, all tables created times are T k on the same horizon; here, k ranges from to 3. When HT becomes full and we still need to log new data into it, router R modifies HT s time field as [T, T ). Then, R creates a new HT and set itstimefieldas[t, T ). The old table is placed below the new one, in a vertical direction. When P 3 arrives R from the interface (UI = ), R computes a new mark for P 3 : mark new = 693. Asthenewmarkislargerthan65535,R computes k=h tab (P 3.srcIP) =. But the log table HT has been filled up, so R set current time T on the table s time field to indicate its filled-up time, [T,T ). Meanwhile, R creates a new table for HT and writes the current time T to the table s time field to indicate its created time, [T,T ) seethefirsttableandtheonebelowitinfigure 3(c).Atlast, R computes l=h idx (P 3.mark) =and inserts P 3.mark and UI into HT. 3.. Path Reconstruction. When a victim detects an attacking packet P j, it sends to the upstream router a path reconstruction request, which includes the packet P j s mark P j.mark, the packet s source address P j.srcip and the packet s received time T j. After a router receives the request, it uses P j.mark to determine the incoming interface UI i of packet P j. According to value of UI i,therearetwosituations. Case. IfUI i =,itmeansthemarkofp j has been logged on this router. Then, the router hashes P j.srcip to find out the log table that contains P j s mark, that is, k=h tab (P j.srcip). BecausetheroutermayhavemorethanonetableforHT k,we needtofindouttheonewhosetimefieldcoversp j s received time: T s k <T j <T f k.wethenusep j.mark to compute the table s index l=p j.mark/(d(r i )+).Ifl=,itmeansthis router is the source router. Otherwise, it gets mark old and UI i from HT j k and overwrites the P j.mark with mark old.last,it continues to trace the origin and sends the reconstruction request along with the P j.mark to its UI i s upstream router. Detailed algorithm of our path reconstruction is shown in Algorithm. Case. IfUI i =, the requested router computes new mark old and UI i and overwrites P j.mark with mark old.then, it sends the reconstruction request along with the P j.mark to its UI i s upstream router. We use the dotted lines in Figure 3 to exemplify how we reconstruct P s path. In this case, when R 3 receives the reconstruction request that contains P.mark =3, P.srcIP and T j,wheret < T j < T, R 3 computes the incoming interface number of P.Thatis,UI 3 =(3% (4 + )) =. Since UI 3 =,itmeansp has not been logged on this router. R 3 computes mark old = 3/5 = 4 and overwrites P.mark with mark old,thatis,4.then,r 3 sends a path reconstruction request with the new mark P.mark through its interface to the upstream router R. When R receives the request, it uses P.mark to compute UI =(4% (3+)) =.BecauseUI =,itmeansp has been logged on R. Next, R computes k=h tab (P.srcIP) = and l = 4/(3 + ) =. Therefore, we know P s mark was logged in R s table HT.Furthermore,R finds out the table of HT whosetimefield[t,t ) satisfies the requirement that T j is between T and T. Next, we get mark old = 985 and UI =from the table of HT whose time field is [T,T ). R overwrites P.mark with mark old,thatis,985.lastr sends a path reconstruction request that contains P.mark = 985 through its interface to the upstream router R.Therouter R and following routers will repeat the steps mentioned above until the requested router s computation result is as follows:theindexvalueisandtheinterfacenumberis, that is, the origin of the attack Reassembly of Packet Segments. According to the filter recommendation of RFC 674 [], a packet is fragmented when its size exceeds a router s maximum transmission unit (MTU). Because RIHT uses fragment offset field to mark packets, their offset value may be too large and exceed the maximum length of a packet during packet assembly. And the routers that comply with RFC 674 will take the segment as abnormal and drop their marks. Furthermore, its 3-bit marking scheme uses ID, flags, and fragment offset fields for marking. This makes its packet reassembly at the destination almost impossible. To prevent this problem, our method only uses each IP header s ID field for marking. It requires only 6 bits and prevents packet drop. In our scheme, any two arbitrary packets take the same path to a router if and only if they havethesamemarksonthesamerouter.itmeansdifferent packetsonthesameroutewillhavethesameidbecausewe use the field for marking. Although, according to Belenky and Ansari [8], the probabilityof fragment interlacing that results from out-of-order arrival of fragmented packets is.8, it can still cause errors in packet reassembly. For this reason, we assemble all the segments according to their offset values. Then, we use the checksum to check the integrity of each packet and to filter those segments that have an identical offsetvaluebutbelongtootherpackets.thisallowsusto verify whether the reassembly is correct. So, our scheme is able to reassemble most fragmented packets. 4. Performance Evaluation and Analysis This section analyzes the storage requirement, precision, and computation loads of our traceback scheme. In the following paragraphs, we will first introduce our simulation environment. Then, we compare the performance of our scheme with that of other hybrid single-packet traceback schemes, that is, MRT, RIHT, and MORE. In the following simulations, the environment consists of a PC with Intel P GHz, G RAM, and FreeBSD Simulation Environment. To simulate the internet topology, we use the skitter project topology distributed by CAIDA [9] asoursampledatasetoftheinternet.thedataset consists of paths to a specific host of the topology. We analyze CAIDA s skitter data and choose only 97,3 complete paths for our network topology. We ignore the incomplete paths

8 8 The Scientific World Journal Reconstruction scheme Input: P j.mark, P j.srcip, T j begin () UI i = P j.mark % (D (R i )+) () if UI i = then (3) l=p j.mark/(d (R i )+) (4) if l = then (5) Get table number k=h tab (P j.srcip) (6) If HT k s time field [T s k, Tf k ) (7) satisfies T s k <T j <T f k (8) UI i =HT l k UI (9) mark old = HT l k.mark () endif () Send reconstruction request with mark old () andp j.srciptoupstreamrouterthrough (3) UI i (4) else (5) This router is the nearest border router (6) to the attacker (7) endif (8) else (9) mark old = P j.mark/(d (R i )+) () Send reconstruction request with mark old () and P j.srciptoupstreamrouterthroughui i () endif end Algorithm : Path reconstruction scheme. in the data set which may cause routers not to respond to the ping command. The analysis results are illustrated in Figure 4. Total number of its routers are 3,67; its average hopcountofpathsis4.4;anditsaverageupstreamdegree is.63. There is a router whose degree is 434 and is the largest inthedataset,whilethesecondlargestdegreeisonly57. The difference between the two degrees is 77. Therefore, according to CAIDA, the router whose degree is 434 requires the largest storage and our scheme will manage to meet its requirements. 4.. Load Factor s Impact on Collision. Since collision may occur when we log packets marks, we use the open addressing [] method to deal with this problem. In the open addressing method, when a new entry has to be inserted, the slots are examined, starting with the hashed-to slot and proceeding in some probe sequence, until an unoccupied slot is found. When searching for an entry, the slots are scanned in the same sequence, until either the target record is found or an unused slot is found. Furthermore, to minimize the impact of collision on our scheme, we adopt the quadratic probing [] as the probe sequence. Quadratic probing requires only lightcomputationandisprovedeffectivewhenwetrytoavoid clustering problem. When we deal with a collision problem, we have to take into consideration the log table s load factor α, which is the proportion of logged paths to the log table s size. This factor can directly affect the number of collision. However, the Number of paths Hop counts Figure 4: Distribution of path length. calculation results of collision times may vary because we have two situations here, successful search and unsuccessful search. Unsuccessful search means that an entry has not been logged in a log table and therefore is to be inserted into an empty slot. A probe is performed each time collision occurs. The expected number of probes in unsuccessful search using open addressing is at most /( α), assuming uniform hashing.successfulsearchmeansanentryhasbeenlogged inahashtable.theexpectednumberofprobesinsuccessful search using open addressing is at most /α In(/( α)), assuming uniform hashing. The expected numbers of probes in the two situations are illustrated in Figure 5. Wecanseethatiftheloadfactorα is

9 The Scientific World Journal 9 Expected number Load factor Unsuccessful search Successful search Figure 5: Expected number of probes Log table s size (deg) (deg) Average logging times.5, the expected numbers of probes in the two situations are both at most. Once α is >.5, the collision in unsuccessful search drastically rises. Accordingly, we require that the load factor of each of our log table is.5 at most Analysis of Storage Requirement. Traceback schemes like MORE, RIHT, MRT, and ours need to log packets marks on routers if their IP fields overflow. When a router has a larger degree, we will need more bits to encode it, which causes larger marks. And since larger marks lead to higher logging frequency, more storage is required for the downstream routers. In order to analyze the global storage requirements of current hybrid single-packet traceback schemes, we use the real Internet topology and require that each router have thesamenumberoftables.buthowmanytablesarerequired for our logging scheme? As there are totally 97,3 paths in the network topology, the number of a router s log tables n should satisfy (n ) (m α ) 973 n (m α ).Each table only uses m α entries to log packet marks. According to the logging scheme in RIHT [8], arouter slogtablewithm entries is bounded by the number of upstream paths. Furthermore, R i needs to find the entry index and computes mark new = index (D(R i )+).Then,it overwrites P j.mark with mark new. Therefore, we can say, the maximum entries of R i s log table are m 65535/(D(R i )+ ). However,CAIDA sskitterdata[9] points out that the numberofpathsofanupstreamroutermayexceed Thus, a router needs multiple tables to log P j.mark. Besides, a largelogtablewillalsoleadtoalargemarkp j.mark in packet P j. Consequently, the packet will have higher frequency of logging in the following routers, and the downstream routers will inevitably have larger storage loads. To prove this, we run the following simulations to analyze the storage requirements of MRT, MORE, RIHT, and the worst case of our scheme. Therefore, we send multiple packets to each of the 97,3 paths and then averaging all the routers storage loads in logging. Among these schemes, both MORE and ours have to maintain a couple of log tables and an interface table on eachrouter.becausethesizeofaninterfacetableisrelatively negligible,hereweleaveitoutofouranalysis Figure 6: Relation among degrees, table size, and average logging times. Figure 6 shows the relation among a router s interface numbers, its table size, and the average logging times of each router. As Figure 6 shows, the larger a router s degree is, the smaller a log table s maximum available entries are. Take the largest router in CAIDA s topology as an example. The router withadegree49mayhavea8-entrylogtableatmost.also, when a log table s size is smaller than 6 entries there is a surge inaverageloggingtimes.itisbecauseasmalllogtablecanbe filled up quickly and therefore results in the increase of log tables. That is why we set the minimum entries of all log tables as 6 in the following simulation. In Figure 7, we inject packets (from million to 5 million) into the network to compare the logging times of our scheme with those of MRT, MORE, and RIHT. Because the logging times increase with packet numbers in MRT and MORE, their average logging times remain much higher than RIHT s and ours from the very beginning. Like RIHT, we bound our logging times with path numbers. The bounded logging times will not increase with packet numbers, so that we can keep our logging times low. Figure 8 shows the storage requirements for MRT, MORE, RIHT, and our scheme on the largest router of CAIDA s topology. Each entry of MRT s log tables contains a 3-bit digest and a 3-bit marking field. In MORE, one entry containsa3-bitdigestanda6-bitmarkingfield.thus,the storage requirements for their routers are n 64bits and n 48 bits, respectively, where n isthenumberofloggedpackets ontherouter.onthesameroute,packetsareloggedonthe same routers. When we inject packets (from million to 5 million) into the network, the simulation results indicate that the storage requirement for MRT ranges from.99 MB to5mb;formore,from.8mbto67mb;forourscheme about MB; and for RIHT, 3 KB unchanged. For MRT and MORE, their storage requirements are lower than ours only

10 The Scientific World Journal Average logging times Average probing times MRT MORE Packet numbers (M) RIHT Our scheme Figure 7: Comparison of logging times RIHT Our scheme Packet numbers (M) Figure 9: Average probing times in path reconstruction. Storage requirements (MB) MRT MORE Packet numbers (M) RIHT Our scheme Figure 8: Comparison of storage requirements. whenthepacketnumbersarebelowmillion.however,a core router with gigabit bandwidth, or even wider, can receive much higher than million packets shortly. If there is a flooding-based attack, the log tables in the two schemes will grow hugely in a short time. However, in RIHT and our scheme, the size of a hash table is fixed, which secures our scheme against flooding-based attacks. RIHT s marking field is 3 bits, which is big enough for most marking. Therefore, it requires less logging and its storageisabout.5mblessthanours.butinourscheme,each router requires only MB for storage. They will not need to drop logged marks for insufficient storage. So, our scheme is as practical as RIHT in storage requirement Analysis of Computation Loads. As for the computing time of a path reconstruction, both MRT and MORE require thatarouterusestherequestpacket sdigesttofinditspreviously stored marking field in the log table. However, their routers log tables are unsorted, so they need an exhaustive search. Therefore, the average search time required for MRT is Θ(n), wheren denotes the number of logged packets in alogtable;anditisθ(n UIi ) for MORE, where n UIi denotes the number of logged packets in the log table associated with UI i. As for RIHT and our scheme, we only need to get the log table s index stored on the request packet s marking field. With the index, we are able to retrieve the logged data from the table without any search. Therefore their computation load is Θ(). Since RIHT and our proposed scheme do not needtospendtimeonsearching,thepathreconstructionin the two schemes is obviously faster than that in MRT and MORE. Figure 9 demonstrates the relation between packet numbers and average probing times in RIHT and our scheme. Here, average probing times represent the average times of probing in path reconstruction. In our scheme, if there are filled-up tables, we may need more probes to find the exact table where the mark is logged. That is why our average probing times slightly increase with packet numbers; see Figure 9. But, mostly our average probing times are just close to. RIHT needs only one search for a logged path because it has only one log table. Following its index, it retrieves the logged data. Our scheme needs at least two searches because we have to find the log table first and then the logged path. The difference of one more search between the two schemes is, in fact, rather insignificant False Positive and False Negative Rates. When a router is mistaken as an attack router, we call it a false positive. When we fail to trace back to an attacker, we call it a false negative. Besides, a router s storage capacity is limited. If packet numbers exceed a router s storage limit, its log tables will be refreshed. Then, false negatives may occur in path reconstruction. Both MRT and MORE use packet digests as their indexes. Consequently, the size of their log tables grows with the number of logged packets. Figure 8 shows that both MRT and MORE require more storage when packet numbers increase. But a router has only limited storage. When a router runs out of space, the two schemes can only refresh their log tables. And this can cause false negatives. Our scheme requires low storage and does not need to refresh the log tables, so it is able to achieve false positive.

11 The Scientific World Journal False positives E + 7.E E E E + 7 RIHT Our scheme Packet numbers Figure : Comparison of false positives. In MRT and MORE, even if their logged data is not cleared,itisstillpossibleforthetwoschemestohavefalse positives because of the collision between attacking packets and other packets. The false positive rates for MRT and MORE are n/ 3,andn UIi / 3 respectively, where n denotes packet numbers; n UIi denotes the number of packets that pass through UI i ;and 3 denotesthenumberofbitsofa packet digest. As a result, we find it obvious that the false positive rates and packet numbers are proportional in MRT and MORE. Unlike the two schemes, RIHT and ours do not use packet digests for indexing. Instead, we use logged packets other fields to store the log tables numbers. Therefore, we will not have false positives because of the collision of packet digests. In spite of the claimed false positive in RIHT, it fails to take packet fragmentation into consideration. When a packet is fragmented, the information marked on the packet will be modified. This can cause false positives in path reconstruction. The false positive rate is equal to the fragmentation rate, that is,.5%. In our method, we use only a 6-bit ID field for marking. Fragmentation will not cause any change to the field. For this reason, we can say our scheme can truly make false positive in path reconstruction. As shown in Figure, RIHT s false positives increase with packet numbers, but ours remains. 5. Conclusion In this paper, we propose a new hybrid single-packet traceback scheme that uses only 6 bits for marking. Compared with RIHT, our storage requirement is only.5 MB higher and we just need one more search in path reconstruction. It can be seen as practical as RIHT in storage requirement. With only MB storage requirement, the chance of a router refreshing our log tables is quite low. However, RIHT uses 3-bit fields for marking and inevitably suffer from packet dropping if packets are fragmented. Its false positive rate rises with packet numbers. As the simulation results indicate, if compared with the 6-bit hybrid traceback scheme MORE, our scheme requires low storage and low logging times. Among current traceback schemes, ours is the first one whose storage, computation loads, and track accuracy are not affected by packet numbers. Therefore, we can achieve false positive in tracking the origin of attacks with spoofed IPs. In conclusion, our scheme has the best performance in storage and traceback among current 6-bit hybrid IP traceback schemes. Notations R i : {R,R,...,R i,...,r x }, routers in a network D(R i ): The degree of R i P j : Received packet P j UI i : The upstream interface number of router R i P j.mark: Marking field of P j P j.srcip: P j s source IP m: A log table with m entries N: n denotes the number of log tables c,c : Constants H tab (): A hash function with hashed value ranging from to n H idx (): A hash function with hashed value ranging from to m HT k : Logtablek HT l k : lth entry in log table HT k,wherel ranging from to m [T s k,tf k ): Ts k denotes log table k s created time; and T f k denotes k s full time, where s,f=...,t,....ifs=,itmeansthe first table of k.iff=,itmeansthetable has not been filled up T j : The time that packet P j arrives at the destination %: Modulo operation. Conflict of Interests The author declares that there is no conflict of interests regarding the publication of this paper. Acknowledgment This research was supported by the National Science Council of Taiwan under Grant no. NSC--E-33-6-MY. References [] A. Hussain, J. Heidemann, and C. Papadopoulos, A Framework for classifying denial of service attacks, in Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications (SIGCOMM 3), pp. 99,ACM,Karlsruhe,Germany,August3. [] A. Yaar, A. Perrig, and D. Song, FIT: fast internet traceback, in Proceedings of the IEEE Annual International Conference on Computer Communications (INFOCOM 5), vol.,pp , March 5. [3] D. X. Song and A. Perrig, Advanced and authenticated marking schemes for IP traceback, in Proceedings of the th Annual

12 The Scientific World Journal Joint Conference of the IEEE Computer and Communications Societies (INFOCOM ), vol., pp , April. [4]H.C.Tian,J.Bi,X.-K.Jiang,andW.Zhang, Aprobabilistic marking scheme for fast traceback, in Proceedings of the nd International Conference on Evolving Internet (Internet ), pp. 37 4, IEEE Computer Society, September. [5]J.S.Liu,Z.-J.Lee,andY.-C.Chung, Dynamicprobabilistic packet marking for efficient IP traceback, Computer Networks, vol.5,no.3,pp ,7. [6] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, Network support for IP traceback, IEEE/ACM Transactions on Networking,vol.9,no.3,pp.6 37,. [7] V.Paruchuri,A.Durresi,andS.Chellappan, TTLbasedpacket marking for IP traceback, in Proceedings of the IEEE Global Telecommunications Conference (GLOBECOM 8), pp. 5, December 8. [8] A. Belenky and N. Ansari, Accommodating fragmentation in deterministic packet marking for IP traceback, in Proceedings of the IEEE Global Telecommunications Conference (GLOBE- COM 3),vol.3,pp ,December3. [9] A. Belenky and N. Ansari, IP traceback with deterministic packet marking, IEEE Communications Letters,vol.7,no.4,pp. 6 64, 3. [] A. Belenky and N. Ansari, Tracing multiple attackers with deterministic packet marking (DPM), in Proceedings of the IEEE Pacific Rim Conference on Communications Computers andsignalprocessing(pacrim 3), vol., pp. 49 5, August 3. [] A. C. Snoeren, C. Partridge, L. A. Sanchez et al., Single-packet IP traceback, IEEE/ACM Transactions on Networking, vol., no. 6, pp ,. [] B. H. Bloom, Space/time trade-offs in hash coding with allowable errors, Communications of the ACM, vol. 3, no. 7, pp. 4 46, 97. [3] L. Zhang and Y. Guan, TOPO: a topology-aware single packet attack traceback scheme, in Proceedings of the IEEE International Conference on Security and Privacy in Communication Networks (SecureComm 6), pp., September 6. [4] C. Gong and K. Sarac, A more practical approach for singlepacket IP traceback using packet logging and marking, IEEE Transactions on Parallel and Distributed Systems,vol.9,no., pp.3 34,8. [5] K.H.ChoiandH.K.Dai, AmarkingschemeusingHuffman codes for IP traceback, in Proceedings of the 7th International Symposium on Parallel Architectures, Algorithms and Networks (SPAN 4), pp. 4 48, May 4. [6] S. Malliga and A. Tamilarasi, A hybrid scheme using packet marking and logging for IP traceback, International Journal of Internet Protocol Technology,vol.5,no.-,pp.8 9,. [7] S. Malliga and A. Tamilarasi, A proposal for new marking scheme with its performance evaluation for IP traceback, WSEAS Transactions on Computer Research, vol.3,no.4,pp. 59 7, 8. [8] M.-H. Yang and M.-C. Yang, RIHT: a novel hybrid IP traceback scheme, IEEE Transactions on Information Forensics and Security,vol.7,no.,pp ,. [9] CAIDA, CAIDA s skitter project,, tools/skitter/. [] W. John and S. Tafvelln, Analysis of internet backbone traffic and header anomalies observed, in Proceedings of the 7th ACM SIGCOMM Conference on Internet Measurement (IMC 7), pp. 6, October 7. [] Security Assessment of the Internet Protocol, Version 4, IETF RFC 674,. [] D. E. Knuth, The Art of Computer Programming, Volume 3: Sorting and Searching, Addison Wesley Longman, Redwood City, Calif, USA, nd edition, 998.

13 International Journal of Rotating Machinery Engineering Journal of The Scientific World Journal International Journal of Distributed Sensor Networks Journal of Sensors Journal of Control Science and Engineering Advances in Civil Engineering Submit your manuscripts at Journal of Journal of Electrical and Computer Engineering Robotics VLSI Design Advances in OptoElectronics International Journal of Navigation and Observation Chemical Engineering Active and Passive Electronic Components Antennas and Propagation Aerospace Engineering International Journal of International Journal of International Journal of Modelling & Simulation in Engineering Shock and Vibration Advances in Acoustics and Vibration