Internet Engineering Task Force                                      IAB
INTERNET-DRAFT                                         Mark
Network Working Group                                    M. Handley (ed)
Internet-Draft                                                       UCL
Expires: November 2004 January 21, 2006                               E. Rescorla (ed)
                                                       Network Resonance
                                                           July 20, 2005

               Internet Denial of Service Considerations

This document
                          draft-iab-dos-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is an Internet-Draft aware
   have been or will be disclosed, and is subject to all provisions any of which he or she becomes
   aware will be disclosed, in accordance with Section 10 6 of RFC2026. BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document provides an overview of possible avenues for denial-of-
   service attack on Internet systems.  The aim is to encourage protocol
   designers and network engineers towards designs that are more robust.
   We discuss partial solutions that reduce the effectiveness of
   attacks, and how some solutions might inadvertently open up
   alternative vulnerabilities.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  An Overview of Denial-of-Service Threats . . . . . . . . . . .  6
     2.1   DoS Attacks on End-systems . . . . . . . . . . . . . . . .  6
       2.1.1   Exploiting Poor Software Quality . . . . . . . . . . .  6
       2.1.2   Application Resource Exhaustion  . . . . . . . . . . .  7
       2.1.3   Operating System Resource Exhaustion . . . . . . . . .  8
       2.1.4   Triggered Lockouts and Quota Exhaustion  . . . . . . .  9
     2.2   DoS Attacks on Routers . . . . . . . . . . . . . . . . . .  9
       2.2.1   Attacks on Routers through Routing Protocols . . . . . 10
       2.2.2   IP Multicast-based DoS Attacks . . . . . . . . . . . . 11
       2.2.3   Attacks on Router Forwarding Engines . . . . . . . . . 12
     2.3   Attacks on Ongoing Communications  . . . . . . . . . . . . 13
     2.4   Attacks using the Victim's Own Resources . . . . . . . . . 14
     2.5   DoS Attacks on Local Hosts or Infrastructure . . . . . . . 14
     2.6   DoS Attacks on Sites though DNS  . . . . . . . . . . . . . 15
     2.7   DoS Attacks on Links . . . . . . . . . . . . . . . . . . . 17
     2.8   DoS attacks on firewalls . . . . . . . . . . . . . . . . . 17
     2.9   DoS attacks on IDS systems . . . . . . . . . . . . . . . . 18
     2.10  DoS attacks on or via NTP  . . . . . . . . . . . . . . . . 18
     2.11  Physical DoS . . . . . . . . . . . . . . . . . . . . . . . 19
     2.12  Social Engineering DoS . . . . . . . . . . . . . . . . . . 19
     2.13  Legal DoS  . . . . . . . . . . . . . . . . . . . . . . . . 19
     2.14  Spam and Black-hole Lists  . . . . . . . . . . . . . . . . 19
   3.  Attack Amplifiers  . . . . . . . . . . . . . . . . . . . . . . 21
     3.1   Methods of Attack Amplification  . . . . . . . . . . . . . 21
     3.2   Strategies to Mitigate Attack Amplification  . . . . . . . 23
   4.  DoS Mitigation Strategies  . . . . . . . . . . . . . . . . . . 24
     4.1   Protocol Design  . . . . . . . . . . . . . . . . . . . . . 24
       4.1.1   Don't Hold State for Unverified Hosts  . . . . . . . . 24
       4.1.2   Make it Hard to Simulate a Legitimate User . . . . . . 24
       4.1.3   Graceful Routing Degradation . . . . . . . . . . . . . 25
       4.1.4   Autoconfiguration and Authentication . . . . . . . . . 26
       4.1.5   Network Design and Configuration . . . . . . . . . . . 26
       4.1.6   Redundancy and Distributed Service . . . . . . . . . . 26
       4.1.7   Authenticate Routing Adjacencies . . . . . . . . . . . 26
       4.1.8   Isolate Router-to-Router Traffic . . . . . . . . . . . 26
     4.2   Router Implementation Issues . . . . . . . . . . . . . . . 27
     4.3   End-System Implementation Issues . . . . . . . . . . . . . 27
       4.3.1   State Lookup Complexity  . . . . . . . . . . . . . . . 27
       4.3.2   Operational Issues . . . . . . . . . . . . . . . . . . 28
   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 29
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
   A.  IAB Members at the time of this writing  . . . . . . . . . . . 36
       Intellectual Property and Copyright Statements . . . . . . . . 37

1.  Introduction

   A Denial-of-Service (DoS) attack is an attack in which one or more
   machines target a victim and attempt to prevent the victim from doing
   useful work.  The victim can be a network server, client or router, a
   network link or an entire network, an individual Internet user or a
   company doing business using the Internet, an Internet Service
   Provider (ISP), country, or any combination of or variant on these.
   Denial of service attacks may involve gaining unauthorized access to
   network or computing resources, but for the most part in this
   document we focus on the cases where the denial-of-service attack
   itself does not involve a compromise of the victim's computing
   facilities.

   Because of the closed context of the original ARPAnet and NSFnet, no
   consideration was given to denial-of-service attacks in the original
   Internet Architecture.  As a result, almost all Internet services are
   vulnerable to denial-of-service attacks of sufficient scale.  In most
   cases, sufficient scale can be achieved by compromising enough end-hosts end-
   hosts (typically using a virus, worm, or remotely controlled "bots")
   or routers, and using those compromised hosts to perpetrate the
   attack.  Such an attack is known as a Distributed Denial of Service
   attack (DDoS).  However, there are also many cases where a single
   well- connected end-system can perpetrate a successful DoS attack.

   This document is intended to serve several purposes:

   o   To highlight possible avenues for attack, and by so doing
   encourage protocol designers and network engineers towards designs
   that are more robust.

   o   To discuss partial solutions that reduce the effectiveness of
   attacks.

   o   To highlight how some partial solutions can be taken advantage of
   by attackers to perpetrate alternative attacks.

   This last point appears to be a recurrent theme in DoS, and
   highlights the lack of proper architectural solutions.  It is our
   hope that this document will help initiate informed debate about
   future architectural solutions that might be feasible and cost-effective cost-
   effective for deployment.

   In addition it is our hope that this document will spur discussion
   leading to architectural solutions that reduce the succeptibility of
   all Internet systems to denial-of-service attacks.

   We note that in principle it is not possible to distinguish between a
   sufficiently subtle DoS attack and a flash-crowd, where unexpected
   heavy but non-malicious traffic has the same effect as a DoS attack.
   Whilst this is true, such malicious attacks are usually more
   expensive to launch than many of the crude attacks that have been
   seen to date.  Thus defending against DoS is not about preventing all
   possible attacks, but rather is largely a question of raising the bar
   sufficiently high for malicious traffic.

   However, it is also important to note that not all DoS problems are
   malicious.  Failed links, flash crowds, misconfigured bots, and
   numerous other causes can result in resource exhaustion problems, and
   so the overall goal should be to be robust to all forms of overload.

2.  An Overview of Denial-of-Service Threats

   In this section we will discuss a wide range of possible DoS attacks.
   This list cannot be exhaustive, but the intent is to provide a good
   overview of the spectrum of possibilities that need to be defended
   against.

   We do not provide descriptions of any attacks that are not already
   publicly well documented.

2.1.

2.1  DoS Attacks on End-systems

   We first discuss attacks on end-systems.  An end-system in this
   context is typically a PC or network server, but it can also include
   any communication endpoint.  For example, a router also is an end-system end-
   system from the point of view of terminating TCP connections for BGP
   [32] or ssh.

2.1.1.

2.1.1  Exploiting Poor Software Quality

   The simplest DoS attacks on end-systems exploit poor software quality
   on the end-systems themselves, and cause that software to simply
   crash.  For example, buffer-overflow attacks might be used to
   compromise the end-system, but even if the buffer-overflow cannot be
   used to gain access, it will usually be possible to overwrite memory
   and cause the software to crash.  Such vulnerabilities can in
   principle affect any software that uses data supplied from the
   network.  Thus not only might a web server be potentially vulnerable,
   but it might also be possible to crash the back-end software (such as
   a database) to which a web server provides data.

   Software crashes due to poor coding not only affect application
   software, but also the operating system kernel itself.  A classic
   example is the so-called "Ping of Death", which became widely known
   in 1996 [10].  This exploit caused many popular operating systems to
   crash when sent a single fragmented ICMP echo request packet whose
   fragments totaled more than the 65535 bytes allowed in an IPv4
   packet.

   While DoS attacks such as the ping-of-death are a significant
   problem, they are not a significant architectural problem.  Once such
   an attack is discovered, the relevant code can easily be patched, and
   the problem goes away.  We should note though that as more and more
   software becomes embedded, it is important not to lose the
   possibility of upgrading the software in such systems.

2.1.2.

2.1.2  Application Resource Exhaustion

   Network applications exist in a context that has finite resources.
   In processing network traffic, such an application uses these
   resources to do its intended task.  However, an attacker may be able
   to prevent the application from performing its intended task by
   causing the application to exhaust the finite supply of a specific
   resource.

   The obvious resources that might be exhausted include:

   o   Available memory.

   o   The CPU cycles available.

   o   The disk space available to the application.

   o   The number of processes or threads or both that the application
   is permitted to use.

   o   The configured maximum number of simultaneous connections the
   application is permitted.

   This list is clearly not exhaustive, but it illustrates a number of
   points.

   Some resources are self-renewing: CPU cycles fall in this category -
   if the attack ceases, more CPU cycles become available.

   Some resources such as disk space require an explicit action to free
   up - if the application cannot do this automatically then the effects
   of the attack may be persistent after the attack has ceased.

   This problem has been understood for many years, and it is common
   practice for logs and incoming email to be stored in a separate disk
   partition (/var) on Unix systems.

   Some resources are constrained by configuration: the maximum number
   of processes and the maximum number of simultaneous connections are
   not normally hard limits, but rather are configured limits.  The
   purpose of such limits is clearly to allow the machine to perform
   other tasks in the event the application misbehaves.  However, great
   care needs to be taken to choose such limits appropriately.  For
   example, if a machine's sole task is to be an ftp server, then
   setting the maximum number of simultaneous connections to be
   significantly less than the machine can service makes the attackers
   job easier.  But setting the limit too high may permit the attacker
   to cause the machine to crash (due to poor OS design in handling
   resource exhaustion) or permit livelock (see below), which are
   generally even less desirable failure modes.

