Practical Network Support for IP Traceback
Stefan Savage, David Wetherall, Anna Karlin and Tom Anderson
Department of Computer Science and Engineering
University of Washington
Seattle, WA, USA
Abstract
This paper describes a technique for tracing anonymous packet
flooding attacks in the Internet back towards their source. This
work is motivated by the increased frequency and sophistication
of denial-of-service attacks and by the difficulty in tracing packets
with incorrect, or “spoofed”, source addresses. In this paper we
describe a general purpose traceback mechanism based on prob-
abilistic packet marking in the network. Our approach allows a
victim to identify the network path(s) traversed by attack traffic
without requiring interactive operational support from Internet Ser-
vice Providers (ISPs). Moreover, this traceback can be performed
“post-mortem” – after an attack has completed. We present an im-
plementation of this technology that is incrementally deployable,
(mostly) backwards compatible and can be efficiently implemented
using conventional technology.
1. INTRODUCTION
Denial-of-service attacks consume the resources of a remote host or
network, thereby denying or degrading service to legitimate users.
Such attacks are among the hardest security problems to address
because they are simple to implement, difficult to prevent, and
very difficult to trace. In the last several years, Internet denial-
of-service attacks have increased in frequency, severity and sophis-
tication. Howard reports that between the years of 1989 and 1995,
the number of such attacks reported to the Computer Emergency
Response Team (CERT) increased by 50 percent per year [25].
More recently, a 1999 CSI/FBI survey reports that 32 percent of re-
spondents detected denial-of-service attacks directed against their
sites [16]. Even more worrying, recent reports indicate that at-
tackers have developed tools to coordinate distributed attacks from
many separate sites [14].
Unfortunately, mechanisms for dealing with denial-of-service have
not advanced at the same pace. Most work in this area has focused
on tolerating attacks by mitigating their effects on the victim [38,
2, 26, 29, 9]. This approach can provide an effective stop-gap mea-
sure, but does not eliminate the problem nor does it discourage at-
tackers. The other option, and the focus of this paper, is to trace
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SIGCOMM'00, Stockholm, Sweden.
Copyright 2000 ACM 1-58113-224-7/00/0008...$5.00.
attacks back towards their origin – ideally stopping an attacker at
the source.
A perfect solution to this problem is complicated by the potential
use of indirection to “launder” the true causal origin of an attack.
For example, an attack may consist of packets sent from many dif-
ferent slave machines, themselves under the control of a remote
master machine. Such indirection may be achieved either explicitly
(by compromising the individual slave hosts directly) or implicitly
(by sending false requests to the slaves on behalf of the victim –
a so-called reflector). More challenging still, the true origin and
identity of the attacker can be similarly concealed through chains
of false computer accounts, call forwarding, and so forth. Conse-
quently, we regard a complete solution – particularly one able to
address the forensic needs of law enforcement – as an open prob-
lem.
Instead, we address the more limited operational goal of simply
identifying the machines that directly generate attack traffic and
the network path this traffic subsequently follows. We call this the
traceback problem and it is motivated by the operational need to
control and contain attacks. In this setting, even incomplete or ap-
proximate information is valuable because the efficacy of measures
such as packet filtering improve as they are applied further from the
victim and closer to the source.
However, even for our restricted problem, determining the source
generating attack traffic is surprisingly difficult due to the stateless
nature of Internet routing. Attackers routinely disguise their loca-
tion using incorrect, or “spoofed”, IP source addresses. As these
packets traverse the Internet their true origin is lost and a victim is
left with little useful information. While there are several ad hoc
traceback techniques in use, they all have significant drawbacks
that limit their practical utility in the current Internet.
In this paper we present a new approach to the traceback problem
that addresses the needs of both victims and network operators.
Our solution is to probabilistically mark packets with partial path
information as they arrive at routers. This approach exploits the ob-
servation that attacks generally comprise large numbers of packets.
While each marked packet represents only a “sample” of the path
it has traversed, by combining a modest number of such packets a
victim can reconstruct the entire path. This allows victims to locate
the approximate source of attack traffic without requiring the assis-
tance of outside network operators. Moreover, this determination
can be made even after an attack has completed. Both facets of our
solution represent substantial improvements over existing capabili-
ties for dealing with flooding-style denial-of-service attacks.
A key practical deployment issue with any modification of Inter-
net routers is to ensure that the mechanisms are efficiently im-
plementable, may be incrementally deployed, and are backwards
compatible with the existing infrastructure. We describe a trace-
back algorithm that adds little or no overhead to the router's critical
forwarding path and may be incrementally deployed to allow trace-
back within the subset of routers supporting our scheme. Further,
we demonstrate that we can encode the necessary path information
in a way that peacefully co-exists with existing routers, host sys-
tems and more than 99% of today's traffic.
The rest of this paper is organized as follows: In Section 2, we
describe related work concerning IP spoofing and solutions to the
traceback problem. Section 3 outlines our basic approach and sec-
tion 4 characterizes several abstract algorithms for implementing
it. In Section 5 we detail a concrete encoding strategy for our al-
gorithm that can be implemented within the current Internet envi-
ronment. We also present experimental results demonstrating the
effectiveness of our solution. In section 6 we discuss the main lim-
itations and weaknesses of our proposal and potential extensions
to address some of them. Finally, we summarize our findings in
Section 7.
2. RELATED WORK
It has been long understood that the IP protocol permits anonymous
attacks. In his 1985 paper on TCP/IP weaknesses, Morris writes:
“The weakness in this scheme [the Internet Protocol]
is that the source host itself fills in the IP source host
id, and there is no provision in ... TCP/IP to discover
the true origin of a packet.” [31]
In addition to denial-of-service attacks, IP spoofing can be used
in conjunction with other vulnerabilities to implement anonymous
one-way TCP channels and covert port scanning [31, 3, 24, 44].
There have been several efforts to reduce the anonymity afforded
by IP spoofing. Table 1 provides a subjective characterization of
each of these approaches in terms of management cost, additional
network load, overhead on the router, the ability to trace multi-
ple simultaneous attacks, the ability trace attacks after they have
completed, and whether they are preventative or reactive. We also
characterize our proposed traceback scheme according to the same
criteria. In the remainder of this section we describe each previous
approach in more detail.
2.1 Ingress filtering
One way to address the problem of anonymous attacks is to elim-
inate the ability to forge source addresses. One such approach,
frequently called ingress filtering,istoconfigure routers to block
packets that arrive with illegitimate source addresses [20]. This re-
quires a router with sufficient power to examine the source address
of every packet and sufficient knowledge to distinguish between le-
gitimate and illegitimate addresses. Consequently, ingress filtering
is most feasible in customer networks or at the border of Internet
Service Providers (ISP) where address ownership is relatively un-
ambiguous and traffic load is low. As traffic is aggregated from
multiple ISPs into transit networks, there is no longer enough in-
formation to unambiguously determine if a packet arriving on a par-
ticular interface has a “legal” source address. Moreover, on many
deployed router architectures the overhead of ingress filter becomes
prohibitive on high-speed links.
The principal problem with ingress filtering is that its effective-
ness depends on widespread, if not universal, deployment. Un-
fortunately, a significant fraction of ISPs, perhaps the majority, do
not implement this service – either because they are uninformed
or have been discouraged by the administrative burden
1
, potential
router overhead and complications with existing services that de-
pend on source address spoofing (e.g. some versions of Mobile
IP [33] and some hybrid satellite communications architectures). A
secondary problem is that even if ingress filtering were universally
deployed at the customer-to-ISP level, attackers could still forge
addresses from the hundreds or thousands of hosts within a valid
customer network [14].
It is clear that wider use of ingress filtering would dramatically im-
prove the Internet's robustness to denial-of-service attacks. At the
same time it is prudent to assume that such a system will never be
fullproof – and therefore traceback technologies will continue to be
important.
2.2 Link testing
Most existing traceback techniques start from the router closest to
the victim and interactively test its upstream links until they deter-
mine which one is used to carry the attacker's traffic. Ideally, this
procedure is repeated recursively on the upstream router until the
source is reached. This technique assumes that an attack remains
active until the completion of a trace and is therefore inappropriate
for attacks that are detected after the fact, attacks that occur inter-
mittently, or attacks that modulate their behavior in response to a
traceback (it is prudent to assume the attacker is fully informed).
Below we describe two varieties of link testing schemes, input de-
bugging and controlled flooding.
2.2.1 Input debugging
Many routers include a feature called input debugging, that al-
lows an operator to filter particular packets on some egress port
and determine which ingress port they arrived on. This capabil-
ity is used to implement a trace as follows: First, the victim must
recognize that it is being attacked and develop an attack signature
that describes a common feature contained in all the attack pack-
ets. The victim communicates this signature to a network operator,
frequently via telephone, who then installs a corresponding input
debugging filter on the victim's upstream egress port. This filter
reveals the associated input port, and hence which upstream router
originated the traffic. The process is then repeated recursively on
the upstream router, until the originating site is reached or the trace
leaves the ISP's border (and hence its administrative control over
the routers). In the later case, the upstream ISP must be contacted
and the procedure repeats itself. While such tracing is frequently
performed manually, several ISPs have developed tools to automat-
ically trace attacks across their own networks [41].
The most obvious problem with the input debugging approach,
even with automated tools, is its considerable management over-
head. Communicating and coordinating with network operators at
multiple ISPs requires the time, attention and commitment of both
the victim and the remote personnel – many of whom have no di-
rect economic incentive to provide aid. If the appropriate network
1
Some modern routers ease the administrative burden of ingress
filtering by providing functionality to automatically check source
addresses against the destination-based routing tables (e.g. ip
verify unicast reverse-path on Cisco's IOS). This ap-
proach is only valid if the route to and from the customer is sym-
metric – generally at the border of single-homed stub networks.
Management Network Router Distributed Post-mortem Preventative/
overhead overhead overhead capability capability reactive
Ingress filtering Moderate Low Moderate N/A N/A Preventative
Link testing
Input debugging High Low High Good Poor Reactive
Controlled flooding Low High Low Poor Poor Reactive
Logging High Low High Excellent Excellent Reactive
ICMP Traceback Low Low Low Good Excellent Reactive
Marking Low Low Low Good Excellent Reactive
Table 1: Qualitative comparison of existing schemes for combating anonymous attacks and the probabilistic marking approach we
propose.
operators are not available, if they are unwilling to assist, or if they
do not have the appropriate technical skills and capabilities, then a
traceback may be slow or impossible to complete [21].
2.2.2 Controlled flooding
Burch and Cheswick have developed a link testing traceback tech-
nique that does not require any support from network operators [6].
We call this technique controlled flooding because it tests links by
flooding them with large bursts of traffic and observing how this
perturbs traffic from the attacker. Using a pre-generated “map”
of Internet topology, the victim coerces selected hosts along the
upstream route into iteratively flooding each incoming link on the
router closest to the victim. Since router buffers are shared, packets
traveling across the loaded link – including any sent by the attacker
– have an increased probability of being dropped. By observing
changes in the rate of packets received from the attacker, the victim
can therefore infer which link they arrived from. As with other link
testing schemes, the basic procedure is then applied recursively on
the next upstream router until the source is reached.
While the scheme is both ingenious and pragmatic, it has several
drawbacks and limitations. Most problematic among these is that
controlled flooding is itself a denial-of-service attack – exploiting
vulnerabilities in unsuspecting hosts to achieve its ends. This draw-
back alone makes it unsuitable for routine use. Also, controlled
flooding requires the victim to have a good topological map of large
sections of the Internet in addition to an associated list of “willing”
flooding hosts. As Burch and Cheswick note, controlled flooding
is also poorly suited for tracing distributed denial-of-service attacks
because the link-testing mechanism is inherently noisy and it can
be difficult to discern the set of paths being exploited when mul-
tiple upstream links are contributing to the attack. Finally, like all
link-testing schemes, controlled flooding is only effective at tracing
an on-going attack and cannot be used “post-mortem”.
2.3 Logging
An approach suggested in [37] and [41] is to log packets at key
routers and then use data mining techniques to determine the path
that the packets traversed. This scheme has the useful property that
it can trace an attack long after the attack has completed. However,
it also has obvious drawbacks, including potentially enormous re-
source requirements (possibly addressed by sampling) and a large
scale inter-provider database integration problem. We are unaware
of any commercial organizations using a fully operational trace-
back approach based on logging
2
.
2
Historically, the T3-NFSNET did log network-to-network traffic
statistics and these were used on at least one occasion to trace IP
spoofing attacks to an upstream provider [43].
2.4 ICMP Traceback
Since the first writing of this paper, a new traceback proposal bas
emerged based on the use of explicit router-generated ICMP trace-
back messages [4]. The principle idea in this scheme is for every
router to sample, with low probability (e.g., 1/20,000), one of the
packets it is forwarding and copy the contents into a special ICMP
traceback message including information about the adjacent routers
along the path to the destination. During a flooding-style attack,
the victim host can then use these messages to reconstruct a path
back to the attacker. This scheme has many benefits compared to
previous work and is in many ways similar to the packet marking
approach we have taken. However, there are several disadvantages
in the current design that complicate its use. Among these: ICMP
traffic is increasingly differentiated and may be filtered or rate lim-
ited differently from normal traffic, the ICMP Traceback message
relies on an input debugging capability (i.e. the ability to asso-
ciate a packet with the input port and/or MAC address on which
it arrived) that is not available in some router architectures, if only
some of the routers participate it seems difficult to positively “con-
nect” traceback messages from participating routers separated by a
non-participating router, and finally, it requires a key distribution
infrastructure to deal with the problem of attackers sending false
ICMP Traceback messages. That said, we believe that the scheme
is promising and that hybrid approaches combining it with some of
the algorithms we propose are likely to be quite effective.
3. OVERVIEW
Burch and Cheswick mention the possibility of tracing flooding at-
tacks by “marking” packets, either probabilistically or deterministi-
cally, with the addresses of the routers they traverse [6]. The victim
uses the information in the marked packets to trace an attack back
to its source. This approach has not been previously explored in any
depth, but has many potential advantages. It does not require inter-
active cooperation with ISPs and therefore avoids the high manage-
ment overhead of input debugging. Unlike controlled flooding, it
does not require significant additional network traffic and can po-
tentially be used to track multiple attacks. Moreover, like logging,
packet marking can be used to trace attacks “post-mortem” – long
after the attack has stopped. Finally, we have found that marking
algorithms can be implemented without incurring any significant
overhead on network routers. The remainder of this paper focuses
on fully exploring and characterizing this approach.
3.1 Definitions
Figure 1 depicts the network as seen from a victim
V
. For the
purposes of this paper,
V
may be a single host under attack, or a
network border device such as a firewall or intrusion detection sys-
tem that represents many such hosts. Every potential attack origin
A
i
is a leaf in a tree rooted at
V
and every router
R
i
is an internal
R
1
V
R
2
R
3
R
4
R
5
R
6
A
1
A
2
R
7
A
3
Figure 1: Network as seen from the victim of an attack,
V
.
Routers are represented by
R
i
, and potential attackers by
A
i
.
The dotted line represents a particular attack path between an
attacker and the victim.
node along a path between some
A
i
and
V
. The attack path from
A
i
is the unique ordered list of routers between
A
i
and
V
. For in-
stance, if an attack originates from
A
2
then to reach
V
it must first
traverse the path
R
6
,
R
3
,
R
2
, and
R
1
– as shown by the dotted line
in Figure 1.
The exact traceback problem is to determine the attack path and
the associated attack origin for each attacker. However, solving
this problem is complicated by several practical limitations. The
exact attack origin may never be revealed (even MAC source ad-
dresses may be spoofed) and a wily attacker may send false signals
to “invent” additional routers in the traceback path. We address
these issues in section 6, but for now we restrict our discussion to
solving a more limited problem. We define the approximate trace-
back problem as finding a candidate attack path for each attacker
that contains the true attack path as a suffix. We call this the valid
suffix of the candidate path. For example, (
R
5
,
R
6
,
R
3
,
R
2
,
R
1
)is
a valid approximate solution to Figure 1 because it contains the true
attack path as a suffix. We say a solution to this problem is robust
if an attacker cannot prevent the victim from discovering candidate
paths containing the valid suffix.
All marking algorithms have two components: a marking proce-
dure executed by routers in the network and a path reconstruc-
tion procedure implemented by the victim. A router “marks” one
or more packets by augmenting them with additional information
about the path they are traveling. The victim attempts to reconstruct
the attack path using only the information in these marked packets.
The convergence time of an algorithm is the number of packets that
the victim must observe to reconstruct the attack path.
3.2 Basic assumptions
The design space of possible marking algorithms is large, and to
place our work in context we identify the assumptions that motivate
and constrain our design:
an attacker may generate any packet,
multiple attackers may conspire,
attackers may be aware they are being traced,
packets may be lost or reordered,
attackers send numerous packets,
the route between attacker and victim is fairly stable,
routers are both CPU and memory limited, and
routers are not widely compromised.
The first four assumptions represent conservative assessments of
the abilities of the modern attackers and limitations of the network.
Designing a traceback system for the Internet environment is ex-
tremely challenging because there is very little that can be trusted.
In particular, the attacker's ability to create arbitrary packets sig-
nificantly constrains potential solutions. When a router receives a
packet, it has no way to tell whether that packet has been marked
by an upstream router or if the attacker simply has forged this in-
formation. In fact, the only invariant that we can depend on is that
a packet from the attacker must traverse all of the routers between
it and the victim.
The remaining assumptions reflect the basis for our design and de-
serve additional discussion. First, denial-of-service attacks are only
effective so long as they occupy the resources of the victim. Con-
sequently, most attacks are comprised of thousands or millions of
packets. Our approach relies on this property because we mark
each packet with only a small piece of path state and the victim
must observe many such packets to reconstruct the complete path
back the the attacker. If many attacks emerge that require only a
single packet to disable a host (e.g. ping-of-death [11]), then this
assumption may not hold (although we note that even these attacks
require multiple packets to keep a machine down).
Second, measurement evidence suggests that while Internet routes
do change, it is extremely rare for packets to follow many different
paths over the short time-scales of a traceback operation (seconds
in our system) [32]. This assumption greatly simplifies the role of
the victim, since it can therefore limit its consideration to a single
primary path for each attacker. If the Internet evolves to allow sig-
nificant degrees of multi-path routing then this assumption may not
hold.
Third, while there have been considerable improvements in router
implementation technology, link speeds have also increased dra-
matically. Consequently, we assert that any viable implementation
must have low per-packet overhead and must not require per-flow
state. Significantly simpler schemes than ours can be implemented
if we assume that routers are not resource constrained.
Finally, since a compromised router can effectively eliminate any
information provided by upstream routers, it is effectively indis-
tinguishable from an attacker. In such circumstances, the security
violation at the router must be addressed first, before any further
traceback is attempted. In normal circumstances, we believe this
is an acceptable design point. However, if non-malicious, but in-
formation hiding, routing infrastructures become popular, such as
described in [22, 35], then this issue may need to be revisited.
4. BASIC MARKING ALGORITHMS
In this section we describe a series of marking algorithms – starting
from the most simple and advancing in complexity. Each algorithm
attempts to solve the approximate traceback problem in a manner
consistent with our assumptions.
Marking procedure at router
R
:
for each packet
w
, append
R
to
w
Path reconstruction procedure at victim
v
:
for any packet
w
from attacker
extract path (
R
i
..
R
j
) from the suffixof
w
Figure 2: Node append algorithm.
4.1 Node append
The simplest marking algorithm – conceptually similar to the IP
Record Route option [34] – is to append each node's address to the
end of the packet as it travels through the network from attacker to
victim (see Figure 2). Consequently, every packet received by the
victim arrives with a complete ordered list of the routers it traversed
– a built-in attack path.
The node append algorithm is both robust and extremely quick to
converge (a single packet), however it has several serious limita-
tions. Principal among these is the infeasibly high router overhead
incurred by appending data to packets in flight. Moreover, since
the length of the path is not known a priori, it is impossible to
ensure that there is sufficient unused space in the packet for the
complete list. This can lead to unnecessary fragmentation and bad
interactions with services such as MTU discovery [30]. This prob-
lem cannot be solved by reserving “enough” space, as the attacker
can completely fill any such space with false, or misleading, path
information.
4.2 Node sampling
To reduce both the router overhead and the per-packet space re-
quirement, we can sample the path one node at a time instead of
recording the entire path. A single static “node” field is reserved
in the packet header – large enough to hold a single router address
(i.e. 32 bits for IPv4). Upon receiving a packet, each router chooses
to write its address in the node field with some probability
p
. Af-
ter enough packets have been sent, the victim will have received at
least one sample for every router in the attack path. As stated in
section 3, we assume that the attacker sends enough packets and
the route is stable enough that this sampling can converge.
Although it might seem impossible to reconstruct an ordered path
given only an unordered collection of node samples, it turns out that
with a sufficient number of trials, the order can be deduced from the
relative number of samples per node. Since routers are arranged se-
rially, the probability that a packet will be marked by a router and
then left unmolested by all downstream routers is a strictly decreas-
ing function of the distance to the victim. If we constrain
p
to be
identical at each router, then the probability of receiving a marked
packet from a router
d
hops away is
p
(1
;
p
)
d
;
1
. Since this func-
tion is monotonic in the distance from the victim, ranking each
router by the number of samples it contributes will tend to produce
the accurate attack path. The full algorithm is shown in Figure 3.
Putting aside for the moment the difficulty in changing the IP header
to add a 32-bit node field, this algorithm is efficient to implement
because it only requires the addition of a write and checksum up-
date to the forwarding path. Current high-speed routers already
must perform these operations efficiently to update the time-to-live
field on each hop. Moreover, if
p>
0
:
5
then this algorithm is ro-
bust against a single attacker because there is no way for an attacker
to insert a “false” router into the path's valid suffix by contributing
Marking procedure at router
R
:
for each packet
w
let
x
be a random number from [0..1)
if
x<p
then,
write
R
into
w
.node
Path reconstruction procedure at victim
v
:
let
NodeT bl
be a table of tuples (node,count)
for each packet
w
from attacker
z
:= lookup
w
.node in
N odeT bl
if
z
!= NIL then
increment
z
.count
else
insert tuple (
w
.node,1) in
N odeT bl
sort
NodeT bl
by count
extract path (
R
i
..
R
j
) from ordered node fields in
NodeT bl
Figure 3: Node sampling algorithm.
more samples than a downstream router, nor to reorder valid routers
in the path by contributing more samples than the difference be-
tween any two downstream routers.
However, there are also two serious limitations. First, inferring the
total router order from the distribution of samples is a slow process.
Routers far away from the victim contribute relatively few samples
(especially since
p
must be large) and random variability can eas-
ily lead to misordering unless a very large number of samples are
observed. For instance, if
d
=15
and
p
=0
:
51
, the receiver must
receive more than 42,000 packets on average before it receives a
single sample from the furthest router. To guarantee that the order
is correct with 95% certainty requires more than seven times that
number.
Second, if there are multiple attackers then multiple routers may
exist at the same distance – and hence be sampled with the sample
probability. Therefore, this technique is not robust against multiple
attackers.
4.3 Edge sampling
A straightforward solution to these problems is to explicitly encode
edges in the attack path rather than simply individual nodes. To do
this, we would need to reserve two static address-sized fields, start
and end, in each packet to represent the routers at each end of a
link, as well as an additional small field to represent the distance of
an edge sample from the victim.
When a router decides to mark a packet, it writes its own address
into the start field and writes a zero into the distance field. Oth-
erwise, if the distance field is already zero this indicates that the
packet was marked by the previous router. In this case, the router
writes its own address into the end field – thereby representing the
edge between itself and the previous router. Finally, if the router
doesn't mark the packet then it always increments the distance
field. This somewhat baroque signaling mechanism allows edge
sampling to be incrementally deployed – edges are constructed only
between participating routers.
The mandatory increment is critical to minimize spoofing by an
attacker. When the packet arrives at the victim its distance field
represents the number of hops traversed since the edge it contains
