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
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.
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
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 1-
bit 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, mark-
spoofing 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.
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,
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
 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 Figure 3. FDPM reconstruction.
source IP addresses reconstructed are invalid. The DPM
reconstruction uses a fix size recovery table, which is unable to Reconstruction at victim V, in network N
for each attacking packet p
handle the situation of digest collision.
mark recognition (length and fields)
Figure 3 shows the reconstruction scheme. When all fields if all fields in one entry are filled
in one entry are filled according the segment number, this output the source IP
source IP address is then recovered and the entry in the delete the entry
recovery table is deleted. If still more fields need to be filled, else
the next packet is processed. To simplify the problem, the if same digest and segment num exist
serial process is shown in the figure, actually parallelized create new entry
processing is also achievable, and thus it saves computation fill the address bits into entry
else
time. The algorithm is shown below.
fill the address bits into entry
end if
end if
 V. ANALYSIS AND EVALUATION 1/2 of that of DPM. Figure 4 shows the comparison of
maximum number of sources can be traced under different
A. Theoretical Analysis situations by FDPM and DPM. The vertical axis is Ln(N)
One limitation of DPM is the maximum number of the instead of N, for better illustration.
attacker sources is only 2048 [4]. This means in the network,
only the IP addresses for 2048 edge routers can be traced, B. Implementation and Evaluation
otherwise the system cannot precisely reconstruct the source IP To build a real testing traceback network environment is
addresses. Moreover, this number is obtained without expensive, since thousands of hosts cost much. So we used a
considering other factors such as the digest collision, network network simulator, SSFNet, to gather experimental data for
traffic condition, IP packet fragment, and so on. analysis. SSFNet (Scalable Simulation Framework) is a
Because of the increased mark length, the FDPM scheme collection of Java components for modeling and simulation of
offers a defense system of much stronger capability to trace Internet protocols and networks at and above the IP packet
multiple attacker sources. The relationship between the number level of detail [21]. The SSFNet models are self-configuring,
of packet(s) that carry one IP address k, the bit of fragment s, that means by querying a configuration database, each SSFNet
the address bits a, the digest bits d, maximum number of class instance is configured separately. The network
attacker source N under different situations of FDPM, which configuration is written in the Domain Modeling Language
could be affected by the digest bits d, and the same relationship (DML) format, which specifies a hierarchy of lists of attributes
of the parameters in the DPM, are shown in table 1. (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
TABLE I. RELATIONSHIP BETWEEN THE PARAMETERS IN FDPM AND configuration files. With this capability to build large scale
DPM
network environments, we have conducted many experiments
k 2 4 8 16 32 to test the FDPM.
s 1 2 3 4 5 Two new Java packages are embedded into SSFNet, one is
a 16 8 4 2 1
Encoding sub-system and the other is Reconstruction sub-
system. The Encoding sub-systems are deployed at the edge of
d 0 6 9 10 10 the protected network, and the Reconstruction sub-system is
FDPM-16
N 1 64 512 1024 1024 deployed at the victim end that will analyze the sources of IP
d 0 7 10 11 11
packets. In the Encoding sub-system, the hash function must be
DPM chosen carefully because we find hash collision is one of the
N 1 128 1024 2048 2048 main factors affect the traceback performance. Given that all
d 2 9 12 13 13 processes in FDPM must be done through the hash function,
FDPM-19 the function must fulfill two requirements: it must be fast, and
N 4 512 4096 8192 8192
it must have a good ability to distribute keys throughout the
d 7 14 17 18 18 hash table. The latter requirement minimizes collisions and
FDPM-24
N 128 16384 131072 262144 262144 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.
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. COMPARISON WITH OTHER TRACEBACK MECHANISMS
Controlled ICMP
The average maximum numbers of sources that can be Criterion
flooding traceback
Logging PPM FDPM
traced under different situations are shown Figure 6. Although Compatibility Good Fair Good Good Good
in the reconstruction process, all possible source addresses are Implementation Easy Fair Difficult Fair Easy
recorded by creating the new digest entries, it also brings false Scalability N/A Fair Low Fair High
positives. If the amendment for the collision of the digest is Computation
Fair Fair High Medium Low
ignored, it brings the high missing probability. Compared with load
Number of
the theoretical analysis in the section before, although in the packets needed Huge Huge Small
Thousan
Small
practical experiments the maximum source number is not as ds
for traceback
large as the theoretical value, in FDPM with 24 bits digest, it Network
Yes Yes Yes Yes No
topology known
still can trace more than 110,000 different sources. Bandwidth
Huge Fair Low Low Low
comsumed
DDoS, DDoS, DDoS,
Application DDoS DDoS
others others others

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
VI. CONCLUSION
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] H. Aljifri, "IP Traceback: A New Denial-of-Service Deterrent?", IEEE
Security & Privacy, Vol.1, No.3, 2003, pp.24-31.
[2] T. Baba and S. Matsuda, "Tracing Network Attacks to Their Sources",
IEEE Internet Computing, Vol.6, No.3, 2002, pp.20-26.
[3] S. M. Bellovin, "ICMP Traceback Messages", Internet Draft, Network
Working Group, 2000.
[4] 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] A. Binstock and J. Rex, Practical Algorithms for Programmers, Pearson
Education, 1995.
[6] H. Burch and B. Cheswick, "Tracing Anonymous Packets to Their
Approximate Source", Proc. of the 14th Systems Administration
Conference (LISA 2000).
[7] Computer Emergency Response Team, CERT, http://www.cert.org.
[8] 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.
[9] N. G. Duffield and M. Grossglauser, "Trajectory sampling for direct
traffic observation", ACM SIGCOMM 2000, pp.271-282.
[10] B. W. Kernighan and Dennis M. Ritchie, The C Programming
Language, Second Edition, Prentice Hall, 1988.
[11] 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.
[12] 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.
[13] T. Peng, C. Leckie, and R. Kotagiri, "Adjusted Probabilistic Packet
Marking for IP Traceback", Networking 2002.
[14] RFC791, Internet Protocol, DARPA, 1981.
[15] RFC1349, Type of Service in the Internet Protocol Suite, Network
Working Group, 1992.
[16] 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.