You are on page 1of 7

Trace IP Packets by Flexible Deterministic Packet Marking (FDPM)

Yang Xiang, Wanlei Zhou and Justin Rough


School of Information Technology Deakin University Melbourne, Australia {yxi, wanlei, ruffy}@deakin.edu.au
Abstract Currently a large number of the notorious Distributed Denial of Service (DDoS) attack incidents make people aware of the importance of the IP traceback technique. IP traceback is the ability to trace the IP packets to their origins. It provides a security system with the ability to identify the true sources of the attacking IP packets. IP traceback mechanisms have been researched for years, aiming at finding the sources of IP packets quickly and precisely. In this paper, an IP traceback scheme, Flexible Deterministic Packet Marking (FDPM), is proposed. It provides more flexible features to trace the IP packets and can obtain better tracing capability over other IP traceback mechanisms, such as link testing, messaging, logging, Probabilistic Packet Marking (PPM), and Deterministic Packet Marking (DPM). The implementation and evaluation demonstrates that the FDPM needs a moderately small number of packets to complete the traceback process, requires little computation and could traceback up to 110,000 sources in one traceback process; therefore this scheme is powerful to trace the IP packets. It can be applied in many security systems, such as DDoS defense systems, Intrusion Detection Systems (IDS), forensic systems, and so on. Keywords-IP traceback; security; Flexible Deterministic Packet Marking; DDoS; hash function

IP traceback mechanisms have been researched for years, aiming at quickly and precisely finding the sources of IP packets. In this paper, an IP traceback scheme based on Deterministic Packet Marking (DPM) [4], is proposed. This scheme, named Flexible Deterministic Packet Marking (FDPM), provides more flexible features to trace the IP packets than DPM, and can obtain better tracing capability. Compared with other IP traceback mechanisms, such as link testing, messaging, logging, and Probabilistic Packet Marking (PPM), FDPM needs a moderately small number of packets to complete the traceback process and requires little computation. The rest of this paper is organized as follows. In section 2, the related work is introduced. Then the basic idea of DPM and hash-based DPM are presented. The shortcomings of DPM are also analyzed. In section 4, the details of FDPM are introduced. Theoretical analysis is given later, and the implementation and evaluation shows that FDPM improves the ability of traceback greatly. A comparison between FDPM and other mechanisms is also analyzed. Finally challenges and conclusions are discussed. II. RELATED WORK

I.

INTRODUCTION

IP traceback is the ability to trace IP packets to their origins [1]; it provides a system with the ability to identify true sources of the IP packets. Recent notorious Distributed Denial of Service (DDoS) attacks [24] have made people aware of the importance of the security and availability of data and services. These attacks have also made the IP traceback technique more and more important, because of its ability to reconstruct the path traversed by the attack packets on their journey from source to the victim [19]. This information can then be used to control and punish the attacks. A DDoS attack is an availability attack, characterized by an explicit attempt from an attacker to prevent legitimate users from using the desired resource [7] [25]. IP address spoofing techniques allow the source address in an IP header to be manipulated and falsified by attackers, where the source IP addresses is usually counterfeited to hide the identity of the attackers. Therefore, these IP addresses are of no use to identify the attackers. Instead, we must rely on IP traceback mechanisms to find the source of attacker.

We classify current IP traceback mechanisms into four categories: link testing, messaging, logging, and packet marking. FDPM falls into the packet marking category. Link testing methods include input debugging [23] and controlled flooding methods [6]. The main idea of it is to start from the victim to find the attack from upstream links by testing possible routes, and then determine which one carries the attack traffic. Although link testing has some advantages such as compatibility with existing protocols, routers and network infrastructure, it also has many significant limitations. First, it consumes a great deal of time to establish the attack path that may include multiple branch points. However, the attack does not often last for an enough long time for traceback. Second, if the attack comes from within the backbone itself, or, a backbone router is a victim, it is not suitable for this method to reconstruct the attack path. Third, if some attacks are only composed of a few packets, this method becomes less effective. Moreover, if the links are flooded, it may not be possible to communicate with routers upstream.