2.1.3.

2.1.3  Operating System Resource Exhaustion

   Conceptually OS resource exhaustion and application resource
   exhaustion are very similar.  However, in the case of application
   resource exhaustion, the operating system may be able to protect
   other tasks from being affected by the DoS attack.  In the case of
   the operating system itself running out of resources, the problem may
   be more catastrophic.

   Perhaps the best-known DoS attack on an operating system is the TCP
   SYN- flood [8], which is essentially a memory-exhaustion attack.  The
   attacker sends a flood of TCP SYN packets to the victim, requesting
   connection setup, but then does not complete the connection setup.
   The victim instantiates state to handle the incoming connections.  If
   the attacker can instantiate state faster than the victim times it
   out, then the victim will run out of memory that it can use to hold
   TCP state, and so it cannot service legitimate TCP connection setup
   attempts.  This issue was exacerbated in some implementations by the
   use of a small dedicated storage space for half-open connections,
   which made the attack easier than it might otherwise have been.  In
   the case of a poorly coded operating system, running out of resources
   may also cause a system crash.

   An alternative TCP DoS attack is the Ack-flood [12], which is
   essentially a CPU exhaustion attack on the victim.  The attacker
   floods the victim with TCP packets pretending to be from connections
   that have never been established.  A busy server that has a large
   number of outstanding connections needs to check which connection the
   packet corresponds to.  Some TCP implementations implemented this
   search rather inefficiently, and so the attacker could use all the
   victim's CPU resources servicing these packets rather than servicing
   legitimate requests.

   We note that strong authentication mechanisms do not mitigate against
   such CPU exhaustion attacks.  In fact poorly designed authentication
   mechanisms using cryptographic methods can exacerbate the problem.
   If such an authentication mechanism allows an attacker to present a
   packet to the victim that requires relatively expensive cryptographic
   authentication before the packet can be discarded, then this makes
   the attacker's CPU exhaustion attack easier.

   CPU exhaustion attacks can be also be exacerbated by poor OS handling
   of incoming network traffic.  In the absence of malicious traffic, an
   ideal OS should behave as follows:

   o   As incoming traffic increases, the useful work done by the OS
   should increase until some resource (such as the CPU) is saturated.

   o   From this point on, as incoming traffic continues to increase the
   useful work done should be constant.

   However, this is often not the case.  Many systems suffer from
   livelock [29] where, after saturation, increasing the load causes a
   decrease in the useful work done.  One cause of this is that the
   system spends an increasing amount of time processing network
   interrupts for packets that will never be processed, and hence a
   decreasing amount of time is available for the application for which
   these packets were intended.

2.1.4.  Attacks on Ongoing Communications

Instead of attacking the end-system itself, it is also possible for an
attacker

2.1.4  Triggered Lockouts and Quota Exhaustion

   Many user-authentication mechanisms attempt to disrupt ongoing communications.  If an attacker can observe
a TCP connection, then it is relatively easy for them to spoof packets
to either reset that connection or to de-synchronize it so that no
further progress can be made [25]. Such protect against
   password guessing attacks are not prevented by
transport or application-level security mechanisms such as TLS [20] or
ssh, because locking the authentication takes place user out after TCP has finished
processing the packets. a small
   number of failed authentications.  If an attacker cannot observe a TCP connection, but can infer that such guess or
   discover a connection exists, it is theoretically possible user's ID, they may be able to reset or
desynchronize that connection by spoofing packets into trigger such a mechanism,
   locking out the connection.
However, this might require an excessively large number of spoofed
packets legitimate user.

   Another way to guess both the port of the active end of the TCP connection
(in most cases the port of the passive end deny service using protection mechanisms is predictable) and the
currently valid TCP sequence numbers.  However, as some operating
systems have poorly implemented predictable algorithms for selecting
either the dynamically selected port or the TCP initial sequence number
[40] [9], then such attacks have been found to be feasible [30]. Advice
as to how cause a
   quota to reduce the vulnerability be exhausted.  This is perhaps most common in the specific case of TCP is
available in [34].
   small web servers being commercially hosted, where the server has a
   contract with the hosting company allowing a fixed amount of traffic
   per day.  An attacker might may be able to significantly reduce the throughput of a
connection by sending spoofed ICMP source quench packets, although most
modern operating systems should ignore such packets.  However, care
should be taken in the design of future transport rapidly exhaust this quota, and signaling
protocols
   cause service to avoid the introduction of similar mechanisms that could be
exploited.

2.1.5.  Attacks using the Victim's Own Resources

Instead of directly overloading the victim, it suspended.  Similar attacks may be possible to cause
   against other forms of quota.

   In the absence of such quotas, if the victim or is charged for their
   network traffic, a machine financial denial-of-service may be possible.

2.2  DoS Attacks on Routers

   Many of the same subnet as denial-of-service attacks that can be launched against
   end- systems can also be launched against the victim to overload
itself.

An example control processor of such an attack is documented in [7], where
   IP router, for example by flooding the attacker
spoofs command and control access
   ports.  In the source address on case of a packet sent router, these attacks may cause the router
   to stall, or may cause the victim's  UDP echo
port.  The source address is that of another machine that is running a
UDP chargen server (a chargen server sends a character pattern back router to cease processing routing
   packets.  Even if the originating source).  The result is router does not stop servicing routing packets,
   it may become sufficiently slow that routing protocols time out.  In
   any of these circumstances, the two machines bounce
packets back and forth as fast as they can, overloading either the
network between them or one consequence of routing failure is not
   only that the end-systems itself.

2.1.6.  Triggered Lockouts and Quota Exhaustion

Many user-authentication mechanisms attempt to protect against password
guessing attacks by locking the user out after a small number of failed
authentications.  If an attacker can guess or discover a user's ID, they
may be able to trigger such a mechanism, locking out the legitimate
user.

Another way to deny service using protection mechanisms is to cause a
quota to be exhausted.  This is perhaps most common in the case of small
web servers being commercially hosted, where the server has a contract
with the hosting company allowing a fixed amount of traffic per day.  An
attacker may be able to rapidly exhaust this quota, and cause service to
be suspended.  Similar attacks may be possible against other forms of
quota.

In the absence of such quotas, if the victim is charged for their
network traffic, a financial denial-of-service may be possible.

2.2.  DoS Attacks on Routers

Many of the denial-of-service attacks that can be launched against end-
systems can also be launched against the control processor of an IP
router, for example by flooding the ssh or telnet ports.  In the case of
a router, these attacks may cause the router to reboot, or may cause the
router to cease processing routing packets.  Even if the router does not
stop servicing routing packets, it may become sufficiently slow that
routing protocols time out.  In any of these circumstances, the
consequence of routing failure is not only that the router ceases router ceases to forward traffic, but also that it
   causes routing protocol churn that may have further side effects.

   An example of such a side effect is caused by BGP route flap damping
   [35], which is intended to reduce global routing churn.  If an
   attacker can cause BGP routing churn, route flap damping may then
   cause the flapping routes to be suppressed [27].  This suppression
   likely causes the networks served by those routes to become
   unreachable.

   A DoS attack on the router control processor might also prevent the
   router being managed effectively.  This may prevent actions being
   taken that would mitigate the DoS attack, and it might prevent
   diagnosis of the cause of the problem.

2.2.1.

2.2.1  Attacks on Routers through Routing Protocols

   In addition to their roles as end-systems, most routers run dynamic
   routing protocols.  The routing protocols themselves can be used to
   stage a DoS attack on a router or a network of routers.  To inject
routing information into a routing protocol, an attacker needs access
either  This
   requires the ability to a router or to a end-host on a subnet where a routing protocol
is running.  In the latter case, if send traffic from addresses which might
   plausibly have generated the relevant routing protocol running on that
subnet messages, which is not authenticated, the end-host may be able to insert spoofed
   somewhat difficult with interior routing information or pretend to be a router. protocols but fairly easy
   with e.g., eBGP.

   The simplest attack on a network of routers is to overload the
   routing table with sufficiently many routes that the router runs out
   of memory, or the router has insufficient CPU power to process the
   routes [15].  We note that depending on the distribution and
   capacities of various routers around the network, such an attack
   might not overwhelm routers near to the attacking router, but might
   cause problems to show up elsewhere in the network.

   Some routing protocols allow limits to be configured on the maximum
   number of routes to be heard from a neighbor [17].  However, if such a
limit doesn't block limits
   often make the spoofed routes at source, then imposition of
such a limit elsewhere in problem worse rather than better, by making it
   possible for the network might cause attacker to push out legitimate routes to
be dropped. with spoofed
   routes, thus creating an an easy form of DoS attack.

   An alternative attack is to overload the routers on the network by
   creating sufficient routing table churn that routers are unable to
   process the changes.  Many routing protocols allow damping factors to
   be configured to avoid just such a problem.  However, as with table
   size, such a threshold applied inconsistently may allow the spoofed
   routes to merge with legitimate routes before the mechanism is
   applied, causing legitimate routes to be damped.

   The simplest routing attack on a specific destination is for an
   attacker to announce a spoofed desirable route to that destination.
   Such a route might be desirable because it has low metric, or because
   it is a more specific route than the legitimate route.  In any event,
   if the route is believed it will cause traffic for the victim to be
   drawn towards the attacking router, where it will typically be
   discarded.

   A more subtle denial-of-service attack might be launched against a
   network rather than against a destination.  Under some circumstances,
   the propagation of inconsistent routing information can cause traffic
   to loop.  If an attacker can cause this to happen on a busy path, the
   looping traffic might cause significant congestion, as well as not
   reaching the legitimate destination.  However in many cases severe
