idnits 2.17.1 draft-iab-dos-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (9 January 2004) is 7413 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Obsolete normative reference: RFC 2246 (ref. '19') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2362 (ref. '20') (Obsoleted by RFC 4601, RFC 5059) -- Possible downref: Normative reference to a draft: ref. '22' ** Obsolete normative reference: RFC 2385 (ref. '23') (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. '24' -- Possible downref: Non-RFC (?) normative reference: ref. '25' -- Possible downref: Non-RFC (?) normative reference: ref. '26' == Outdated reference: A later version (-20) exists of draft-ietf-msdp-spec-15 ** Downref: Normative reference to an Experimental draft: draft-ietf-msdp-spec (ref. '27') -- Possible downref: Non-RFC (?) normative reference: ref. '28' ** Obsolete normative reference: RFC 1771 (ref. '29') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '30' -- Possible downref: Non-RFC (?) normative reference: ref. '32' -- Possible downref: Non-RFC (?) normative reference: ref. '33' ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '34') -- Possible downref: Non-RFC (?) normative reference: ref. '35' -- Possible downref: Non-RFC (?) normative reference: ref. '36' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force IAB 2 INTERNET-DRAFT Mark Handley (ed) 3 draft-iab-dos-00.txt 9 January 2004 4 Expires: July 2004 6 Internet Denial of Service Considerations 8 This document is an Internet-Draft and is subject to all provisions of 9 Section 10 of RFC2026. 11 Internet-Drafts are working documents of the Internet Engineering Task 12 Force (IETF), its areas, and its working groups. Note that other groups 13 may also distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference material 18 or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/1id-abstracts.html 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html 26 Abstract 28 This document provides an overview of possible avenues for denial-of- 29 service attack on Internet systems. The aim is to encourage protocol 30 designers and network engineers towards designs that are more robust. 31 We discuss partial solutions that reduce the effectiveness of attacks, 32 and how some solutions might inadvertently open up alternative 33 vulnerabilities. 35 1. Introduction 37 A Denial-of-Service (DoS) attack is an attack in which one or more 38 machines target a victim and attempt to prevent the victim from doing 39 useful work. The victim can be a network server, client or router, a 40 network link or an entire network, an individual Internet user or a 41 company doing business using the Internet, an Internet Service Provider 42 (ISP), country, or any combination of or variant on these. Denial of 43 service attacks may involve gaining unauthorized access to network or 44 computing resources, but for the most part in this document we focus on 45 the cases where the denial-of-service attack itself does not involve a 46 compromise of the victim's computing facilities. 48 Because of the closed context of the original ARPAnet and NSFnet, no 49 consideration was given to denial-of-service attacks in the original 50 Internet Architecture. As a result, almost all Internet services are 51 vulnerable to denial-of-service attacks of sufficient scale. In most 52 cases, sufficient scale can be achieved by compromising enough end-hosts 53 (typically using a virus, worm, or remotely controlled "bots") or 54 routers, and using those compromised hosts to perpetrate the attack. 55 Such an attack is known as a Distributed Denial of Service attack 56 (DDoS). However, there are also many cases where a single well- 57 connected end-system can perpetrate a successful DoS attack. 59 This document is intended to serve several purposes: 61 o To highlight possible avenues for attack, and by so doing encourage 62 protocol designers and network engineers towards designs that are 63 more robust. 65 o To discuss partial solutions that reduce the effectiveness of 66 attacks. 68 o To highlight how some partial solutions can be taken advantage of by 69 attackers to perpetrate alternative attacks. 71 This last point appears to be a recurrent theme in DoS, and highlights 72 the lack of proper architectural solutions. It is our hope that this 73 document will help initiate informed debate about future architectural 74 solutions that might be feasible and cost-effective for deployment. 76 In addition it is our hope that this document will spur discussion 77 leading to architectural solutions that reduce the succeptibility of all 78 Internet systems to denial-of-service attacks. 80 We note that in principle it is not possible to distinguish between a 81 sufficiently subtle DoS attack and a flash-crowd, where unexpected heavy 82 but non-malicious traffic has the same effect as a DoS attack. Whilst 83 this is true, such malicious attacks are usually more expensive to 84 launch than many of the crude attacks that have been seen to date. Thus 85 defending against DoS is not about preventing all possible attacks, but 86 rather is largely a question of raising the bar sufficiently high for 87 malicious traffic. 89 However, it is also important to note that not all DoS problems are 90 malicious. Failed links, flash crowds, misconfigured bots, and numerous 91 other causes can result in resource exhaustion problems, and so the 92 overall goal should be to be robust to all forms of overload. 94 2. An Overview of Denial-of-Service Threats 96 In this section we will discuss a wide range of possible DoS attacks. 97 This list cannot be exhaustive, but the intent is to provide a good 98 overview of the spectrum of possibilities that need to be defended 99 against. 101 We do not provide descriptions of any attacks that are not already 102 publicly well documented. 104 2.1. DoS Attacks on End-systems 106 We first discuss attacks on end-systems. An end-system in this context 107 is typically a PC or network server, but it can also include any 108 communication endpoint. For example, a router also is an end-system 109 from the point of view of terminating TCP connections for BGP [29] or 110 ssh. 112 2.1.1. Exploiting Poor Software Quality 114 The simplest DoS attacks on end-systems exploit poor software quality on 115 the end-systems themselves, and cause that software to simply crash. 116 For example, buffer-overflow attacks might be used to compromise the 117 end-system, but even if the buffer-overflow cannot be used to gain 118 access, it will usually be possible to overwrite memory and cause the 119 software to crash. Such vulnerabilities can in principle affect any 120 software that uses data supplied from the network. Thus not only might 121 a web server be potentially vulnerable, but it might also be possible to 122 crash the back-end software (such as a database) to which a web server 123 provides data. 125 Software crashes due to poor coding not only affect application 126 software, but also the operating system kernel itself. A classic 127 example is the so-called "Ping of Death", which became widely known in 128 1996 [10]. This exploit caused many popular operating systems to crash 129 when sent a single fragmented ICMP echo request packet whose fragments 130 totaled more than the 65535 bytes allowed in an IPv4 packet. 132 While DoS attacks such as the ping-of-death are a significant problem, 133 they are not a significant architectural problem. Once such an attack 134 is discovered, the relevant code can easily be patched, and the problem 135 goes away. We should note though that as more and more software becomes 136 embedded, it is important not to lose the possibility of upgrading the 137 software in such systems. 139 2.1.2. Application Resource Exhaustion 141 Network applications exist in a context that has finite resources. In 142 processing network traffic, such an application uses these resources to 143 do its intended task. However, an attacker may be able to prevent the 144 application from performing its intended task by causing the application 145 to exhaust the finite supply of a specific resource. 147 The obvious resources that might be exhausted include: 149 o Available memory. 151 o The CPU cycles available. 153 o The disk space available to the application. 155 o The number of processes or threads or both that the application is 156 permitted to use. 158 o The configured maximum number of simultaneous connections the 159 application is permitted. 161 This list is clearly not exhaustive, but it illustrates a number of 162 points. 164 Some resources are self-renewing: CPU cycles fall in this category - if 165 the attack ceases, more CPU cycles become available. 167 Some resources such as disk space require an explicit action to free up 168 - if the application cannot do this automatically then the effects of 169 the attack may be persistent after the attack has ceased. 171 This problem has been understood for many years, and it is common 172 practice for logs and incoming email to be stored in a separate disk 173 partition (/var) on Unix systems. 175 Some resources are constrained by configuration: the maximum number of 176 processes and the maximum number of simultaneous connections are not 177 normally hard limits, but rather are configured limits. The purpose of 178 such limits is clearly to allow the machine to perform other tasks in 179 the event the application misbehaves. However, great care needs to be 180 taken to choose such limits appropriately. For example, if a machine's 181 sole task is to be an ftp server, then setting the maximum number of 182 simultaneous connections to be significantly less than the machine can 183 service makes the attackers job easier. But setting the limit too high 184 may permit the attacker to cause the machine to crash (due to poor OS 185 design in handling resource exhaustion) or permit livelock (see below), 186 which are generally even less desirable failure modes. 188 2.1.3. Operating System Resource Exhaustion 190 Conceptually OS resource exhaustion and application resource exhaustion 191 are very similar. However, in the case of application resource 192 exhaustion, the operating system may be able to protect other tasks from 193 being affected by the DoS attack. In the case of the operating system 194 itself running out of resources, the problem may be more catastrophic. 196 Perhaps the best-known DoS attack on an operating system is the TCP SYN- 197 flood [8], which is essentially a memory-exhaustion attack. The 198 attacker sends a flood of TCP SYN packets to the victim, requesting 199 connection setup, but then does not complete the connection setup. The 200 victim instantiates state to handle the incoming connections. If the 201 attacker can instantiate state faster than the victim times it out, then 202 the victim will run out of memory that it can use to hold TCP state, and 203 so it cannot service legitimate TCP connection setup attempts. This 204 issue was exacerbated in some implementations by the use of a small 205 dedicated storage space for half-open connections, which made the attack 206 easier that it might otherwise have been. In the case of a poorly coded 207 operating system, running out of resources may also cause a system 208 crash. 210 An alternative TCP DoS attack is the Ack-flood [12], which is 211 essentially a CPU exhaustion attack on the victim. The attacker floods 212 the victim with TCP packets pretending to be from connections that have 213 never been established. A busy server that has a large number of 214 outstanding connections needs to check which connection the packet 215 corresponds to. Some TCP implementations implemented this search rather 216 inefficiently, and so the attacker could use all the victim's CPU 217 resources servicing these packets rather than servicing legitimate 218 requests. 220 We note that strong authentication mechanisms do not mitigate against 221 such CPU exhaustion attacks. In fact poorly designed authentication 222 mechanisms using cryptographic methods can exacerbate the problem. If 223 such an authentication mechanism allows an attacker to present a packet 224 to the victim that requires relatively expensive cryptographic 225 authentication before the packet can be discarded, then this makes the 226 attacker's CPU exhaustion attack easier. 228 CPU exhaustion attacks can be also be exacerbated by poor OS handling of 229 incoming network traffic. In the absence of malicious traffic, an ideal 230 OS should behave as follows: 232 o As incoming traffic increases, the useful work done by the OS should 233 increase until some resource (such as the CPU) is saturated. 235 o From this point on, as incoming traffic continues to increase the 236 useful work done should be constant. 238 However, this is often not the case. Many systems suffer from livelock 239 where, after saturation, increasing the load causes a decrease in the 240 useful work done. One cause of this is that the system spends an 241 increasing amount of time processing network interrupts for packets that 242 will never be processed, and hence a decreasing amount of time is 243 available for the application for which these packets were intended. 245 2.1.4. Attacks on Ongoing Communications 247 Instead of attacking the end-system itself, it is also possible for an 248 attacker to disrupt ongoing communications. If an attacker can observe 249 a TCP connection, then it is relatively easy for them to spoof packets 250 to either reset that connection or to de-synchronize it so that no 251 further progress can be made [24]. Such attacks are not prevented by 252 transport or application-level security mechanisms such as TLS [19] or 253 ssh, because the authentication takes place after TCP has finished 254 processing the packets. 256 If an attacker cannot observe a TCP connection, but can infer that such 257 a connection exists, it is theoretically possible to reset or 258 desynchronize that connection by spoofing packets into the connection. 259 However, in the absence of any other information, this would require an 260 excessively large number of spoofed packets to guess both the port of 261 the active end of the TCP connection (in most cases the port of the 262 passive end is predictable) and the currently valid TCP sequence 263 numbers. However, as some operating systems have poorly implemented 264 predictable algorithms for selecting either the dynamically selected 265 port or the TCP initial sequence number [36] [9], then such attacks may 266 still be feasible. 268 An attacker might be able to significantly reduce the throughput of a 269 connection by sending spoofed ICMP source quench packets, although most 270 modern operating systems should ignore such packets. However, care 271 should be taken in the design of future transport and signaling 272 protocols to avoid the introduction of similar mechanisms that could be 273 exploited. 275 2.1.5. Attacks using the Victim's Own Resources 277 Instead of directly overloading the victim, it may be possible to cause 278 the victim or a machine on the same subnet as the victim to overload 279 itself. 281 An example of such an attack is documented in [7], where the attacker 282 spoofs the source address on a packet sent to the victim's UDP echo 283 port. The source address is that of another machine that is running a 284 UDP chargen server (a chargen server sends a character pattern back to 285 the originating source). The result is that the two machines bounce 286 packets back and forth as fast as they can, overloading either the 287 network between them or one of the end-systems itself. 289 2.1.6. Triggered Lockouts and Quota Exhaustion 291 Many user-authentication mechanisms attempt to protect against password 292 guessing attacks by locking the user out after a small number of failed 293 authentications. If an attacker can guess or discover a user's ID, they 294 may be able to trigger such a mechanism, locking out the legitimate 295 user. 297 Another way to deny service using protection mechanisms is to cause a 298 quota to be exhausted. This is perhaps most common in the case of small 299 web servers being commercially hosted, where the server has a contract 300 with the hosting company allowing a fixed amount of traffic per day. An 301 attacker may be able to rapidly exhaust this quota, and cause service to 302 be suspended. Similar attacks may be possible against other forms of 303 quota. 305 In the absence of such quotas, if the victim is charged for their 306 network traffic, a financial denial-of-service may be possible. 308 2.2. DoS Attacks on Routers 310 Many of the denial-of-service attacks that can be launched against end- 311 systems can also be launched against the control processor of an IP 312 router. In the case of a router, these attacks may cause the router to 313 reboot, or may cause the router to cease processing routing packets. 314 Even if the router does not stop servicing routing packets, it may 315 become sufficiently slow that routing protocols time out. In any of 316 these circumstances, the consequence of routing failure is not only that 317 the router ceases to forward traffic, but also that it causes routing 318 protocol churn that may have further side effects. 320 An example of such a side effect is caused by BGP route flap damping 321 [31], which is intended to reduce global routing churn. If an attacker 322 can cause BGP routing churn, route flap damping may then cause the 323 flapping routes to be suppressed [26]. 325 A DoS attack on the router control processor might also prevent the 326 router being managed effectively. This may prevent actions being taken 327 that would mitigate the DoS attack, and it might prevent diagnosis of 328 the cause of the problem. 330 2.2.1. Attacks on Routers through Routing Protocols 332 In addition to their roles as end-systems, most routers run dynamic 333 routing protocols. The routing protocols themselves can be used to 334 stage a DoS attack on a router or a network of routers. To inject 335 routing information into a routing protocol, an attacker needs access 336 either to a router or to a end-host on a subnet where a routing protocol 337 is running. In the latter case, if the routing protocol running on that 338 subnet is not authenticated, the end-host may be able to insert spoofed 339 routing information or pretend to be a router. 341 The simplest attack on a network of routers is to overload the routing 342 table with sufficiently many routes that the router runs out of memory, 343 or the router has insufficient CPU power to process the routes We note 344 that depending on the distribution and capacities of various routers 345 around the network, such an attack might not overwhelm routers near to 346 the attacking router, but might cause problems to show up elsewhere in 347 the network. 349 Some routing protocols allow limits to be configured on the maximum 350 number of routes to be heard from a neighbor [16] limit doesn't block 351 the spoofed routes at source, then imposition of such a limit elsewhere 352 in the network might cause legitimate routes to be dropped. 354 An alternative attack is to overload the routers on the network by 355 creating sufficient routing table churn that routers are unable to 356 process the changes. Many routing protocols allow damping factors to be 357 configured to avoid just such a problem. However, as with table size, 358 such a threshold applied inconsistently may allow the spoofed routes to 359 merge with legitimate routes before the mechanism is applied, causing 360 legitimate routes to be damped. 362 The simplest routing attack on a specific destination is for an attacker 363 to announce a spoofed desirable route to that destination. Such a route 364 might be desirable because it has low metric, or because it is a more 365 specific route than the legitimate route. In any event, if the route is 366 believed it will cause traffic for the victim to be drawn towards the 367 attacking router, where it will typically be discarded. 369 A more subtle denial-of-service attack might be launched against a 370 network rather than against a destination. Under some circumstances, 371 the propagation of inconsistent routing information can cause traffic to 372 loop. If an attacker can cause this to happen on a busy path, the 373 looping traffic might cause significant congestion, as well as not 374 reaching the legitimate destination. However in many cases severe 375 congestion is unlikely because TCP's congestion control will shut down 376 the majority of traffic that fails to reach the destination. 378 If an attacker has access to a host on the same subnet as a router 379 running certain routing protocols, even if that router is configured not 380 to accept routes, it might be possible to cause that router to run out 381 of memory by spoofing the existence of fake routers on that subnet. 383 In the past there have been cases where different generations of router 384 interpreted a routing protocol specification differently. In 385 particular, BGP specifies that in the case of an error, the BGP peering 386 should be dropped. However, if some of the routers in a network treat a 387 particular route as valid and other routes treat the route as invalid, 388 then it may be possible to inject a BGP route at one point in the 389 Internet and cause peerings to be dropped at many other places in the 390 Internet. Unlike many of the examples above, while such an issue might 391 be a serious short-term problem, this is not a fundamental architectural 392 problem. Once the problem is understood, deploying patched routing code 393 can permanently solve the issue. 395 2.2.2. IP Multicast-based DoS Attacks 397 There are essentially two forms of IP multicast: "traditional" IP 398 multicast (ASM), as specified in RFC 1112 [18] where multiple sources 399 can send to the same multicast group, and source-specific multicast 400 (SSM) where the receiver must specify both the IP source address and the 401 group address. The two forms of multicast provide rather different DoS 402 possibilities. 404 With ASM, an attacker can simply send to multiple multicast groups. 405 Routing protocols such as PIM-SM [20], MSDP [27] and DVMRP [34] then 406 have to instantiate routing state to ensure that the traffic goes to the 407 group receivers and not to non-receivers. Thus ASM is particularly 408 vulnerable to DoS attacks causing both multicast routing table explosion 409 (and hence control processor memory exhaustion) and multicast forwarding 410 table exhaustion (and hence forwarding card memory exhaustion or 411 thrashing). 413 ASM also permits an attacker to send traffic to the same group as 414 legitimate traffic, potentially causing network congestion and denying 415 service to the legitimate group. 417 However, unlike unicast traffic, it is comparatively difficult to spoof 418 source addresses for IP multicast traffic. Most deployed IP multicast 419 routing protocols use reverse-path checks to build the forwarding tree, 420 and so multicast attackers are easily located. In addition, multicast 421 traffic will only continue to flow to a receiver as long as the receiver 422 joins the multicast group. Thus it may be harder to use multicast 423 traffic to cause a denial-of-service attack on a destination - an 424 attacker would need to be opportunistic, sending traffic to a multicast 425 group that is already being received by the victim or another host 426 located close to the victim. 428 SSM does not permit senders to send to arbitrary groups unless a 429 receiver has requested the traffic. Thus sender-based attacks on 430 multicast routing state are not possible with SSM. However, as with 431 ASM, a receiver can still join a large number of multicast groups 432 causing routers to hold a large amount of multicast routing state, 433 potentially causing memory exhaustion and hence denial-of-service to 434 legitimate traffic. 436 2.2.3. Attacks on Router Forwarding Engines 438 Router vendors implement many different mechanisms for packet 439 forwarding, but broadly speaking they fall into two categories: ones 440 that use a forwarding cache, and ones that do not. With a forwarding 441 cache, the forwarding engine does not hold the full routing table, but 442 rather holds just the currently active subset of the forwarding table. 444 Routers or switches using a forwarding cache are potentially vulnerable 445 if an attacker can send many packets to different destinations through 446 the same router, causing the forwarding cache to thrash. One effect of 447 this is likely to be that legitimate traffic is dropped because the 448 cache entry has been lost and takes time to reinstate. Another possible 449 effect is that the control traffic caused by the forwarding engine 450 attempting to refresh the cache causes overload of the control processor 451 (and potentially causes routing adjacencies to be dropped). In 452 practice, this is only an issue if the forwarding engine does not have 453 sufficient space for the full routing table. Even then such attacks may 454 be difficult to perpetrate if the intended victim is not close to the 455 attacker. In other cases such an effect would normally only be seen in 456 the presence of a worm that manages to compromise a very large number of 457 hosts, and then scans widely in its attempt to propagate further. 459 Many modern routers use a loosely coupled architecture, where one or 460 more control processors handle the routing protocols, and communicate 461 over an internal network link to special-purpose forwarding engines, 462 which actually forward the data traffic. In such architectures it may 463 be possible for an attacker to overwhelm the communications link between 464 the control processor and the forwarding engine. This is possible 465 because the forwarding engines support very high speed links, and the 466 control processor simply cannot handle a similar rate of traffic. 468 There may be many ways in which an attacker can trigger communication 469 between the forwarding engines and the control processor. The simplest 470 way is for the attacker to simply send to the router's IP address, but 471 this should in principle be relatively easy to prevent using filtering 472 on the forwarding engines. Another way might be to cause the router to 473 forward data packets using the "slow path". This involves sending 474 packets that require special attention from the forwarding router; if 475 the forwarding engine is not smart enough to perform such forwarding, 476 then it will typically pass the packet to the control processor. In a 477 router using a forwarding cache, it may be possible to overload the 478 internal communications by thrashing the forwarding cache. Finally, any 479 form of data-triggered communication between the forwarding engine and 480 the control processor might cause such a problem. Certain multicast 481 routing protocols including PIM-SM contain many such data triggered 482 events that could potentially be problematic. 484 The effects of overloading such internal communications are hard to 485 predict, and very implementation-dependent. One possible effect might 486 be that the forwarding table in the forwarding engine gets out of 487 synchronization with the routing table in the control processor that 488 reflects what the routing protocols believe is happening. This might 489 cause traffic to be dropped or to loop. 491 2.3. DoS Attacks on Local Hosts or Infrastructure 493 There are a number of attacks that might only be performed by a local 494 attacker. 496 An attacker with access to a subnet may be able to prevent other local 497 hosts from accessing the network at all by simply exhausting the address 498 pool allocated by a DHCP server. This requires being able to spoof the 499 MAC address of an ethernet or wireless card, but this is quite feasible 500 with certain hardware and operating systems. 502 An alternative DHCP-based attack is simply to respond faster than the 503 legitimate DHCP server, and to give out an address that is not useful to 504 the victim. 506 These sort of bootstrapping attacks tend to be difficult to avoid 507 because most of the time trust relationships are established after IP 508 communication has already been established. 510 Similar attacks are possible through ARP spoofing [4]; an attacker can 511 respond to ARP requests before the victim and prevent traffic from 512 reaching the victim. Some brands of ethernet switch allow an even 513 simpler attack - simply send from the victim's MAC address, and the 514 switch will redirect traffic destined for the victim to the attacker's 515 port. 517 It may be possible to cause broadcast storms [4] on a local LAN by 518 sending a stream of unicast IP packets to the broadcast MAC address - 519 some hosts on the LAN may then attempt to forward the packets to the 520 correct MAC address greatly amplifying the traffic on the LAN. 522 802.11 wireless networks provide many opportunities to deny service to 523 other users. Unless encryption is enabled, it is trivial to announce 524 the presence of a basestation (or even ad-hoc mode host) with the same 525 network name (SSID) as the legitimate basestation. Most host stacks 526 don't deal gracefully with this. 528 Some 802.11 basestations have limited memory for the number of 529 associations they can support. If this is exceeded, they may drop all 530 associations. 532 Finally, as the authentication in 802.11 takes place at a comparatively 533 high level in the stack, it is possible to simply deauthenticate or 534 disassociate the victim from the basestation, even if WEP is in use 535 [25]. Bellardo and Savage [3] describe some simple remedies that reduce 536 the effectiveness of such attacks. 538 What all these attacks have in common is that they exploit 539 vulnerabilities in the link auto-configuration mechanisms. Such 540 problems are hard to solve because the reason for the existence of such 541 autoconfiguration mechanisms is ease of use, and to secure them requires 542 some form of authentication at a sufficiently early place in the 543 autoconfiguration process. 545 2.4. DoS Attacks on Sites though DNS 547 In today's Internet, DNS is of sufficient importance that if access to a 548 site's DNS servers is denied, the site is effectively unreachable, even 549 if there is no actual communication problem with the site itself. 551 Many of the attacks on end-systems described above can be perpetrated on 552 DNS servers. As servers go, DNS servers are not particularly vulnerable 553 to DoS. So long as a DNS server has sufficient memory, a modern host 554 can usually respond very rapidly to DNS requests for which it is 555 authoritative. This was demonstrated in October 2002 when the root 556 nameservers were subjected to a very large DoS attack [32]. A number of 557 the root nameservers have since been replicated using anycast [1] to 558 further improve their resistance to DoS. However it is important for 559 authoritative servers to have relaying disabled, or it is possible for 560 an attacker to force the DNS server to hold state [35]. 562 Many of the routing attacks can also be used against DNS servers by 563 targeting the routing for the server. If the DNS server is co-located 564 with the site for which is authoritative, then the fact that the DNS 565 server is also unavailable of secondary importance. However, if all the 566 DNS servers are made unavailable, this may cause email to that site to 567 bounce rather than being stored while the mail servers are unreachable, 568 so distribution of DNS server locations is important. 570 Causing network congestion on links to and from a DNS server can have 571 similar effects to end-system attacks or routing attacks, causing DNS to 572 fail to obtain an answer, and effectively denying access to the site 573 being served. 575 We note that if an attacker can deny external access to all the DNS for 576 a site, this will not only cause email to that site to be dropped, but 577 will also causes email from that site to be dropped. This is because 578 recent versions of mail transfer agents such as sendmail will drop email 579 if the mail originates from a domain that does not exist. This is a 580 classic example of unexpected consequences. Sendmail performs this 581 check as an anti-spam measure, and spam itself can be viewed as a form 582 of DoS attack. Thus defending against one DoS attack opens up the 583 vulnerability that allows another DoS attack. 585 Finally, a data corruption attack is possible if a site's nameserver is 586 permitted to relay requests from untrusted third parties [35]. The 587 attacker issues a query for the data he wishes to corrupt, and the 588 victim's nameserver relays the request to the authoritative nameserver. 589 The request contains a 16-bit ID that is used to match up the response 590 with the request. If the attacker spoofs sufficient response packets 591 from the authoritative nameserver just before the official response will 592 arrive, each containing a forged response and a different DNS ID, then 593 there is a reasonable chance that one of the forged responses will have 594 the correct DNS ID. The incorrect data will then be believed and cached 595 by the victim's nameserver, so giving the incorrect response to future 596 queries. The probability of the attack can further be increased if the 597 attacker issues many different requests for the same data with different 598 DNS IDs, because many nameserver implementations will the issue relayed 599 requests with different DNS IDs, and so the response only has to match 600 any one of these request IDs [6] [30]. 602 2.5. DoS Attacks on Links 604 The simplest DoS attack is to simply send enough non-congestion- 605 controlled traffic that a link becomes excessively congested, and 606 legitimate traffic suffers unacceptably high packet loss. 608 Under some circumstances the effect of such a link DoS can be much more 609 extensive. We have already discussed the effects of denying access to a 610 DNS server. Congesting a link might also cause a routing protocol to 611 drop an adjacency if sufficient routing packets are lost, potentially 612 greatly amplifying the effects of the attack. Good router 613 implementations will prioritize the transmission of routing packets, but 614 this is not a total panacea. If routers are peered across a shared 615 medium such as ethernet, it may be possible to congest the medium 616 sufficiently that routing packets are still lost. 618 Even if a link DoS does not cause routing packets to be lost, it may 619 prevent remote access to a router using ssh or SNMP. This might make 620 the router unmanageable, or prevent the attack being correctly 621 diagnosed. 623 The prioritization of routing packets can itself cause a DoS problem. 624 If the attacker can cause a large amount of routing flux, it may be 625 possible for a router to send routing packets at a high enough rate that 626 normal traffic is effectively excluded. This is however unlikely except 627 on low bandwidth links. 629 Finally, it may be possible to an attacker to deny access to a link by 630 causing the router to generate sufficient monitoring or report traffic 631 that the link is filled. SNMP traps are one possible vector for such an 632 attack, as they are not normally congestion controlled. 634 2.6. DoS attacks on firewalls 636 Firewalls are intended to defend the systems behind them against attack. 637 In that they restrict the traffic that can reach those systems, then may 638 also aid in defending against denial-of-service attacks. However, under 639 some circumstances the firewall itself may also be used as a weapon in a 640 DoS attack. 642 There are many different types of firewall, but generally speaking they 643 fall into stateful and stateless classes. The state here refers to 644 whether the firewall holds state for the active flows traversing the 645 firewall. Stateless firewalls generally can only be attacked by 646 attempting to exhaust the processing resources of the firewall. 647 Stateful firewalls can be attacked by sending traffic that causes the 648 firewall to hold excessive state or state which has pathological 649 structure. 651 In the case of excessive state, the firewall simply runs out of memory, 652 and can no longer instantiate the state required to pass legitimate 653 flows. Most firewalls will then fail closed, causing denial-of-service 654 to the systems behind the firewall. 656 In the case of pathological structure, the attacker sends traffic that 657 causes the firewall's data structures to exhibit worst case behaviour. 658 An example of this would be when the firewall uses hash tables to look 659 up forwarding state, and the attacker can predict the hash function 660 used. The attacker may then be able to cause a large amount of flow 661 state to hash to the same bucket, which causes the firewall's lookup 662 performance to change from O(1) to O(n), where n is the number of flows 663 the attacker can instantiate [17]. Thus the attacker can cause 664 forwarding performance to degrade to the point where service is 665 effectively denied to the legitimate traffic traversing the firewall. 667 2.7. DoS attacks on IDS systems 669 Intrusion detection systems (IDS) suffer from similar problems to 670 firewalls. It may be possible for an attacker to cause the IDS to 671 exhaust its available processing power, to run out of memory, or to 672 instantiate state with pathological structure. Unlike a firewall, an 673 IDS will normally fail open, which will not deny service to the systems 674 protected by the IDS. However it may mean that subsequent attacks that 675 the IDS would have detected will be missed. 677 Some IDSs are reactive; that is on detection of a hostile event they 678 react to block subsequent traffic from the hostile system, or to 679 terminate an ongoing connection from that system. It may be possible 680 for an attacker to spoof packets from a legitimate system, and hence 681 cause the IDS to believe that system is hostile. The IDS will then 682 cause traffic from the legitimate system to be blocks, hence denying 683 service to it. The effect can be particularly bad if the legitimate 684 system is a router, DNS server, or other system whose performance is 685 essential for the operation of a large number of other systems. 687 2.8. DoS attacks on or via NTP 689 Network time servers are generally not considered security-critical 690 services, but under some circumstances NTP servers might be used to 691 perpetrate a DoS attack. 693 The most obvious such attack is to DoS the NTP servers themselves. Many 694 end systems have rather poor clock accuracy and so, without access to 695 network time, their clock will naturally drift. This can cause problems 696 with distributed systems that rely on good clocks. For example one 697 commonly used revision control system can fail if it perceives the 698 modification timestamp to be in the future. 700 If the NTP servers relied on by a host can be subverted, either through 701 compromising or impersonating them, then the attacker may be able to 702 control the host's system clock. This can cause many unexpected 703 consequences, including the premature expiry of dated resources such as 704 encryption or authentication keys. This in turn can prevent access to 705 other more critical services. 707 2.9. Physical DoS 709 The discussion thus far has centered on denial-of-service attacks 710 perpetrated using the network. However, computer systems are only as 711 resilient as the weakest link. It may be easier to deny service by 712 causing a power failure, by cutting network cables, or by simply 713 switching a system off, and so physical security is at least as 714 important as network security. 716 2.10. Social Engineering DoS 718 The weakest link may also be human. In defending against DoS, the 719 possibility of denial-of-service through social engineering should not 720 be neglected, such as convincing an employee to make a configuration 721 change that prevents normal operation. 723 2.11. Legal DoS 725 Computer systems cannot be considered in isolation from the social and 726 legal systems in which they operate. This document focuses primarily on 727 the technical issues, but we note that "cease and desist" letters, 728 government censorship, and other legal mechanisms also touch on denial- 729 of-service issues. 731 2.12. Spam and Black-hole Lists 733 Unsolicited commercial email, also known as "spam", can effectively 734 cause denial-of-service to email systems. While the intent is not 735 denial-of-service, the large amount of unwanted mail can waste the 736 recipient's time, or cause legitimate email to fail to be noticed 737 amongst all the background noise. If spam filtering software is used, 738 some level of false positives is to be expected, and so these messages 739 are effectively denied service. 741 One mechanism to reduce spam is the use of black-hole lists. The IP 742 addresses of dial-up ISPs or mail servers used to originate or relay 743 spam are added to black-hole lists. The recipients of mail choose to 744 consult these lists and reject spam if it originates or is relayed by 745 systems on the list. One significant problem with such lists is that it 746 may be possible for an attacker to cause a victim to be black-hole 747 listed, even if the victim was not responsible for relaying spam. Thus 748 the black-hole list itself can be a mechanism for effecting a DoS 749 attack. Note that every black-hole list has its own policy regarding 750 additions, and some are less susceptible to this DoS attack than others. 751 Consumers of black-hole list technology are advised to investigate these 752 policies before they subscribe. 754 3. Attack Amplifiers 756 Many of the attacks described above rely on sending sufficient traffic 757 to overwhelm the victim. Such attacks are made much easier by the 758 existence of "attack amplifiers", where an attacker can send traffic 759 from the spoofed source address of the victim and cause a larger 760 responses to be returned to the victim. A detailed discussion of such 761 reflection attacks can be found in [28]. 763 The simplest such attack was the "smurf" attack [11], where an ICMP echo 764 request packet with the spoofed source address of the victim is sent to 765 the subnet-broadcast address of a network to be used as an amplifier. 766 Every system on that subnet then responds with an ICMP echo response 767 that returns to the victim. Smurf attacks are no longer such a serious 768 problem, as these days routers usually drop such packets and end-systems 769 do not respond to them. 771 An alternative form of attack amplifier is typified by a DNS reflection 772 attack. An attacker sends a DNS request to a DNS server requesting 773 resolution of a domain name. Again the source address of the request is 774 the spoofed address of the victim. The request is carefully chosen so 775 that the size of the response is significantly greater than the size of 776 the request, thereby providing the amplification. As an aside, it is 777 interesting to note that the largest DNS responses tend to be those 778 incorporating DNSsec authentication information. This attack amplifier 779 can only be used by an attacker with the ability to spoof the source 780 address of the victim. However, we note that if the victim's DNS server 781 is configured to relay requests from external clients, it may be 782 possible to cause it to congest its own incoming network link. 784 Another variant of attack amplifier involves amplification through 785 retransmission. This is typified by TCP amplification attack known as 786 "bang.c". The attacker sends a spoofed TCP SYN with the source address 787 of the victim to a arbitrary TCP server. The server will respond with a 788 SYN|ACK which is sent to the victim, and when no final ACK is received 789 to complete the handshake, the SYN|ACK will be retransmitted a number of 790 times. Typically this attack uses a very large list of arbitrarily 791 chosen servers as reflectors. For the attack to be successful, the 792 reflector must not receive a RST from the victim in response to the 793 SYN|ACK - however if the attack traffic sufficiently overwhelms the 794 server or access link to the server, then packet loss will ensure that 795 many reflectors do not receive a RST in response to their SYN|ACK, and 796 so continue to retransmit. The attack can be exacerbated by firewalls 797 that silently drop the incoming SYN|ACK without sending a RST. 799 In general, the architectural lessons to be learnt are simple: 801 o As far as possible, perform ingress filtering [21] [33] to prevent 802 source address filtering. 804 o Avoid designing protocols or mechanisms that can return 805 significantly larger responses than the size of the request, unless 806 a handshake is performed to validate the client's source address. 807 Such a handshake needs to incorporate an unpredictable nonce that is 808 secure enough to mitigate the amplification effects of the protocol. 810 o All retransmission during initial connection setup should be 811 performed by the client. 813 4. DoS Solutions 815 Although it is not in principle possible to distinguish between a flash- 816 crowd and a DoS attack, in practice it should be possible to raise the 817 bar high enough that an attacker is forced to disguise their attack as 818 legitimate traffic. This makes it much more expensive to perpetrate an 819 attack. In addition, the goal should be to make it impossible to 820 perpetrate an attack from an untraceable host. Thus, even though some 821 attacks may be impossible to prevent, the victim would then have legal 822 recourse. This does not however mean that anonymity should be 823 impossible at the application level; merely that the choice to interact 824 with an anonymous party should be at the discretion of the other party. 826 A guiding principle when hardening systems against DoS is to avoid 827 causing additional different avenues for attack. A classic example is 828 that of a mail server that verifies the "from" address of email is 829 resolvable, which allows email from a site to be DoSed by merely 830 preventing access to that site's DNS servers. 832 The guidelines below primarily concern the relatively obvious mechanisms 833 that are already reasonably well understood. The aim of this document 834 is to help protocol designers and network operators understand the state 835 of the art, and to stimulate discussion on additional architectural 836 solutions. 838 Don't Create an Attack Amplifier 840 The simplest guideline is to avoid building attack amplifiers and, as 841 far as possible, to perform ingress filtering to prevent compromised 842 systems on a subnet from spoofing the source address on packets. 844 Don't Hold State for Unverified Hosts 846 From an end-system server point of view, one simple aim is to avoid 847 instantiating state without having completed a handshake with the client 848 to validate their address, and as far as possible to push work and 849 stateholding to client. There are a number of techniques that might be 850 used to do this, including SYN-cookies [5] [2]. All client-server 851 protocols should probably be designed to allow such techniques to be 852 used, but the enabling of the mechanism should normally be at the 853 server's discretion to avoid unnecessary work under normal 854 circumstances. 856 State Lookup Complexity 858 Any system that instantiates per-connection state should take great care 859 to implement the state-lookup mechanisms in such a way that performance 860 can not be controlled by the attacker. One way to achieve this is to 861 use hash-tables where the hash mechanism is keyed in such a way that the 862 attacker cannot instantiate a large number of flows in the same hash 863 bucket. 865 Avoid Livelock 867 Most operating systems use network interrupts to receive data from the 868 network, which is a good solution if the host spends only a small amount 869 of its time handling network traffic. However, this leaves the host 870 open to livelock where under heavy load the OS spends all its time 871 handling interrupts and no time doing the work needed to handle the 872 traffic at the application level. Server operating systems should 873 consider using network polling at times of heavy load, rather that being 874 interrupt-driven, and should be carefully architected so that as far as 875 reasonably possible, traffic received by the OS is processed to 876 completion, or very cheaply discarded. 878 Use Unpredictable Values for Session IDs 880 Most recent TCP implementations use fairly good random mechanisms for 881 allocating the TCP initial sequence numbers. In general, any 882 dynamically allocated value used purely to identify a communications 883 session should be allocated using an unpredictable mechanism, as this 884 increases the search space for an attacker that wishes to disrupt 885 ongoing communications. Thus the dynamically allocated port of the 886 active end of a TCP connection might also randomly allocated. 888 With DNS, the ID which is used to match responses with requests should 889 also be randomly generated. However, as the ID field is only 16 bits, 890 the protection is rather limited, especially in the face of birthday 891 attacks. 893 Authenticate Routing Adjacencies 895 In general, cryptographic authentication mechanisms are too costly to 896 form the main part in DoS prevention. However, routing adjacencies are 897 too important to risk an attacker being able to inject bad routing 898 information, which can affect more than the router in question. 899 Additional non-cryptographic mechanisms should then be used to avoid 900 arbitrary end-systems being able to cause the router to spend CPU cycles 901 on validating authentication data. 903 For BGP, at the very least, this implies the use of TCP MD5 [23] or 904 IPsec authentication, combined with the TTL 255 hack [22] to prevent 905 EBGP association with non-immediate neighbours. In future, this will 906 likely imply better authentication of the routing information itself. 908 Isolate Router-to-Router Traffic 910 As far as is feasible, router-to-router traffic should be isolated from 911 data traffic. How this should be implemented depends on the precise 912 technologies available, both in the router and at the link-layer. The 913 goal should be that failure of the link for data traffic should also 914 cause failure for the routing traffic, but that an attacker cannot 915 directly send packets to the control processor of the routers. 917 A downside of this is that some diagnostic techniques (such as pinging 918 consecutive routers to find the source of a delay) may no longer be 919 possible. Ideally, alternative mechanisms (which do not open up 920 additional avenues for DoS) should be designed to replace such lost 921 techniques. 923 Graceful Routing Degradation 925 A goal with routing protocols is that of graceful degradation in 926 overload, and automatic recovery after the source of the overload has 927 been remedied. Some routing protocols satisfy this goal more than 928 others. Although RIP doesn't scale well, if a router runs out of memory 929 when receiving a RIP route, it can just drop the route and send an 930 infinite metric to its peers. The route will later be refreshed, and if 931 the original source of the problem has been resolved, the router will 932 now be able to process it correctly. 934 On the other hand, BGP is stateful in the sense that a peer assumes you 935 have processed or chosen to filter any route that it sent you. There is 936 no mechanism to refresh state in the base BGP spec, and even the later 937 route refresh option [15] is hard to use usefully in the presence of 938 overload. A BGP router that cannot store a route it received has two 939 choices: completely restart BGP, or shutdown one or more peerings This 940 means that the effects of a BGP overload are rather more severe than 941 they need to be, and so amplifies the effect of any attack. 943 In general, few routing protocol designs actively consider the possible 944 behaviour of routers under overload conditions; this should be an 945 explicit part of future routing protocol designs. Although precise 946 details should clearly be left to implementors, the protocol design 947 needs to give them the capability to do their job properly. 949 Source-Specific Multicast 951 Source-specific multicast is easier to manage than ASM, and opens up 952 many fewer avenues for DoS attack. However, ASM has many uses for 953 resource discovery and autoconfiguration. A prudent deployment strategy 954 would be to use SSM for inter-domain multicast and ASM only within the 955 more controlled environment of an intranet. In both environments, 956 administrative controls should be set to prevent a single receiver from 957 joining sufficient multicast groups to cause a state exhaustion problem 958 in the multicast routers. Such a threshold needs to take into account 959 that some multicast congestion control mechanisms use multiple multicast 960 groups to allow the receiver to select an appropriate rate. 962 In the future, multicast protocols may be deployed which use shared 963 bidirectional trees for interdomain multicast. Thus might allow ASM to 964 be deployed without the DoS vulnerabilities exhibited by current inter- 965 domain ASM solutions. Such solutions are not currently available. 967 Autoconfiguration and Authentication 969 Autoconfiguration mechanisms greatly ease deployment, and are 970 increasingly necessary as the number of networked devices grows beyond 971 what can be managed manually. However, it should be recognised that 972 unauthenticated autoconfiguration opens up many avenues for attack. 973 There is a clear tension between ease of configuration and security of 974 configuration. Future autoconfiguration protocols should consider the 975 need to allow different end-systems to operate at different points in 976 this spectrum within the same autoconfiguration framework. 978 Establish a Monitoring Framework 980 Network operators are strongly encouraged to establish a monitoring 981 framework to detect and log abnormal network activity. One can not 982 defend against an attack one doesn't detect or understand. Such 983 monitoring tools can be used to set a baseline of "normal" traffic, and 984 can be used to determine: 986 1. Aberrant flows. 988 2. Type and source of the aberrant flows. 990 This is extremely helpful when responding to DDoS or a flash crowd, and 991 should be in place prior to the event. 993 5. Conclusions 995 In this document we have highlighted possible avenues for DoS attack on 996 networks and networked systems, with the aim of encouraging protocol 997 designers and network engineers towards designs that are more robust. 998 We have discussed partial solutions that reduce the effectiveness of 999 attacks, and highlighted how some partial solutions can be taken 1000 advantage of by attackers to perpetrate alternative attacks. 1002 Our focus has primarily been on protocol and network architecture 1003 issues, but there are many things that network and service operators can 1004 do to lessen the threat. Further advice and information for network 1005 operators can be found in [13] [33] [14]. 1007 It is our hope that this document will spur discussion leading to 1008 architectural solutions that reduce the succeptibility of all Internet 1009 systems to denial-of-service attacks. 1011 6. Acknowledgements 1013 We are very grateful to Vern Paxson, Paul Vixie, Rob Thomas and Dug Song 1014 for their constructive comments on earlier versions of this document. 1016 7. Authors' Addresses 1018 Mark Handley 1019 Department of Computer Science 1020 University College London 1021 Gower Street 1022 London WC1E 6BT 1023 United Kingdom. 1025 Email: M.Handley@cs.ucl.ac.uk 1027 8. References 1029 [1] J. Abley, "Hierarchical Anycast for Global Service Distribution", 1030 http://www.isc.org/tn/isc-tn-2003-1.txt 1032 [2] T. Aura, P. Nikander, J. Leiwo, "DOS-resistant authentication with 1033 client puzzles", In B. Christianson, B. Crispo, and M. Roe, 1034 editors, Proceedings of the 8th International Workshop on Security 1035 Protocols, Lecture Notes in Computer Science, Cambridge, UK, April 1036 2000. 1038 [3] J. Bellardo, S. Savage, "802.11 Denial-of-Service Attacks: Real 1039 Vulnerabilities and Practical Solutions", Proceedings of the USENIX 1040 Security Symposium, Washington D.C., August 2003. 1042 [4] S.M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", 1043 Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April 1044 1989. 1046 [5] D.J. Bernstein, "SYN Cookies", http://cr.yp.to/syncookies.html 1048 [6] CCAIS/RNP Alertas do Cais ALR-19112002a, "Vulnerability in the 1049 sending requests control of Bind versions 4 and 8 allows DNS 1050 spoofing", http://www.rnp.br/cais/alertas/2002/cais- 1051 ALR-19112002a.html 1053 [7] CERT Advisory CA-1996-01, "UDP Port Denial-of-Service Attack", Feb 1054 1996. 1056 [8] CERT Advisory CA-1996-21, "TCP SYN Flooding and IP Spoofing 1057 Attacks", Sept 1996. 1059 [9] CERT Advisory CA-2001-09, "Statistical Weaknesses in TCP/IP Initial 1060 Sequence Numbers", May 2001. 1062 [10] CERT Advisory CA-1996-26, "Denial-of-Service Attack via ping", Dec 1063 1996. 1065 [11] CERT Advisory CA-1998-01, "Smurf IP Denial-of-Service Attacks", 1066 http://www.cert.org/advisories/CA-1998-01.html, Jan 1998. 1068 [12] CERT Incident Note IN-2000-05, "'mstream' Distributed Denial of 1069 Service Tool", May 2000. 1071 [13] CERT/CC - "Managing the Threat of Denial of Service Attacks", 1072 http://www.cert.org/archive/pdf/Managing_DoS.pdf 1074 [14] CERT/CC - "Trends in Denial of Service Attack Technology", 1075 http://www.cert.org/archive/pdf/DoS_trends.pdf 1077 D.-F. Chang, R. Govindan, J. Heidemann, "An Empirical Study of Router 1078 Response to Large Routing Table Load", Proceedings of the 2nd 1079 Internet Measurement Workshop (IMW 2002), 2002. 1081 [15] E. Chen, "Route Refresh Capability for BGP-4", RFC 2918, September 1082 2000 1084 [16] Cisco Systems, "Configuring the BGP Maximum-Prefix Feature", Cisco 1085 Document ID: 25160, http://www.cisco.com/warp/public/459/bgp- 1086 maximum-prefix.html 1088 [17] Scott A Crosby and Dan S Wallach, "Denial of Service via 1089 Algorithmic Complexity Attacks", Proceedings of the USENIX Security 1090 Symposium, Washington D.C., August 2003. 1092 [18] S. Deering, "Host extensions for IP multicasting", RFC 1112, Aug 1093 1989. 1095 [19] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, Jan 1096 1999. 1098 [20] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. 1099 Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol 1100 Independent Multicast-Sparse Mode (PIM-SM): Protocol 1101 Specification", RFC 2362, June 1998. 1103 [21] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating Denial 1104 of Service Attacks which employ IP Source Address Spoofing", RFC 1105 2827, May 2000. 1107 [22] V. Gill, J. Heasley, D. Meyer, "The BGP TTL Security Hack (BTSH)", 1108 draft-gill-btsh-02.txt (work in progress), 29-May-03. 1110 [23] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature 1111 Option", RFC 2385, August 1998. 1113 [24] Laurent Joncheray, "Simple Active Attack Against TCP", 5th USENIX 1114 Security Symposium, 1995. 1116 [25] M. Lough, "A Taxonomy of Computer Attacks with Applications to 1117 Wireless", PhD thesis, Virginia Polytechnic Institute, April 2001. 1119 [26] Z. Mao, R. Govindan, G. Varghese, R. Katz, "Route Flap Dampening 1120 Exacerbates Internet Routing Convergence", Proceedings of ACM 1121 SIGCOMM, 2002. 1123 [27] D. Meyer, W. Fenner (Editors), "Multicast Source Discovery Protocol 1124 (MSDP)", draft-ietf-msdp-spec-15.txt, Work in Progress. 1126 J. Mogul, KK. Ramakrishnan, "Eliminating Receive Livelock in an 1127 Interrupt-driven Kernel", ACM Transactions on Computer Systems, Vol 1128 15, Number 3, pp. 217-252, 1997. 1130 [28] V. Paxson, "An Analysis of Using Reflectors for Distributed Denial- 1131 of-Service Attacks", Computer Communication Review 31(3), July 1132 2001. 1134 [29] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, 1135 March 1995. 1137 [30] Joe Stewart, "DNS Cache Poisoning - The Next Generation", Jan 27 1138 2003, http://www.securityfocus.com/guest/17905 1140 [31] C. Villamizar, R. Chandra, R. Govindan, "BGP Route Flap Damping", 1141 RFC 2439, November 1998. 1143 [32] P. Vixie, G. Sneeringer, M. Schleifer, "Events of 21-Oct-2002", 1144 http://f.root-servers.org/october21.txt 1146 [33] P. Vixie, "Securing the Edge", 1147 http://www.icann.org/committees/security/sac004.txt 1149 [34] D. Waitzman, C. Partridge, S.E. Deering, "Distance Vector Multicast 1150 Routing Protocol", RFC 1075, Nov 1988. 1152 [35] D. Wessels, "Running An Authoritative-Only BIND Nameserver", 1153 http://www.isc.org/tn/isc-tn-2002-2.txt 1155 [36] M. Zalewski, "Strange Attractors and TCP/IP Sequence Number 1156 Analysis", http://razor.bindview.com/publish/papers/tcpseq.html