Another traceback technique is messaging. Bellovin proposed an ICMP message to find the source of forged IP packets [3]. Allison Mankin modified this method by proposing an intension-driven ICMP traceback [11]. However, if the attacking packets contribute only a small amount of the total attack traffic, it is difficult for this method to rebuild the real path. Moreover, ICMP packets are often treated or filtered by routers with a low priority, thus it also causes this method less effective. ICMP traceback is vulnerable to attackers with the falsified ICMP messages. In general, the messaging traceback introduces additional network traffic, and cannot handle the highly distributed DDoS attacks. Logging involves storing the traffic data for analysis. Although to store all the data in the network is impossible, probabilistic sampling or storing transformed information is still feasible. For example, trajectory sampling is used to measure the network traffic [9], Alex C. Snoreren [19] proposed a hash-based logging traceback method, T. Baba and S. Matsuda [2] proposed a scheme that the tracing agents (tracers) are deployed in the network to log the attack packets, and are coordinated by the managing agents. The main advantage of this method is that it can even find the source of a single packet in some situations [19], however, this method also has excessive processing and storage requirements, which makes it difficult to be widely deployed. Packet marking involves inserting traceback data into the IP packet on its way through the various routers from the attack source to the destination. These marks in the IP packets can be used to reconstruct the path of the malicious traffic. Probabilistic Packet Marking (PPM) [18] is one of the packet marking methods. The assumption of PPM is that the attacking packets are much more frequent than the normal packets. It lets routers mark the packets with path information in a probabilistic manner and lets the victim reconstruct the attack path by using the marked packets. PPM encodes the information in rarely used identification field within the IP header (used for identifying which packet a fragment belongs to). To reduce the data to be stored to 16 bits, the compressed edge fragment sampling algorithm was used. PPM requires less traffic volume than ICMP traceback, but encounters computational difficulties as the numbers of attack sources increases. Peng et al. proposed an adjusted PPM that reduces the number of packets needed to reconstruct the attack path [13]. To some degree it solved the problem of vulnerabilities of PPM [12], which is easy to be affected by spoofed marking field. An alternative packet marking method, which does not use the probabilistic assumption above, is the Deterministic Packet Marking (DPM) [4]. This scheme has many advantages over others, including simple implementation, no bandwidth requirement, less computation overhead, and it is free from the problem of spoofed marking. However, to perform a successful traceback, enough packets also must be collected to reconstruct the attack path (e.g. in the best case, at lease 2 packets are required to trace an IP source). Flexible Deterministic Packet Marking (FDPM), an optimized version of DPM, is discussed in the later section. Other practical issues, for example, the maximum number of sources can be traced; the

implementation, effectiveness of hash function, and the reduction of IP packets required are analyzed in detail as well. Other packet marking schemes include the Advanced and Authenticated Marking Scheme [20], Path Identifier (Pi) [26], and the polynomial path reconstruction [8]. The detailed information could be found in the references. III. HASH-BASED DETERMINISTIC PACKET MARKING (DPM)

Hash-based Deterministic Packet Marking [4] utilizes a fixed length mark that consists of the 16-bit ID field and the 1bit Reserved Flag (RF) in the IP header. When the packet enters the protected network, it will be marked by the interface close to the source of the packet on an edge ingress router. The mark will not be changed when the packet traverses the network. The source IP addresses are stored in the marks. At any point within the network, the source IP addresses can be assembled when they are necessary. Because all the packets will be marked by the very first router the packet passes, markspoofing by the attackers is not effective. So this scheme is naturally free of mark-spoofing. Given that only 17 bits are available in the IP header for marking, at least 2 packets are needed to carry the 32-bit source IP address. Each packet holding the mark will be used to reconstruct the source IP address at any victim end within the network. A segment number is also assigned to the mark, because when reconstructing the packet, the segment order of the source IP address bits should be known. After all the segments corresponding to the same ingress address have arrived to the destination, the source IP address of the packets can be reconstructed. In order to keep a track on a set of IP packets that are used for reconstruction, the identities shown the packets come from the same source must be given. The source IP address field in the IP header is completely unreliable, because it can be easily forged by the attackers. If only the source IP address is used to match the packets carrying source IP bits, the reconstruction process could mismatch the packets using different spoofed source IP addresses. Therefore, the scheme could produce a high false positive rate. To determine whether several IP packets come from the same source, a hash of the ingress address is kept in the mark, known as the digest. The hash-based scheme is proposed to be more efficient and accurate for the path reconstruction under attacks than other schemes. The mark in DPM therefore needs another place to store the digest. This digest will always remain the same for a DPM interface from which the packets enter the network. It provides the victim end the ability to recognize which packets being analyzed are from a same source, although the digest itself cannot tell the real address. Mark Recording and Ingress Address Recovery are two separate processes at the victim end to reconstruct IP addresses. The source IP address can be recovered by the marks that include three parts, address information, ingress address digest and segment number. This is the basic idea of hash-based DPM scheme for tracing IP packets. In the following section, the modified version of DPM, Flexible Deterministic Packet Marking (FDPM) is discussed in detail.