congestion is unlikely because TCP's congestion control will shut down
the majority of traffic that fails to reach the destination.

If an attacker has access to a host on the same subnet as a router
running certain routing protocols, even if that router is configured not
to accept routes, it might be possible to cause that router to run out
of memory by spoofing the existence of fake routers on that subnet.

   In the past there have been cases where different generations of
   routers interpreted a routing protocol specification differently.  In
   particular, BGP specifies that in the case of an error, the BGP
   peering should be dropped.  However, if some of the routers in a
   network treat a particular route as valid and other routes treat the
   route as invalid, then it may be possible to inject a BGP route at
   one point in the Internet and cause peerings to be dropped at many
   other places in the Internet.  Unlike many of the examples above,
   while such an issue might be a serious short-term problem, this is
   not a fundamental architectural problem.  Once the problem is
   understood, deploying patched routing code can permanently solve the
   issue.

2.2.2.

2.2.2  IP Multicast-based DoS Attacks

   There are essentially two forms of IP multicast: "traditional" IP
   multicast (ASM), as specified in RFC 1112 [19] where multiple sources
   can send to the same multicast group, and source-specific multicast
   (SSM) where the receiver must specify both the IP source address and
   the group address.  The two forms of multicast provide rather
   different DoS possibilities.

   With ASM, an attacker can simply send to multiple multicast groups.
   Routing protocols such as PIM-SM [21], MSDP [28] and DVMRP [38] then
   have to instantiate routing state to ensure that the traffic goes to
   the group receivers and not to non-receivers.  Thus ASM is
   particularly vulnerable to DoS attacks causing both multicast routing
   table explosion (and hence control processor memory exhaustion) and
   multicast forwarding table exhaustion (and hence forwarding card
   memory exhaustion or thrashing).

   ASM also permits an attacker to send traffic to the same group as
   legitimate traffic, potentially causing network congestion and
   denying service to the legitimate group.

   However, unlike unicast traffic, it is comparatively difficult to
   spoof source addresses for IP multicast traffic.  Most deployed IP
   multicast routing protocols use reverse-path checks to build the
   forwarding tree, and so multicast attackers are easily located.  In
   addition, multicast traffic will only continue to flow to a receiver
   as long as the receiver joins the multicast group.  Thus it may be
   harder to use multicast traffic to cause a denial-of-service attack
   on a destination - an attacker would need to be opportunistic,
   sending traffic to a multicast group that is already being received
   by the victim or another host located close to the victim.

   SSM does not permit senders to send to arbitrary groups unless a
   receiver has requested the traffic.  Thus sender-based attacks on
   multicast routing state are not possible with SSM.  However, as with
   ASM, a receiver can still join a large number of multicast groups
   causing routers to hold a large amount of multicast routing state,
   potentially causing memory exhaustion and hence denial-of-service to
   legitimate traffic.

   With IPv6, hosts are required to send ICMP Packet Too Big or
   Parameter Problem messages under certain circumstances, even if the
   destination address is a multicast address.  If the attacker can
   place himself in the appropriate position in the multicast tree, a
   packet with an unknown but mandatory Destination Option, for
   instance, could generate a very large number of responses to the
   claimed sender.

   With IPv4 the same problem exists with multicast ICMP Echo Request
   packets, but these are somewhat easier to filter.

2.2.3.

2.2.3  Attacks on Router Forwarding Engines

   Router vendors implement many different mechanisms for packet
   forwarding, but broadly speaking they fall into two categories: ones
   that use a forwarding cache, and ones that do not.  With a forwarding
   cache, the forwarding engine does not hold the full routing table,
   but rather holds just the currently active subset of the forwarding
   table.

Routers or switches using

   Many modern routers use a loosely coupled architecture, where one or
   more control processors handle the routing protocols, and communicate
   over an internal network link to special-purpose forwarding cache are potentially vulnerable
if engines,
   which actually forward the data traffic.  In such architectures it
   may be possible for an attacker can send many packets to different destinations through overwhelm the same router, causing communications link
   between the control processor and the forwarding cache to thrash.  One effect of
this is likely to be that legitimate traffic engine.  This is dropped because the
cache entry has been lost and takes time to reinstate.  Another possible

effect is that the control traffic caused by the forwarding engine
attempting to refresh the cache causes overload of the control processor
(and potentially causes routing adjacencies to be dropped).  In
practice, this is only an issue if the forwarding engine does not have
sufficient space for the full routing table.  Even then such attacks may
be difficult to perpetrate if the intended victim is not close to the
attacker.  In other cases such an effect would normally only be seen in
the presence of a worm that manages to compromise a very large number of
hosts, and then scans widely in its attempt to propagate further.

Many modern routers use a loosely coupled architecture, where one or
more control processors handle the routing protocols, and communicate
over an internal network link to special-purpose forwarding engines,
which actually forward the data traffic.  In such architectures it may
be possible for an attacker to overwhelm the communications link between
the control processor and the forwarding engine.  This is possible
   possible because the forwarding engines support very high speed
   links, and the control processor simply cannot handle a similar rate
   of traffic.

   There may be many ways in which an attacker can trigger communication
   between the forwarding engines and the control processor.  The
   simplest way is for the attacker to simply send to the router's IP
   address, but this should in principle be relatively easy to prevent
   using filtering on the forwarding engines.  Another way might be to
   cause the router to forward data packets using the "slow path".  This
   involves sending packets that require special attention from the
   forwarding router; if the forwarding engine is not smart enough to
   perform such forwarding, then it will typically pass the packet to
   the control processor.  In a router using a forwarding cache, it may
   be possible to overload the internal communications by thrashing the
   forwarding cache.  Finally, any form of data-triggered communication
   between the forwarding engine and the control processor might cause
   such a problem.  Certain multicast routing protocols including PIM-SM
   contain many such data triggered events that could potentially be
   problematic.

   The effects of overloading such internal communications are hard to
   predict, and very implementation-dependent.  One possible effect
   might be that the forwarding table in the forwarding engine gets out
   of synchronization with the routing table in the control processor
   that reflects what the routing protocols believe is happening.  This
   might cause traffic to be dropped or to loop.

   Finally, if an attacker can generate traffic that causes a router to
install
   auto-install access control list (ACL) entries, perhaps by triggering
   a response from an intrusion detection system, then it may be
   possible to exhaust the hardware ACL resources on the router.  This might
   prevent future attacks from being filtered, or worse, cause ACL
   processing to be handled by the route processor.

2.3.  DoS

2.3  Attacks on Local Hosts or Infrastructure

There are a number Ongoing Communications

   Instead of attacks that might only be performed by a local
attacker.

An attacking the end-system itself, it is also possible for
   an attacker with access to a subnet may be able to prevent other local
hosts from accessing the network at all by simply exhausting the address
pool allocated by disrupt ongoing communications.  If an attacker can
   observe a DHCP server.  This requires being able TCP connection, then it is relatively easy for them to
   spoof the
MAC address of an ethernet or wireless card, but this is quite feasible
with certain hardware and operating systems.

An alternative DHCP-based attack is simply to respond faster than the
legitimate DHCP server, and packets to give out an address either reset that is not useful to
the victim.

These sorts of bootstrapping attacks tend connection or to de-synchronize it
   so that no further progress can be difficult to avoid made [25].  Such attacks are not
   prevented by transport or application-level security mechanisms such
   as TLS [20] or ssh, because most of the time trust relationships are established authentication takes place after IP
communication TCP
   has already been established.

Similar attacks are possible through ARP spoofing [4]; finished processing the packets.

   If an attacker cannot observe a TCP connection, but can
respond to ARP requests before the victim and prevent traffic from
reaching the victim.  Some brands of ethernet switch allow an even
simpler attack - simply send from the victim's MAC address, and the
switch will redirect traffic destined for the victim to the attacker's
port.

It may be infer that
   such a connection exists, it is theoretically possible to cause broadcast storms [4] on a local LAN reset or
   desynchronize that connection by
sending a stream spoofing packets into the
   connection.  However, this might require an excessively large number
   of unicast IP spoofed packets to guess both the broadcast MAC address -
some hosts on port of the LAN may then attempt to forward active end of the packets to
   TCP connection (in most cases the
correct MAC address greatly amplifying port of the traffic on passive end is
   predictable) and the LAN.

802.11 wireless networks provide many opportunities to deny service to
other users.  Unless encryption is enabled, it is trivial to announce currently valid TCP sequence numbers.  However,
   as some operating systems have poorly implemented predictable
   algorithms for selecting either the presence of a basestation (or even of an ad-hoc mode host) with dynamically selected port or the
same network name (SSID)
   TCP initial sequence number [40] [9], then such attacks have been
   found to be feasible [30].  Advice as to how to reduce the legitimate basestation.  Even adding
authentication and encryption a la 802.1X and 802.11i may not help much
   vulnerability in this respect. The SSID space the specific case of TCP is unmanaged, so everyone's free available in [34].

   An attacker might be able to put
anything they want significantly reduce the throughput of a
   connection by sending spoofed ICMP source quench packets, although
   most modern operating systems should ignore such packets.  However,
   care should be taken in the SSID field.  Most host stacks don't deal
gracefully with this.

Some 802.11 basestations have limited memory for design of future transport and signaling
   protocols to avoid the number introduction of
associations they can support.  If this is exceeded, they may drop all
associations.

Finally, as similar mechanisms that could
   be exploited.

2.4  Attacks using the authentication in 802.11 takes place at a comparatively
high level in Victim's Own Resources

   Instead of directly overloading the stack, victim, it is may be possible to simply deauthenticate or
disassociate
   cause the victim from or a machine on the basestation, even if WEP is in use
[26]. Bellardo and Savage [3] describe some simple remedies that reduce same subnet as the effectiveness victim to
   overload itself.

   An example of such attacks.

What all these attacks have in common an attack is that they exploit
vulnerabilities documented in [7], where the link auto-configuration mechanisms.  Such
problems are hard to solve because attacker
   spoofs the reason for source address on a packet sent to the existence of such
