idnits 2.17.1 draft-iab-dos-01.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 (10 May 2004) is 7290 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. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' ** Obsolete normative reference: RFC 2246 (ref. '20') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2362 (ref. '21') (Obsoleted by RFC 4601, RFC 5059) -- Possible downref: Normative reference to a draft: ref. '23' ** Obsolete normative reference: RFC 2385 (ref. '24') (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. '25' -- Possible downref: Non-RFC (?) normative reference: ref. '26' -- Possible downref: Non-RFC (?) normative reference: ref. '27' == 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. '28') -- Possible downref: Non-RFC (?) normative reference: ref. '29' -- Possible downref: Non-RFC (?) normative reference: ref. '30' -- Possible downref: Non-RFC (?) normative reference: ref. '31' ** Obsolete normative reference: RFC 1771 (ref. '32') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '33' == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-00 -- Possible downref: Non-RFC (?) normative reference: ref. '36' -- Possible downref: Non-RFC (?) normative reference: ref. '37' ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '38') -- Possible downref: Non-RFC (?) normative reference: ref. '39' -- Possible downref: Non-RFC (?) normative reference: ref. '40' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 31 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-01.txt 10 May 2004 4 Expires: November 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 [32] 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 than 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 [29] where, after saturation, increasing the load causes a decrease in 240 the 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 [25]. Such attacks are not prevented by 252 transport or application-level security mechanisms such as TLS [20] 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, this might require an excessively large number of spoofed 260 packets to guess both the port of the active end of the TCP connection 261 (in most cases the port of the passive end is predictable) and the 262 currently valid TCP sequence numbers. However, as some operating 263 systems have poorly implemented predictable algorithms for selecting 264 either the dynamically selected port or the TCP initial sequence number 265 [40] [9], then such attacks have been found to be feasible [30]. Advice 266 as to how to reduce the vulnerability in the specific case of TCP is 267 available in [34]. 269 An attacker might be able to significantly reduce the throughput of a 270 connection by sending spoofed ICMP source quench packets, although most 271 modern operating systems should ignore such packets. However, care 272 should be taken in the design of future transport and signaling 273 protocols to avoid the introduction of similar mechanisms that could be 274 exploited. 276 2.1.5. Attacks using the Victim's Own Resources 278 Instead of directly overloading the victim, it may be possible to cause 279 the victim or a machine on the same subnet as the victim to overload 280 itself. 282 An example of such an attack is documented in [7], where the attacker 283 spoofs the source address on a packet sent to the victim's UDP echo 284 port. The source address is that of another machine that is running a 285 UDP chargen server (a chargen server sends a character pattern back to 286 the originating source). The result is that the two machines bounce 287 packets back and forth as fast as they can, overloading either the 288 network between them or one of the end-systems itself. 290 2.1.6. Triggered Lockouts and Quota Exhaustion 292 Many user-authentication mechanisms attempt to protect against password 293 guessing attacks by locking the user out after a small number of failed 294 authentications. If an attacker can guess or discover a user's ID, they 295 may be able to trigger such a mechanism, locking out the legitimate 296 user. 298 Another way to deny service using protection mechanisms is to cause a 299 quota to be exhausted. This is perhaps most common in the case of small 300 web servers being commercially hosted, where the server has a contract 301 with the hosting company allowing a fixed amount of traffic per day. An 302 attacker may be able to rapidly exhaust this quota, and cause service to 303 be suspended. Similar attacks may be possible against other forms of 304 quota. 306 In the absence of such quotas, if the victim is charged for their 307 network traffic, a financial denial-of-service may be possible. 309 2.2. DoS Attacks on Routers 311 Many of the denial-of-service attacks that can be launched against end- 312 systems can also be launched against the control processor of an IP 313 router, for example by flooding the ssh or telnet ports. In the case of 314 a router, these attacks may cause the router to reboot, or may cause the 315 router to cease processing routing packets. Even if the router does not 316 stop servicing routing packets, it may become sufficiently slow that 317 routing protocols time out. In any of these circumstances, the 318 consequence of routing failure is not only that the router ceases to 319 forward traffic, but also that it causes routing protocol churn that may 320 have further side effects. 322 An example of such a side effect is caused by BGP route flap damping 323 [35], which is intended to reduce global routing churn. If an attacker 324 can cause BGP routing churn, route flap damping may then cause the 325 flapping routes to be suppressed [27]. 327 A DoS attack on the router control processor might also prevent the 328 router being managed effectively. This may prevent actions being taken 329 that would mitigate the DoS attack, and it might prevent diagnosis of 330 the cause of the problem. 332 2.2.1. Attacks on Routers through Routing Protocols 334 In addition to their roles as end-systems, most routers run dynamic 335 routing protocols. The routing protocols themselves can be used to 336 stage a DoS attack on a router or a network of routers. To inject 337 routing information into a routing protocol, an attacker needs access 338 either to a router or to a end-host on a subnet where a routing protocol 339 is running. In the latter case, if the routing protocol running on that 340 subnet is not authenticated, the end-host may be able to insert spoofed 341 routing information or pretend to be a router. 343 The simplest attack on a network of routers is to overload the routing 344 table with sufficiently many routes that the router runs out of memory, 345 or the router has insufficient CPU power to process the routes [15]. We 346 note that depending on the distribution and capacities of various 347 routers around the network, such an attack might not overwhelm routers 348 near to the attacking router, but might cause problems to show up 349 elsewhere in the network. 351 Some routing protocols allow limits to be configured on the maximum 352 number of routes to be heard from a neighbor [17]. However, if such a 353 limit doesn't block the spoofed routes at source, then imposition of 354 such a limit elsewhere in the network might cause legitimate routes to 355 be dropped. 357 An alternative attack is to overload the routers on the network by 358 creating sufficient routing table churn that routers are unable to 359 process the changes. Many routing protocols allow damping factors to be 360 configured to avoid just such a problem. However, as with table size, 361 such a threshold applied inconsistently may allow the spoofed routes to 362 merge with legitimate routes before the mechanism is applied, causing 363 legitimate routes to be damped. 365 The simplest routing attack on a specific destination is for an attacker 366 to announce a spoofed desirable route to that destination. Such a route 367 might be desirable because it has low metric, or because it is a more 368 specific route than the legitimate route. In any event, if the route is 369 believed it will cause traffic for the victim to be drawn towards the 370 attacking router, where it will typically be discarded. 372 A more subtle denial-of-service attack might be launched against a 373 network rather than against a destination. Under some circumstances, 374 the propagation of inconsistent routing information can cause traffic to 375 loop. If an attacker can cause this to happen on a busy path, the 376 looping traffic might cause significant congestion, as well as not 377 reaching the legitimate destination. However in many cases severe 378 congestion is unlikely because TCP's congestion control will shut down 379 the majority of traffic that fails to reach the destination. 381 If an attacker has access to a host on the same subnet as a router 382 running certain routing protocols, even if that router is configured not 383 to accept routes, it might be possible to cause that router to run out 384 of memory by spoofing the existence of fake routers on that subnet. 386 In the past there have been cases where different generations of routers 387 interpreted a routing protocol specification differently. In 388 particular, BGP specifies that in the case of an error, the BGP peering 389 should be dropped. However, if some of the routers in a network treat a 390 particular route as valid and other routes treat the route as invalid, 391 then it may be possible to inject a BGP route at one point in the 392 Internet and cause peerings to be dropped at many other places in the 393 Internet. Unlike many of the examples above, while such an issue might 394 be a serious short-term problem, this is not a fundamental architectural 395 problem. Once the problem is understood, deploying patched routing code 396 can permanently solve the issue. 398 2.2.2. IP Multicast-based DoS Attacks 400 There are essentially two forms of IP multicast: "traditional" IP 401 multicast (ASM), as specified in RFC 1112 [19] where multiple sources 402 can send to the same multicast group, and source-specific multicast 403 (SSM) where the receiver must specify both the IP source address and the 404 group address. The two forms of multicast provide rather different DoS 405 possibilities. 407 With ASM, an attacker can simply send to multiple multicast groups. 408 Routing protocols such as PIM-SM [21], MSDP [28] and DVMRP [38] then 409 have to instantiate routing state to ensure that the traffic goes to the 410 group receivers and not to non-receivers. Thus ASM is particularly 411 vulnerable to DoS attacks causing both multicast routing table explosion 412 (and hence control processor memory exhaustion) and multicast forwarding 413 table exhaustion (and hence forwarding card memory exhaustion or 414 thrashing). 416 ASM also permits an attacker to send traffic to the same group as 417 legitimate traffic, potentially causing network congestion and denying 418 service to the legitimate group. 420 However, unlike unicast traffic, it is comparatively difficult to spoof 421 source addresses for IP multicast traffic. Most deployed IP multicast 422 routing protocols use reverse-path checks to build the forwarding tree, 423 and so multicast attackers are easily located. In addition, multicast 424 traffic will only continue to flow to a receiver as long as the receiver 425 joins the multicast group. Thus it may be harder to use multicast 426 traffic to cause a denial-of-service attack on a destination - an 427 attacker would need to be opportunistic, sending traffic to a multicast 428 group that is already being received by the victim or another host 429 located close to the victim. 431 SSM does not permit senders to send to arbitrary groups unless a 432 receiver has requested the traffic. Thus sender-based attacks on 433 multicast routing state are not possible with SSM. However, as with 434 ASM, a receiver can still join a large number of multicast groups 435 causing routers to hold a large amount of multicast routing state, 436 potentially causing memory exhaustion and hence denial-of-service to 437 legitimate traffic. 439 With IPv6, hosts are required to send ICMP Packet Too Big or Parameter 440 Problem messages under certain circumstances, even if the destination 441 address is a multicast address. If the attacker can place himself in the 442 appropriate position in the multicast tree, a packet with an unknown but 443 mandatory Destination Option, for instance, could generate a very large 444 number of responses to the claimed sender. 446 With IPv4 the same problem exists with multicast ICMP Echo Request 447 packets, but these are somewhat easier to filter. 449 2.2.3. Attacks on Router Forwarding Engines 451 Router vendors implement many different mechanisms for packet 452 forwarding, but broadly speaking they fall into two categories: ones 453 that use a forwarding cache, and ones that do not. With a forwarding 454 cache, the forwarding engine does not hold the full routing table, but 455 rather holds just the currently active subset of the forwarding table. 457 Routers or switches using a forwarding cache are potentially vulnerable 458 if an attacker can send many packets to different destinations through 459 the same router, causing the forwarding cache to thrash. One effect of 460 this is likely to be that legitimate traffic is dropped because the 461 cache entry has been lost and takes time to reinstate. Another possible 462 effect is that the control traffic caused by the forwarding engine 463 attempting to refresh the cache causes overload of the control processor 464 (and potentially causes routing adjacencies to be dropped). In 465 practice, this is only an issue if the forwarding engine does not have 466 sufficient space for the full routing table. Even then such attacks may 467 be difficult to perpetrate if the intended victim is not close to the 468 attacker. In other cases such an effect would normally only be seen in 469 the presence of a worm that manages to compromise a very large number of 470 hosts, and then scans widely in its attempt to propagate further. 472 Many modern routers use a loosely coupled architecture, where one or 473 more control processors handle the routing protocols, and communicate 474 over an internal network link to special-purpose forwarding engines, 475 which actually forward the data traffic. In such architectures it may 476 be possible for an attacker to overwhelm the communications link between 477 the control processor and the forwarding engine. This is possible 478 because the forwarding engines support very high speed links, and the 479 control processor simply cannot handle a similar rate of traffic. 481 There may be many ways in which an attacker can trigger communication 482 between the forwarding engines and the control processor. The simplest 483 way is for the attacker to simply send to the router's IP address, but 484 this should in principle be relatively easy to prevent using filtering 485 on the forwarding engines. Another way might be to cause the router to 486 forward data packets using the "slow path". This involves sending 487 packets that require special attention from the forwarding router; if 488 the forwarding engine is not smart enough to perform such forwarding, 489 then it will typically pass the packet to the control processor. In a 490 router using a forwarding cache, it may be possible to overload the 491 internal communications by thrashing the forwarding cache. Finally, any 492 form of data-triggered communication between the forwarding engine and 493 the control processor might cause such a problem. Certain multicast 494 routing protocols including PIM-SM contain many such data triggered 495 events that could potentially be problematic. 497 The effects of overloading such internal communications are hard to 498 predict, and very implementation-dependent. One possible effect might 499 be that the forwarding table in the forwarding engine gets out of 500 synchronization with the routing table in the control processor that 501 reflects what the routing protocols believe is happening. This might 502 cause traffic to be dropped or to loop. 504 Finally, if an attacker can generate traffic that causes a router to 505 install access control list (ACL) entries, perhaps by triggering a 506 response from an intrusion detection system, then it may be possible to 507 exhaust the hardware ACL resources on the router. This might prevent 508 future attacks from being filtered, or worse, cause ACL processing to be 509 handled by the route processor. 511 2.3. DoS Attacks on Local Hosts or Infrastructure 513 There are a number of attacks that might only be performed by a local 514 attacker. 516 An attacker with access to a subnet may be able to prevent other local 517 hosts from accessing the network at all by simply exhausting the address 518 pool allocated by a DHCP server. This requires being able to spoof the 519 MAC address of an ethernet or wireless card, but this is quite feasible 520 with certain hardware and operating systems. 522 An alternative DHCP-based attack is simply to respond faster than the 523 legitimate DHCP server, and to give out an address that is not useful to 524 the victim. 526 These sorts of bootstrapping attacks tend to be difficult to avoid 527 because most of the time trust relationships are established after IP 528 communication has already been established. 530 Similar attacks are possible through ARP spoofing [4]; an attacker can 531 respond to ARP requests before the victim and prevent traffic from 532 reaching the victim. Some brands of ethernet switch allow an even 533 simpler attack - simply send from the victim's MAC address, and the 534 switch will redirect traffic destined for the victim to the attacker's 535 port. 537 It may be possible to cause broadcast storms [4] on a local LAN by 538 sending a stream of unicast IP packets to the broadcast MAC address - 539 some hosts on the LAN may then attempt to forward the packets to the 540 correct MAC address greatly amplifying the traffic on the LAN. 542 802.11 wireless networks provide many opportunities to deny service to 543 other users. Unless encryption is enabled, it is trivial to announce 544 the presence of a basestation (or even of an ad-hoc mode host) with the 545 same network name (SSID) as the legitimate basestation. Even adding 546 authentication and encryption a la 802.1X and 802.11i may not help much 547 in this respect. The SSID space is unmanaged, so everyone's free to put 548 anything they want in the SSID field. Most host stacks don't deal 549 gracefully with this. 551 Some 802.11 basestations have limited memory for the number of 552 associations they can support. If this is exceeded, they may drop all 553 associations. 555 Finally, as the authentication in 802.11 takes place at a comparatively 556 high level in the stack, it is possible to simply deauthenticate or 557 disassociate the victim from the basestation, even if WEP is in use 558 [26]. Bellardo and Savage [3] describe some simple remedies that reduce 559 the effectiveness of such attacks. 561 What all these attacks have in common is that they exploit 562 vulnerabilities in the link auto-configuration mechanisms. Such 563 problems are hard to solve because the reason for the existence of such 564 autoconfiguration mechanisms is ease of use, and to secure them requires 565 some form of authentication at a sufficiently early place in the 566 autoconfiguration process. 568 2.4. DoS Attacks on Sites though DNS 570 In today's Internet, DNS is of sufficient importance that if access to a 571 site's DNS servers is denied, the site is effectively unreachable, even 572 if there is no actual communication problem with the site itself. 574 Many of the attacks on end-systems described above can be perpetrated on 575 DNS servers. As servers go, DNS servers are not particularly vulnerable 576 to DoS. So long as a DNS server has sufficient memory, a modern host 577 can usually respond very rapidly to DNS requests for which it is 578 authoritative. This was demonstrated in October 2002 when the root 579 nameservers were subjected to a very large DoS attack [36]. A number of 580 the root nameservers have since been replicated using anycast [1] to 581 further improve their resistance to DoS. However it is important for 582 authoritative servers to have relaying disabled, or it is possible for 583 an attacker to force the DNS servers to hold state [39]. 585 Many of the routing attacks can also be used against DNS servers by 586 targeting the routing for the server. If the DNS server is co-located 587 with the site for which is authoritative, then the fact that the DNS 588 server is also unavailable of secondary importance. However, if all the 589 DNS servers are made unavailable, this may cause email to that site to 590 bounce rather than being stored while the mail servers are unreachable, 591 so distribution of DNS server locations is important. 593 Causing network congestion on links to and from a DNS server can have 594 similar effects to end-system attacks or routing attacks, causing DNS to 595 fail to obtain an answer, and effectively denying access to the site 596 being served. 598 We note that if an attacker can deny external access to all the DNS for 599 a site, this will not only cause email to that site to be dropped, but 600 will also cause email from that site to be dropped. This is because 601 recent versions of mail transfer agents such as sendmail will drop email 602 if the mail originates from a domain that does not exist. This is a 603 classic example of unexpected consequences. Sendmail performs this 604 check as an anti-spam measure, and spam itself can be viewed as a form 605 of DoS attack. Thus defending against one DoS attack opens up the 606 vulnerability that allows another DoS attack. 608 Finally, a data corruption attack is possible if a site's nameserver is 609 permitted to relay requests from untrusted third parties [39]. The 610 attacker issues a query for the data he wishes to corrupt, and the 611 victim's nameserver relays the request to the authoritative nameserver. 612 The request contains a 16-bit ID that is used to match up the response 613 with the request. If the attacker spoofs sufficient response packets 614 from the authoritative nameserver just before the official response will 615 arrive, each containing a forged response and a different DNS ID, then 616 there is a reasonable chance that one of the forged responses will have 617 the correct DNS ID. The incorrect data will then be believed and cached 618 by the victim's nameserver, so giving the incorrect response to future 619 queries. The probability of the attack can further be increased if the 620 attacker issues many different requests for the same data with different 621 DNS IDs, because many nameserver implementations will the issue relayed 622 requests with different DNS IDs, and so the response only has to match 623 any one of these request IDs [6] [33]. 625 2.5. DoS Attacks on Links 627 The simplest DoS attack is to simply send enough non-congestion- 628 controlled traffic that a link becomes excessively congested, and 629 legitimate traffic suffers unacceptably high packet loss. 631 Under some circumstances the effect of such a link DoS can be much more 632 extensive. We have already discussed the effects of denying access to a 633 DNS server. Congesting a link might also cause a routing protocol to 634 drop an adjacency if sufficient routing packets are lost, potentially 635 greatly amplifying the effects of the attack. Good router 636 implementations will prioritize the transmission of routing packets, but 637 this is not a total panacea. If routers are peered across a shared 638 medium such as ethernet, it may be possible to congest the medium 639 sufficiently that routing packets are still lost. 641 Even if a link DoS does not cause routing packets to be lost, it may 642 prevent remote access to a router using ssh or SNMP. This might make 643 the router unmanageable, or prevent the attack being correctly 644 diagnosed. 646 The prioritization of routing packets can itself cause a DoS problem. 647 If the attacker can cause a large amount of routing flux, it may be 648 possible for a router to send routing packets at a high enough rate that 649 normal traffic is effectively excluded. This is however unlikely except 650 on low bandwidth links. 652 Finally, it may be possible to an attacker to deny access to a link by 653 causing the router to generate sufficient monitoring or report traffic 654 that the link is filled. SNMP traps are one possible vector for such an 655 attack, as they are not normally congestion controlled. 657 2.6. DoS attacks on firewalls 659 Firewalls are intended to defend the systems behind them against attack. 660 In that they restrict the traffic that can reach those systems, they may 661 also aid in defending against denial-of-service attacks. However, under 662 some circumstances the firewall itself may also be used as a weapon in a 663 DoS attack. 665 There are many different types of firewall, but generally speaking they 666 fall into stateful and stateless classes. The state here refers to 667 whether the firewall holds state for the active flows traversing the 668 firewall. Stateless firewalls generally can only be attacked by 669 attempting to exhaust the processing resources of the firewall. 670 Stateful firewalls can be attacked by sending traffic that causes the 671 firewall to hold excessive state or state which has pathological 672 structure. 674 In the case of excessive state, the firewall simply runs out of memory, 675 and can no longer instantiate the state required to pass legitimate 676 flows. Most firewalls will then fail closed, causing denial-of-service 677 to the systems behind the firewall. 679 In the case of pathological structure, the attacker sends traffic that 680 causes the firewall's data structures to exhibit worst case behaviour. 681 An example of this would be when the firewall uses hash tables to look 682 up forwarding state, and the attacker can predict the hash function 683 used. The attacker may then be able to cause a large amount of flow 684 state to hash to the same bucket, which causes the firewall's lookup 685 performance to change from O(1) to O(n), where n is the number of flows 686 the attacker can instantiate [18]. Thus the attacker can cause 687 forwarding performance to degrade to the point where service is 688 effectively denied to the legitimate traffic traversing the firewall. 690 2.7. DoS attacks on IDS systems 692 Intrusion detection systems (IDS) suffer from similar problems to 693 firewalls. It may be possible for an attacker to cause the IDS to 694 exhaust its available processing power, to run out of memory, or to 695 instantiate state with pathological structure. Unlike a firewall, an 696 IDS will normally fail open, which will not deny service to the systems 697 protected by the IDS. However it may mean that subsequent attacks that 698 the IDS would have detected will be missed. 700 Some IDSs are reactive; that is on detection of a hostile event they 701 react to block subsequent traffic from the hostile system, or to 702 terminate an ongoing connection from that system. It may be possible 703 for an attacker to spoof packets from a legitimate system, and hence 704 cause the IDS to believe that system is hostile. The IDS will then 705 cause traffic from the legitimate system to be blocked, hence denying 706 service to it. The effect can be particularly bad if the legitimate 707 system is a router, DNS server, or other system whose performance is 708 essential for the operation of a large number of other systems. 710 2.8. DoS attacks on or via NTP 712 Network time servers are generally not considered security-critical 713 services, but under some circumstances NTP servers might be used to 714 perpetrate a DoS attack. 716 The most obvious such attack is to DoS the NTP servers themselves. Many 717 end systems have rather poor clock accuracy and so, without access to 718 network time, their clock will naturally drift. This can cause problems 719 with distributed systems that rely on good clocks. For example one 720 commonly used revision control system can fail if it perceives the 721 modification timestamp to be in the future. 723 If the NTP servers relied on by a host can be subverted, either through 724 compromising or impersonating them, then the attacker may be able to 725 control the host's system clock. This can cause many unexpected 726 consequences, including the premature expiry of dated resources such as 727 encryption or authentication keys. This in turn can prevent access to 728 other more critical services. 730 2.9. Physical DoS 732 The discussion thus far has centered on denial-of-service attacks 733 perpetrated using the network. However, computer systems are only as 734 resilient as the weakest link. It may be easier to deny service by 735 causing a power failure, by cutting network cables, or by simply 736 switching a system off, and so physical security is at least as 737 important as network security. 739 2.10. Social Engineering DoS 741 The weakest link may also be human. In defending against DoS, the 742 possibility of denial-of-service through social engineering should not 743 be neglected, such as convincing an employee to make a configuration 744 change that prevents normal operation. 746 2.11. Legal DoS 748 Computer systems cannot be considered in isolation from the social and 749 legal systems in which they operate. This document focuses primarily on 750 the technical issues, but we note that "cease and desist" letters, 751 government censorship, and other legal mechanisms also touch on denial- 752 of-service issues. 754 2.12. Spam and Black-hole Lists 756 Unsolicited commercial email, also known as "spam", can effectively 757 cause denial-of-service to email systems. While the intent is not 758 denial-of-service, the large amount of unwanted mail can waste the 759 recipient's time, or cause legitimate email to fail to be noticed 760 amongst all the background noise. If spam filtering software is used, 761 some level of false positives is to be expected, and so these messages 762 are effectively denied service. 764 One mechanism to reduce spam is the use of black-hole lists. The IP 765 addresses of dial-up ISPs or mail servers used to originate or relay 766 spam are added to black-hole lists. The recipients of mail choose to 767 consult these lists and reject spam if it originates or is relayed by 768 systems on the list. One significant problem with such lists is that it 769 may be possible for an attacker to cause a victim to be black-hole 770 listed, even if the victim was not responsible for relaying spam. Thus 771 the black-hole list itself can be a mechanism for effecting a DoS 772 attack. Note that every black-hole list has its own policy regarding 773 additions, and some are less susceptible to this DoS attack than others. 774 Consumers of black-hole list technology are advised to investigate these 775 policies before they subscribe. 777 3. Attack Amplifiers 779 Many of the attacks described above rely on sending sufficient traffic 780 to overwhelm the victim. Such attacks are made much easier by the 781 existence of "attack amplifiers", where an attacker can send traffic 782 from the spoofed source address of the victim and cause larger responses 783 to be returned to the victim. A detailed discussion of such reflection 784 attacks can be found in [31]. 786 The simplest such attack was the "smurf" attack [11], where an ICMP echo 787 request packet with the spoofed source address of the victim is sent to 788 the subnet-broadcast address of a network to be used as an amplifier. 789 Every system on that subnet then responds with an ICMP echo response 790 that returns to the victim. Smurf attacks are no longer such a serious 791 problem, as these days routers usually drop such packets and end-systems 792 do not respond to them. 794 An alternative form of attack amplifier is typified by a DNS reflection 795 attack. An attacker sends a DNS request to a DNS server requesting 796 resolution of a domain name. Again the source address of the request is 797 the spoofed address of the victim. The request is carefully chosen so 798 that the size of the response is significantly greater than the size of 799 the request, thereby providing the amplification. As an aside, it is 800 interesting to note that the largest DNS responses tend to be those 801 incorporating DNSsec authentication information. This attack amplifier 802 can only be used by an attacker with the ability to spoof the source 803 address of the victim. However, we note that if the victim's DNS server 804 is configured to relay requests from external clients, it may be 805 possible to cause it to congest its own incoming network link. 807 Another variant of attack amplifier involves amplification through 808 retransmission. This is typified by a TCP amplification attack known as 809 "bang.c". The attacker sends a spoofed TCP SYN with the source address 810 of the victim to a arbitrary TCP server. The server will respond with a 811 SYN|ACK which is sent to the victim, and when no final ACK is received 812 to complete the handshake, the SYN|ACK will be retransmitted a number of 813 times. Typically this attack uses a very large list of arbitrarily 814 chosen servers as reflectors. For the attack to be successful, the 815 reflector must not receive a RST from the victim in response to the 816 SYN|ACK - however if the attack traffic sufficiently overwhelms the 817 server or access link to the server, then packet loss will ensure that 818 many reflectors do not receive a RST in response to their SYN|ACK, and 819 so continue to retransmit. The attack can be exacerbated by firewalls 820 that silently drop the incoming SYN|ACK without sending a RST. 822 Care must also be taken with services that relay requests. If an 823 attacker can send a request to a proxy, and that proxy now attempts to 824 connect to a victim whose address is chosen by the attacker then, if the 825 proxy repeatedly resends the request when receiving no answer, this can 826 also serve as an attack amplifier. 828 Another variant of amplification occurs in protocols that include, 829 within the protocol payload, an IP address or name of host to which 830 subsequent messages should be sent. An example of such as protocol is 831 the Session Initiation Protocol (SIP), which carries a payload defined 832 by the Session Description Protocol (SDP). The SDP payload of the SIP 833 message conveys the IP address and port to which media packets, 834 typically encoded using the Real Time Transport Protocol (RTP), are 835 sent. 837 To launch this attack, an attacker sends a protocol message, and sets 838 the IP address within the payload to point to the attack target. The 839 recipient of the message will generate subsequent traffic to that IP 840 address. Depending on the protocol, this attack can provide substantial 841 amplification properties. In the specific case of SIP, if a caller makes 842 calls to high bandwidth media sources (such as a video server or 843 streaming audio server), a single SIP INVITE packet, typically a few 844 hundred bytes, can result in a nearly continuous stream of media packets 845 at rates anywhere from a few kbits per second up to megabits per second. 846 This particular attack is called the "voice hammer". 848 Unlike the other techniques described above, this technique does not 849 require the attacker to modify packets or even spoof their source IP 850 address. This makes it easier to launch. 852 This attack is prevented through careful protocol design. Protocols 853 should, whenever possible, avoid including IP addresses or hostnames 854 within protocol payloads as addresses to which subsequent messaging 855 should be sent. Rather, when possible, messages should be sent to the 856 source IP from which the protocol packet came. If such a design is not 857 possible, the protocol should include a handshake whereby it can be 858 positively determined that the protocol entity at that IP address or 859 hostname does, in fact, wish to receive that subsequent messaging. That 860 handshake itself needs to be lightweight (to avoid being the source of 861 another DoS attack), and secured against the spoofing of the handshake 862 response. 864 Finally, a somewhat similar attack is possible with some protocols where 865 where one message leads to another message that is not sent as a reply 866 to the source address of the first message. This can be an issue with 867 protocols to enable mobility for example, and might permit an attacker 868 to avoid ingress filtering. Such protocols are notoriously difficult to 869 get right. 871 In general, the architectural lessons to be learnt are simple: 873 o As far as possible, perform ingress filtering [22] [37] to prevent 874 source address spoofing. 876 o Avoid designing protocols or mechanisms that can return 877 significantly larger responses than the size of the request, unless 878 a handshake is performed to validate the client's source address. 879 Such a handshake needs to incorporate an unpredictable nonce that is 880 secure enough to mitigate the amplification effects of the protocol. 882 o All retransmission during initial connection setup should be 883 performed by the client. 885 o Proxies should not arbitrarily relay requests to destinations chosen 886 by a client. 888 o Avoid signaling third-party connections. Any unavoidable third- 889 party connections setup by a signaling protocol should incorporate 890 lightweight validation before sending significant data. 892 4. DoS Solutions 894 Although it is not in principle possible to distinguish between a flash- 895 crowd and a DoS attack, in practice it should be possible to raise the 896 bar high enough that an attacker is forced to disguise their attack as 897 legitimate traffic. This makes it much more expensive to perpetrate an 898 attack. In addition, the goal should be to make it impossible to 899 perpetrate an attack from an untraceable host. Thus, even though some 900 attacks may be impossible to prevent, the victim would then have legal 901 recourse. This does not however mean that anonymity should be 902 impossible at the application level; merely that the choice to interact 903 with an anonymous party should be at the discretion of the other party. 905 A guiding principle when hardening systems against DoS is to avoid 906 causing additional different avenues for attack. A classic example is 907 that of a mail server that verifies the "from" address of email is 908 resolvable, which allows email from a site to be DoSed by merely 909 preventing access to that site's DNS servers. 911 The guidelines below primarily concern the relatively obvious mechanisms 912 that are already reasonably well understood. The aim of this document 913 is to help protocol designers and network operators understand the state 914 of the art, and to stimulate discussion on additional architectural 915 solutions. 917 Don't Create an Attack Amplifier 919 The simplest guideline is to avoid building attack amplifiers and, as 920 far as possible, to perform ingress filtering to prevent compromised 921 systems on a subnet from spoofing the source address on packets. 923 Don't Hold State for Unverified Hosts 925 From an end-system server point of view, one simple aim is to avoid 926 instantiating state without having completed a handshake with the client 927 to validate their address, and as far as possible to push work and 928 stateholding to client. There are a number of techniques that might be 929 used to do this, including SYN-cookies [5] [2]. All client-server 930 protocols should probably be designed to allow such techniques to be 931 used, but the enabling of the mechanism should normally be at the 932 server's discretion to avoid unnecessary work under normal 933 circumstances. 935 State Lookup Complexity 937 Any system that instantiates per-connection state should take great care 938 to implement the state-lookup mechanisms in such a way that performance 939 can not be controlled by the attacker. One way to achieve this is to 940 use hash-tables where the hash mechanism is keyed in such a way that the 941 attacker cannot instantiate a large number of flows in the same hash 942 bucket. 944 Avoid Livelock 946 Most operating systems use network interrupts to receive data from the 947 network, which is a good solution if the host spends only a small amount 948 of its time handling network traffic. However, this leaves the host 949 open to livelock [29], where under heavy load the OS spends all its time 950 handling interrupts and no time doing the work needed to handle the 951 traffic at the application level. Server operating systems should 952 consider using network polling at times of heavy load, rather that being 953 interrupt-driven, and should be carefully architected so that as far as 954 reasonably possible, traffic received by the OS is processed to 955 completion, or very cheaply discarded. 957 Use Unpredictable Values for Session IDs 959 Most recent TCP implementations use fairly good random mechanisms for 960 allocating the TCP initial sequence numbers. In general, any 961 dynamically allocated value used purely to identify a communications 962 session should be allocated using an unpredictable mechanism, as this 963 increases the search space for an attacker that wishes to disrupt 964 ongoing communications. Thus the dynamically allocated port of the 965 active end of a TCP connection might also be randomly allocated. 967 With DNS, the ID which is used to match responses with requests should 968 also be randomly generated. However, as the ID field is only 16 bits, 969 the protection is rather limited, especially in the face of birthday 970 attacks. 972 Authenticate Routing Adjacencies 974 In general, cryptographic authentication mechanisms are too costly to 975 form the main part in DoS prevention. However, routing adjacencies are 976 too important to risk an attacker being able to inject bad routing 977 information, which can affect more than the router in question. 978 Additional non-cryptographic mechanisms should then be used to avoid 979 arbitrary end-systems being able to cause the router to spend CPU cycles 980 on validating authentication data. 982 For BGP, at the very least, this implies the use of TCP MD5 [24] or 983 IPsec authentication, combined with the TTL 255 hack [23] to prevent 984 EBGP association with non-immediate neighbours. In future, this will 985 likely imply better authentication of the routing information itself. 987 Isolate Router-to-Router Traffic 989 As far as is feasible, router-to-router traffic should be isolated from 990 data traffic. How this should be implemented depends on the precise 991 technologies available, both in the router and at the link-layer. The 992 goal should be that failure of the link for data traffic should also 993 cause failure for the routing traffic, but that an attacker cannot 994 directly send packets to the control processor of the routers. 996 A downside of this is that some diagnostic techniques (such as pinging 997 consecutive routers to find the source of a delay) may no longer be 998 possible. Ideally, alternative mechanisms (which do not open up 999 additional avenues for DoS) should be designed to replace such lost 1000 techniques. 1002 Graceful Routing Degradation 1004 A goal with routing protocols is that of graceful degradation in 1005 overload, and automatic recovery after the source of the overload has 1006 been remedied. Some routing protocols satisfy this goal more than 1007 others. Although RIP doesn't scale well, if a router runs out of memory 1008 when receiving a RIP route, it can just drop the route and send an 1009 infinite metric to its peers. The route will later be refreshed, and if 1010 the original source of the problem has been resolved, the router will 1011 now be able to process it correctly. 1013 On the other hand, BGP is stateful in the sense that a peer assumes you 1014 have processed or chosen to filter any route that it sent you. There is 1015 no mechanism to refresh state in the base BGP spec, and even the later 1016 route refresh option [16] is hard to use usefully in the presence of 1017 overload. A BGP router that cannot store a route it received has two 1018 choices: completely restart BGP, or shutdown one or more peerings [15]. 1019 This means that the effects of a BGP overload are rather more severe 1020 than they need to be, and so amplifies the effect of any attack. 1022 In general, few routing protocol designs actively consider the possible 1023 behaviour of routers under overload conditions; this should be an 1024 explicit part of future routing protocol designs. Although precise 1025 details should clearly be left to implementors, the protocol design 1026 needs to give them the capability to do their job properly. 1028 Source-Specific Multicast 1030 Source-specific multicast is easier to manage than ASM, and opens up 1031 many fewer avenues for DoS attack. However, ASM has many uses for 1032 resource discovery and autoconfiguration. A prudent deployment strategy 1033 would be to use SSM for inter-domain multicast and ASM only within the 1034 more controlled environment of an intranet. In both environments, 1035 administrative controls should be set to prevent a single receiver from 1036 joining sufficient multicast groups to cause a state exhaustion problem 1037 in the multicast routers. Such a threshold needs to take into account 1038 that some multicast congestion control mechanisms use multiple multicast 1039 groups to allow the receiver to select an appropriate rate. 1041 In the future, multicast protocols may be deployed which use shared 1042 bidirectional trees for interdomain multicast. This might allow ASM to 1043 be deployed without the DoS vulnerabilities exhibited by current inter- 1044 domain ASM solutions. Such solutions are not currently available. 1046 Autoconfiguration and Authentication 1048 Autoconfiguration mechanisms greatly ease deployment, and are 1049 increasingly necessary as the number of networked devices grows beyond 1050 what can be managed manually. However, it should be recognised that 1051 unauthenticated autoconfiguration opens up many avenues for attack. 1052 There is a clear tension between ease of configuration and security of 1053 configuration. Future autoconfiguration protocols should consider the 1054 need to allow different end-systems to operate at different points in 1055 this spectrum within the same autoconfiguration framework. 1057 Establish a Monitoring Framework 1059 Network operators are strongly encouraged to establish a monitoring 1060 framework to detect and log abnormal network activity. One can not 1061 defend against an attack one doesn't detect or understand. Such 1062 monitoring tools can be used to set a baseline of "normal" traffic, and 1063 can be used to determine: 1065 1. Aberrant flows. 1067 2. Type and source of the aberrant flows. 1069 This is extremely helpful when responding to DDoS or a flash crowd, and 1070 should be in place prior to the event. 1072 5. Conclusions 1074 In this document we have highlighted possible avenues for DoS attack on 1075 networks and networked systems, with the aim of encouraging protocol 1076 designers and network engineers towards designs that are more robust. 1077 We have discussed partial solutions that reduce the effectiveness of 1078 attacks, and highlighted how some partial solutions can be taken 1079 advantage of by attackers to perpetrate alternative attacks. 1081 Our focus has primarily been on protocol and network architecture 1082 issues, but there are many things that network and service operators can 1083 do to lessen the threat. Further advice and information for network 1084 operators can be found in [13] [37] [14]. 1086 It is our hope that this document will spur discussion leading to 1087 architectural solutions that reduce the succeptibility of all Internet 1088 systems to denial-of-service attacks. 1090 6. Acknowledgements 1092 We are very grateful to Vern Paxson, Paul Vixie, Rob Thomas, Dug Song, 1093 George Jones and Jari Arkko for their constructive comments on earlier 1094 versions of this document. 1096 7. Authors' Addresses 1098 Mark Handley 1099 Department of Computer Science 1100 University College London 1101 Gower Street 1102 London WC1E 6BT 1103 United Kingdom. 1105 Email: M.Handley@cs.ucl.ac.uk 1107 8. References 1109 [1] J. Abley, "Hierarchical Anycast for Global Service Distribution", 1110 http://www.isc.org/tn/isc-tn-2003-1.txt 1112 [2] T. Aura, P. Nikander, J. Leiwo, "DOS-resistant authentication with 1113 client puzzles", In B. Christianson, B. Crispo, and M. Roe, 1114 editors, Proceedings of the 8th International Workshop on Security 1115 Protocols, Lecture Notes in Computer Science, Cambridge, UK, April 1116 2000. 1118 [3] J. Bellardo, S. Savage, "802.11 Denial-of-Service Attacks: Real 1119 Vulnerabilities and Practical Solutions", Proceedings of the USENIX 1120 Security Symposium, Washington D.C., August 2003. 1122 [4] S.M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", 1123 Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April 1124 1989. 1126 [5] D.J. Bernstein, "SYN Cookies", http://cr.yp.to/syncookies.html 1128 [6] CCAIS/RNP Alertas do Cais ALR-19112002a, "Vulnerability in the 1129 sending requests control of Bind versions 4 and 8 allows DNS 1130 spoofing", http://www.rnp.br/cais/alertas/2002/cais- 1131 ALR-19112002a.html 1133 [7] CERT Advisory CA-1996-01, "UDP Port Denial-of-Service Attack", Feb 1134 1996. 1136 [8] CERT Advisory CA-1996-21, "TCP SYN Flooding and IP Spoofing 1137 Attacks", Sept 1996. 1139 [9] CERT Advisory CA-2001-09, "Statistical Weaknesses in TCP/IP Initial 1140 Sequence Numbers", May 2001. 1142 [10] CERT Advisory CA-1996-26, "Denial-of-Service Attack via ping", Dec 1143 1996. 1145 [11] CERT Advisory CA-1998-01, "Smurf IP Denial-of-Service Attacks", 1146 http://www.cert.org/advisories/CA-1998-01.html, Jan 1998. 1148 [12] CERT Incident Note IN-2000-05, "'mstream' Distributed Denial of 1149 Service Tool", May 2000. 1151 [13] CERT/CC - "Managing the Threat of Denial of Service Attacks", 1152 http://www.cert.org/archive/pdf/Managing_DoS.pdf 1154 [14] CERT/CC - "Trends in Denial of Service Attack Technology", 1155 http://www.cert.org/archive/pdf/DoS_trends.pdf 1157 [15] D.F. Chang, R. Govindan, J. Heidemann, "An Empirical Study of 1158 Router Response to Large Routing Table Load", Proceedings of the 1159 2nd Internet Measurement Workshop (IMW 2002), 2002. 1161 [16] E. Chen, "Route Refresh Capability for BGP-4", RFC 2918, September 1162 2000 1164 [17] Cisco Systems, "Configuring the BGP Maximum-Prefix Feature", Cisco 1165 Document ID: 25160, http://www.cisco.com/warp/public/459/bgp- 1166 maximum-prefix.html 1168 [18] Scott A Crosby and Dan S Wallach, "Denial of Service via 1169 Algorithmic Complexity Attacks", Proceedings of the USENIX Security 1170 Symposium, Washington D.C., August 2003. 1172 [19] S. Deering, "Host extensions for IP multicasting", RFC 1112, Aug 1173 1989. 1175 [20] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, Jan 1176 1999. 1178 [21] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. 1179 Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol 1180 Independent Multicast-Sparse Mode (PIM-SM): Protocol 1181 Specification", RFC 2362, June 1998. 1183 [22] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating Denial 1184 of Service Attacks which employ IP Source Address Spoofing", RFC 1185 2827, May 2000. 1187 [23] V. Gill, J. Heasley, D. Meyer, "The BGP TTL Security Hack (BTSH)", 1188 draft-gill-btsh-02.txt (work in progress), 29-May-03. 1190 [24] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature 1191 Option", RFC 2385, August 1998. 1193 [25] Laurent Joncheray, "Simple Active Attack Against TCP", 5th USENIX 1194 Security Symposium, 1995. 1196 [26] M. Lough, "A Taxonomy of Computer Attacks with Applications to 1197 Wireless", PhD thesis, Virginia Polytechnic Institute, April 2001. 1199 [27] Z. Mao, R. Govindan, G. Varghese, R. Katz, "Route Flap Dampening 1200 Exacerbates Internet Routing Convergence", Proceedings of ACM 1201 SIGCOMM, 2002. 1203 [28] D. Meyer, W. Fenner (Editors), "Multicast Source Discovery Protocol 1204 (MSDP)", draft-ietf-msdp-spec-15.txt, Work in Progress. 1206 [29] J. Mogul, KK. Ramakrishnan, "Eliminating Receive Livelock in an 1207 Interrupt-driven Kernel", ACM Transactions on Computer Systems, Vol 1208 15, Number 3, pp. 217-252, 1997. 1210 [30] National Infrastructure Secuity Co-ordination Center (NISCC), 1211 Vulnerability Advisory 236929, April 2004, 1212 http://www.uniras.gov.uk/vuls/2004/236929/ 1214 [31] V. Paxson, "An Analysis of Using Reflectors for Distributed Denial- 1215 of-Service Attacks", Computer Communication Review 31(3), July 1216 2001. 1218 [32] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, 1219 March 1995. 1221 [33] Joe Stewart, "DNS Cache Poisoning - The Next Generation", Jan 27 1222 2003, http://www.securityfocus.com/guest/17905 1224 [34] R. Stewart (Editor), Transmission Control Protocol security 1225 considerations, Internet Draft, April 2004, draft-ietf-tcpm- 1226 tcpsecure-00.txt 1228 [35] C. Villamizar, R. Chandra, R. Govindan, "BGP Route Flap Damping", 1229 RFC 2439, November 1998. 1231 [36] P. Vixie, G. Sneeringer, M. Schleifer, "Events of 21-Oct-2002", 1232 http://f.root-servers.org/october21.txt 1234 [37] P. Vixie, "Securing the Edge", 1235 http://www.icann.org/committees/security/sac004.txt 1237 [38] D. Waitzman, C. Partridge, S.E. Deering, "Distance Vector Multicast 1238 Routing Protocol", RFC 1075, Nov 1988. 1240 [39] D. Wessels, "Running An Authoritative-Only BIND Nameserver", 1241 http://www.isc.org/tn/isc-tn-2002-2.txt 1243 [40] M. Zalewski, "Strange Attractors and TCP/IP Sequence Number 1244 Analysis", http://razor.bindview.com/publish/papers/tcpseq.html