idnits 2.17.1 draft-iab-dos-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1681. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 25, 2006) is 6514 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) -- Looks like a reference, but probably isn't: 'RFC1350' on line 1155 == Unused Reference: '43' is defined on line 1574, but no explicit reference was found in the text == Unused Reference: '44' is defined on line 1577, but no explicit reference was found in the text == Unused Reference: '48' is defined on line 1594, but no explicit reference was found in the text == Unused Reference: '52' is defined on line 1610, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2246 (ref. '20') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2362 (ref. '21') (Obsoleted by RFC 4601, RFC 5059) ** Obsolete normative reference: RFC 3682 (ref. '23') (Obsoleted by RFC 5082) ** Obsolete normative reference: RFC 2385 (ref. '24') (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 1771 (ref. '32') (Obsoleted by RFC 4271) ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '38') -- Possible downref: Non-RFC (?) normative reference: ref. '42' == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-04 -- Obsolete informational reference (is this intentional?): RFC 2338 (ref. '50') (Obsoleted by RFC 3768) -- Obsolete informational reference (is this intentional?): RFC 1784 (ref. '52') (Obsoleted by RFC 2349) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Handley (ed) 3 Internet-Draft UCL 4 Expires: December 27, 2006 E. Rescorla (ed) 5 Network Resonance 6 June 25, 2006 8 Internet Denial of Service Considerations 9 draft-iab-dos-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 27, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document provides an overview of possible avenues for denial-of- 43 service attack on Internet systems. The aim is to encourage protocol 44 designers and network engineers towards designs that are more robust. 45 We discuss partial solutions that reduce the effectiveness of 46 attacks, and how some solutions might inadvertently open up 47 alternative vulnerabilities. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. An Overview of Denial-of-Service Threats . . . . . . . . . . . 6 53 2.1. DoS Attacks on End-systems . . . . . . . . . . . . . . . . 6 54 2.1.1. Exploiting Poor Software Quality . . . . . . . . . . . 6 55 2.1.2. Application Resource Exhaustion . . . . . . . . . . . 7 56 2.1.3. Operating System Resource Exhaustion . . . . . . . . . 8 57 2.1.4. Triggered Lockouts and Quota Exhaustion . . . . . . . 9 58 2.2. DoS Attacks on Routers . . . . . . . . . . . . . . . . . . 9 59 2.2.1. Attacks on Routers through Routing Protocols . . . . . 10 60 2.2.2. IP Multicast-based DoS Attacks . . . . . . . . . . . . 11 61 2.2.3. Attacks on Router Forwarding Engines . . . . . . . . . 12 62 2.3. Attacks on Ongoing Communications . . . . . . . . . . . . 13 63 2.4. Attacks using the Victim's Own Resources . . . . . . . . . 14 64 2.5. DoS Attacks on Local Hosts or Infrastructure . . . . . . . 14 65 2.6. DoS Attacks on Sites though DNS . . . . . . . . . . . . . 16 66 2.7. DoS Attacks on Links . . . . . . . . . . . . . . . . . . . 17 67 2.8. DoS attacks on firewalls . . . . . . . . . . . . . . . . . 18 68 2.9. DoS attacks on IDS systems . . . . . . . . . . . . . . . . 19 69 2.10. DoS attacks on or via NTP . . . . . . . . . . . . . . . . 19 70 2.11. Physical DoS . . . . . . . . . . . . . . . . . . . . . . . 20 71 2.12. Social Engineering DoS . . . . . . . . . . . . . . . . . . 20 72 2.13. Legal DoS . . . . . . . . . . . . . . . . . . . . . . . . 20 73 2.14. Spam and Black-hole Lists . . . . . . . . . . . . . . . . 20 74 3. Attack Amplifiers . . . . . . . . . . . . . . . . . . . . . . 22 75 3.1. Methods of Attack Amplification . . . . . . . . . . . . . 22 76 3.2. Strategies to Mitigate Attack Amplification . . . . . . . 24 77 4. DoS Mitigation Strategies . . . . . . . . . . . . . . . . . . 25 78 4.1. Protocol Design . . . . . . . . . . . . . . . . . . . . . 25 79 4.1.1. Don't Hold State for Unverified Hosts . . . . . . . . 25 80 4.1.2. Make it Hard to Simulate a Legitimate User . . . . . . 25 81 4.1.3. Graceful Routing Degradation . . . . . . . . . . . . . 26 82 4.1.4. Autoconfiguration and Authentication . . . . . . . . . 27 83 4.2. Network Design and Configuration . . . . . . . . . . . . . 27 84 4.2.1. Redundancy and Distributed Service . . . . . . . . . . 28 85 4.2.2. Authenticate Routing Adjacencies . . . . . . . . . . . 28 86 4.2.3. Isolate Router-to-Router Traffic . . . . . . . . . . . 28 87 4.3. Router Implementation Issues . . . . . . . . . . . . . . . 28 88 4.3.1. Checking Protocol Syntax and Semantics . . . . . . . . 29 89 4.3.2. Consistency Checks . . . . . . . . . . . . . . . . . . 29 90 4.3.3. Enhance Router Robustness through Operational 91 Adjustments . . . . . . . . . . . . . . . . . . . . . 30 92 4.3.4. Proper Handling of Router Resource Exhaustion . . . . 31 93 4.4. End-System Implementation Issues . . . . . . . . . . . . . 31 94 4.4.1. State Lookup Complexity . . . . . . . . . . . . . . . 31 95 4.4.2. Operational Issues . . . . . . . . . . . . . . . . . . 32 96 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 98 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 99 8. Normative References . . . . . . . . . . . . . . . . . . . . . 36 100 9. Informative References . . . . . . . . . . . . . . . . . . . . 37 101 Appendix A. IAB Members at the time of this writing . . . . . . . 40 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 103 Intellectual Property and Copyright Statements . . . . . . . . . . 42 105 1. Introduction 107 A Denial-of-Service (DoS) attack is an attack in which one or more 108 machines target a victim and attempt to prevent the victim from doing 109 useful work. The victim can be a network server, client or router, a 110 network link or an entire network, an individual Internet user or a 111 company doing business using the Internet, an Internet Service 112 Provider (ISP), country, or any combination of or variant on these. 113 Denial of service attacks may involve gaining unauthorized access to 114 network or computing resources, but for the most part in this 115 document we focus on the cases where the denial-of-service attack 116 itself does not involve a compromise of the victim's computing 117 facilities. 119 Because of the closed context of the original ARPAnet and NSFnet, no 120 consideration was given to denial-of-service attacks in the original 121 Internet Architecture. As a result, almost all Internet services are 122 vulnerable to denial-of-service attacks of sufficient scale. In most 123 cases, sufficient scale can be achieved by compromising enough end- 124 hosts (typically using a virus, worm, or remotely controlled "bots") 125 or routers, and using those compromised hosts to perpetrate the 126 attack. Such an attack is known as a Distributed Denial of Service 127 attack (DDoS). However, there are also many cases where a single 128 well- connected end-system can perpetrate a successful DoS attack. 130 This document is intended to serve several purposes: 132 o To highlight possible avenues for attack, and by so doing encourage 133 protocol designers and network engineers towards designs that are 134 more robust. 136 o To discuss partial solutions that reduce the effectiveness of 137 attacks. 139 o To highlight how some partial solutions can be taken advantage of 140 by attackers to perpetrate alternative attacks. 142 This last point appears to be a recurrent theme in DoS, and 143 highlights the lack of proper architectural solutions. It is our 144 hope that this document will help initiate informed debate about 145 future architectural solutions that might be feasible and cost- 146 effective for deployment. 148 In addition it is our hope that this document will spur discussion 149 leading to architectural solutions that reduce the succeptibility of 150 all Internet systems to denial-of-service attacks. 152 We note that in principle it is not possible to distinguish between a 153 sufficiently subtle DoS attack and a flash-crowd, where unexpected 154 heavy but non-malicious traffic has the same effect as a DoS attack. 155 Whilst this is true, such malicious attacks are usually more 156 expensive to launch than many of the crude attacks that have been 157 seen to date. Thus defending against DoS is not about preventing all 158 possible attacks, but rather is largely a question of raising the bar 159 sufficiently high for malicious traffic. 161 However, it is also important to note that not all DoS problems are 162 malicious. Failed links, flash crowds, misconfigured bots, and 163 numerous other causes can result in resource exhaustion problems, and 164 so the overall goal should be to be robust to all forms of overload. 166 2. An Overview of Denial-of-Service Threats 168 In this section we will discuss a wide range of possible DoS attacks. 169 This list cannot be exhaustive, but the intent is to provide a good 170 overview of the spectrum of possibilities that need to be defended 171 against. 173 We do not provide descriptions of any attacks that are not already 174 publicly well documented. 176 2.1. DoS Attacks on End-systems 178 We first discuss attacks on end-systems. An end-system in this 179 context is typically a PC or network server, but it can also include 180 any communication endpoint. For example, a router also is an end- 181 system from the point of view of terminating TCP connections for BGP 182 [32] or ssh [49]. 184 2.1.1. Exploiting Poor Software Quality 186 The simplest DoS attacks on end-systems exploit poor software quality 187 on the end-systems themselves, and cause that software to simply 188 crash. For example, buffer-overflow attacks might be used to 189 compromise the end-system, but even if the buffer-overflow cannot be 190 used to gain access, it will usually be possible to overwrite memory 191 and cause the software to crash. Such vulnerabilities can in 192 principle affect any software that uses data supplied from the 193 network. Thus not only might a web server be potentially vulnerable, 194 but it might also be possible to crash the back-end software (such as 195 a database) to which a web server provides data. 197 Software crashes due to poor coding not only affect application 198 software, but also the operating system kernel itself. A classic 199 example is the so-called "Ping of Death", which became widely known 200 in 1996 [10]. This exploit caused many popular operating systems to 201 crash when sent a single fragmented ICMP echo request packet whose 202 fragments totaled more than the 65535 bytes allowed in an IPv4 203 packet. 205 While DoS attacks such as the ping-of-death are a significant 206 problem, they are not a significant architectural problem. Once such 207 an attack is discovered, the relevant code can easily be patched, and 208 the problem goes away. We should note though that as more and more 209 software becomes embedded, it is important not to lose the 210 possibility of upgrading the software in such systems. 212 2.1.2. Application Resource Exhaustion 214 Network applications exist in a context that has finite resources. 215 In processing network traffic, such an application uses these 216 resources to do its intended task. However, an attacker may be able 217 to prevent the application from performing its intended task by 218 causing the application to exhaust the finite supply of a specific 219 resource. 221 The obvious resources that might be exhausted include: 223 o Available memory. 225 o The CPU cycles available. 227 o The disk space available to the application. 229 o The number of processes or threads or both that the application is 230 permitted to use. 232 o The configured maximum number of simultaneous connections the 233 application is permitted. 235 This list is clearly not exhaustive, but it illustrates a number of 236 points. 238 Some resources are self-renewing: CPU cycles fall in this category - 239 if the attack ceases, more CPU cycles become available. 241 Some resources such as disk space require an explicit action to free 242 up - if the application cannot do this automatically then the effects 243 of the attack may be persistent after the attack has ceased. 245 This problem has been understood for many years, and it is common 246 practice for logs and incoming email to be stored in a separate disk 247 partition (/var on Unix systems) in order to limit the impact of 248 exhaustion. 250 Some resources are constrained by configuration: the maximum number 251 of processes and the maximum number of simultaneous connections are 252 not normally hard limits, but rather are configured limits. The 253 purpose of such limits is clearly to allow the machine to perform 254 other tasks in the event the application misbehaves. However, great 255 care needs to be taken to choose such limits appropriately. For 256 example, if a machine's sole task is to be an FTP server, then 257 setting the maximum number of simultaneous connections to be 258 significantly less than the machine can service makes the attacker's 259 job easier. But setting the limit too high may permit the attacker 260 to cause the machine to crash (due to poor OS design in handling 261 resource exhaustion) or permit livelock (see below), which are 262 generally even less desirable failure modes. 264 2.1.3. Operating System Resource Exhaustion 266 Conceptually OS resource exhaustion and application resource 267 exhaustion are very similar. However, in the case of application 268 resource exhaustion, the operating system may be able to protect 269 other tasks from being affected by the DoS attack. In the case of 270 the operating system itself running out of resources, the problem may 271 be more catastrophic. 273 Perhaps the best-known DoS attack on an operating system is the TCP 274 SYN- flood [8], which is essentially a memory-exhaustion attack. The 275 attacker sends a flood of TCP SYN packets to the victim, requesting 276 connection setup, but then does not complete the connection setup. 277 The victim instantiates state to handle the incoming connections. If 278 the attacker can instantiate state faster than the victim times it 279 out, then the victim will run out of memory that it can use to hold 280 TCP state, and so it cannot service legitimate TCP connection setup 281 attempts. This issue was exacerbated in some implementations by the 282 use of a small dedicated storage space for half-open connections, 283 which made the attack easier than it might otherwise have been. In 284 the case of a poorly coded operating system, running out of resources 285 may also cause a system crash. 287 An alternative TCP DoS attack is the Ack-flood [12], which is 288 essentially a CPU exhaustion attack on the victim. The attacker 289 floods the victim with TCP packets pretending to be from connections 290 that have never been established. A busy server that has a large 291 number of outstanding connections needs to check which connection the 292 packet corresponds to. Some TCP implementations implemented this 293 search rather inefficiently, and so the attacker could use all the 294 victim's CPU resources servicing these packets rather than servicing 295 legitimate requests. 297 We note that strong authentication mechanisms do not mitigate against 298 such CPU exhaustion attacks. In fact poorly designed authentication 299 mechanisms using cryptographic methods can exacerbate the problem. 300 If such an authentication mechanism allows an attacker to present a 301 packet to the victim that requires relatively expensive cryptographic 302 authentication before the packet can be discarded, then this makes 303 the attacker's CPU exhaustion attack easier. 305 CPU exhaustion attacks can be also be exacerbated by poor OS handling 306 of incoming network traffic. In the absence of malicious traffic, an 307 ideal OS should behave as follows: 309 o As incoming traffic increases, the useful work done by the OS 310 should increase until some resource (such as the CPU) is saturated. 312 o From this point on, as incoming traffic continues to increase the 313 useful work done should be constant. 315 However, this is often not the case. Many systems suffer from 316 livelock [29] where, after saturation, increasing the load causes a 317 decrease in the useful work done. One cause of this is that the 318 system spends an increasing amount of time processing network 319 interrupts for packets that will never be processed, and hence a 320 decreasing amount of time is available for the application for which 321 these packets were intended. 323 2.1.4. Triggered Lockouts and Quota Exhaustion 325 Many user-authentication mechanisms attempt to protect against 326 password guessing attacks by locking the user out after a small 327 number of failed authentications. If an attacker can guess or 328 discover a user's ID, they may be able to trigger such a mechanism, 329 locking out the legitimate user. 331 Another way to deny service using protection mechanisms is to cause a 332 quota to be exhausted. This is perhaps most common in the case of 333 small web servers being commercially hosted, where the server has a 334 contract with the hosting company allowing a fixed amount of traffic 335 per day. An attacker may be able to rapidly exhaust this quota, and 336 cause service to be suspended. Similar attacks may be possible 337 against other forms of quota. 339 In the absence of such quotas, if the victim is charged for their 340 network traffic, a financial denial-of-service may be possible. 342 2.2. DoS Attacks on Routers 344 Many of the denial-of-service attacks that can be launched against 345 end-systems can also be launched against the control processor of an 346 IP router, for example by flooding the command and control access 347 ports. In the case of a router, these attacks may cause the router 348 to stall, or may cause the router to cease processing routing 349 packets. Even if the router does not stop servicing routing packets, 350 it may become sufficiently slow that routing protocols time out. In 351 any of these circumstances, the consequence of routing failure is not 352 only that the router ceases to forward traffic, but also that it 353 causes routing protocol churn that may have further side effects. 355 An example of such a side effect is caused by BGP route flap damping 356 [35], which is intended to reduce global routing churn. If an 357 attacker can cause BGP routing churn, route flap damping may then 358 cause the flapping routes to be suppressed [27]. This suppression 359 likely causes the networks served by those routes to become 360 unreachable. 362 A DoS attack on the router control processor might also prevent the 363 router from being managed effectively. This may prevent actions 364 being taken that would mitigate the DoS attack, and it might prevent 365 diagnosis of the cause of the problem. 367 2.2.1. Attacks on Routers through Routing Protocols 369 In addition to their roles as end-systems, most routers run dynamic 370 routing protocols. The routing protocols themselves can be used to 371 stage a DoS attack on a router or a network of routers. This 372 requires the ability to send traffic from addresses which might 373 plausibly have generated the relevant routing messages, which is 374 somewhat difficult with interior routing protocols but fairly easy 375 with eBGP, for instance. 377 The simplest attack on a network of routers is to overload the 378 routing table with sufficiently many routes that the router runs out 379 of memory, or the router has insufficient CPU power to process the 380 routes [15]. We note that depending on the distribution and 381 capacities of various routers around the network, such an attack 382 might not overwhelm routers near to the attacking router, but might 383 cause problems to show up elsewhere in the network. 385 Some routing protocol implementations allow limits to be configured 386 on the maximum number of routes to be heard from a neighbor [17]. 387 However, limits often make the problem worse rather than better, by 388 making it possible for the attacker to push out legitimate routes 389 with spoofed routes, thus creating an easy form of DoS attack. 391 An alternative attack is to overload the routers on the network by 392 creating sufficient routing table churn that routers are unable to 393 process the changes. Many routing protocols allow damping factors to 394 be configured to avoid just such a problem. However, as with table 395 size, such a threshold applied inconsistently may allow the spoofed 396 routes to merge with legitimate routes before the mechanism is 397 applied, causing legitimate routes to be damped. 399 The simplest routing attack on a specific destination is for an 400 attacker to announce a spoofed desirable route to that destination. 401 Such a route might be desirable because it has low metric, or because 402 it is a more specific route than the legitimate route. In any event, 403 if the route is believed, it will cause traffic for the victim to be 404 drawn towards the attacking router, where it will typically be 405 discarded. 407 A more subtle denial-of-service attack might be launched against a 408 network rather than against a destination. Under some circumstances, 409 the propagation of inconsistent routing information can cause traffic 410 to loop. If an attacker can cause this to happen on a busy path, the 411 looping traffic might cause significant congestion, as well as fail 412 to reach the legitimate destination. 414 In the past there have been cases where different generations of 415 routers interpreted a routing protocol specification differently. In 416 particular, BGP specifies that in the case of an error, the BGP 417 peering should be dropped. However, if some of the routers in a 418 network treat a particular route as valid and other routers treat the 419 route as invalid, then it may be possible to inject a BGP route at 420 one point in the Internet and cause peerings to be dropped at many 421 other places in the Internet. Unlike many of the examples above, 422 while such an issue might be a serious short-term problem, this is 423 not a fundamental architectural problem. Once the problem is 424 understood, deploying patched routing code can permanently solve the 425 issue. 427 2.2.2. IP Multicast-based DoS Attacks 429 There are essentially two forms of IP multicast: traditional Any- 430 Source Multicast (ASM), as specified in RFC 1112 [19] where multiple 431 sources can send to the same multicast group, and Source-Specific 432 Multicast (SSM) where the receiver must specify both the IP source 433 address and the group address. The two forms of multicast provide 434 rather different DoS possibilities. 436 ASM protocols such as PIM-SM [21], MSDP [28] and DVMRP [38] typically 437 cause some routers to instantiate routing state at the time a packet 438 is sent to a multicast group. They do this to ensure that the 439 traffic goes to the group receivers and not to non-receivers. Such 440 protocols are particularly vulnerable to DoS attacks, as an attacker 441 that sends to many multicast groups may cause both multicast routing 442 table explosion (and hence control processor memory exhaustion) and 443 multicast forwarding table exhaustion (and hence forwarding card 444 memory exhaustion or thrashing). 446 ASM also permits an attacker to send traffic to the same group as 447 legitimate traffic, potentially causing network congestion and 448 denying service to the legitimate group. 450 SSM does not permit senders to send to arbitrary groups unless a 451 receiver has requested the traffic. Thus sender-based attacks on 452 multicast routing state are not possible with SSM. However, as with 453 ASM, a receiver can still join a large number of multicast groups 454 causing routers to hold a large amount of multicast routing state, 455 potentially causing memory exhaustion and hence denial-of-service to 456 legitimate traffic. 458 With IPv6, hosts are required to send ICMP Packet Too Big or 459 Parameter Problem messages under certain circumstances, even if the 460 destination address is a multicast address. If the attacker can 461 place himself in the appropriate position in the multicast tree, a 462 packet with an unknown but mandatory Destination Option, for 463 instance, could generate a very large number of responses to the 464 claimed sender. 466 With IPv4 the same problem exists with multicast ICMP Echo Request 467 packets, but these are somewhat easier to filter. 469 The examples above should not be taken as exhaustive. These are 470 actually specific cases of a general problem that can happen whene a 471 multicast/broadcast request solicits a reply from a large number of 472 nodes. 474 2.2.3. Attacks on Router Forwarding Engines 476 Router vendors implement many different mechanisms for packet 477 forwarding, but broadly speaking they fall into two categories: ones 478 that use a forwarding cache, and ones that do not. With a forwarding 479 cache, the forwarding engine does not hold the full routing table, 480 but rather holds just the currently active subset of the forwarding 481 table. 483 Many modern routers use a loosely coupled architecture, where one or 484 more control processors handle the routing protocols, and communicate 485 over an internal network link to special-purpose forwarding engines, 486 which actually forward the data traffic. In such architectures it 487 may be possible for an attacker to overwhelm the communications link 488 between the control processor and the forwarding engine. This is 489 possible because the forwarding engines support very high speed 490 links, and the control processor simply cannot handle a similar rate 491 of traffic. 493 There may be many ways in which an attacker can trigger communication 494 between the forwarding engines and the control processor. The 495 simplest way is for the attacker to simply send to the router's IP 496 address, but this should in principle be relatively easy to prevent 497 using filtering on the forwarding engines. Another way might be to 498 cause the router to forward data packets using the "slow path". This 499 involves sending packets that require special attention from the 500 forwarding router; if the forwarding engine is not smart enough to 501 perform such forwarding, then it will typically pass the packet to 502 the control processor. In a router using a forwarding cache, it may 503 be possible to overload the internal communications by thrashing the 504 forwarding cache. Finally, any form of data-triggered communication 505 between the forwarding engine and the control processor might cause 506 such a problem. Certain multicast routing protocols including PIM-SM 507 contain many such data triggered events that could potentially be 508 problematic. 510 The effects of overloading such internal communications are hard to 511 predict, and very implementation-dependent. One possible effect 512 might be that the forwarding table in the forwarding engine gets out 513 of synchronization with the routing table in the control processor 514 that reflects what the routing protocols believe is happening. This 515 might cause traffic to be dropped or to loop. 517 Finally, if an attacker can generate traffic that causes a router to 518 auto-install access control list (ACL) entries, perhaps by triggering 519 a response from an intrusion detection system, then it may be 520 possible to exhaust the ACL resources on the router. This might 521 prevent future attacks from being filtered, or worse, cause ACL 522 processing to be handled by the route processor. 524 2.3. Attacks on Ongoing Communications 526 Instead of attacking the end-system itself, it is also possible for 527 an attacker to disrupt ongoing communications. If an attacker can 528 observe a TCP connection, then it is relatively easy for them to 529 spoof packets to either reset that connection or to de-synchronize it 530 so that no further progress can be made [25]. Such attacks are not 531 prevented by transport or application-level security mechanisms such 532 as TLS [20] or ssh, because the authentication takes place after TCP 533 has finished processing the packets. 535 If an attacker cannot observe a TCP connection, but can infer that 536 such a connection exists, it is theoretically possible to reset or 537 desynchronize that connection by spoofing packets into the 538 connection. However, this might require an excessively large number 539 of spoofed packets to guess both the port of the active end of the 540 TCP connection (in most cases the port of the passive end is 541 predictable) and the currently valid TCP sequence numbers. However, 542 as some operating systems have poorly implemented predictable 543 algorithms for selecting either the dynamically selected port or the 544 TCP initial sequence number [40] [9], then such attacks have been 545 found to be feasible [30]. Advice as to how to reduce the 546 vulnerability in the specific case of TCP is available in [34]. 548 An attacker might be able to significantly reduce the throughput of a 549 connection by sending spoofed ICMP source quench packets, although 550 most modern operating systems should ignore such packets. However, 551 care should be taken in the design of future transport and signaling 552 protocols to avoid the introduction of similar mechanisms that could 553 be exploited. 555 2.4. Attacks using the Victim's Own Resources 557 Instead of directly overloading the victim, it may be possible to 558 cause the victim or a machine on the same subnet as the victim to 559 overload itself. 561 An example of such an attack is documented in [7], where the attacker 562 spoofs the source address on a packet sent to the victim's UDP echo 563 port. The source address is that of another machine that is running 564 a UDP chargen server (a chargen server sends a character pattern back 565 to the originating source). The result is that the two machines 566 bounce packets back and forth as fast as they can, overloading either 567 the network between them or one of the end-systems itself. 569 2.5. DoS Attacks on Local Hosts or Infrastructure 571 There are a number of attacks that might only be performed by a local 572 attacker. 574 An attacker with access to a subnet may be able to prevent other 575 local hosts from accessing the network at all by simply exhausting 576 the address pool allocated by a DHCP server. This requires being 577 able to spoof the MAC address of an ethernet or wireless card, but 578 this is quite feasible with certain hardware and operating systems. 580 An alternative DHCP-based attack is simply to respond faster than the 581 legitimate DHCP server, and to give out an address that is not useful 582 to the victim. 584 These sorts of bootstrapping attacks tend to be difficult to avoid 585 because most of the time trust relationships are established after IP 586 communication has already been established. 588 Similar attacks are possible through ARP spoofing [4]; an attacker 589 can respond to ARP requests before the victim and prevent traffic 590 from reaching the victim. Some brands of ethernet switch allow an 591 even simpler attack - simply send from the victim's MAC address, and 592 the switch will redirect traffic destined for the victim to the 593 attacker's port. This attack might also potentially be used to block 594 traffic from the victim by engaging screening or flap-dampening 595 algorithms in the switch, depending on the switch design. 597 It may be possible to cause broadcast storms [4] on a local LAN by 598 sending a stream of unicast IP packets to the broadcast MAC address - 599 some hosts on the LAN may then attempt to forward the packets to the 600 correct MAC address greatly amplifying the traffic on the LAN. 602 802.11 wireless networks provide many opportunities to deny service 603 to other users. In some cases, the lack of defenses against DoS was 604 a deliberate choice--because 802.11 operates on unlicensed spectrum 605 it was assumed that there would be sources of interference and that 606 producing intentional radio-level jamming would be trivial. Thus, 607 the amount of DoS protection possible at higher levels was minimal. 609 Nevertheless, some of the weaknesses of the protocols against more 610 sophisticated attacks are worth noting. The most prominent of these 611 is that association is unprotected, thus allowing rogue APs to 612 solicit notifications that would otherwise have gone to legitimate 613 APs. 615 The SSID field provides effectively no defense against this kind of 616 attacks. Unless encryption is enabled, it is trivial to announce the 617 presence of a base station (or even of an ad-hoc mode host) with the 618 same network name (SSID) as the legitimate basestation. Even adding 619 authentication and encryption a la 802.1X and 802.11i may not help 620 much in this respect. The SSID space is unmanaged, so everyone's 621 free to put anything they want in the SSID field. Most host stacks 622 don't deal gracefully with this. Moreover, SSIDs are very often set 623 to the manufacturer's default, making them highly predictable. 625 Some 802.11 basestations have limited memory for the number of 626 associations they can support. If this is exceeded, they may drop 627 all associations. In an attempt to forestall this problem, some APs 628 advertise their load so as to enable stations to choose APs that are 629 less loaded. However, crude implementations of these algorithms can 630 result in instability. 632 Finally, as the authentication in 802.11 takes place at a 633 comparatively high level in the stack, it is possible to simply 634 deauthenticate or disassociate the victim from the basestation, even 635 if WEP is in use [26]. Bellardo and Savage [3] describe some simple 636 remedies that reduce the effectiveness of such attacks. While IEEE 637 802.11w will protect Deauthenticate or Disassociate frames, this 638 attack is still possible via forging of Association frames. 640 What all these attacks have in common is that they exploit 641 vulnerabilities in the link auto-configuration mechanisms. In a 642 wireless network it is necessary for a station to detect the presence 643 of APs in order to choose which one to connect to. In 802.11 this is 644 handled via the Beacon and Probe Request/Response mechanisms. 646 The Beacon cannot easily be encrypted, because the station needs to 647 utilize them prior to authentication in order to discover which APs 648 it may wish to communicate with. Since authentication can only occur 649 after interpreting the Beacon, an encrypted Beacon would present a 650 chicken-egg problem: you can't obtain a key to decrypt the Beacon 651 until completing authentication, and you may not be able to figure 652 out which AP to authenticate with prior to decrypting the Beacon. 653 Note that in principle you could encrypt the Beacons with a shared 654 (per-AP) key but this would require each station to trial-decrypt 655 beacons until it find one that matches up to whatever shared 656 authentication secret it had. This is not particularly convenient. 658 As a result, discussions of Beacon frame security have largely 659 focused on authentication of Beacon frames, not encryption. Even 660 here, solutions are difficult. While it may be possible to for a 661 station to validate a Beacon *after* authentication (either by 662 checking a MIC computed with the group key provided by the AP, or 663 verifying the Beacon parameters during the 4-way handshake), doing so 664 *before* authentication may require synchronization of keys between 665 APs within an SSID. 667 2.6. DoS Attacks on Sites though DNS 669 In today's Internet, DNS is of sufficient importance that if access 670 to a site's DNS servers is denied, the site is effectively 671 unreachable, even if there is no actual communication problem with 672 the suite itself. 674 Many of the attacks on end-systems described above can be perpetrated 675 on DNS servers. As servers go, DNS servers are not particularly 676 vulnerable to DoS. So long as a DNS server has sufficient memory, a 677 modern host can usually respond very rapidly to DNS requests for 678 which it is authoritative. This was demonstrated in October 2002 679 when the root nameservers were subjected to a very large DoS attack 680 [36]. A number of the root nameservers have since been replicated 681 using anycast [1] to further improve their resistance to DoS. 682 However it is important for authoritative servers to have relaying 683 disabled, or it is possible for an attacker to force the DNS servers 684 to hold state [39]. 686 Many of the routing attacks can also be used against DNS servers by 687 targeting the routing for the server. If the DNS server is co- 688 located with the site for which is authoritative, then the fact that 689 the DNS server is also unavailable is of secondary importance. 690 However, if all the DNS servers are made unavailable, this may cause 691 email to that site to bounce rather than being stored while the mail 692 servers are unreachable, so distribution of DNS server locations is 693 important. 695 Causing network congestion on links to and from a DNS server can have 696 similar effects to end-system attacks or routing attacks, causing DNS 697 to fail to obtain an answer, and effectively denying access to the 698 site being served. 700 We note that if an attacker can deny external access to all the DNS 701 servers for a site, this will not only cause email to that site to be 702 dropped, but will also cause email from that site to be dropped. 703 This is because recent versions of mail transfer agents such as 704 sendmail will drop email if the mail originates from a domain that 705 does not exist. This is a classic example of unexpected 706 consequences. Sendmail performs this check as an anti-spam measure, 707 and spam itself can be viewed as a form of DoS attack. Thus 708 defending against one DoS attack opens up the vulnerability that 709 allows another DoS attack. If a receiving implementation is using a 710 blackhole list (see Section 2.14) served by DNS an attacker can also 711 mount a DoS attack by attacking the blackhole server. 713 Finally, a data corruption attack is possible if a site's nameserver 714 is permitted to relay requests from untrusted third parties [39]. 715 The attacker issues a query for the data he wishes to corrupt, and 716 the victim's nameserver relays the request to the authoritative 717 nameserver. The request contains a 16-bit ID that is used to match 718 up the response with the request. If the attacker spoofs sufficient 719 response packets from the authoritative nameserver just before the 720 official response will arrive, each containing a forged response and 721 a different DNS ID, then there is a reasonable chance that one of the 722 forged responses will have the correct DNS ID. The incorrect data 723 will then be believed and cached by the victim's nameserver, so 724 giving the incorrect response to future queries. The probability of 725 the attack can further be increased if the attacker issues many 726 different requests for the same data with different DNS IDs, because 727 many nameserver implementations will issue relayed requests with 728 different DNS IDs, and so the response only has to match any one of 729 these request IDs [6] [33]. 731 The use of anycast for DNS services makes it even more vulnerable to 732 spoofing attacks. An attacker who can convince the ISP to accept an 733 anycast route to his fake DNS server can arrange to receive requests 734 and generate fake responses. Anycast DNS also makes DoS attacks on 735 DNS easier. The idea is to disable one of the DNS servers while 736 maintaining the BGP route to that server. This creates failures for 737 any client which is routed to the (now defunct) server. 739 2.7. DoS Attacks on Links 741 The simplest DoS attack is to simply send enough non-congestion- 742 controlled traffic such that a link becomes excessively congested, 743 and legitimate traffic suffers unacceptably high packet loss. 745 Under some circumstances the effect of such a link DoS can be much 746 more extensive. We have already discussed the effects of denying 747 access to a DNS server. Congesting a link might also cause a routing 748 protocol to drop an adjacency if sufficient routing packets are lost, 749 potentially greatly amplifying the effects of the attack. Good 750 router implementations will prioritize the transmission of routing 751 packets, but this is not a total panacea. If routers are peered 752 across a shared medium such as ethernet, it may be possible to 753 congest the medium sufficiently that routing packets are still lost. 755 Even if a link DoS does not cause routing packets to be lost, it may 756 prevent remote access to a router using ssh or SNMP. This might make 757 the router unmanageable, or prevent the attack from being correctly 758 diagnosed. 760 The prioritization of routing packets can itself cause a DoS problem. 761 If the attacker can cause a large amount of routing flux, it may be 762 possible for a router to send routing packets at a high enough rate 763 that normal traffic is effectively excluded. This is however 764 unlikely except on low bandwidth links. 766 Finally, it may be possible to an attacker to deny access to a link 767 by causing the router to generate sufficient monitoring or report 768 traffic that the link is filled. SNMP traps are one possible vector 769 for such an attack, as they are not normally congestion controlled. 771 Attackers with physical access to multiple access links can easily 772 bring down the link. This is particularly easy to mount and 773 difficult to counter with wireless networks. 775 2.8. DoS attacks on firewalls 777 Firewalls are intended to defend the systems behind them against 778 attack. In that they restrict the traffic that can reach those 779 systems, they may also aid in defending against denial-of-service 780 attacks. However, under some circumstances the firewall itself may 781 also be used as a weapon in a DoS attack. 783 There are many different types of firewall, but generally speaking 784 they fall into stateful and stateless classes. The state here refers 785 to whether the firewall holds state for the active flows traversing 786 the firewall. Stateless firewalls generally can only be attacked by 787 attempting to exhaust the processing resources of the firewall. 788 Stateful firewalls can be attacked by sending traffic that causes the 789 firewall to hold excessive state or state which has pathological 790 structure. 792 In the case of excessive state, the firewall simply runs out of 793 memory, and can no longer instantiate the state required to pass 794 legitimate flows. Most firewalls will then fail disconnected, 795 causing denial-of-service to the systems behind the firewall. 797 In the case of pathological structure, the attacker sends traffic 798 that causes the firewall's data structures to exhibit worst case 799 behaviour. An example of this would be when the firewall uses hash 800 tables to look up forwarding state, and the attacker can predict the 801 hash function used. The attacker may then be able to cause a large 802 amount of flow state to hash to the same bucket, which causes the 803 firewall's lookup performance to change from O(1) to O(n), where n is 804 the number of flows the attacker can instantiate [18]. Thus the 805 attacker can cause forwarding performance to degrade to the point 806 where service is effectively denied to the legitimate traffic 807 traversing the firewall. 809 2.9. DoS attacks on IDS systems 811 Intrusion detection systems (IDS) suffer from similar problems to 812 firewalls. It may be possible for an attacker to cause the IDS to 813 exhaust its available processing power, to run out of memory, or to 814 instantiate state with pathological structure. Unlike a firewall, an 815 IDS will normally fail open, which will not deny service to the 816 systems protected by the IDS. However it may mean that subsequent 817 attacks that the IDS would have detected will be missed. 819 Some IDSs are reactive; that is on detection of a hostile event they 820 react to block subsequent traffic from the hostile system, or to 821 terminate an ongoing connection from that system. It may be possible 822 for an attacker to spoof packets from a legitimate system, and hence 823 cause the IDS to believe that system is hostile. The IDS will then 824 cause traffic from the legitimate system to be blocked, hence denying 825 service to it. The effect can be particularly bad if the legitimate 826 system is a router, DNS server, or other system whose performance is 827 essential for the operation of a large number of other systems. 829 2.10. DoS attacks on or via NTP 831 Network time servers are generally not considered security-critical 832 services, but under some circumstances NTP servers might be used to 833 perpetrate a DoS attack. 835 The most obvious such attack is to DoS the NTP servers themselves. 836 Many end systems have rather poor clock accuracy and so, without 837 access to network time, their clock will naturally drift. This can 838 cause problems with distributed systems that rely on good clocks. 839 For example one commonly used revision control system can fail if it 840 perceives the modification timestamp to be in the future. 842 If the NTP servers relied on by a host can be subverted, either 843 through compromising or impersonating them, then the attacker may be 844 able to control the host's system clock. This can cause many 845 unexpected consequences, including the premature expiry of dated 846 resources such as encryption or authentication keys. This in turn 847 can prevent access to other more critical services. 849 2.11. Physical DoS 851 The discussion thus far has centered on denial-of-service attacks 852 perpetrated using the network. However, computer systems are only as 853 resilient as the weakest link. It may be easier to deny service by 854 causing a power failure, by cutting network cables, or by simply 855 switching a system off, and so physical security is at least as 856 important as network security. Physical attacks can also serve as 857 entry points for non-physical DoS, for instance by reducing the 858 resources available to deal with overcapacity. 860 2.12. Social Engineering DoS 862 The weakest link may also be human. In defending against DoS, the 863 possibility of denial-of-service through social engineering should 864 not be neglected, such as convincing an employee to make a 865 configuration change that prevents normal operation. 867 2.13. Legal DoS 869 Computer systems cannot be considered in isolation from the social 870 and legal systems in which they operate. This document focuses 871 primarily on the technical issues, but we note that "cease and 872 desist" letters, government censorship, and other legal mechanisms 873 also touch on denial-of-service issues. 875 2.14. Spam and Black-hole Lists 877 Unsolicited commercial email, also known as "spam", can effectively 878 cause denial-of-service to email systems. While the intent is not 879 denial-of-service, the large amount of unwanted mail can waste the 880 recipient's time, or cause legitimate email to fail to be noticed 881 amongst all the background noise. If spam filtering software is 882 used, some level of false positives is to be expected, and so these 883 messages are effectively denied service. 885 One mechanism to reduce spam is the use of black-hole lists. The IP 886 addresses of dial-up ISPs or mail servers used to originate or relay 887 spam are added to black-hole lists. The recipients of mail choose to 888 consult these lists and reject spam if it originates or is relayed by 889 systems on the list. One significant problem with such lists is that 890 it may be possible for an attacker to cause a victim to be black-hole 891 listed, even if the victim was not responsible for relaying spam. 892 Thus the black-hole list itself can be a mechanism for effecting a 893 DoS attack. Note that every black-hole list has its own policy 894 regarding additions, and some are less susceptible to this DoS attack 895 than others. Consumers of black-hole list technology are advised to 896 investigate these policies before they subscribe. Similar 897 considerations apply to feeds of bad BGP bad route advertisements. 899 3. Attack Amplifiers 901 Many of the attacks described above rely on sending sufficient 902 traffic to overwhelm the victim. Such attacks are made much easier 903 by the existence of "attack amplifiers", where an attacker can send 904 traffic from the spoofed source address of the victim and cause 905 larger responses to be returned to the victim. A detailed discussion 906 of such reflection attacks can be found in [31]. 908 3.1. Methods of Attack Amplification 910 The simplest such attack was the "smurf" attack [11], where an ICMP 911 echo request packet with the spoofed source address of the victim is 912 sent to the subnet-broadcast address of a network to be used as an 913 amplifier. Every system on that subnet then responds with an ICMP 914 echo response that returns to the victim. Smurf attacks are no 915 longer such a serious problem, as these days routers usually drop 916 such packets and end-systems do not respond to them. 918 An alternative form of attack amplifier is typified by a DNS 919 reflection attack. An attacker sends a DNS request to a DNS server 920 requesting resolution of a domain name. Again the source address of 921 the request is the spoofed address of the victim. The request is 922 carefully chosen so that the size of the response is significantly 923 greater than the size of the request, thereby providing the 924 amplification. As an aside, it is interesting to note that the 925 largest DNS responses tend to be those incorporating DNSsec 926 authentication information. This attack amplifier can only be used 927 by an attacker with the ability to spoof the source address of the 928 victim. However, we note that if the victim's DNS server is 929 configured to relay requests from external clients, it may be 930 possible to cause it to congest its own incoming network link. 932 Another variant of attack amplifier involves amplification through 933 retransmission. This is typified by a TCP amplification attack known 934 as "bang.c". The attacker sends a spoofed TCP SYN with the source 935 address of the victim to an arbitrary TCP server. The server will 936 respond with a SYN|ACK which is sent to the victim, and when no final 937 ACK is received to complete the handshake, the SYN|ACK will be 938 retransmitted a number of times. Typically this attack uses a very 939 large list of arbitrarily chosen servers as reflectors. For the 940 attack to be successful, the reflector must not receive a RST from 941 the victim in response to the SYN|ACK - however if the attack traffic 942 sufficiently overwhelms the server or access link to the server, then 943 packet loss will ensure that many reflectors do not receive a RST in 944 response to their SYN|ACK, and so continue to retransmit. The attack 945 can be exacerbated by firewalls that silently drop the incoming SYN| 946 ACK without sending a RST. 948 Care must also be taken with services that relay requests. If an 949 attacker can send a request to a proxy, and that proxy now attempts 950 to connect to a victim whose address is chosen by the attacker then, 951 if the proxy repeatedly resends the request when receiving no answer, 952 this can also serve as an attack amplifier. 954 Another variant of amplification occurs in protocols that include, 955 within the protocol payload, an IP address or name of host to which 956 subsequent messages should be sent. An example of such a protocol is 957 the Session Initiation Protocol (SIP), which carries a payload 958 defined by the Session Description Protocol (SDP). The SDP payload 959 of the SIP message conveys the IP address and port to which media 960 packets, typically encoded using the Real Time Transport Protocol 961 (RTP), are sent. 963 To launch this attack, an attacker sends a protocol message, and sets 964 the IP address within the payload to point to the attack target. The 965 recipient of the message will generate subsequent traffic to that IP 966 address. Depending on the protocol, this attack can provide 967 substantial amplification properties. In the specific case of SIP, 968 if a caller makes calls to high bandwidth media sources (such as a 969 video server or streaming audio server), a single SIP INVITE packet, 970 typically a few hundred bytes, can result in a nearly continuous 971 stream of media packets at rates anywhere from a few kbits per second 972 up to megabits per second. This particular attack is called the 973 "voice hammer". 975 Unlike the other techniques described above, this technique does not 976 require the attacker to modify packets or even spoof their source IP 977 address. This makes it easier to launch. 979 This attack is prevented through careful protocol design. Protocols 980 should, whenever possible, avoid including IP addresses or hostnames 981 within protocol payloads as addresses to which subsequent messaging 982 should be sent. Rather, when possible, messages should be sent to 983 the source IP from which the protocol packet came. If such a design 984 is not possible, the protocol should include a handshake whereby it 985 can be positively determined that the protocol entity at that IP 986 address or hostname does, in fact, wish to receive that subsequent 987 messaging. That handshake itself needs to be lightweight (to avoid 988 being the source of another DoS attack), and secured against the 989 spoofing of the handshake response. 991 Finally, a somewhat similar attack is possible with some protocols 992 where where one message leads to another message that is not sent as 993 a reply to the source address of the first message. This can be an 994 issue with protocols to enable mobility for example, and might permit 995 an attacker to avoid ingress filtering. Such protocols are 996 notoriously difficult to get right. 998 3.2. Strategies to Mitigate Attack Amplification 1000 In general, the architectural lessons to be learnt are simple: 1002 o As far as possible, perform ingress filtering [22] [37] to prevent 1003 source address spoofing. 1005 o Avoid designing protocols or mechanisms that can return 1006 significantly larger responses than the size of the request, unless a 1007 handshake is performed to validate the client's source address. Such 1008 a handshake needs to incorporate an unpredictable nonce that is 1009 secure enough to mitigate the amplification effects of the protocol. 1011 o All retransmission during initial connection setup should be 1012 performed by the client. 1014 o Proxies should not arbitrarily relay requests to destinations 1015 chosen by a client. 1017 o Avoid signaling third-party connections. Any unavoidable third- 1018 party connections setup by a signaling protocol should incorporate 1019 lightweight validation before sending significant data. 1021 4. DoS Mitigation Strategies 1023 A general problem with DoS defense is that it is not in principle 1024 possible to distinguish between a flash-crowd and a DoS attack. 1025 Indeed, having your site taken down by a flash crowd is probably a 1026 more common experience than having it DoS-ed --- so common it's 1027 acquired its own names: being Slashdotted or Farked, after the web 1028 sites that are common sources of flash crowds. Thus, the first line 1029 of defense against DoS attacks must be to provision your service so 1030 that it can handle a foreseeable legitimate peak load. 1031 Underprovisioned sites are the easiest to take down. 1033 Specific strategies for DoS defense fall into two broad categories: 1035 1. Avoiding allowing attacks that are better than generic resource 1036 consumption. 1038 2. Minimizing the extent to which generic resource consumption 1039 attacks crowd out legitimate users. 1041 In the remainder of this section, we consider specific applications 1042 of these two approaches at a variety of levels of network system 1043 architecture. 1045 4.1. Protocol Design 1047 4.1.1. Don't Hold State for Unverified Hosts 1049 From an end-system server point of view, one simple aim is to avoid 1050 instantiating state without having completed a handshake with the 1051 client to validate their address, and as far as possible to push work 1052 and stateholding to client. There are a number of techniques that 1053 might be used to do this, including SYN-cookies [5] [2]. All client- 1054 server protocols should probably be designed to allow such techniques 1055 to be used, but the enabling of the mechanism should normally be at 1056 the server's discretion to avoid unnecessary work under normal 1057 circumstances. 1059 4.1.2. Make it Hard to Simulate a Legitimate User 1061 Other than having massive overcapacity, the only real defense against 1062 resource consumption attacks is to preferentially discriminate 1063 against attackers. The general idea is to find something that 1064 legitimate users can do but attackers can't. The most commonly 1065 proposed approaches include: 1067 1. Puzzles: force the attacker to do some computation that would not 1068 be onerous for a single user but is too expensive to do en masse. 1070 [2] 1072 2. Reverse Turing Tests: specialized puzzles that are hard for 1073 machines to do but easy for humans, thus making automated attacks 1074 hard.[42] 1076 3. Reachability testing: force the proposed client to demonstrate 1077 that it can receive traffic at a given IP address. This makes it 1078 easier to trace attackers. 1080 All of these techniques have substantial limitations. Puzzles tend 1081 to discriminate against legitimate users with slow computers. In 1082 addition, the wide availability of "bots" means that attackers have 1083 ample computing power at their disposal. There has been substantial 1084 work in attacking Reverse Turing Tests automatically, thus making 1085 them of limited applicability. Finally, reachability testing is 1086 substantially weakened by bots because the attacker does not need to 1087 hide his source address. 1089 4.1.3. Graceful Routing Degradation 1091 A goal with routing protocols is that of graceful degradation in 1092 overload, and automatic recovery after the source of the overload has 1093 been remedied. Some routing protocols satisfy this goal more than 1094 others. Although RIP doesn't scale well, if a router runs out of 1095 memory when receiving a RIP route, it can just drop the route and 1096 send an infinite metric to its peers. The route will later be 1097 refreshed, and if the original source of the problem has been 1098 resolved, the router will now be able to process it correctly. 1100 On the other hand, BGP is stateful in the sense that a peer assumes 1101 you have processed or chosen to filter any route that it sent you. 1102 There is no mechanism to refresh state in the base BGP spec, and even 1103 the later route refresh option [16] is hard to use usefully in the 1104 presence of overload. A BGP router that cannot store a route it 1105 received has two choices: completely restart BGP, or shutdown one or 1106 more peerings [15]. This means that the effects of a BGP overload 1107 are rather more severe than they need to be, and so amplifies the 1108 effect of any attack. 1110 In general, few routing protocol designs actively consider the 1111 possible behaviour of routers under overload conditions; this should 1112 be an explicit part of future routing protocol designs. Although 1113 precise details should clearly be left to implementors, the protocol 1114 design needs to give them the capability to do their job properly. 1116 4.1.4. Autoconfiguration and Authentication 1118 Autoconfiguration mechanisms greatly ease deployment, and are 1119 increasingly necessary as the number of networked devices grows 1120 beyond what can be managed manually. However, it should be 1121 recognised that unauthenticated autoconfiguration opens up many 1122 avenues for attack. There is a clear tension between ease of 1123 configuration and security of configuration, especially because there 1124 are environments in which it is desirable for units to operate with 1125 effectively no authentication (e.g., airport hotspots). Future 1126 autoconfiguration protocols should consider the need to allow 1127 different end-systems to operate at different points in this spectrum 1128 within the same autoconfiguration framework. However, this also 1129 implies that the network elements should avoid acting for 1130 unauthenticated hosts, instead just letting them access the network 1131 more or less directly. 1133 4.2. Network Design and Configuration 1135 In general, networks should be provisioned with private, out-of-band 1136 access to console or control ports so that such control facilities 1137 will be available in the face of a DoS attack launched against either 1138 the control or data plane of the (in-band) network. Typically such 1139 out-of-band networks are provisioned on a separate infrastructure for 1140 exactly this purpose. Out-of-band access is a crucial capability for 1141 DoS mitigation, since many of the typical redundancy and capacity 1142 management techniques (such as prioritizing routing or network 1143 management traffic) fail during such attacks. In addition, many 1144 redundancy protocols such as VRRP [50] can fail during such attacks 1145 as they may be unable to keep adjacencies alive. 1147 There are several default configuration settings that can also be 1148 exploited to generate several of the attacks outlined in this 1149 document. For example, some vendors may have features such as IP 1150 redirect, directed broadcast, and proxy ARP enabled by default. 1151 Similar defaults, such as publicly readable SNMP [51] communities 1152 (e.g., "public") can be used to reveal otherwise confidential 1153 information to a prospective attacker. Finally, other 1154 unauthenticated configuration management protocols such as TFTP 1155 [RFC1350] should be avoided if possible; at the very least access to 1156 TFTP configuration archives should be protected and TFTP should be 1157 filtered at administrative boundaries. Finally, since many of the 1158 password encryption techniques used by router vendors are reversible, 1159 keeping such passwords on a configuration archive (as part of a 1160 configuration file), even in the encrypted form written by the 1161 router, can lead to unauthorized access if the archive is 1162 compromized. 1164 4.2.1. Redundancy and Distributed Service 1166 A basic principle of designing systems to handle failure to have 1167 redundant servers which can take over when one fails. This is 1168 equally true in the case of DoS attacks, which often focus on a given 1169 server and/or link. If service delivery points can be distributed 1170 across the network, then it becomes much harder to attack the entire 1171 service. In particular, this makes attacks on a single network link 1172 more difficult. 1174 4.2.2. Authenticate Routing Adjacencies 1176 In general, cryptographic authentication mechanisms are too costly to 1177 form the main part in DoS prevention. However, routing adjacencies 1178 are too important to risk an attacker being able to inject bad 1179 routing information, which can affect more than the router in 1180 question. Additional non-cryptographic mechanisms should then be 1181 used to avoid arbitrary end-systems being able to cause the router to 1182 spend CPU cycles on validating authentication data. 1184 For BGP, at the very least, this implies the use of TCP MD5 [24] or 1185 IPsec authentication, combined with the GTSM [23] to prevent EBGP 1186 association with non-immediate neighbours. In future, this will 1187 likely imply better authentication of the routing information itself. 1189 4.2.3. Isolate Router-to-Router Traffic 1191 As far as is feasible, router-to-router traffic should be isolated 1192 from data traffic. How this should be implemented depends on the 1193 precise technologies available, both in the router and at the link- 1194 layer. The goal should be that failure of the link for data traffic 1195 should also cause failure for the routing traffic, but that an 1196 attacker cannot directly send packets to the control processor of the 1197 routers. 1199 A downside of this is that some diagnostic techniques (such as 1200 pinging consecutive routers to find the source of a delay) may no 1201 longer be possible. Ideally, alternative mechanisms (which do not 1202 open up additional avenues for DoS) should be designed to replace 1203 such lost techniques. 1205 4.3. Router Implementation Issues 1207 Because a router can be considered as an end-system, it can 1208 potentially benefit from all the prevention mechanisms prescribed for 1209 end-system implementation. However one basic distinction between a 1210 router and a host is that the former implements routing protocols and 1211 forwards data, which in turn lead to additional router specific 1212 implementation considerations. The issues described below are meant 1213 to be illustrative and not exhaustive. 1215 4.3.1. Checking Protocol Syntax and Semantics 1217 Protocol syntax defines the formation of the protocol messages and 1218 the rules of exchanges. The questions addressed by protocol syntax 1219 checking includes, but is not limited to, the following: 1221 1. Who sent the message? 1223 2. Does the content conform to the protocol format? 1225 3. Was the message sent with correct timing? 1227 The first step in protocol syntax verification is to ensure that an 1228 incoming message was sent by a legitimate party. There are multiple 1229 ways to perform this check. One can verify the source IP address and 1230 even the MAC address of the message. Utilizing the fact that eBGP 1231 peers are normally directly connected, one can also check the TTL 1232 value in a packet and discard any BGP updates packet whose TTL is 1233 less than some maximum value (typically max TTL - 1) [23]. 1234 Cryptographic authentication should also be used whenever available 1235 to verify that an incoming message is indeed from an expected sender. 1236 For BGP, at the very least, this implies the use of TCP MD5 [24] or 1237 IPsec authentication. 1239 In addition to the sender verification, it is also important to check 1240 the syntax of a received routing message, as opposed to assuming that 1241 all messages came in a correct format. It happened in the past that 1242 routers crashed upon receiving ill-formed routing messages. Such 1243 faults will be prevented by performing rigorous syntax checking. 1245 4.3.2. Consistency Checks 1247 Protocol semantics define the meaning of the message content, the 1248 interpretation of the values, and the actions to be taken according 1249 to the content. Here is a simple example of using semantic checking. 1250 When a link failure causes a router in AS A to send a peer router B a 1251 withdrawal message for prefix P, B should make sure that any 1252 alternative path it finds to reach P does not go through A. This 1253 simple check is shown to significantly improve BGP convergence time 1254 in many cases [45]. 1256 Another example of using semantic checking against false routing 1257 injection is described in [47]. The basic idea is to attach to the 1258 route announcement for prefix P a list of the valid origin ASes. Due 1259 to the rich connectivity in today's Internet topology, a remote AS 1260 will receive routing updates from multiple different paths and can 1261 check to see whether each update carries the identical origin AS 1262 list. Although a false origin may announce reachability to P, or 1263 alter the origin AS list, it would be difficult, if not impossible, 1264 to block the correct updates from propagating out, thus remote ASes 1265 can detect the existence of false updates by observing the 1266 inconsistency of the received origin AS lists for P. Research studies 1267 show that the "allowed origin list" test can effectively detect 1268 majority of falsely originated updates. 1270 Generally speaking, verifying the validity of BGP routes can be 1271 challenging because BGP is policy driven and policies of individual 1272 ISPs are not known in most cases. But assuming policies do not 1273 change in short time scale, in principle one could verify new updates 1274 against observed routes from recent past, which reflect the routing 1275 policies in place. Research work is needed to explore this 1276 direction. 1278 Note that while the above steps are all fairly simple and don't 1279 really "bullet-proof" the protocol, each adds some degree of 1280 protection. As such, the combination of the above techniques can 1281 result in an efffective reduction in the probability of undetected 1282 faults. 1284 4.3.3. Enhance Router Robustness through Operational Adjustments 1286 There exist a number of configuration tunings that can enhance 1287 robustness of BGP operations. One example is to let BGP peers 1288 coordinate the setting of a limit on the number of prefixes which one 1289 BGP speaker will send to its peer [46]. Although such check does not 1290 validate the prefix owned by each peer, it can prevent false 1291 announcements of large number of invalid routes. Had all BGP routers 1292 been configured with this simple checking earlier, several large 1293 scale routing outages in the past could have been prevented. Note, 1294 however, that care must be taken with hard limits of this type 1295 because they can be used to mount a DoS because implementations often 1296 discard excess routes indiscriminately, thus potentially causing 1297 black-holing of correct routes. 1299 Another example of useful configuration tuning is to adjust the BGP's 1300 KeepAlive and Hold Timer values to minimize BGP peering session 1301 resets. Previous measurements show that heavy traffic load, such as 1302 those caused by Worms, can cause BGP KeepAlive messages to be delayed 1303 or dropped, which in turn cause BGP peering session break down. Such 1304 load-induced session breaks and re-establishments can lead to an 1305 excessive amount of BGP updates during the periods when stable 1306 routing is needed most. 1308 4.3.4. Proper Handling of Router Resource Exhaustion 1310 In addition to the resource exhaustion problems that are generally 1311 apply to all end systems, as described in Section 2, router 1312 implementations must also take special care in handling resource 1313 exhaustions when they occur in order to keep the router operating 1314 despite the problem. For example under normal operations a router 1315 does not require a large cache to hold outstanding ARP requests 1316 because the replies are normally received within a few milliseconds. 1317 However certain conditions can lead to ARP cache exhaustion, for 1318 example during a virus attack where many packets are sent to non- 1319 existing IP addresses, thus there are no ARP replies to the requests 1320 for those addresses. Such phenomena have happened in the past and 1321 led to routers failing to forward packets. 1323 Another example is queue management. Many high-end routers are 1324 designed so that most packets can be handled purely in specialized 1325 processors (ASICs, FPGAs, etc.). However, exceptional packets must 1326 be routed to a supporting general purpose CPU for handling. On some 1327 such systems, it may be possible mount a low-effort DoS attack by 1328 saturating the queues between the specialized hardware and the 1329 supporting processor. 1331 So the attack vector on routers/network devices is a low PPS queue 1332 saturation attack on the ASIC's raw queue structure. The 1333 countermeasure here is to have multiple such queues designed in such 1334 a way that it's difficult for an attacker to arrange to fill multiple 1335 queues [41]. 1337 4.4. End-System Implementation Issues 1339 4.4.1. State Lookup Complexity 1341 Any system that instantiates per-connection state should take great 1342 care to implement state-lookup mechanisms in such a way that 1343 performance can not be controlled by the attacker. One way to 1344 achieve this is to use hash-tables where the hash mechanism is keyed 1345 in such a way that the attacker cannot instantiate a large number of 1346 flows in the same hash bucket. 1348 4.4.1.1. Avoid Livelock 1350 Most operating systems use network interrupts to receive data from 1351 the network, which is a good solution if the host spends only a small 1352 amount of its time handling network traffic. However, this leaves 1353 the host open to livelock [29], where under heavy load the OS spends 1354 all its time handling interrupts and no time doing the work needed to 1355 handle the traffic at the application level. Server operating 1356 systems should consider using network polling at times of heavy load, 1357 rather than being interrupt-driven, and should be carefully 1358 architected so that as far as reasonably possible, traffic received 1359 by the OS is processed to completion, or very cheaply discarded. 1361 4.4.1.2. Use Unpredictable Values for Session IDs 1363 Most recent TCP implementations use fairly good random mechanisms for 1364 allocating the TCP initial sequence numbers. In general, any 1365 dynamically allocated value used purely to identify a communication 1366 session should be allocated using an unpredictable mechanism, as this 1367 increases the search space for an attacker that wishes to disrupt 1368 ongoing communications. Thus the dynamically allocated port of the 1369 active end of a TCP connection might also be randomly allocated. 1371 With DNS, the ID which is used to match responses with requests 1372 should also be randomly generated. However, as the ID field is only 1373 16 bits, the protection is rather limited. 1375 4.4.2. Operational Issues 1377 4.4.2.1. Eliminate Bad Traffic Early 1379 Many DoS attacks are generic bandwidth consumption attacks that 1380 operate by clogging the link that connects the victim server to the 1381 Internet. Filtering these attacks at the server does no good because 1382 the traffic has already traversed the link which is the scarce 1383 resource. Such flows need to be filtered at some point closer to the 1384 attacker. Where possible, operators should filter out obviously bad 1385 traffic. In particular, they should perform ingress filtering [22]. 1387 4.4.2.2. Establish a Monitoring Framework 1389 Network operators are strongly encouraged to establish a monitoring 1390 framework to detect and log abnormal network activity. One can not 1391 defend against an attack one doesn't detect or understand. Such 1392 monitoring tools can be used to set a baseline of "normal" traffic, 1393 and can be used to detect aberrant flows and determine the type and 1394 source of the aberrant flows. This is extremely helpful when 1395 responding to distributed DoS attacks or a flash crowd, and should be 1396 in place prior to the event. 1398 5. Conclusions 1400 In this document we have highlighted possible avenues for DoS attacks 1401 on networks and networked systems, with the aim of encouraging 1402 protocol designers and network engineers towards designs that are 1403 more robust. We have discussed partial solutions that reduce the 1404 effectiveness of attacks, and highlighted how some partial solutions 1405 can be taken advantage of by attackers to perpetrate alternative 1406 attacks. 1408 Our focus has primarily been on protocol and network architecture 1409 issues, but there are many things that network and service operators 1410 can do to lessen the threat. Further advice and information for 1411 network operators can be found in [13] [37] [14]. 1413 It is our hope that this document will spur discussion leading to 1414 architectural solutions that reduce the succeptibility of all 1415 Internet systems to denial-of-service attacks. 1417 6. Security Considerations 1419 This entire document is about security. 1421 7. Acknowledgements 1423 We are very grateful to Vern Paxson, Paul Vixie, Rob Thomas, Dug 1424 Song, George Jones, Jari Arkko, and Geoff Huston for their 1425 constructive comments on earlier versions of this document. 1427 8. Normative References 1429 [1] J. Abley, "Hierarchical Anycast for Global Service Distribution", 1430 http://www.isc.org/tn/isc-tn-2003-1.txt 1432 [5] D.J. Bernstein, "SYN Cookies", http://cr.yp.to/syncookies.html 1434 [16] E. Chen, "Route Refresh Capability for BGP-4", RFC 2918, 1435 September 2000 1437 [19] S. Deering, "Host extensions for IP multicasting", RFC 1112, Aug 1438 1989. 1440 [20] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, 1441 Jan 1999. 1443 [21] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. 1444 Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol 1445 Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", 1446 RFC 2362, June 1998. 1448 [22] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating 1449 Denial of Service Attacks which employ IP Source Address Spoofing", 1450 RFC 2827, May 2000. 1452 [23] V. Gill, J. Heasley, D. Meyer "The Generalized TTL Security 1453 Mechanism (GTSM)", RFC 3682, February 2004. 1455 [24] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 1456 Signature Option", RFC 2385, August 1998. 1458 [32] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1459 1771, March 1995. 1461 [35] C. Villamizar, R. Chandra, R. Govindan, "BGP Route Flap 1462 Damping", RFC 2439, November 1998. 1464 [38] D. Waitzman, C. Partridge, S.E. Deering, "Distance Vector 1465 Multicast Routing Protocol", RFC 1075, Nov 1988. 1467 [42] L. von Ahn, M. Blum, N. Hopper, and J. Langford. CAPTCHA: Using 1468 hard AI problems for security. In Proceedings of Eurocrypt, 2003. 1470 9. Informative References 1472 [2] T. Aura, P. Nikander, J. Leiwo, "DOS-resistant authentication 1473 with client puzzles", In B. Christianson, B. Crispo, and M. Roe, 1474 editors, Proceedings of the 8th International Workshop on Security 1475 Protocols, Lecture Notes in Computer Science, Cambridge, UK, April 1476 2000. 1478 [3] J. Bellardo, S. Savage, "802.11 Denial-of-Service Attacks: Real 1479 Vulnerabilities and Practical Solutions", Proceedings of the USENIX 1480 Security Symposium, Washington D.C., August 2003. 1482 [4] S.M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", 1483 Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April 1989. 1485 [6] CCAIS/RNP Alertas do Cais ALR-19112002a, "Vulnerability in the 1486 sending requests control of Bind versions 4 and 8 allows DNS 1487 spoofing", http://www.rnp.br/cais/alertas/2002/cais- ALR- 1488 19112002a.html 1490 [7] CERT Advisory CA-1996-01, "UDP Port Denial-of-Service Attack", 1491 Feb 1996. 1493 [8] CERT Advisory CA-1996-21, "TCP SYN Flooding and IP Spoofing 1494 Attacks", Sept 1996. 1496 [9] CERT Advisory CA-2001-09, "Statistical Weaknesses in TCP/IP 1497 Initial Sequence Numbers", May 2001. 1499 [10] CERT Advisory CA-1996-26, "Denial-of-Service Attack via ping", 1500 Dec 1996. 1502 [11] CERT Advisory CA-1998-01, "Smurf IP Denial-of-Service Attacks", 1503 http://www.cert.org/advisories/CA-1998-01.html, Jan 1998. 1505 [12] CERT Incident Note IN-2000-05, "'mstream' Distributed Denial of 1506 Service Tool", May 2000. 1508 [13] CERT/CC - "Managing the Threat of Denial of Service Attacks", 1509 http://www.cert.org/archive/pdf/Managing_DoS.pdf 1511 [14] CERT/CC - "Trends in Denial of Service Attack Technology", 1512 http://www.cert.org/archive/pdf/DoS_trends.pdf 1514 [15] D.F. Chang, R. Govindan, J. Heidemann, "An Empirical Study of 1515 Router Response to Large Routing Table Load", Proceedings of the 2nd 1516 Internet Measurement Workshop (IMW 2002), 2002. 1518 [17] Cisco Systems, "Configuring the BGP Maximum-Prefix Feature", 1519 Cisco Document ID: 25160, http://www.cisco.com/warp/public/459/bgp- 1520 maximum-prefix.html 1522 [18] Scott A Crosby and Dan S Wallach, "Denial of Service via 1523 Algorithmic Complexity Attacks", Proceedings of the USENIX Security 1524 Symposium, Washington D.C., August 2003. 1526 [25] Laurent Joncheray, "Simple Active Attack Against TCP", 5th 1527 USENIX Security Symposium, 1995. 1529 [26] M. Lough, "A Taxonomy of Computer Attacks with Applications to 1530 Wireless", PhD thesis, Virginia Polytechnic Institute, April 2001. 1532 [27] Z. Mao, R. Govindan, G. Varghese, R. Katz, "Route Flap Dampening 1533 Exacerbates Internet Routing Convergence", Proceedings of ACM 1534 SIGCOMM, 2002. 1536 [28] D. Meyer, W. Fenner (Editors), "Multicast Source Discovery 1537 Protocol (MSDP)", RFC 3618, October 2003. 1539 [29] J. Mogul, KK. Ramakrishnan, "Eliminating Receive Livelock in an 1540 Interrupt-driven Kernel", ACM Transactions on Computer Systems, Vol 1541 15, Number 3, pp. 217-252, 1997. 1543 [30] National Infrastructure Secuity Co-ordination Center (NISCC), 1544 Vulnerability Advisory 236929, April 2004, 1545 http://www.uniras.gov.uk/vuls/2004/236929/ 1547 [31] V. Paxson, "An Analysis of Using Reflectors for Distributed 1548 Denial- of-Service Attacks", Computer Communication Review 31(3), 1549 July 2001. 1551 [33] Joe Stewart, "DNS Cache Poisoning - The Next Generation", Jan 27 1552 2003, http://www.securityfocus.com/guest/17905 1554 [34] R. Stewart (ed.), M. Dalal, (ed.) "Improving TCP's Robustness 1555 to Blind In-Window Attacks",, Internet Draft, February 2006, 1556 draft-ietf-tcpm-tcpsecure-04.txt 1558 [36] P. Vixie, G. Sneeringer, M. Schleifer, "Events of 21-Oct-2002", 1559 http://f.root-servers.org/october21.txt 1561 [37] P. Vixie, "Securing the Edge", 1562 http://www.icann.org/committees/security/sac004.txt 1564 [39] D. Wessels, "Running An Authoritative-Only BIND Nameserver", 1565 http://www.isc.org/tn/isc-tn-2002-2.txt 1567 [40] M. Zalewski, "Strange Attractors and TCP/IP Sequence Number 1568 Analysis", http://razor.bindview.com/publish/papers/tcpseq.html 1570 [41] J. Bellardo and S. Savage, "802.11 Denial-of-Service Attacks: 1571 Real Vulnerabilities and Practical Solutions", Proceedings of the 1572 12th USENIX Security Symposium, August 2003. 1574 [43] The whole world disappeared? http://www.merit.edu/mail.archives/ 1575 nanog/1998-04/msg00181.html, Apr 1998. 1577 [44] Outage: MCI Worldcom nationwide ATM network. 1578 http://www.merit.edu/ mail.archives/nanog/1999-02/msg00077.html, Feb 1579 1999. 1581 [45] D. Pei, X. Zhao, L. Wang, D. Massey, A. Mankin, F. S. Wu, and L. 1582 Zhang. Improving BGP Conver-gence Through Assertions Approach. In 1583 Proc. of IEEE INFOCOM, June 2002. 1585 [46] Srikanth Chavali, Vasile Radoaca, Mo Miri, Luyuan Fang, and 1586 Susan Hares. Peer prefix limits ex-change in bgp. http:// 1587 www.ietf.org/internet-drafts/draft-chavali-bgp-prefixlimit-01.txt, 1588 April 2004. 1590 [47] X. Zhao, D. Massey, A. Mankin, S.F. Wu, D. Pei, L. Wang, L. 1591 Zhang, "BGP Multiple Origin AS (MOAS) Conflicts", 1592 http://nanog.org/mtg-0110/lixia.html, 2001. 1594 [48] Cisco Systems, "Building Security Into the Hardware", 1595 ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/ Paris- 1596 Sept-04/SE14-BUILDING-SECURITY-INTO-THE HARDWARE-c1_8_30_04.pdf, 1597 2004. 1599 [49] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH) Protocol 1600 Architecture", RFC 4251, January 2006. 1602 [50] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., 1603 Hunt, P., Higginson, P., Shand, M. and A. Lindemn, "Virtual Router 1604 Redundancy Protocol", RFC 2338, April 1998. 1606 [51] D. Harrington, R. Presuhn, B. Wijnen., "An Architecture for 1607 Describing Simple Network Management Protocol (SNMP) Management 1608 Frameworks.", RFC 3411, December 2002. 1610 [52] K. Sollins., "The TFTP Protocol (Revision 2)", RFC 1784, July 1611 1992. 1613 Appendix A. IAB Members at the time of this writing 1615 o Bernard Aboba 1617 o Loa Andersson 1619 o Brian Carpenter 1621 o Leslie Daigle 1623 o Elwyn Davies 1625 o Kevin Fall 1627 o Olaf Kolkman 1629 o Kurtis Lindvist 1631 o David Meyer 1633 o David Oran 1635 o Eric Rescorla 1637 o Dave Thaler 1639 o Lixia Zhang 1641 Authors' Addresses 1643 Mark J. Handley (ed) 1644 UCL 1645 Gower Street 1646 London WC1E 6BT 1647 UK 1649 Email: M.Handley@cs.ucl.ac.uk 1651 Eric Rescorla (ed) 1652 Network Resonance 1653 2483 E. Bayshore #212 1654 Palo Alto 94303 1655 USA 1657 Email: ekr@networkresonance.com 1659 Intellectual Property Statement 1661 The IETF takes no position regarding the validity or scope of any 1662 Intellectual Property Rights or other rights that might be claimed to 1663 pertain to the implementation or use of the technology described in 1664 this document or the extent to which any license under such rights 1665 might or might not be available; nor does it represent that it has 1666 made any independent effort to identify any such rights. Information 1667 on the procedures with respect to rights in RFC documents can be 1668 found in BCP 78 and BCP 79. 1670 Copies of IPR disclosures made to the IETF Secretariat and any 1671 assurances of licenses to be made available, or the result of an 1672 attempt made to obtain a general license or permission for the use of 1673 such proprietary rights by implementers or users of this 1674 specification can be obtained from the IETF on-line IPR repository at 1675 http://www.ietf.org/ipr. 1677 The IETF invites any interested party to bring to its attention any 1678 copyrights, patents or patent applications, or other proprietary 1679 rights that may cover technology that may be required to implement 1680 this standard. Please address the information to the IETF at 1681 ietf-ipr@ietf.org. 1683 Disclaimer of Validity 1685 This document and the information contained herein are provided on an 1686 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1687 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1688 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1689 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1690 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1693 Copyright Statement 1695 Copyright (C) The Internet Society (2006). This document is subject 1696 to the rights, licenses and restrictions contained in BCP 78, and 1697 except as set forth therein, the authors retain all their rights. 1699 Acknowledgment 1701 Funding for the RFC Editor function is currently provided by the 1702 Internet Society.