autoconfiguration mechanisms victim's  UDP echo
   port.  The source address is ease that of use, and another machine that is running
   a UDP chargen server (a chargen server sends a character pattern back
   to secure the originating source).  The result is that the two machines
   bounce packets back and forth as fast as they can, overloading either
   the network between them requires
some form or one of authentication at a sufficiently early place in the
autoconfiguration process.

2.4. end-systems itself.

2.5  DoS Attacks on Sites though DNS

In today's Internet, DNS is Local Hosts or Infrastructure

   There are a number of sufficient importance attacks that if might only be performed by a local
   attacker.

   An attacker with access to a
site's DNS servers is denied, subnet may be able to prevent other
   local hosts from accessing the site is effectively unreachable, even
if there network at all by simply exhausting
   the address pool allocated by a DHCP server.  This requires being
   able to spoof the MAC address of an ethernet or wireless card, but
   this is no actual communication problem quite feasible with certain hardware and operating systems.

   An alternative DHCP-based attack is simply to respond faster than the site itself.

Many of
   legitimate DHCP server, and to give out an address that is not useful
   to the victim.

   These sorts of bootstrapping attacks on end-systems described above can tend to be perpetrated on
DNS servers.  As servers go, DNS servers are not particularly vulnerable difficult to DoS.  So long as a DNS server avoid
   because most of the time trust relationships are established after IP
   communication has sufficient memory, a modern host already been established.

   Similar attacks are possible through ARP spoofing [4]; an attacker
   can usually respond very rapidly to DNS ARP requests for which it is
authoritative.  This was demonstrated in October 2002 when before the root
nameservers were subjected to a very large DoS attack [36]. A number victim and prevent traffic
   from reaching the victim.  Some brands of ethernet switch allow an
   even simpler attack - simply send from the root nameservers have since been replicated using anycast [1] to
further improve their resistance to DoS.  However it is important for
authoritative servers to have relaying disabled, or it is possible victim's MAC address, and
   the switch will redirect traffic destined for
an attacker to force the DNS servers victim to hold state [39].

Many of the routing attacks can also
   attacker's port.

   It may be used against DNS servers possible to cause broadcast storms [4] on a local LAN by
targeting the routing for the server.  If
   sending a stream of unicast IP packets to the DNS server is co-located
with broadcast MAC address -
   some hosts on the site for which is authoritative, LAN may then attempt to forward the fact that packets to the DNS
server is also unavailable of secondary importance.  However, if all
   correct MAC address greatly amplifying the
DNS servers are made unavailable, this may cause email traffic on the LAN.

   802.11 wireless networks provide many opportunities to that site deny service
   to
bounce rather than being stored while the mail servers are unreachable,
so distribution of DNS server locations other users.  Unless encryption is important.

Causing network congestion on links to and from a DNS server can have
similar effects to end-system attacks or routing attacks, causing DNS to
fail to obtain an answer, and effectively denying access to the site
being served.

We note that if an attacker can deny external access enabled, it is trivial to all
   announce the DNS for presence of a site, this will not only cause email to that site to be dropped, but
will also cause email from that site to be dropped.  This is because
recent versions basestation (or even of mail transfer agents such an ad-hoc mode
   host) with the same network name (SSID) as sendmail will drop email
if the mail originates from legitimate
   basestation.  Even adding authentication and encryption a domain that does la 802.1X
   and 802.11i may not exist.  This help much in this respect.  The SSID space is a
classic example
   unmanaged, so everyone's free to put anything they want in the SSID
   field.  Most host stacks don't deal gracefully with this.

   Some 802.11 basestations have limited memory for the number of unexpected consequences.  Sendmail performs this
check as an anti-spam measure, and spam itself
   associations they can be viewed support.  If this is exceeded, they may drop
   all associations.

   Finally, as a form

of DoS attack.  Thus defending against one DoS attack opens up the
vulnerability that allows another DoS attack.

Finally, authentication in 802.11 takes place at a data corruption attack
   comparatively high level in the stack, it is possible if a site's nameserver is
permitted to relay requests simply
   deauthenticate or disassociate the victim from untrusted third parties [39]. The
attacker issues a query for the data he wishes to corrupt, basestation, even
   if WEP is in use [26].  Bellardo and the
victim's nameserver relays the request to the authoritative nameserver.
The request contains a 16-bit ID Savage [3] describe some simple
   remedies that is used to match up the response
with reduce the request.  If effectiveness of such attacks.

   What all these attacks have in common is that they exploit
   vulnerabilities in the attacker spoofs sufficient response packets
from link auto-configuration mechanisms.  Such
   problems are hard to solve because the authoritative nameserver just before reason for the official response will
arrive, each containing a forged response existence of
   such autoconfiguration mechanisms is ease of use, and to secure them
   requires some form of authentication at a different sufficiently early place in
   the autoconfiguration process.

2.6  DoS Attacks on Sites though DNS

   In today's Internet, DNS ID, then
there is a reasonable chance that one of the forged responses will have
the correct sufficient importance that if access
   to a site's DNS ID.  The incorrect data will then be believed and cached
by servers is denied, the victim's nameserver, so giving site is effectively
   unreachable, even if there is no actual communication problem with
   the incorrect response to future
queries.  The probability site itself.

   Many of the attack attacks on end-systems described above can further be increased if the
attacker issues many different requests for the same data with different perpetrated
   on DNS IDs, because many nameserver implementations will the issue relayed
requests with different servers.  As servers go, DNS IDs, and so the response only has to match
any one of these request IDs [6] [33].

2.5.  DoS Attacks on Links

The simplest DoS attack is servers are not particularly
   vulnerable to simply send enough non-congestion-
controlled traffic that DoS.  So long as a link becomes excessively congested, and
legitimate traffic suffers unacceptably high packet loss.

Under some circumstances the effect of such DNS server has sufficient memory, a link DoS
   modern host can be much more
extensive.  We have already discussed the effects of denying access usually respond very rapidly to a DNS server.  Congesting a link might also cause requests for
   which it is authoritative.  This was demonstrated in October 2002
   when the root nameservers were subjected to a routing protocol very large DoS attack
   [36].  A number of the root nameservers have since been replicated
   using anycast [1] to
drop further improve their resistance to DoS.
   However it is important for authoritative servers to have relaying
   disabled, or it is possible for an adjacency if sufficient routing packets are lost, potentially
greatly amplifying attacker to force the effects DNS servers
   to hold state [39].

   Many of the attack.  Good router
implementations will prioritize routing attacks can also be used against DNS servers by
   targeting the transmission of routing packets, but
this is not a total panacea. for the server.  If routers the DNS server is co-
   located with the site for which is authoritative, then the fact that
   the DNS server is also unavailable of secondary importance.  However,
   if all the DNS servers are peered across a shared
medium such as ethernet, it made unavailable, this may be possible cause email to congest the medium
sufficiently
   that routing packets are still lost.

Even if a link DoS does not cause routing packets to be lost, it may
prevent remote access site to a router using ssh or SNMP.  This might make
the router unmanageable, or prevent the attack bounce rather than being correctly
diagnosed.

The prioritization of routing packets can itself cause a DoS problem.
If stored while the attacker can cause a large amount mail servers
   are unreachable, so distribution of routing flux, it may be
possible for DNS server locations is
   important.

   Causing network congestion on links to and from a router DNS server can have
   similar effects to send end-system attacks or routing packets at a high enough rate that
normal traffic is attacks, causing DNS
   to fail to obtain an answer, and effectively excluded.  This is however unlikely except
on low bandwidth links.

Finally, it may be possible denying access to the
   site being served.

   We note that if an attacker to can deny external access to a link by
causing the router to generate sufficient monitoring or report traffic
that all the link is filled.  SNMP traps are one possible vector DNS
   for such an
attack, as they are a site, this will not normally congestion controlled.

2.6.  DoS attacks on firewalls

Firewalls are intended only cause email to defend the systems behind them against attack.
In that they restrict the traffic that can reach those systems, they may
also aid in defending against denial-of-service attacks.  However, under
some circumstances the firewall itself may site to be
   dropped, but will also cause email from that site to be used dropped.
   This is because recent versions of mail transfer agents such as
   sendmail will drop email if the mail originates from a weapon in a
DoS attack.

There are many different types domain that
   does not exist.  This is a classic example of firewall, but generally speaking they
fall into stateful unexpected
   consequences.  Sendmail performs this check as an anti-spam measure,
   and stateless classes.  The state here refers to
whether the firewall holds state for the active flows traversing the
firewall.  Stateless firewalls generally spam itself can only be attacked by
attempting to exhaust the processing resources viewed as a form of DoS attack.  Thus
   defending against one DoS attack opens up the firewall.
Stateful firewalls can be attacked by sending traffic vulnerability that causes the
firewall
   allows another DoS attack.

   Finally, a data corruption attack is possible if a site's nameserver
   is permitted to hold excessive state or state which has pathological
structure.

In the case of excessive state, relay requests from untrusted third parties [39].
   The attacker issues a query for the firewall simply runs out of memory, data he wishes to corrupt, and can no longer instantiate
   the state required to pass legitimate
flows.  Most firewalls will then fail closed, causing denial-of-service victim's nameserver relays the request to the systems behind authoritative
   nameserver.  The request contains a 16-bit ID that is used to match
   up the firewall.

In response with the case of pathological structure, request.  If the attacker sends traffic that
causes spoofs sufficient
   response packets from the firewall's data structures to exhibit worst case behaviour.
An example of this would be when authoritative nameserver just before the firewall uses hash tables to look
up forwarding state,
   official response will arrive, each containing a forged response and
   a different DNS ID, then there is a reasonable chance that one of the attacker can predict the hash function
used.
   forged responses will have the correct DNS ID.  The attacker may incorrect data
   will then be able believed and cached by the victim's nameserver, so
   giving the incorrect response to cause a large amount future queries.  The probability of flow