IV.

FLEXIBLE DETERMINISTIC PACKET MARKING (FDPM)

A. IP Header DPM uses 17 bits in the IP header to store the marking information. However, the length of the available fields in IP header still can be expanded. Importantly, this must be accomplished without sacrificing backwards compatibility. The Type of Service (TOS) field is an 8-bit field that provides an indication of the abstract parameters of the quality of service desired [14]. The details of handling and specification of TOS values can be found in [15]. The TOS parameters are to be used to guide the selection of the actual service parameters when transmitting a datagram through a particular network. However, this field has been rarely supported by most routers in the past. Some proposed standards such as Differentiated Services in TOS [17], used to indicate particular Quality of Service needs from the network, are still under development. Therefore, in FDPM scheme, the TOS field will be used to store the mark under some circumstances. The other two fields in the IP header are also exploited, one is Fragment ID, and the other is the Reserved Flag. An identifying value is assigned to the ID field by the sender to aid in assembling the fragments of a datagram. Given that less than 0.25% of all Internet traffic is fragments [22], this field can be safely overloaded without causing serious compatibility problems. Similarly, the use of the Reserved Flag field should not cause compatibility problems. As shown in Figure 1, a total of 25 bits are available for the storage of mark information in a maximum case. When considering the possibility that the TOS field may be unavailable partly or totally, the minimum number of the bits in IP header is 16 (excluding the 1bit flag). The reserved flag is not considered as it is used to indicate whether or not the TOS field is being used, which will be discussed later. FDPM can adjust the mark length according to the protocols of the network in which FDPM is deployed. For example, given that some IPv4 fields do not exist in IPv6 [16], the selection of fields may not suitable in an IPv6 network. However, FDPM still can be deployed under IPv6, only with some changes of marking field in the IP header.

it will be written to the different fields in the header of the IP packet. The ingress IP address is divided into k segments, which means these k parts are stored into the marks to reconstruct one source IP address. The segment number keeps the order of the address bits. The address digest enables the reconstruction process to recognize the packets being analyzed are from a same source. Without this part, the reconstruction process cannot trace multiple IP packets, because it cannot identify the packets come from different sources.

Figure 2. FDPM encoding.

The encoding algorithm is shown below. In the FDPM scheme, before the encoding process begins, the length of the mark should be calculated. If the TOS field in the IP packet is not being used by the network, the 1-bit Reserved Flag in the header is set to 0, and the length of mark is set to 24. Under other situations the length of mark will be 19 or 16, with relevant bit in TOS marked. If the network supports TOS Precedence but not TOS Priority, 4th-6th bit of TOS is utilized for marking; and if the network supports TOS Priority but not TOS Precedence, 1st-3rd bit of TOS is utilized for marking.
Marking process at router R, edge interface A, in network N if N does not utilize TOS Reserved_Flag:=0 th th 7 and 8 bit of TOS:=0 Length_of_Mark:=24 else Reserved_Flag :=1 if N utilizes Differentiated Services Field or N support Precedence and Priority 7th and 8th bit of TOS:=1 Length_of_Mark:=16 else if N support Precedence but not Priority 7th bit of TOS:=1 th 8 bit of TOS:=0 Length_of_Mark:=19 else if N support Priority but not Precedence

Figure 1. The IP header fields (darked) utilized in FDPM.

B. Encoding The encoding of the mark in FDPM, as shown in Figure 2, is similar to the encoding used in DPM [4]. However, before the FDPM mark can be generated, the length of mark should first be decided based on the network protocols deployed within the protected network. According to the different situations, the length of mark could be 24 bits long at most, 19 bits at middle, and 16 bits at least. After the mark is generated,

7th bit of TOS:=0 th 8 bit of TOS:=1 Length_of_Mark:=19 end if end if Decide the lengths of each part in the mark Digest:=H(A) loop i=0 to k-1 Mark[i].Digest:=Digest Mark[i].Segment_number:=i Mark[i].Address_bit:=A[i] end loop for each incoming packet p j:=random integer from 0 to k-1 write Mark[j] into w.Mark

C. Reconstruction The reconstruction process includes two steps: mark recognition and address recovery. Compared to DPM, the reconstruction process is simpler and more flexible. When each packet that is used to reconstruct the source IP address arrives at the victim, it is put into a cache, because in some cases the processing speed is lower than the arrival speed of the incoming packets. The cache can also output the packet information to another process unit, by this design the different reconstruction methods can be applied and compared with each other. By differentiating the fields in the IP header, the length of the mark and which fields in the IP header store the mark can be recognized. The second step, address recovery, analyzes the mark and stores it in a recovery table. The number of columns in the table is k, representing the number of segments used to carry the source address in the packets. Here the segment number is used to put the data in the correct location. Each column in the same row stores the bits in the same IP address which is carried by different incoming packets. The row of the table means the entry; usually each digest owns one entry. However, the same digest may have several entries. Because the digest is a hash of the source IP address, and thus is shorter than the IP address, different source IP addresses may have the same digest. When a collision occurs, more than one entry may be created in order to keep as much information as possible, although many of the source IP addresses reconstructed are invalid. The DPM reconstruction uses a fix size recovery table, which is unable to handle the situation of digest collision. Figure 3 shows the reconstruction scheme. When all fields in one entry are filled according the segment number, this source IP address is then recovered and the entry in the recovery table is deleted. If still more fields need to be filled, the next packet is processed. To simplify the problem, the serial process is shown in the figure, actually parallelized processing is also achievable, and thus it saves computation time. The algorithm is shown below.

Figure 3. FDPM reconstruction.

Reconstruction at victim V, in network N for each attacking packet p mark recognition (length and fields) if all fields in one entry are filled output the source IP delete the entry else if same digest and segment num exist create new entry fill the address bits into entry else fill the address bits into entry end if end if

V.

ANALYSIS AND EVALUATION

A. Theoretical Analysis One limitation of DPM is the maximum number of the attacker sources is only 2048 [4]. This means in the network, only the IP addresses for 2048 edge routers can be traced, otherwise the system cannot precisely reconstruct the source IP addresses. Moreover, this number is obtained without considering other factors such as the digest collision, network traffic condition, IP packet fragment, and so on. Because of the increased mark length, the FDPM scheme offers a defense system of much stronger capability to trace multiple attacker sources. The relationship between the number of packet(s) that carry one IP address k, the bit of fragment s, the address bits a, the digest bits d, maximum number of attacker source N under different situations of FDPM, which could be affected by the digest bits d, and the same relationship of the parameters in the DPM, are shown in table 1.
TABLE I. k s a FDPM-16 d N d N d N d N RELATIONSHIP BETWEEN THE PARAMETERS IN FDPM AND DPM 2 1 16 0 1 0 1 2 4 7 128 4 2 8 6 64 7 128 9 512 14 16384 8 3 4 9 512 10 1024 12 4096 17 131072 16 4 2 10 1024 11 2048 13 8192 18 262144 32 5 1 10 1024 11 2048 13 8192 18 262144