state to hash to
   the attack can further be increased if the attacker issues many
   different requests for the same bucket, which causes data with different DNS IDs, because
   many nameserver implementations will the firewall's lookup
performance to change from O(1) to O(n), where n is issue relayed requests with
   different DNS IDs, and so the number response only has to match any one of flows
the
   these request IDs [6] [33].  The use of anycast for DNS services
   makes it even more vulnerable to spoofing attacks.  An attacker who
   can instantiate [18]. Thus convince the attacker can cause
forwarding performance ISP to degrade accept an anycast route to the point where service his fake DNS
   server can arrange to receive requests and generate fake responses.

2.7  DoS Attacks on Links

   The simplest DoS attack is
effectively denied to the simply send enough non-congestion-
   controlled traffic that a link becomes excessively congested, and
   legitimate traffic traversing suffers unacceptably high packet loss.

   Under some circumstances the firewall.

2.7. effect of such a link DoS attacks on IDS systems

Intrusion detection systems (IDS) suffer from similar problems to
firewalls.  It may can be possible for an attacker to cause much
   more extensive.  We have already discussed the IDS to
exhaust its available processing power, to run out effects of memory, or denying
   access to
instantiate state with pathological structure.  Unlike a firewall, an
IDS will normally fail open, which will not deny service DNS server.  Congesting a link might also cause a routing
   protocol to drop an adjacency if sufficient routing packets are lost,
   potentially greatly amplifying the systems
protected by the IDS.  However it may mean that subsequent attacks that effects of the IDS would have detected attack.  Good
   router implementations will be missed.

Some IDSs are reactive; that is on detection prioritize the transmission of routing
   packets, but this is not a hostile event they
react to block subsequent traffic from the hostile system, or to
terminate an ongoing connection from that system.  It total panacea.  If routers are peered
   across a shared medium such as ethernet, it may be possible
for an attacker to spoof packets from a legitimate system, and hence
cause
   congest the IDS to believe medium sufficiently that system is hostile.  The IDS will then routing packets are still lost.

   Even if a link DoS does not cause traffic from the legitimate system routing packets to be blocked, hence denying
service lost, it may
   prevent remote access to it.  The effect can be particularly bad if the legitimate
system is a router, DNS server, router using ssh or other system whose performance is
essential for SNMP.  This might make
   the operation router unmanageable, or prevent the attack being correctly
   diagnosed.

   The prioritization of routing packets can itself cause a DoS problem.
   If the attacker can cause a large number amount of other systems.

2.8.  DoS attacks on or via NTP

Network time servers are generally not considered security-critical
services, but under some circumstances NTP servers might routing flux, it may be used to
perpetrate
   possible for a DoS attack.

The most obvious such attack is to DoS the NTP servers themselves.  Many
end systems have rather poor clock accuracy and so, without access router to
network time, their clock will naturally drift.  This can cause problems
with distributed systems send routing packets at a high enough rate
   that rely normal traffic is effectively excluded.  This is however
   unlikely except on good clocks.  For example one
commonly used revision control system can fail if low bandwidth links.

   Finally, it perceives the
modification timestamp to be in the future.

If the NTP servers relied on by a host can be subverted, either through
compromising or impersonating them, then the attacker may be able possible to
control an attacker to deny access to a link
   by causing the host's system clock.  This can cause many unexpected
consequences, including router to generate sufficient monitoring or report
   traffic that the premature expiry of dated resources link is filled.  SNMP traps are one possible vector
   for such an attack, as
encryption or authentication keys.  This in turn can prevent they are not normally congestion controlled.

   Attackers with physical access to
other more critical services.