1/2 of that of DPM. Figure 4 shows the comparison of maximum number of sources can be traced under different situations by FDPM and DPM. The vertical axis is Ln(N) instead of N, for better illustration. B. Implementation and Evaluation To build a real testing traceback network environment is expensive, since thousands of hosts cost much. So we used a network simulator, SSFNet, to gather experimental data for analysis. SSFNet (Scalable Simulation Framework) is a collection of Java components for modeling and simulation of Internet protocols and networks at and above the IP packet level of detail [21]. The SSFNet models are self-configuring, that means by querying a configuration database, each SSFNet class instance is configured separately. The network configuration is written in the Domain Modeling Language (DML) format, which specifies a hierarchy of lists of attributes (key-value pairs), that can be stored as ASCII files which are easy to read and interpret. Thus, we can describe a network environment by using a simple, standardized syntax of all configuration files. With this capability to build large scale network environments, we have conducted many experiments to test the FDPM. Two new Java packages are embedded into SSFNet, one is Encoding sub-system and the other is Reconstruction subsystem. The Encoding sub-systems are deployed at the edge of the protected network, and the Reconstruction sub-system is deployed at the victim end that will analyze the sources of IP packets. In the Encoding sub-system, the hash function must be chosen carefully because we find hash collision is one of the main factors affect the traceback performance. Given that all processes in FDPM must be done through the hash function, the function must fulfill two requirements: it must be fast, and it must have a good ability to distribute keys throughout the hash table. The latter requirement minimizes collisions and prevents data items with similar values from hashing to just one part of the hash table. Two general-purpose hash functions are selected to test the effectiveness of hashing in FDPM. PJW Hash function [5] is based on work by Peter J. Weinberger of AT&T Bell Labs, and is widely used. Another hash function, BKDR Hash Function [10] is also chosen. These algorithms are very popular because they can be implemented in any programming language and are quite fast. Figure 5 shows the average non-collision rate of the hashed digest in the traceback experiments. When the number of segments used increases, the non-collision rates are stable below 45%. Under most circumstances, tuning hash functions can be difficult because it requires considerable empirical testing, and it largely depends on what data set is used. Unless the hash table is set up in a pre-set manner (the possible hash value is subjectively chosen beforehand and cannot fit for the general network environments), the non-collision rate can hardly be improved.

DPM

FDPM-19

FDPM-24

Figure 4. Comparison of maximum number of sources can be traced under different situations.

From this table we can see under the optimal situation, the maximum number of sources which can be traced in by FDPM is 262144. Theoretically, it is 128 times of that of DPM, although in the worst case, the maximum number by FDPM is

value. Furthermore, this scheme is unable to handle fragmentation of an IP packet, because it utilizes the 16-bit ID field in the IP header. In particular, on DDoS defense issue current research proves traceback is an effective countermeasure against the attacks [1]. However, prevalent traceback methods can only probabilistically trace every attack host, but not the real attacker. If housands of zombies launch a single attack, the traceback will become less effective. Therefore, further research is required to provide a solution to traceback to the real attacker.
Figure 5. Non-collision rate. TABLE II.
Criterion Compatibility Implementation Scalability Computation load Number of packets needed for traceback Network topology known Bandwidth comsumed Application

COMPARISON WITH OTHER TRACEBACK MECHANISMS


Controlled flooding Good Easy N/A Fair Huge Yes Huge DDoS ICMP traceback Fair Fair Fair Fair Huge Yes Fair DDoS, others Logging Good Difficult Low High Small Yes Low DDoS, others PPM Good Fair Fair Medium Thousan ds Yes Low DDoS FDPM Good Easy High Low Small No Low DDoS, others

The average maximum numbers of sources that can be traced under different situations are shown Figure 6. Although in the reconstruction process, all possible source addresses are recorded by creating the new digest entries, it also brings false positives. If the amendment for the collision of the digest is ignored, it brings the high missing probability. Compared with the theoretical analysis in the section before, although in the practical experiments the maximum source number is not as large as the theoretical value, in FDPM with 24 bits digest, it still can trace more than 110,000 different sources.

VI.

CONCLUSION

Figure 6. Maximum number of sources traced in experiments.

C. Comparison with other traceback mechanisms The analysis above shows FDPM offers more flexibility and capability to trace the different IP sources than DPM from the points of view of both theoretical and practical issues. In this section, FDPM is compared with other categories of traceback schemes such as controlled flooding, ICMP traceback, logging, and Probabilistic Packet Marking as the following table. The major advantages of FDPM is that it can trace the IP sources with low computation load, while it needs a small number of packets to accomplish the traceback process, without knowing the topology of the protected network. Moreover, it can trace much more sources at a single traceback process than other schemes. D. Challenges Although the FDPM provides many advantages to trace the sources of IP packets, there are still many challenges. For example, the digest collision makes the practical maximum number of sources that can be traced lower than the theoretical

In this paper, an IP packet traceback scheme, Flexible Deterministic Packet Marking (FDPM) is presented. It provides more flexible features to trace the sources of IP packets and can obtain better tracing capability over other IP traceback mechanisms. The implementation and evaluation demonstrates that the FDPM needs a moderately small number of packets to complete the traceback process, requires little computation and could traceback up to 110,000 sources in one traceback process; therefore this scheme is powerful to trace the IP packets. It can be applied in many security systems, such as DDoS defense systems, Intrusion Detection Systems (IDS), and forensic systems, etc. ACKNOWLEDGMENT The authors would like to thank the anonymous reviewers for their constructive suggestions that helped improve the quality of this paper. REFERENCES
[1] [2] [3] [4] H. Aljifri, "IP Traceback: A New Denial-of-Service Deterrent?", IEEE Security & Privacy, Vol.1, No.3, 2003, pp.24-31. T. Baba and S. Matsuda, "Tracing Network Attacks to Their Sources", IEEE Internet Computing, Vol.6, No.3, 2002, pp.20-26. S. M. Bellovin, "ICMP Traceback Messages", Internet Draft, Network Working Group, 2000. A. Belenky and N. Ansari, "Tracing Multiple Attackers with Deterministic Packet Marking (DPM)", Proc. of IEEE Pacific Rim Conference on Communications, Computers and Signal Processing, 2003.

[5] [6]

[7] [8]

[9] [10] [11]

[12]

[13] [14] [15] [16]

A. Binstock and J. Rex, Practical Algorithms for Programmers, Pearson Education, 1995. H. Burch and B. Cheswick, "Tracing Anonymous Packets to Their Approximate Source", Proc. of the 14th Systems Administration Conference (LISA 2000). Computer Emergency Response Team, CERT, http://www.cert.org. D. Dean, M. Franklin, and A. Stubblefield, "An Algebraic Approach to IP Traceback", Proc. of Network and Distributed System Security Symposium (NDSS 2001), pp.3-12. N. G. Duffield and M. Grossglauser, "Trajectory sampling for direct traffic observation", ACM SIGCOMM 2000, pp.271-282. B. W. Kernighan and Dennis M. Ritchie, The C Programming Language, Second Edition, Prentice Hall, 1988. A. Mankin, D. Massey, C.-L. Wu, S. F. Wu and L. Zhang, "On Design and Evaluation of Intention-Driven ICMP Traceback", Proc. of Computer Communications and Networks, 2001. K. Park and H. Lee, "On the Effectiveness of Probabilistic Packet Marking for IP Traceback under Denial of Service Attack", IEEE INFOCOM 2001, pp.338-347. T. Peng, C. Leckie, and R. Kotagiri, "Adjusted Probabilistic Packet Marking for IP Traceback", Networking 2002. RFC791, Internet Protocol, DARPA, 1981. RFC1349, Type of Service in the Internet Protocol Suite, Network Working Group, 1992. RFC2460, Internet Protocol, Version 6 (IPv6) Specification, Network Working Group, 1998.

[17] RFC2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, Network Working Group, 1998. [18] S. Savage, D. Wetherall, A. Karlin and T. Anderson, "Network Support for IP Traceback", ACM/IEEE Transactions on Networking, Vol.9, No.3, 2001, pp.226-237. [19] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones, F. Tchakountio, B. Schwartz, S. T. Kent, and W. T. Strayer, "Single-Packet IP Traceback", IEEE/ACM Transactions on Networking, December, 2002, pp.721-734. [20] D. Song and A. Perrig, "Advanced and Authenticated Marking Schemes for IP Traceback", IEEE INFOCOM 2001, pp.878-886. [21] Scalable Simulation Framework, http://www.ssfnet.org. [22] I. Stocia and H. Zhang, "Providing Guaranteed Services Without Per Flow Management", ACM SIGCOMM99, 1999, pp. 81-94. [23] R. Stone, "CenterTrack: An IP Overlay Network for Tracking DoS Floods", 9th Usenix Security Symposium, 2000, pp.199-212. [24] Y. Xiang, W. Zhou, and M. Chowdhury, "A Survey of Active and Passive Defence Mechanisms against DDoS Attacks", Technical Report, TR C04/02, School of Information Technology, Deakin University, Australia, March, 2004. [25] Y. Xiang, and W. Zhou, "An Active Distributed Defense System to Protect Web Applications from DDoS Attacks", Proc. of the 6th International Conference on Information Integration and Web Based Application & Services (iiWAS2004). [26] A. Yaar, A. Perrig, and D. Song, "Pi: A Path Identification Mechanism to Defend against DDoS Attacks", 2003 IEEE Symposium on Security and Privacy.

You might also like