2.9.  Physical multiple access links can easily
   bring down the link.  This is particularly easy to mount and
   difficult to counter with wireless networks [

2.8  DoS

The discussion thus far has centered on denial-of-service attacks
perpetrated using on firewalls

   Firewalls are intended to defend the network.  However, computer systems are only as
resilient as behind them against
   attack.  In that they restrict the weakest link.  It traffic that can reach those
   systems, they may also aid in defending against denial-of-service
   attacks.  However, under some circumstances the firewall itself may
   also be easier to deny service by
causing used as a power failure, by cutting network cables, or by simply
switching weapon in a system off, and so physical security is at least as
important as network security.

2.10.  Social Engineering DoS attack.

   There are many different types of firewall, but generally speaking
   they fall into stateful and stateless classes.  The weakest link may also be human.  In defending against DoS, state here refers
   to whether the
possibility of denial-of-service through social engineering should not firewall holds state for the active flows traversing
   the firewall.  Stateless firewalls generally can only be neglected, such as convincing an employee attacked by
   attempting to make a configuration
change that prevents normal operation.

2.11.  Legal DoS

Computer systems cannot be considered in isolation from exhaust the social and
legal systems in which they operate.  This document focuses primarily on processing resources of the technical issues, but we note that "cease and desist" letters,
government censorship, and other legal mechanisms also touch on denial-
of-service issues.

2.12.  Spam and Black-hole Lists

Unsolicited commercial email, also known as "spam", firewall.
   Stateful firewalls can effectively
cause denial-of-service be attacked by sending traffic that causes the
   firewall to email systems.  While hold excessive state or state which has pathological
   structure.

   In the intent is not
denial-of-service, case of excessive state, the large amount firewall simply runs out of unwanted mail
   memory, and can waste no longer instantiate the
recipient's time, or cause legitimate email state required to pass
   legitimate flows.  Most firewalls will then fail closed, causing
   denial-of-service to be noticed
amongst all the background noise.  If spam filtering software is used,
some level systems behind the firewall.

   In the case of false positives is to be expected, and so these messages
are effectively denied service.

One mechanism to reduce spam is pathological structure, the use of black-hole lists.  The IP
addresses of dial-up ISPs or mail servers used to originate or relay
spam are added attacker sends traffic
   that causes the firewall's data structures to black-hole lists.  The recipients exhibit worst case
   behaviour.  An example of mail choose this would be when the firewall uses hash
   tables to
consult these lists look up forwarding state, and reject spam if it originates or is relayed by
systems on the list.  One significant problem with such lists is that it attacker can predict the
   hash function used.  The attacker may then be possible for an attacker able to cause a victim large
   amount of flow state to hash to be black-hole
listed, even if the victim was not responsible for relaying spam.  Thus same bucket, which causes the black-hole list itself can be a mechanism for effecting a DoS
attack.  Note that every black-hole list has its own policy regarding
additions, and some are less susceptible to this DoS attack than others.
Consumers of black-hole list technology are advised
   firewall's lookup performance to investigate these
policies before they subscribe.

3.  Attack Amplifiers

Many of the attacks described above rely on sending sufficient traffic change from O(1) to overwhelm the victim.  Such attacks are made much easier by O(n), where n is
   the
existence number of "attack amplifiers", where an flows the attacker can send traffic
from the spoofed source address of instantiate [18].  Thus the victim and
   attacker can cause larger responses forwarding performance to be returned degrade to the victim.  A detailed discussion of such reflection
attacks can be found in [31].

The simplest such attack was the "smurf" attack [11], point
   where an ICMP echo
request packet with the spoofed source address of the victim service is sent effectively denied to the subnet-broadcast address of a network legitimate traffic
   traversing the firewall.

2.9  DoS attacks on IDS systems

   Intrusion detection systems (IDS) suffer from similar problems to
   firewalls.  It may be used as an amplifier.
Every system on that subnet then responds with possible for an ICMP echo response
that returns attacker to cause the victim.  Smurf attacks are no longer such a serious
problem, as these days routers usually drop such packets and end-systems
do not respond IDS to them.

An alternative form of attack amplifier is typified by a DNS reflection
attack.  An attacker sends a DNS request
   exhaust its available processing power, to a DNS server requesting
resolution run out of memory, or to
   instantiate state with pathological structure.  Unlike a domain name.  Again the source address of the request is firewall, an
   IDS will normally fail open, which will not deny service to the spoofed address of
   systems protected by the victim.  The request is carefully chosen so IDS.  However it may mean that subsequent
   attacks that the size of the response IDS would have detected will be missed.

   Some IDSs are reactive; that is significantly greater than the size on detection of
the request, thereby providing the amplification.  As an aside, it is
interesting a hostile event they
   react to note that block subsequent traffic from the largest DNS responses tend hostile system, or to
   terminate an ongoing connection from that system.  It may be those
incorporating DNSsec authentication information.  This attack amplifier
can only be used by possible
   for an attacker with the ability to spoof packets from a legitimate system, and hence
   cause the source
address of the victim.  However, we note IDS to believe that if the victim's DNS server system is configured to relay requests hostile.  The IDS will then
   cause traffic from external clients, it may be
possible the legitimate system to cause it be blocked, hence denying
   service to congest its own incoming network link.

Another variant of attack amplifier involves amplification through
retransmission.  This is typified by a TCP amplification attack known as
"bang.c". it.  The attacker sends effect can be particularly bad if the legitimate
   system is a spoofed TCP SYN with router, DNS server, or other system whose performance is
   essential for the source address operation of the victim a large number of other systems.

2.10  DoS attacks on or via NTP

   Network time servers are generally not considered security-critical
   services, but under some circumstances NTP servers might be used to
   perpetrate a arbitrary TCP server. DoS attack.

   The server will respond with a
SYN|ACK which most obvious such attack is sent to DoS the victim, NTP servers themselves.
   Many end systems have rather poor clock accuracy and when no final ACK is received so, without
   access to complete the handshake, the SYN|ACK network time, their clock will be retransmitted a number of
times.  Typically this attack uses a very large list of arbitrarily
chosen servers as reflectors. naturally drift.  This can
   cause problems with distributed systems that rely on good clocks.
   For example one commonly used revision control system can fail if it
   perceives the attack modification timestamp to be successful, in the
reflector must not receive future.

   If the NTP servers relied on by a RST from host can be subverted, either
   through compromising or impersonating them, then the victim in response attacker may be
   able to control the
SYN|ACK - however if the attack traffic sufficiently overwhelms host's system clock.  This can cause many
   unexpected consequences, including the
server premature expiry of dated
   resources such as encryption or authentication keys.  This in turn
   can prevent access link to other more critical services.

2.11  Physical DoS

   The discussion thus far has centered on denial-of-service attacks
   perpetrated using the server, then packet loss will ensure that
many reflectors do not receive a RST in response network.  However, computer systems are only as
   resilient as the weakest link.  It may be easier to their SYN|ACK, deny service by
   causing a power failure, by cutting network cables, or by simply
   switching a system off, and so continue to retransmit. physical security is at least as
   important as network security.

2.12  Social Engineering DoS

   The attack can weakest link may also be exacerbated by firewalls
that silently drop human.  In defending against DoS, the incoming SYN|ACK without sending a RST.

Care must also
   possibility of denial-of-service through social engineering should
   not be taken with services that relay requests.  If neglected, such as convincing an
attacker can send a request employee to make a proxy, and
   configuration change that proxy now attempts to
connect to a victim whose address is chosen by prevents normal operation.

2.13  Legal DoS

   Computer systems cannot be considered in isolation from the attacker then, if social
   and legal systems in which they operate.  This document focuses
   primarily on the
proxy repeatedly resends the request when receiving no answer, this can technical issues, but we note that "cease and
   desist" letters, government censorship, and other legal mechanisms
   also serve touch on denial- of-service issues.

2.14  Spam and Black-hole Lists

   Unsolicited commercial email, also known as an attack amplifier.

Another variant "spam", can effectively
   cause denial-of-service to email systems.  While the intent is not
   denial-of-service, the large amount of amplification occurs in protocols that include,
within unwanted mail can waste the protocol payload, an IP address
   recipient's time, or name of host cause legitimate email to fail to which
subsequent messages should be sent. An example of such as protocol is
the Session Initiation Protocol (SIP), which carries a payload defined
by noticed
   amongst all the Session Description Protocol (SDP). The SDP payload background noise.  If spam filtering software is
   used, some level of the SIP
message conveys the IP address and port false positives is to which media packets,
typically encoded using the Real Time Transport Protocol (RTP), are
sent.

To launch this attack, an attacker sends a protocol message, be expected, and sets so these
   messages are effectively denied service.

   One mechanism to reduce spam is the use of black-hole lists.  The IP address within the payload
   addresses of dial-up ISPs or mail servers used to point originate or relay
   spam are added to the attack target. black-hole lists.  The
recipient recipients of the message will generate subsequent traffic mail choose to that IP
address. Depending
   consult these lists and reject spam if it originates or is relayed by
   systems on the protocol, this attack can provide substantial
amplification properties. In the specific case of SIP, if a caller list.  One significant problem with such lists is that
   it may be possible for an attacker to cause a victim to be black-hole
   listed, even if the victim was not responsible for relaying spam.
   Thus the black-hole list itself can be a mechanism for effecting a
   DoS attack.  Note that every black-hole list has its own policy
   regarding additions, and some are less susceptible to this DoS attack
   than others.  Consumers of black-hole list technology are advised to
   investigate these policies before they subscribe.

3.  Attack Amplifiers

   Many of the attacks described above rely on sending sufficient
   traffic to overwhelm the victim.  Such attacks are made much easier
   by the existence of "attack amplifiers", where an attacker can send
   traffic from the spoofed source address of the victim and cause
   larger responses to be returned to the victim.  A detailed discussion
   of such reflection attacks can be found in [31].

3.1  Methods of Attack Amplification

   The simplest such attack was the "smurf" attack [11], where an ICMP
   echo request packet with the spoofed source address of the victim is
   sent to the subnet-broadcast address of a network to be used as an
   amplifier.  Every system on that subnet then responds with an ICMP
   echo response that returns to the victim.  Smurf attacks are no
   longer such a serious problem, as these days routers usually drop
   such packets and end-systems do not respond to them.

   An alternative form of attack amplifier is typified by a DNS
   reflection attack.  An attacker sends a DNS request to a DNS server
   requesting resolution of a domain name.  Again the source address of
   the request is the spoofed address of the victim.  The request is
   carefully chosen so that the size of the response is significantly
   greater than the size of the request, thereby providing the
   amplification.  As an aside, it is interesting to note that the
   largest DNS responses tend to be those incorporating DNSsec
   authentication information.  This attack amplifier can only be used
   by an attacker with the ability to spoof the source address of the
   victim.  However, we note that if the victim's DNS server is
   configured to relay requests from external clients, it may be
   possible to cause it to congest its own incoming network link.

   Another variant of attack amplifier involves amplification through
   retransmission.  This is typified by a TCP amplification attack known
   as "bang.c".  The attacker sends a spoofed TCP SYN with the source
   address of the victim to a arbitrary TCP server.  The server will
   respond with a SYN|ACK which is sent to the victim, and when no final
   ACK is received to complete the handshake, the SYN|ACK will be
   retransmitted a number of times.  Typically this attack uses a very
   large list of arbitrarily chosen servers as reflectors.  For the
   attack to be successful, the reflector must not receive a RST from
   the victim in response to the SYN|ACK - however if the attack traffic
   sufficiently overwhelms the server or access link to the server, then
   packet loss will ensure that many reflectors do not receive a RST in
   response to their SYN|ACK, and so continue to retransmit.  The attack
   can be exacerbated by firewalls that silently drop the incoming SYN|
   ACK without sending a RST.

   Care must also be taken with services that relay requests.  If an
   attacker can send a request to a proxy, and that proxy now attempts
   to connect to a victim whose address is chosen by the attacker then,
   if the proxy repeatedly resends the request when receiving no answer,
   this can also serve as an attack amplifier.

   Another variant of amplification occurs in protocols that include,
   within the protocol payload, an IP address or name of host to which
   subsequent messages should be sent.  An example of such as protocol
   is the Session Initiation Protocol (SIP), which carries a payload
   defined by the Session Description Protocol (SDP).  The SDP payload
   of the SIP message conveys the IP address and port to which media
   packets, typically encoded using the Real Time Transport Protocol
   (RTP), are sent.

   To launch this attack, an attacker sends a protocol message, and sets
   the IP address within the payload to point to the attack target.  The
   recipient of the message will generate subsequent traffic to that IP
   address.  Depending on the protocol, this attack can provide
   substantial amplification properties.  In the specific case of SIP,
   if a caller makes calls to high bandwidth media sources (such as a
   video server or streaming audio server), a single SIP INVITE packet,
   typically a few hundred bytes, can result in a nearly continuous
   stream of media packets at rates anywhere from a few kbits per second
   up to megabits per second.  This particular attack is called the
   "voice hammer".

   Unlike the other techniques described above, this technique does not
   require the attacker to modify packets or even spoof their source IP
   address.  This makes it easier to launch.

   This attack is prevented through careful protocol design.  Protocols
   should, whenever possible, avoid including IP addresses or hostnames
   within protocol payloads as addresses to which subsequent messaging
   should be sent.  Rather, when possible, messages should be sent to
   the source IP from which the protocol packet came.  If such a design
   is not possible, the protocol should include a handshake whereby it
   can be positively determined that the protocol entity at that IP
   address or hostname does, in fact, wish to receive that subsequent
   messaging.  That handshake itself needs to be lightweight (to avoid
   being the source of another DoS attack), and secured against the
   spoofing of the handshake response.

   Finally, a somewhat similar attack is possible with some protocols
   where where one message leads to another message that is not sent as
   a reply to the source address of the first message.  This can be an
   issue with protocols to enable mobility for example, and might permit
   an attacker to avoid ingress filtering.  Such protocols are
   notoriously difficult to get right.

3.2  Strategies to Mitigate Attack Amplification

   In general, the architectural lessons to be learnt are simple:

   o   As far as possible, perform ingress filtering [22] [37] to
   prevent source address spoofing.

   o   Avoid designing protocols or mechanisms that can return
   significantly larger responses than the size of the request, unless a
   handshake is performed to validate the client's source address.  Such
   a handshake needs to incorporate an unpredictable nonce that is
   secure enough to mitigate the amplification effects of the protocol.

   o   All retransmission during initial connection setup should be
   performed by the client.

   o   Proxies should not arbitrarily relay requests to destinations
   chosen by a client.

   o   Avoid signaling third-party connections.  Any unavoidable third-
   party connections setup by a signaling protocol should incorporate
   lightweight validation before sending significant data.

4.  DoS Solutions

Although Mitigation Strategies

   NOTE: This section is incomplete

   A general problem with DoS defense is that it is not in principle
   possible to distinguish between a flash-
crowd flash-crowd and a DoS attack, in practice it should be possible to raise the
bar high enough that an attacker attack.
   Indeed, having your site taken down by a flash crowd is forced to disguise their attack as
legitimate traffic.  This makes it much probably a
   more expensive to perpetrate an
attack.  In addition, the goal should be to make common experience than having it impossible to
perpetrate an attack from an untraceable host.  Thus, even though some
attacks may be impossible to prevent, the victim would then have legal
recourse.  This does not however mean that anonymity should be
impossible at DoS-ed --- so common it's
   acquired its own names: being Slashdotted or Farked, after the application level; merely web
   sites that the choice to interact
with an anonymous party should be at the discretion are common sources of flash crowds.  Thus, the other party.

A guiding principle when hardening systems first line
   of defense against DoS is attacks must be to avoid
causing additional different avenues for attack.  A classic example is provision your service so
   that of it can handle a mail server that verifies foreseeable legitimate peak load.
   Underprovisioned sites are the "from" address of email is
resolvable, which allows email from a site to be DoSed by merely
preventing access easiest to that site's DNS servers.

The guidelines below primarily concern the relatively obvious mechanisms take down.

   Specific strategies for DoS defense fall into two broad categories:

   1.  Avoiding allowing attacks that are already reasonably well understood.  The aim of this document
is better than generic resource
       consumption.

   2.  Minimizing the extent to help protocol designers and network operators understand which generic resource consumption
       attacks crowd

   In the state remainder of the art, and to stimulate discussion on additional architectural
solutions.

Don't Create an Attack Amplifier

The simplest guideline is to avoid building attack amplifiers and, as
far as possible, to perform ingress filtering to prevent compromised
systems on this section, we consider specific applications
   of these two approaches at a subnet from spoofing the source address on packets. variety of levels of network system
   architecture.

4.1  Protocol Design

4.1.1  Don't Hold State for Unverified Hosts

   From an end-system server point of view, one simple aim is to avoid
   instantiating state without having completed a handshake with the
   client to validate their address, and as far as possible to push work
   and stateholding to client.  There are a number of techniques that
   might be used to do this, including SYN-cookies [5] [2].  All client-server client-
   server protocols should probably be designed to allow such techniques
   to be
used, but used, but the enabling of the mechanism should normally be at
   the server's discretion to avoid unnecessary work under normal
   circumstances.

4.1.2  Make it Hard to Simulate a Legitimate User

   Other than having massive overcapacity, the only real defense against
   resource consumption attacks is to preferentially discriminate
   against attackers.  The general idea is to find something that
   legitimate users can do but attackers can't.  The most commonly
   proposed approaches include:

   1.  Puzzles: force the attacker to do some computation that would not
       be onerous for a single user but is too expensive to do en masse.
       [2]

   2.  Reverse Turing Tests: specialized puzzles that are hard for
       machines to do but easy for humans, thus making automated attacks
       hard.[42]

   3.  Reachability testing: force the proposed client to demonstrate
       that it can receive traffic at a given IP address.  This makes it
       easier to trace attackers.

   All of these techniques have substantial limitations.  Puzzles tend
   to discriminate against legitimate users with slow computers.  In
   addition, the wide availability of "bots" means that attackers have
   ample computing power at their disposal.  There has been substantial
   work in attacking Reverse Turing Tests automatically, thus making
   them of limited applicability.  Finally, reachability testing is
   substantially weakened by bots because the attacker does not need to
   hide his source address.

4.1.3  Graceful Routing Degradation

   A goal with routing protocols is that of graceful degradation in
   overload, and automatic recovery after the source of the overload has
   been remedied.  Some routing protocols satisfy this goal more than
   others.  Although RIP doesn't scale well, if a router runs out of
   memory when receiving a RIP route, it can just drop the route and
   send an infinite metric to its peers.  The route will later be
   refreshed, and if the enabling original source of the mechanism should normally be at problem has been
   resolved, the

server's discretion to avoid unnecessary work under normal
circumstances.

State Lookup Complexity

Any system that instantiates per-connection state should take great care router will now be able to implement process it correctly.

   On the state-lookup mechanisms other hand, BGP is stateful in such a way that performance
can not be controlled by the attacker.  One way sense that a peer assumes
   you have processed or chosen to achieve this filter any route that it sent you.
   There is to
use hash-tables where the hash no mechanism is keyed to refresh state in such a way that the
attacker cannot instantiate a large number of flows in base BGP spec, and even
   the same hash
bucket.

Avoid Livelock

Most operating systems use network interrupts later route refresh option [16] is hard to receive data from use usefully in the
network, which is
   presence of overload.  A BGP router that cannot store a good solution if route it
   received has two choices: completely restart BGP, or shutdown one or
   more peerings [15].  This means that the host spends only a small amount effects of its time handling network traffic.  However, this leaves the host
open to livelock [29], where under heavy load the OS spends all its time
handling interrupts and no time doing the work needed a BGP overload
   are rather more severe than they need to handle be, and so amplifies the
traffic at
   effect of any attack.

   In general, few routing protocol designs actively consider the application level.  Server operating systems
   possible behaviour of routers under overload conditions; this should
consider using network polling at times
   be an explicit part of heavy load, rather that being
interrupt-driven, and future routing protocol designs.  Although
   precise details should clearly be carefully architected so that as far as
reasonably possible, traffic received by left to implementors, the OS is processed protocol
   design needs to
completion, or very cheaply discarded.

Use Unpredictable Values for Session IDs

Most recent TCP implementations use fairly good random mechanisms for
allocating give them the TCP initial sequence numbers.  In general, any
dynamically allocated value used purely capability to identify a communications
session should be allocated using an unpredictable mechanism, do their job properly.

4.1.4  Autoconfiguration and Authentication

   Autoconfiguration mechanisms greatly ease deployment, and are
   increasingly necessary as this
increases the search space for an attacker number of networked devices grows
   beyond what can be managed manually.  However, it should be
   recognised that wishes to disrupt
ongoing communications.  Thus the dynamically allocated port unauthenticated autoconfiguration opens up many
   avenues for attack.  There is a clear tension between ease of
   configuration and security of configuration.  Future
   autoconfiguration protocols should consider the
active end need to allow
   different end-systems to operate at different points in this spectrum
   within the same autoconfiguration framework.

4.1.5  Network Design and Configuration

4.1.6  Redundancy and Distributed Service

   A basic principle of a TCP connection might also be randomly allocated.

With DNS, designing systems to handle failure to have
   redundant servers which can take over when one fails.  This is
   equally true in the ID case of DoS attacks, which is used to match responses with requests should
also often focus on a given
   server and/or link.  If service delivery points can be randomly generated.  However, as the ID field is only 16 bits, distributed
   across the protection is rather limited, especially in network, then it becomes much harder to attack the face of birthday
attacks. entire
   service.  In particular, this makes attacks on a single network link
   more difficult.

4.1.7  Authenticate Routing Adjacencies

   In general, cryptographic authentication mechanisms are too costly to
   form the main part in DoS prevention.  However, routing adjacencies
   are too important to risk an attacker being able to inject bad
   routing information, which can affect more than the router in
   question.  Additional non-cryptographic mechanisms should then be
   used to avoid arbitrary end-systems being able to cause the router to
   spend CPU cycles on validating authentication data.

   For BGP, at the very least, this implies the use of TCP MD5 [24] or
   IPsec authentication, combined with the TTL 255 hack [23] to prevent
   EBGP association with non-immediate neighbours.  In future, this will
   likely imply better authentication of the routing information itself.

4.1.8  Isolate Router-to-Router Traffic

   As far as is feasible, router-to-router traffic should be isolated
   from data traffic.  How this should be implemented depends on the
   precise technologies available, both in the router and at the link-layer. link-
   layer.  The goal should be that failure of the link for data traffic
   should also cause failure for the routing traffic, but that an
   attacker cannot directly send packets to the control processor of the
   routers.

   A downside of this is that some diagnostic techniques (such as
   pinging consecutive routers to find the source of a delay) may no
   longer be possible.  Ideally, alternative mechanisms (which do not
   open up additional avenues for DoS) should be designed to replace
   such lost techniques.

Graceful Routing Degradation

A goal with routing protocols is

4.2  Router Implementation Issues

4.3  End-System Implementation Issues

4.3.1  State Lookup Complexity

   Any system that of graceful degradation in
overload, and automatic recovery after the source of instantiates per-connection state should take great
   care to implement the overload has
been remedied.  Some routing protocols satisfy this goal more than
others.  Although RIP doesn't scale well, if a router runs out of memory
when receiving state-lookup mechanisms in such a RIP route, it way that
   performance can just drop the route and send an
infinite metric to its peers.  The route will later not be refreshed, and if
the original source of the problem has been resolved, controlled by the router will
now be able attacker.  One way to process it correctly.

On
   achieve this is to use hash-tables where the other hand, BGP hash mechanism is stateful keyed
   in the sense that such a peer assumes you
have processed or chosen to filter any route way that it sent you.  There is
no mechanism to refresh state in the base BGP spec, and even attacker cannot instantiate a large number of
   flows in the later
route refresh option [16] is hard to same hash bucket.

4.3.1.1  Avoid Livelock

   Most operating systems use usefully in network interrupts to receive data from
   the presence of
overload.  A BGP router that cannot store network, which is a route it received has two
choices: completely restart BGP, or shutdown one or more peerings [15].
This means that good solution if the effects of host spends only a BGP overload are rather more severe
than they need small
   amount of its time handling network traffic.  However, this leaves
   the host open to be, livelock [29], where under heavy load the OS spends
   all its time handling interrupts and so amplifies no time doing the effect of any attack.

In general, few routing protocol designs actively consider work needed to
   handle the possible
behaviour of routers under overload conditions; this traffic at the application level.  Server operating
   systems should be an
explicit part consider using network polling at times of future routing protocol designs.  Although precise
details heavy load,
   rather that being interrupt-driven, and should clearly be left to implementors, the protocol design
needs to give them carefully
   architected so that as far as reasonably possible, traffic received
   by the capability to do their job properly.

Source-Specific Multicast

Source-specific multicast OS is easier processed to manage than ASM, and opens up
many fewer avenues for DoS attack.  However, ASM has many uses completion, or very cheaply discarded.

4.3.1.2  Use Unpredictable Values for
resource discovery and autoconfiguration.  A prudent deployment strategy
would be to Session IDs

   Most recent TCP implementations use SSM fairly good random mechanisms for inter-domain multicast and ASM only within
   allocating the
more controlled environment of an intranet. TCP initial sequence numbers.  In both environments,
administrative controls should be set to prevent a single receiver from
joining sufficient multicast groups general, any
   dynamically allocated value used purely to cause identify a state exhaustion problem
in communications
   session should be allocated using an unpredictable mechanism, as this
   increases the multicast routers.  Such a threshold needs to take into account search space for an attacker that some multicast congestion control mechanisms use multiple multicast
groups wishes to allow disrupt
   ongoing communications.  Thus the receiver to select an appropriate rate.

In dynamically allocated port of the future, multicast protocols may
   active end of a TCP connection might also be deployed randomly allocated.

   With DNS, the ID which use shared
bidirectional trees for interdomain multicast.  This might allow ASM is used to match responses with requests
   should also be deployed without randomly generated.  However, as the ID field is only
   16 bits, the protection is rather limited, especially in the face of
   birthday attacks.

4.3.2  Operational Issues

4.3.2.1  Eliminate Bad Traffic Early

   Many DoS vulnerabilities exhibited by current inter-
domain ASM solutions.  Such solutions are not currently available.

Autoconfiguration and Authentication

Autoconfiguration mechanisms greatly ease deployment, and attacks are
increasingly necessary as generic bandwidth consumption attacks that
   operate by clogging the number of networked devices grows beyond
what can be managed manually.  However, it should be recognised link that
unauthenticated autoconfiguration opens up many avenues for attack.
There connects the victim server to the
   Internet.  Filtering these attacks at the server does no good because
   the traffic has already traversed the link which is a clear tension between ease of configuration and security of
configuration.  Future autoconfiguration protocols should consider the scarce
   resource.  Such flows need to allow different end-systems to operate be filtered at different points in
this spectrum within some point closer to the same autoconfiguration framework.
   attacker.  Where possible, operators should filter out obviously bad
   traffic.  In particular, they should perform ingress filtering [22].

4.3.2.2  Establish a Monitoring Framework

   Network operators are strongly encouraged to establish a monitoring
   framework to detect and log abnormal network activity.  One can not
   defend against an attack one doesn't detect or understand.  Such
   monitoring tools can be used to set a baseline of "normal" traffic,
   and can be used to determine:

1.

   o  Aberrant flows.

2.

   o  Type and source of the aberrant flows. flows

   This is extremely helpful when responding to DDoS or a flash crowd,
   and should be in place prior to the event.

5.  Conclusions

   In this document we have highlighted possible avenues for DoS attack
   on networks and networked systems, with the aim of encouraging
   protocol designers and network engineers towards designs that are
   more robust.  We have discussed partial solutions that reduce the
   effectiveness of attacks, and highlighted how some partial solutions
   can be taken advantage of by attackers to perpetrate alternative
   attacks.

   Our focus has primarily been on protocol and network architecture
   issues, but there are many things that network and service operators
   can do to lessen the threat.  Further advice and information for
   network operators can be found in [13] [37] [14].

   It is our hope that this document will spur discussion leading to
   architectural solutions that reduce the succeptibility of all
   Internet systems to denial-of-service attacks.

6.  Security Considerations

   This entire document is about security.

7.  Acknowledgements

   We are very grateful to Vern Paxson, Paul Vixie, Rob Thomas, Dug
   Song, George Jones and Jones, Jari Arkko Arkko, and Geoff Huston for their
   constructive comments on earlier versions of this document.

7.  Authors' Addresses

Mark Handley
Department of Computer Science
University College London
Gower Street
London WC1E 6BT
United Kingdom.

Email: M.Handley@cs.ucl.ac.uk

8.  References

   [1] J. Abley, "Hierarchical Anycast for Global Service Distribution",
   http://www.isc.org/tn/isc-tn-2003-1.txt

   [2] T. Aura, P. Nikander, J. Leiwo, "DOS-resistant authentication
   with client puzzles", In B. Christianson, B. Crispo, and M. Roe,
   editors, Proceedings of the 8th International Workshop on Security
   Protocols, Lecture Notes in Computer Science, Cambridge, UK, April
   2000.

   [3] J. Bellardo, S. Savage, "802.11 Denial-of-Service Attacks: Real
   Vulnerabilities and Practical Solutions", Proceedings of the USENIX
   Security Symposium, Washington D.C., August 2003.

   [4] S.M. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
   Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April 1989.

   [5] D.J. Bernstein, "SYN Cookies", http://cr.yp.to/syncookies.html

   [6] CCAIS/RNP Alertas do Cais ALR-19112002a, "Vulnerability in the
   sending requests control of Bind versions 4 and 8 allows DNS
   spoofing", http://www.rnp.br/cais/alertas/2002/cais-
     ALR-19112002a.html ALR-
   19112002a.html

   [7] CERT Advisory CA-1996-01, "UDP Port Denial-of-Service Attack",
   Feb 1996.

   [8] CERT Advisory CA-1996-21, "TCP SYN Flooding and IP Spoofing
   Attacks", Sept 1996.

   [9] CERT Advisory CA-2001-09, "Statistical Weaknesses in TCP/IP
   Initial Sequence Numbers", May 2001.

   [10] CERT Advisory CA-1996-26, "Denial-of-Service Attack via ping",
   Dec 1996.

   [11] CERT Advisory CA-1998-01, "Smurf IP Denial-of-Service Attacks",
   http://www.cert.org/advisories/CA-1998-01.html, Jan 1998.

   [12] CERT Incident Note IN-2000-05, "'mstream' Distributed Denial of
   Service Tool", May 2000.

   [13] CERT/CC - "Managing the Threat of Denial of Service Attacks",
   http://www.cert.org/archive/pdf/Managing_DoS.pdf

   [14] CERT/CC - "Trends in Denial of Service Attack Technology",
   http://www.cert.org/archive/pdf/DoS_trends.pdf
   [15] D.F. Chang, R. Govindan, J. Heidemann, "An Empirical Study of
   Router Response to Large Routing Table Load", Proceedings of the 2nd
   Internet Measurement Workshop (IMW 2002), 2002.

   [16] E. Chen, "Route Refresh Capability for BGP-4", RFC 2918,
   September 2000

   [17] Cisco Systems, "Configuring the BGP Maximum-Prefix Feature",
   Cisco Document ID: 25160, http://www.cisco.com/warp/public/459/bgp-
   maximum-prefix.html

   [18] Scott A Crosby and Dan S Wallach, "Denial of Service via
   Algorithmic Complexity Attacks", Proceedings of the USENIX Security
   Symposium, Washington D.C., August 2003.

   [19] S. Deering, "Host extensions for IP multicasting", RFC 1112, Aug
   1989.

   [20] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0", RFC 2246,
   Jan 1999.

   [21] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.
   Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol
   Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification",
   RFC 2362, June 1998.

   [22] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating
   Denial of Service Attacks which employ IP Source Address Spoofing",
   RFC 2827, May 2000.

   [23] V. Gill, J. Heasley, D. Meyer, "The BGP TTL Security Hack
   (BTSH)", draft-gill-btsh-02.txt (work in progress), 29-May-03.

   [24] A. Heffernan, "Protection of BGP Sessions via the TCP MD5
   Signature Option", RFC 2385, August 1998.

   [25] Laurent Joncheray, "Simple Active Attack Against TCP", 5th
   USENIX Security Symposium, 1995.

   [26] M. Lough, "A Taxonomy of Computer Attacks with Applications to
   Wireless", PhD thesis, Virginia Polytechnic Institute, April 2001.

   [27] Z. Mao, R. Govindan, G. Varghese, R. Katz, "Route Flap Dampening
   Exacerbates Internet Routing Convergence", Proceedings of ACM
   SIGCOMM, 2002.

   [28] D. Meyer, W. Fenner (Editors), "Multicast Source Discovery
   Protocol (MSDP)", draft-ietf-msdp-spec-15.txt, Work in Progress.

   [29] J. Mogul, KK.  Ramakrishnan, "Eliminating Receive Livelock in an
   Interrupt-driven Kernel", ACM Transactions on Computer Systems, Vol
   15, Number 3, pp. 217-252, 1997.

   [30] National Infrastructure Secuity Co-ordination Center (NISCC),
   Vulnerability Advisory 236929, April 2004,
   http://www.uniras.gov.uk/vuls/2004/236929/

   [31] V. Paxson, "An Analysis of Using Reflectors for Distributed
   Denial- of-Service Attacks", Computer Communication Review 31(3),
   July 2001.

   [32] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
   1771, March 1995.

   [33] Joe Stewart, "DNS Cache Poisoning - The Next Generation", Jan 27
   2003, http://www.securityfocus.com/guest/17905

   [34] R. Stewart (Editor), Transmission Control Protocol security
   considerations, Internet Draft, April 2004, draft-ietf-tcpm-
   tcpsecure-00.txt

   [35] C. Villamizar, R. Chandra, R. Govindan, "BGP Route Flap
   Damping", RFC 2439, November 1998.

   [36] P. Vixie, G. Sneeringer, M. Schleifer, "Events of 21-Oct-2002",
   http://f.root-servers.org/october21.txt

   [37] P. Vixie, "Securing the Edge",
   http://www.icann.org/committees/security/sac004.txt

   [38] D. Waitzman, C. Partridge, S.E. Deering, "Distance Vector
   Multicast Routing Protocol", RFC 1075, Nov 1988.

   [39] D. Wessels, "Running An Authoritative-Only BIND Nameserver",
   http://www.isc.org/tn/isc-tn-2002-2.txt

   [40] M. Zalewski, "Strange Attractors and TCP/IP Sequence Number
   Analysis", http://razor.bindview.com/publish/papers/tcpseq.html

   [41] J. Bellardo and S. Savage, "802.11 Denial-of-Service Attacks:
   Real Vulnerabilities and Practical Solutions", Proceedings of the
   12th USENIX Security Symposium, August 2003.

   [42] L. von Ahn, M. Blum, N. Hopper, and J. Langford.  CAPTCHA: Using
   hard AI problems for security.  In Proceedings of Eurocrypt, 2003.

Authors' Addresses

   Mark J. Handley (ed)
   UCL
   Gower Street
   London  WC1E 6BT
   UK

   Email: M.Handley@cs.ucl.uk

   Eric Rescorla (ed)
   Network Resonance
   2483 E. Bayshore #212
   Palo Alto  94303
   USA

   Email: ekr@networkresonance.com

Appendix A.  IAB Members at the time of this writing

   o  Bernard Aboba

   o  Loa Andersson

   o  Brian Carpenter

   o  Leslie Daigle

   o  Patrik Faltstrom

   o  Bob Hinden

   o  Kurtis Lindqvist

   o  David Meyer

   o  Pekka Nikander

   o  Eric Rescorla

   o  Pete Resnick

   o  Jonathan Rosenberg

   o  Lixia Zhang

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.