Internet Engineering Task Force IAB INTERNET-DRAFT MarkNetwork Working Group M. Handley (ed) Internet-Draft UCL Expires: November 2004January 21, 2006 E. Rescorla (ed) Network Resonance July 20, 2005 Internet Denial of Service Considerations This documentdraft-iab-dos-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is an Internet-Draftaware have been or will be disclosed, and is subject to all provisionsany of which he or she becomes aware will be disclosed, in accordance with Section 106 of RFC2026.BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- DraftsInternet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.htmlhttp://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.htmlhttp://www.ietf.org/shadow.html. This Internet-Draft will expire on January 21, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document provides an overview of possible avenues for denial-of- service attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. An Overview of Denial-of-Service Threats . . . . . . . . . . . 6 2.1 DoS Attacks on End-systems . . . . . . . . . . . . . . . . 6 2.1.1 Exploiting Poor Software Quality . . . . . . . . . . . 6 2.1.2 Application Resource Exhaustion . . . . . . . . . . . 7 2.1.3 Operating System Resource Exhaustion . . . . . . . . . 8 2.1.4 Triggered Lockouts and Quota Exhaustion . . . . . . . 9 2.2 DoS Attacks on Routers . . . . . . . . . . . . . . . . . . 9 2.2.1 Attacks on Routers through Routing Protocols . . . . . 10 2.2.2 IP Multicast-based DoS Attacks . . . . . . . . . . . . 11 2.2.3 Attacks on Router Forwarding Engines . . . . . . . . . 12 2.3 Attacks on Ongoing Communications . . . . . . . . . . . . 13 2.4 Attacks using the Victim's Own Resources . . . . . . . . . 14 2.5 DoS Attacks on Local Hosts or Infrastructure . . . . . . . 14 2.6 DoS Attacks on Sites though DNS . . . . . . . . . . . . . 15 2.7 DoS Attacks on Links . . . . . . . . . . . . . . . . . . . 17 2.8 DoS attacks on firewalls . . . . . . . . . . . . . . . . . 17 2.9 DoS attacks on IDS systems . . . . . . . . . . . . . . . . 18 2.10 DoS attacks on or via NTP . . . . . . . . . . . . . . . . 18 2.11 Physical DoS . . . . . . . . . . . . . . . . . . . . . . . 19 2.12 Social Engineering DoS . . . . . . . . . . . . . . . . . . 19 2.13 Legal DoS . . . . . . . . . . . . . . . . . . . . . . . . 19 2.14 Spam and Black-hole Lists . . . . . . . . . . . . . . . . 19 3. Attack Amplifiers . . . . . . . . . . . . . . . . . . . . . . 21 3.1 Methods of Attack Amplification . . . . . . . . . . . . . 21 3.2 Strategies to Mitigate Attack Amplification . . . . . . . 23 4. DoS Mitigation Strategies . . . . . . . . . . . . . . . . . . 24 4.1 Protocol Design . . . . . . . . . . . . . . . . . . . . . 24 4.1.1 Don't Hold State for Unverified Hosts . . . . . . . . 24 4.1.2 Make it Hard to Simulate a Legitimate User . . . . . . 24 4.1.3 Graceful Routing Degradation . . . . . . . . . . . . . 25 4.1.4 Autoconfiguration and Authentication . . . . . . . . . 26 4.1.5 Network Design and Configuration . . . . . . . . . . . 26 4.1.6 Redundancy and Distributed Service . . . . . . . . . . 26 4.1.7 Authenticate Routing Adjacencies . . . . . . . . . . . 26 4.1.8 Isolate Router-to-Router Traffic . . . . . . . . . . . 26 4.2 Router Implementation Issues . . . . . . . . . . . . . . . 27 4.3 End-System Implementation Issues . . . . . . . . . . . . . 27 4.3.1 State Lookup Complexity . . . . . . . . . . . . . . . 27 4.3.2 Operational Issues . . . . . . . . . . . . . . . . . . 28 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35 A. IAB Members at the time of this writing . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . 37 1. Introduction A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work. The victim can be a network server, client or router, a network link or an entire network, an individual Internet user or a company doing business using the Internet, an Internet Service Provider (ISP), country, or any combination of or variant on these. Denial of service attacks may involve gaining unauthorized access to network or computing resources, but for the most part in this document we focus on the cases where the denial-of-service attack itself does not involve a compromise of the victim's computing facilities. Because of the closed context of the original ARPAnet and NSFnet, no consideration was given to denial-of-service attacks in the original Internet Architecture. As a result, almost all Internet services are vulnerable to denial-of-service attacks of sufficient scale. In most cases, sufficient scale can be achieved by compromising enough end-hostsend- hosts (typically using a virus, worm, or remotely controlled "bots") or routers, and using those compromised hosts to perpetrate the attack. Such an attack is known as a Distributed Denial of Service attack (DDoS). However, there are also many cases where a single well- connected end-system can perpetrate a successful DoS attack. This document is intended to serve several purposes: o To highlight possible avenues for attack, and by so doing encourage protocol designers and network engineers towards designs that are more robust. o To discuss partial solutions that reduce the effectiveness of attacks. o To highlight how some partial solutions can be taken advantage of by attackers to perpetrate alternative attacks. This last point appears to be a recurrent theme in DoS, and highlights the lack of proper architectural solutions. It is our hope that this document will help initiate informed debate about future architectural solutions that might be feasible and cost-effectivecost- effective for deployment. In addition it is our hope that this document will spur discussion leading to architectural solutions that reduce the succeptibility of all Internet systems to denial-of-service attacks. We note that in principle it is not possible to distinguish between a sufficiently subtle DoS attack and a flash-crowd, where unexpected heavy but non-malicious traffic has the same effect as a DoS attack. Whilst this is true, such malicious attacks are usually more expensive to launch than many of the crude attacks that have been seen to date. Thus defending against DoS is not about preventing all possible attacks, but rather is largely a question of raising the bar sufficiently high for malicious traffic. However, it is also important to note that not all DoS problems are malicious. Failed links, flash crowds, misconfigured bots, and numerous other causes can result in resource exhaustion problems, and so the overall goal should be to be robust to all forms of overload. 2. An Overview of Denial-of-Service Threats In this section we will discuss a wide range of possible DoS attacks. This list cannot be exhaustive, but the intent is to provide a good overview of the spectrum of possibilities that need to be defended against. We do not provide descriptions of any attacks that are not already publicly well documented. 184.108.40.206 DoS Attacks on End-systems We first discuss attacks on end-systems. An end-system in this context is typically a PC or network server, but it can also include any communication endpoint. For example, a router also is an end-systemend- system from the point of view of terminating TCP connections for BGP  or ssh. 220.127.116.11.1.1 Exploiting Poor Software Quality The simplest DoS attacks on end-systems exploit poor software quality on the end-systems themselves, and cause that software to simply crash. For example, buffer-overflow attacks might be used to compromise the end-system, but even if the buffer-overflow cannot be used to gain access, it will usually be possible to overwrite memory and cause the software to crash. Such vulnerabilities can in principle affect any software that uses data supplied from the network. Thus not only might a web server be potentially vulnerable, but it might also be possible to crash the back-end software (such as a database) to which a web server provides data. Software crashes due to poor coding not only affect application software, but also the operating system kernel itself. A classic example is the so-called "Ping of Death", which became widely known in 1996 . This exploit caused many popular operating systems to crash when sent a single fragmented ICMP echo request packet whose fragments totaled more than the 65535 bytes allowed in an IPv4 packet. While DoS attacks such as the ping-of-death are a significant problem, they are not a significant architectural problem. Once such an attack is discovered, the relevant code can easily be patched, and the problem goes away. We should note though that as more and more software becomes embedded, it is important not to lose the possibility of upgrading the software in such systems. 18.104.22.168.1.2 Application Resource Exhaustion Network applications exist in a context that has finite resources. In processing network traffic, such an application uses these resources to do its intended task. However, an attacker may be able to prevent the application from performing its intended task by causing the application to exhaust the finite supply of a specific resource. The obvious resources that might be exhausted include: o Available memory. o The CPU cycles available. o The disk space available to the application. o The number of processes or threads or both that the application is permitted to use. o The configured maximum number of simultaneous connections the application is permitted. This list is clearly not exhaustive, but it illustrates a number of points. Some resources are self-renewing: CPU cycles fall in this category - if the attack ceases, more CPU cycles become available. Some resources such as disk space require an explicit action to free up - if the application cannot do this automatically then the effects of the attack may be persistent after the attack has ceased. This problem has been understood for many years, and it is common practice for logs and incoming email to be stored in a separate disk partition (/var) on Unix systems. Some resources are constrained by configuration: the maximum number of processes and the maximum number of simultaneous connections are not normally hard limits, but rather are configured limits. The purpose of such limits is clearly to allow the machine to perform other tasks in the event the application misbehaves. However, great care needs to be taken to choose such limits appropriately. For example, if a machine's sole task is to be an ftp server, then setting the maximum number of simultaneous connections to be significantly less than the machine can service makes the attackers job easier. But setting the limit too high may permit the attacker to cause the machine to crash (due to poor OS design in handling resource exhaustion) or permit livelock (see below), which are generally even less desirable failure modes. 22.214.171.124.1.3 Operating System Resource Exhaustion Conceptually OS resource exhaustion and application resource exhaustion are very similar. However, in the case of application resource exhaustion, the operating system may be able to protect other tasks from being affected by the DoS attack. In the case of the operating system itself running out of resources, the problem may be more catastrophic. Perhaps the best-known DoS attack on an operating system is the TCP SYN- flood , which is essentially a memory-exhaustion attack. The attacker sends a flood of TCP SYN packets to the victim, requesting connection setup, but then does not complete the connection setup. The victim instantiates state to handle the incoming connections. If the attacker can instantiate state faster than the victim times it out, then the victim will run out of memory that it can use to hold TCP state, and so it cannot service legitimate TCP connection setup attempts. This issue was exacerbated in some implementations by the use of a small dedicated storage space for half-open connections, which made the attack easier than it might otherwise have been. In the case of a poorly coded operating system, running out of resources may also cause a system crash. An alternative TCP DoS attack is the Ack-flood , which is essentially a CPU exhaustion attack on the victim. The attacker floods the victim with TCP packets pretending to be from connections that have never been established. A busy server that has a large number of outstanding connections needs to check which connection the packet corresponds to. Some TCP implementations implemented this search rather inefficiently, and so the attacker could use all the victim's CPU resources servicing these packets rather than servicing legitimate requests. We note that strong authentication mechanisms do not mitigate against such CPU exhaustion attacks. In fact poorly designed authentication mechanisms using cryptographic methods can exacerbate the problem. If such an authentication mechanism allows an attacker to present a packet to the victim that requires relatively expensive cryptographic authentication before the packet can be discarded, then this makes the attacker's CPU exhaustion attack easier. CPU exhaustion attacks can be also be exacerbated by poor OS handling of incoming network traffic. In the absence of malicious traffic, an ideal OS should behave as follows: o As incoming traffic increases, the useful work done by the OS should increase until some resource (such as the CPU) is saturated. o From this point on, as incoming traffic continues to increase the useful work done should be constant. However, this is often not the case. Many systems suffer from livelock  where, after saturation, increasing the load causes a decrease in the useful work done. One cause of this is that the system spends an increasing amount of time processing network interrupts for packets that will never be processed, and hence a decreasing amount of time is available for the application for which these packets were intended. 2.1.4. Attacks on Ongoing Communications Instead of attacking the end-system itself, it is also possible for an attacker2.1.4 Triggered Lockouts and Quota Exhaustion Many user-authentication mechanisms attempt to disrupt ongoing communications. If an attacker can observe a TCP connection, then it is relatively easy for them to spoof packets to either reset that connection or to de-synchronize it so that no further progress can be made . Suchprotect against password guessing attacks are not preventedby transport or application-level security mechanisms such as TLS  or ssh, becauselocking the authentication takes placeuser out after TCP has finished processing the packets.a small number of failed authentications. If an attacker cannot observe a TCP connection, butcan infer that suchguess or discover a connection exists, it is theoretically possibleuser's ID, they may be able to reset or desynchronize that connection by spoofing packets intotrigger such a mechanism, locking out the connection. However, this might require an excessively large number of spoofed packetslegitimate user. Another way to guess both the port of the active end of the TCP connection (in most cases the port of the passive enddeny service using protection mechanisms is predictable) and the currently valid TCP sequence numbers. However, as some operating systems have poorly implemented predictable algorithms for selecting either the dynamically selected port or the TCP initial sequence number  , then such attacks have been found to be feasible . Advice asto howcause a quota to reduce the vulnerabilitybe exhausted. This is perhaps most common in the specificcase of TCP is available in .small web servers being commercially hosted, where the server has a contract with the hosting company allowing a fixed amount of traffic per day. An attacker mightmay be able to significantly reduce the throughput of a connection by sending spoofed ICMP source quench packets, although most modern operating systems should ignore such packets. However, care should be taken in the design of future transportrapidly exhaust this quota, and signaling protocolscause service to avoid the introduction of similar mechanisms that couldbe exploited. 2.1.5. Attacks using the Victim's Own Resources Instead of directly overloading the victim, itsuspended. Similar attacks may be possible to causeagainst other forms of quota. In the absence of such quotas, if the victim oris charged for their network traffic, a machinefinancial denial-of-service may be possible. 2.2 DoS Attacks on Routers Many of the same subnet asdenial-of-service attacks that can be launched against end- systems can also be launched against the victim to overload itself. An examplecontrol processor of suchan attack is documented in , whereIP router, for example by flooding the attacker spoofscommand and control access ports. In the source address oncase of a packet sentrouter, these attacks may cause the router to stall, or may cause the victim's UDP echo port. The source address is that of another machine that is running a UDP chargen server (a chargen server sends a character pattern backrouter to cease processing routing packets. Even if the originating source). The result isrouter does not stop servicing routing packets, it may become sufficiently slow that routing protocols time out. In any of these circumstances, the two machines bounce packets back and forth as fast as they can, overloading either the network between them or oneconsequence of routing failure is not only that the end-systems itself. 2.1.6. Triggered Lockouts and Quota Exhaustion Many user-authentication mechanisms attempt to protect against password guessing attacks by locking the user out after a small number of failed authentications. If an attacker can guess or discover a user's ID, they may be able to trigger such a mechanism, locking out the legitimate user. Another way to deny service using protection mechanisms is to cause a quota to be exhausted. This is perhaps most common in the case of small web servers being commercially hosted, where the server has a contract with the hosting company allowing a fixed amount of traffic per day. An attacker may be able to rapidly exhaust this quota, and cause service to be suspended. Similar attacks may be possible against other forms of quota. In the absence of such quotas, if the victim is charged for their network traffic, a financial denial-of-service may be possible. 2.2. DoS Attacks on Routers Many of the denial-of-service attacks that can be launched against end- systems can also be launched against the control processor of an IP router, for example by flooding the ssh or telnet ports. In the case of a router, these attacks may cause the router to reboot, or may cause the router to cease processing routing packets. Even if the router does not stop servicing routing packets, it may become sufficiently slow that routing protocols time out. In any of these circumstances, the consequence of routing failure is not only that the router ceasesrouter ceases to forward traffic, but also that it causes routing protocol churn that may have further side effects. An example of such a side effect is caused by BGP route flap damping , which is intended to reduce global routing churn. If an attacker can cause BGP routing churn, route flap damping may then cause the flapping routes to be suppressed . This suppression likely causes the networks served by those routes to become unreachable. A DoS attack on the router control processor might also prevent the router being managed effectively. This may prevent actions being taken that would mitigate the DoS attack, and it might prevent diagnosis of the cause of the problem. 126.96.36.199.2.1 Attacks on Routers through Routing Protocols In addition to their roles as end-systems, most routers run dynamic routing protocols. The routing protocols themselves can be used to stage a DoS attack on a router or a network of routers. To inject routing information into a routing protocol, an attacker needs access eitherThis requires the ability to a router or to a end-host on a subnet where a routing protocol is running. In the latter case, ifsend traffic from addresses which might plausibly have generated the relevant routing protocol running on that subnetmessages, which is not authenticated, the end-host may be able to insert spoofedsomewhat difficult with interior routing information or pretend to be a router.protocols but fairly easy with e.g., eBGP. The simplest attack on a network of routers is to overload the routing table with sufficiently many routes that the router runs out of memory, or the router has insufficient CPU power to process the routes . We note that depending on the distribution and capacities of various routers around the network, such an attack might not overwhelm routers near to the attacking router, but might cause problems to show up elsewhere in the network. Some routing protocols allow limits to be configured on the maximum number of routes to be heard from a neighbor . However, if such a limit doesn't blocklimits often make the spoofed routes at source, then imposition of such a limit elsewhere inproblem worse rather than better, by making it possible for the network might causeattacker to push out legitimate routes to be dropped.with spoofed routes, thus creating an an easy form of DoS attack. An alternative attack is to overload the routers on the network by creating sufficient routing table churn that routers are unable to process the changes. Many routing protocols allow damping factors to be configured to avoid just such a problem. However, as with table size, such a threshold applied inconsistently may allow the spoofed routes to merge with legitimate routes before the mechanism is applied, causing legitimate routes to be damped. The simplest routing attack on a specific destination is for an attacker to announce a spoofed desirable route to that destination. Such a route might be desirable because it has low metric, or because it is a more specific route than the legitimate route. In any event, if the route is believed it will cause traffic for the victim to be drawn towards the attacking router, where it will typically be discarded. A more subtle denial-of-service attack might be launched against a network rather than against a destination. Under some circumstances, the propagation of inconsistent routing information can cause traffic to loop. If an attacker can cause this to happen on a busy path, the looping traffic might cause significant congestion, as well as not reaching the legitimate destination. However in many cases severe congestion is unlikely because TCP's congestion control will shut down the majority of traffic that fails to reach the destination. If an attacker has access to a host on the same subnet as a router running certain routing protocols, even if that router is configured not to accept routes, it might be possible to cause that router to run out of memory by spoofing the existence of fake routers on that subnet.In the past there have been cases where different generations of routers interpreted a routing protocol specification differently. In particular, BGP specifies that in the case of an error, the BGP peering should be dropped. However, if some of the routers in a network treat a particular route as valid and other routes treat the route as invalid, then it may be possible to inject a BGP route at one point in the Internet and cause peerings to be dropped at many other places in the Internet. Unlike many of the examples above, while such an issue might be a serious short-term problem, this is not a fundamental architectural problem. Once the problem is understood, deploying patched routing code can permanently solve the issue. 188.8.131.52.2.2 IP Multicast-based DoS Attacks There are essentially two forms of IP multicast: "traditional" IP multicast (ASM), as specified in RFC 1112  where multiple sources can send to the same multicast group, and source-specific multicast (SSM) where the receiver must specify both the IP source address and the group address. The two forms of multicast provide rather different DoS possibilities. With ASM, an attacker can simply send to multiple multicast groups. Routing protocols such as PIM-SM , MSDP  and DVMRP  then have to instantiate routing state to ensure that the traffic goes to the group receivers and not to non-receivers. Thus ASM is particularly vulnerable to DoS attacks causing both multicast routing table explosion (and hence control processor memory exhaustion) and multicast forwarding table exhaustion (and hence forwarding card memory exhaustion or thrashing). ASM also permits an attacker to send traffic to the same group as legitimate traffic, potentially causing network congestion and denying service to the legitimate group. However, unlike unicast traffic, it is comparatively difficult to spoof source addresses for IP multicast traffic. Most deployed IP multicast routing protocols use reverse-path checks to build the forwarding tree, and so multicast attackers are easily located. In addition, multicast traffic will only continue to flow to a receiver as long as the receiver joins the multicast group. Thus it may be harder to use multicast traffic to cause a denial-of-service attack on a destination - an attacker would need to be opportunistic, sending traffic to a multicast group that is already being received by the victim or another host located close to the victim. SSM does not permit senders to send to arbitrary groups unless a receiver has requested the traffic. Thus sender-based attacks on multicast routing state are not possible with SSM. However, as with ASM, a receiver can still join a large number of multicast groups causing routers to hold a large amount of multicast routing state, potentially causing memory exhaustion and hence denial-of-service to legitimate traffic. With IPv6, hosts are required to send ICMP Packet Too Big or Parameter Problem messages under certain circumstances, even if the destination address is a multicast address. If the attacker can place himself in the appropriate position in the multicast tree, a packet with an unknown but mandatory Destination Option, for instance, could generate a very large number of responses to the claimed sender. With IPv4 the same problem exists with multicast ICMP Echo Request packets, but these are somewhat easier to filter. 184.108.40.206.2.3 Attacks on Router Forwarding Engines Router vendors implement many different mechanisms for packet forwarding, but broadly speaking they fall into two categories: ones that use a forwarding cache, and ones that do not. With a forwarding cache, the forwarding engine does not hold the full routing table, but rather holds just the currently active subset of the forwarding table. Routers or switches usingMany modern routers use a loosely coupled architecture, where one or more control processors handle the routing protocols, and communicate over an internal network link to special-purpose forwarding cache are potentially vulnerable ifengines, which actually forward the data traffic. In such architectures it may be possible for an attacker can send many packetsto different destinations throughoverwhelm the same router, causingcommunications link between the control processor and the forwarding cache to thrash. One effect of this is likely to be that legitimate trafficengine. This is dropped because the cache entry has been lost and takes time to reinstate. Another possible effect is that the control traffic caused by the forwarding engine attempting to refresh the cache causes overload of the control processor (and potentially causes routing adjacencies to be dropped). In practice, this is only an issue if the forwarding engine does not have sufficient space for the full routing table. Even then such attacks may be difficult to perpetrate if the intended victim is not close to the attacker. In other cases such an effect would normally only be seen in the presence of a worm that manages to compromise a very large number of hosts, and then scans widely in its attempt to propagate further. Many modern routers use a loosely coupled architecture, where one or more control processors handle the routing protocols, and communicate over an internal network link to special-purpose forwarding engines, which actually forward the data traffic. In such architectures it may be possible for an attacker to overwhelm the communications link between the control processor and the forwarding engine. This is possiblepossible because the forwarding engines support very high speed links, and the control processor simply cannot handle a similar rate of traffic. There may be many ways in which an attacker can trigger communication between the forwarding engines and the control processor. The simplest way is for the attacker to simply send to the router's IP address, but this should in principle be relatively easy to prevent using filtering on the forwarding engines. Another way might be to cause the router to forward data packets using the "slow path". This involves sending packets that require special attention from the forwarding router; if the forwarding engine is not smart enough to perform such forwarding, then it will typically pass the packet to the control processor. In a router using a forwarding cache, it may be possible to overload the internal communications by thrashing the forwarding cache. Finally, any form of data-triggered communication between the forwarding engine and the control processor might cause such a problem. Certain multicast routing protocols including PIM-SM contain many such data triggered events that could potentially be problematic. The effects of overloading such internal communications are hard to predict, and very implementation-dependent. One possible effect might be that the forwarding table in the forwarding engine gets out of synchronization with the routing table in the control processor that reflects what the routing protocols believe is happening. This might cause traffic to be dropped or to loop. Finally, if an attacker can generate traffic that causes a router to installauto-install access control list (ACL) entries, perhaps by triggering a response from an intrusion detection system, then it may be possible to exhaust the hardwareACL resources on the router. This might prevent future attacks from being filtered, or worse, cause ACL processing to be handled by the route processor. 2.3. DoS2.3 Attacks on Local Hosts or Infrastructure There are a numberOngoing Communications Instead of attacks that might only be performed by a local attacker. Anattacking the end-system itself, it is also possible for an attacker with access to a subnet may be ableto prevent other local hosts from accessing the network at all by simply exhausting the address pool allocated bydisrupt ongoing communications. If an attacker can observe a DHCP server. This requires being ableTCP connection, then it is relatively easy for them to spoof the MAC address of an ethernet or wireless card, but this is quite feasible with certain hardware and operating systems. An alternative DHCP-based attack is simply to respond faster than the legitimate DHCP server, andpackets to give out an addresseither reset that is not useful to the victim. These sorts of bootstrapping attacks tendconnection or to de-synchronize it so that no further progress can be difficult to avoidmade . Such attacks are not prevented by transport or application-level security mechanisms such as TLS  or ssh, because most ofthe time trust relationships are establishedauthentication takes place after IP communicationTCP has already been established. Similar attacks are possible through ARP spoofing ;finished processing the packets. If an attacker cannot observe a TCP connection, but can respond to ARP requests before the victim and prevent traffic from reaching the victim. Some brands of ethernet switch allow an even simpler attack - simply send from the victim's MAC address, and the switch will redirect traffic destined for the victim to the attacker's port. It may beinfer that such a connection exists, it is theoretically possible to cause broadcast storms  on a local LANreset or desynchronize that connection by sending a streamspoofing packets into the connection. However, this might require an excessively large number of unicast IPspoofed packets to guess both the broadcast MAC address - some hosts onport of the LAN may then attempt to forwardactive end of the packets toTCP connection (in most cases the correct MAC address greatly amplifyingport of the traffic onpassive end is predictable) and the LAN. 802.11 wireless networks provide many opportunities to deny service to other users. Unless encryption is enabled, it is trivial to announcecurrently valid TCP sequence numbers. However, as some operating systems have poorly implemented predictable algorithms for selecting either the presence of a basestation (or even of an ad-hoc mode host) withdynamically selected port or the same network name (SSID)TCP initial sequence number  , then such attacks have been found to be feasible . Advice as to how to reduce the legitimate basestation. Even adding authentication and encryption a la 802.1X and 802.11i may not help muchvulnerability in this respect. The SSID spacethe specific case of TCP is unmanaged, so everyone's freeavailable in . An attacker might be able to put anything they wantsignificantly reduce the throughput of a connection by sending spoofed ICMP source quench packets, although most modern operating systems should ignore such packets. However, care should be taken in the SSID field. Most host stacks don't deal gracefully with this. Some 802.11 basestations have limited memory fordesign of future transport and signaling protocols to avoid the numberintroduction of associations they can support. If this is exceeded, they may drop all associations. Finally, assimilar mechanisms that could be exploited. 2.4 Attacks using the authentication in 802.11 takes place at a comparatively high level inVictim's Own Resources Instead of directly overloading the stack,victim, it ismay be possible to simply deauthenticate or disassociatecause the victim fromor a machine on the basestation, even if WEP is in use . Bellardo and Savage  describe some simple remedies that reducesame subnet as the effectivenessvictim to overload itself. An example of such attacks. What all these attacks have in commonan attack is that they exploit vulnerabilitiesdocumented in , where the link auto-configuration mechanisms. Such problems are hard to solve becauseattacker spoofs the reason forsource address on a packet sent to the existence of such autoconfiguration mechanismsvictim's UDP echo port. The source address is easethat of use, andanother machine that is running a UDP chargen server (a chargen server sends a character pattern back to securethe originating source). The result is that the two machines bounce packets back and forth as fast as they can, overloading either the network between them requires some formor one of authentication at a sufficiently early place inthe autoconfiguration process. 2.4.end-systems itself. 2.5 DoS Attacks on Sites though DNS In today's Internet, DNS isLocal Hosts or Infrastructure There are a number of sufficient importanceattacks that ifmight only be performed by a local attacker. An attacker with access to a site's DNS servers is denied,subnet may be able to prevent other local hosts from accessing the site is effectively unreachable, even if therenetwork at all by simply exhausting the address pool allocated by a DHCP server. This requires being able to spoof the MAC address of an ethernet or wireless card, but this is no actual communication problemquite feasible with certain hardware and operating systems. An alternative DHCP-based attack is simply to respond faster than the site itself. Many oflegitimate DHCP server, and to give out an address that is not useful to the victim. These sorts of bootstrapping attacks on end-systems described above cantend to be perpetrated on DNS servers. As servers go, DNS servers are not particularly vulnerabledifficult to DoS. So long as a DNS serveravoid because most of the time trust relationships are established after IP communication has sufficient memory, a modern hostalready been established. Similar attacks are possible through ARP spoofing ; an attacker can usuallyrespond very rapidlyto DNSARP requests for which it is authoritative. This was demonstrated in October 2002 whenbefore the root nameservers were subjected to a very large DoS attack . A numbervictim and prevent traffic from reaching the victim. Some brands of ethernet switch allow an even simpler attack - simply send from the root nameservers have since been replicated using anycast  to further improve their resistance to DoS. However it is important for authoritative servers to have relaying disabled, or it is possiblevictim's MAC address, and the switch will redirect traffic destined for an attacker to forcethe DNS serversvictim to hold state . Many ofthe routing attacks can alsoattacker's port. It may be used against DNS serverspossible to cause broadcast storms  on a local LAN by targeting the routing for the server. Ifsending a stream of unicast IP packets to the DNS server is co-located withbroadcast MAC address - some hosts on the site for which is authoritative,LAN may then attempt to forward the fact thatpackets to the DNS server is also unavailable of secondary importance. However, if allcorrect MAC address greatly amplifying the DNS servers are made unavailable, this may cause emailtraffic on the LAN. 802.11 wireless networks provide many opportunities to that sitedeny service to bounce rather than being stored while the mail servers are unreachable, so distribution of DNS server locationsother users. Unless encryption is important. Causing network congestion on links to and from a DNS server can have similar effects to end-system attacks or routing attacks, causing DNS to fail to obtain an answer, and effectively denying access to the site being served. We note that if an attacker can deny external accessenabled, it is trivial to allannounce the DNS forpresence of a site, this will not only cause email to that site to be dropped, but will also cause email from that site to be dropped. This is because recent versionsbasestation (or even of mail transfer agents suchan ad-hoc mode host) with the same network name (SSID) as sendmail will drop email ifthe mail originates fromlegitimate basestation. Even adding authentication and encryption a domain that doesla 802.1X and 802.11i may not exist. Thishelp much in this respect. The SSID space is a classic exampleunmanaged, so everyone's free to put anything they want in the SSID field. Most host stacks don't deal gracefully with this. Some 802.11 basestations have limited memory for the number of unexpected consequences. Sendmail performs this check as an anti-spam measure, and spam itselfassociations they can be viewedsupport. If this is exceeded, they may drop all associations. Finally, as a form of DoS attack. Thus defending against one DoS attack opens upthe vulnerability that allows another DoS attack. Finally,authentication in 802.11 takes place at a data corruption attackcomparatively high level in the stack, it is possible if a site's nameserver is permittedto relay requestssimply deauthenticate or disassociate the victim from untrusted third parties . The attacker issues a query forthe data he wishes to corrupt,basestation, even if WEP is in use . Bellardo and the victim's nameserver relays the request to the authoritative nameserver. The request contains a 16-bit IDSavage  describe some simple remedies that is used to match up the response withreduce the request. Ifeffectiveness of such attacks. What all these attacks have in common is that they exploit vulnerabilities in the attacker spoofs sufficient response packets fromlink auto-configuration mechanisms. Such problems are hard to solve because the authoritative nameserver just beforereason for the official response will arrive, each containing a forged responseexistence of such autoconfiguration mechanisms is ease of use, and to secure them requires some form of authentication at a differentsufficiently early place in the autoconfiguration process. 2.6 DoS Attacks on Sites though DNS In today's Internet, DNS ID, then thereis a reasonable chance that oneof the forged responses will have the correctsufficient importance that if access to a site's DNS ID. The incorrect data will then be believed and cached byservers is denied, the victim's nameserver, so givingsite is effectively unreachable, even if there is no actual communication problem with the incorrect response to future queries. The probabilitysite itself. Many of the attackattacks on end-systems described above can furtherbe increased if the attacker issues many different requests for the same data with differentperpetrated on DNS IDs, because many nameserver implementations will the issue relayed requests with differentservers. As servers go, DNS IDs, and so the response only has to match any one of these request IDs  . 2.5. DoS Attacks on Links The simplest DoS attack isservers are not particularly vulnerable to simply send enough non-congestion- controlled traffic thatDoS. So long as a link becomes excessively congested, and legitimate traffic suffers unacceptably high packet loss. Under some circumstances the effect of suchDNS server has sufficient memory, a link DoSmodern host can be much more extensive. We have already discussed the effects of denying accessusually respond very rapidly to aDNS server. Congesting a link might also causerequests for which it is authoritative. This was demonstrated in October 2002 when the root nameservers were subjected to a routing protocolvery large DoS attack . A number of the root nameservers have since been replicated using anycast  to dropfurther improve their resistance to DoS. However it is important for authoritative servers to have relaying disabled, or it is possible for an adjacency if sufficient routing packets are lost, potentially greatly amplifyingattacker to force the effectsDNS servers to hold state . Many of the attack. Good router implementations will prioritizerouting attacks can also be used against DNS servers by targeting the transmission ofrouting packets, but this is not a total panacea.for the server. If routersthe DNS server is co- located with the site for which is authoritative, then the fact that the DNS server is also unavailable of secondary importance. However, if all the DNS servers are peered across a shared medium such as ethernet, itmade unavailable, this may be possiblecause email to congest the medium sufficientlythat routing packets are still lost. Even if a link DoS does not cause routing packets to be lost, it may prevent remote accesssite to a router using ssh or SNMP. This might make the router unmanageable, or prevent the attackbounce rather than being correctly diagnosed. The prioritization of routing packets can itself cause a DoS problem. Ifstored while the attacker can cause a large amountmail servers are unreachable, so distribution of routing flux, it may be possible forDNS server locations is important. Causing network congestion on links to and from a routerDNS server can have similar effects to sendend-system attacks or routing packets at a high enough rate that normal traffic isattacks, causing DNS to fail to obtain an answer, and effectively excluded. This is however unlikely except on low bandwidth links. Finally, it may be possibledenying access to the site being served. We note that if an attacker tocan deny external access to a link by causing the router to generate sufficient monitoring or report traffic thatall the link is filled. SNMP traps are one possible vectorDNS for such an attack, as they area site, this will not normally congestion controlled. 2.6. DoS attacks on firewalls Firewalls are intendedonly cause email to defend the systems behind them against attack. In that they restrict the trafficthat can reach those systems, they may also aid in defending against denial-of-service attacks. However, under some circumstances the firewall itself maysite to be dropped, but will also cause email from that site to be useddropped. This is because recent versions of mail transfer agents such as sendmail will drop email if the mail originates from a weapon in a DoS attack. There are many different typesdomain that does not exist. This is a classic example of firewall, but generally speaking they fall into statefulunexpected consequences. Sendmail performs this check as an anti-spam measure, and stateless classes. The state here refers to whether the firewall holds state for the active flows traversing the firewall. Stateless firewalls generallyspam itself can onlybe attacked by attempting to exhaust the processing resourcesviewed as a form of DoS attack. Thus defending against one DoS attack opens up the firewall. Stateful firewalls can be attacked by sending trafficvulnerability that causes the firewallallows another DoS attack. Finally, a data corruption attack is possible if a site's nameserver is permitted to hold excessive state or state which has pathological structure. In the case of excessive state,relay requests from untrusted third parties . The attacker issues a query for the firewall simply runs out of memory,data he wishes to corrupt, and can no longer instantiatethe state required to pass legitimate flows. Most firewalls will then fail closed, causing denial-of-servicevictim's nameserver relays the request to the systems behindauthoritative nameserver. The request contains a 16-bit ID that is used to match up the firewall. Inresponse with the case of pathological structure,request. If the attacker sends traffic that causesspoofs sufficient response packets from the firewall's data structures to exhibit worst case behaviour. An example of this would be whenauthoritative nameserver just before the firewall uses hash tables to look up forwarding state,official response will arrive, each containing a forged response and a different DNS ID, then there is a reasonable chance that one of the attacker can predict the hash function used.forged responses will have the correct DNS ID. The attacker mayincorrect data will then be ablebelieved and cached by the victim's nameserver, so giving the incorrect response to cause a large amountfuture queries. The probability of flow state to hash tothe attack can further be increased if the attacker issues many different requests for the same bucket, which causesdata with different DNS IDs, because many nameserver implementations will the firewall's lookup performance to change from O(1) to O(n), where n isissue relayed requests with different DNS IDs, and so the numberresponse only has to match any one of flows thethese request IDs  . The use of anycast for DNS services makes it even more vulnerable to spoofing attacks. An attacker who can instantiate . Thusconvince the attacker can cause forwarding performanceISP to degradeaccept an anycast route to the point where servicehis fake DNS server can arrange to receive requests and generate fake responses. 2.7 DoS Attacks on Links The simplest DoS attack is effectively deniedto thesimply send enough non-congestion- controlled traffic that a link becomes excessively congested, and legitimate traffic traversingsuffers unacceptably high packet loss. Under some circumstances the firewall. 2.7.effect of such a link DoS attacks on IDS systems Intrusion detection systems (IDS) suffer from similar problems to firewalls. It maycan be possible for an attacker to causemuch more extensive. We have already discussed the IDS to exhaust its available processing power, to run outeffects of memory, ordenying access to instantiate state with pathological structure. Unlikea firewall, an IDS will normally fail open, which will not deny serviceDNS server. Congesting a link might also cause a routing protocol to drop an adjacency if sufficient routing packets are lost, potentially greatly amplifying the systems protected by the IDS. However it may mean that subsequent attacks thateffects of the IDS would have detectedattack. Good router implementations will be missed. Some IDSs are reactive; that is on detectionprioritize the transmission of routing packets, but this is not a hostile event they react to block subsequent traffic from the hostile system, or to terminate an ongoing connection from that system. Ittotal panacea. If routers are peered across a shared medium such as ethernet, it may be possible for an attackerto spoof packets from a legitimate system, and hence causecongest the IDS to believemedium sufficiently that system is hostile. The IDS will thenrouting packets are still lost. Even if a link DoS does not cause traffic from the legitimate systemrouting packets to be blocked, hence denying servicelost, it may prevent remote access to it. The effect can be particularly bad if the legitimate system isa router, DNS server,router using ssh or other system whose performance is essential forSNMP. This might make the operationrouter unmanageable, or prevent the attack being correctly diagnosed. The prioritization of routing packets can itself cause a DoS problem. If the attacker can cause a large numberamount of other systems. 2.8. DoS attacks on or via NTP Network time servers are generally not considered security-critical services, but under some circumstances NTP servers mightrouting flux, it may be used to perpetratepossible for a DoS attack. The most obvious such attack is to DoS the NTP servers themselves. Many end systems have rather poor clock accuracy and so, without accessrouter to network time, their clock will naturally drift. This can cause problems with distributed systemssend routing packets at a high enough rate that relynormal traffic is effectively excluded. This is however unlikely except on good clocks. For example one commonly used revision control system can fail iflow bandwidth links. Finally, it perceives the modification timestamp to be in the future. If the NTP servers relied on by a host can be subverted, either through compromising or impersonating them, then the attackermay be ablepossible to controlan attacker to deny access to a link by causing the host's system clock. This can cause many unexpected consequences, includingrouter to generate sufficient monitoring or report traffic that the premature expiry of dated resourceslink is filled. SNMP traps are one possible vector for such an attack, as encryption or authentication keys. This in turn can preventthey are not normally congestion controlled. Attackers with physical access to other more critical services. 2.9. Physicalmultiple access links can easily bring down the link. This is particularly easy to mount and difficult to counter with wireless networks [ 2.8 DoS The discussion thus far has centered on denial-of-serviceattacks perpetrated usingon firewalls Firewalls are intended to defend the network. However, computersystems are only as resilient asbehind them against attack. In that they restrict the weakest link. Ittraffic that can reach those systems, they may also aid in defending against denial-of-service attacks. However, under some circumstances the firewall itself may also be easier to deny service by causingused as a power failure, by cutting network cables, or by simply switchingweapon in a system off, and so physical security is at least as important as network security. 2.10. Social EngineeringDoS attack. There are many different types of firewall, but generally speaking they fall into stateful and stateless classes. The weakest link may also be human. In defending against DoS,state here refers to whether the possibility of denial-of-service through social engineering should notfirewall holds state for the active flows traversing the firewall. Stateless firewalls generally can only be neglected, such as convincing an employeeattacked by attempting to make a configuration change that prevents normal operation. 2.11. Legal DoS Computer systems cannot be considered in isolation fromexhaust the social and legal systems in which they operate. This document focuses primarily onprocessing resources of the technical issues, but we note that "cease and desist" letters, government censorship, and other legal mechanisms also touch on denial- of-service issues. 2.12. Spam and Black-hole Lists Unsolicited commercial email, also known as "spam",firewall. Stateful firewalls can effectively cause denial-of-servicebe attacked by sending traffic that causes the firewall to email systems. Whilehold excessive state or state which has pathological structure. In the intent is not denial-of-service,case of excessive state, the large amountfirewall simply runs out of unwanted mailmemory, and can wasteno longer instantiate the recipient's time, or cause legitimate emailstate required to pass legitimate flows. Most firewalls will then fail closed, causing denial-of-service to be noticed amongst allthe background noise. If spam filtering software is used, some levelsystems behind the firewall. In the case of false positives is to be expected, and so these messages are effectively denied service. One mechanism to reduce spam ispathological structure, the use of black-hole lists. The IP addresses of dial-up ISPs or mail servers used to originate or relay spam are addedattacker sends traffic that causes the firewall's data structures to black-hole lists. The recipientsexhibit worst case behaviour. An example of mail choosethis would be when the firewall uses hash tables to consult these listslook up forwarding state, and reject spam if it originates or is relayed by systems onthe list. One significant problem with such lists is that itattacker can predict the hash function used. The attacker may then be possible for an attackerable to cause a victimlarge amount of flow state to hash to be black-hole listed, even ifthe victim was not responsible for relaying spam. Thussame bucket, which causes the black-hole list itself can be a mechanism for effecting a DoS attack. Note that every black-hole list has its own policy regarding additions, and some are less susceptible to this DoS attack than others. Consumers of black-hole list technology are advisedfirewall's lookup performance to investigate these policies before they subscribe. 3. Attack Amplifiers Many of the attacks described above rely on sending sufficient trafficchange from O(1) to overwhelm the victim. Such attacks are made much easier byO(n), where n is the existencenumber of "attack amplifiers", where anflows the attacker can send traffic from the spoofed source address ofinstantiate . Thus the victim andattacker can cause larger responsesforwarding performance to be returneddegrade to the victim. A detailed discussion of such reflection attacks can be found in . The simplest such attack was the "smurf" attack ,point where an ICMP echo request packet with the spoofed source address of the victimservice is senteffectively denied to the subnet-broadcast address of a networklegitimate traffic traversing the firewall. 2.9 DoS attacks on IDS systems Intrusion detection systems (IDS) suffer from similar problems to firewalls. It may be used as an amplifier. Every system on that subnet then responds withpossible for an ICMP echo response that returnsattacker to cause the victim. Smurf attacks are no longer such a serious problem, as these days routers usually drop such packets and end-systems do not respondIDS to them. An alternative form of attack amplifier is typified by a DNS reflection attack. An attacker sends a DNS requestexhaust its available processing power, to a DNS server requesting resolutionrun out of memory, or to instantiate state with pathological structure. Unlike a domain name. Again the source address of the request isfirewall, an IDS will normally fail open, which will not deny service to the spoofed address ofsystems protected by the victim. The request is carefully chosen soIDS. However it may mean that subsequent attacks that the size of the responseIDS would have detected will be missed. Some IDSs are reactive; that is significantly greater than the sizeon detection of the request, thereby providing the amplification. As an aside, it is interestinga hostile event they react to note thatblock subsequent traffic from the largest DNS responses tendhostile system, or to terminate an ongoing connection from that system. It may be those incorporating DNSsec authentication information. This attack amplifier can only be used bypossible for an attacker with the abilityto spoof packets from a legitimate system, and hence cause the source address of the victim. However, we noteIDS to believe that if the victim's DNS serversystem is configured to relay requestshostile. The IDS will then cause traffic from external clients, it may be possiblethe legitimate system to cause itbe blocked, hence denying service to congest its own incoming network link. Another variant of attack amplifier involves amplification through retransmission. This is typified by a TCP amplification attack known as "bang.c".it. The attacker sendseffect can be particularly bad if the legitimate system is a spoofed TCP SYN withrouter, DNS server, or other system whose performance is essential for the source addressoperation of the victima large number of other systems. 2.10 DoS attacks on or via NTP Network time servers are generally not considered security-critical services, but under some circumstances NTP servers might be used to perpetrate a arbitrary TCP server.DoS attack. The server will respond with a SYN|ACK whichmost obvious such attack is sentto DoS the victim,NTP servers themselves. Many end systems have rather poor clock accuracy and when no final ACK is receivedso, without access to complete the handshake, the SYN|ACKnetwork time, their clock will be retransmitted a number of times. Typically this attack uses a very large list of arbitrarily chosen servers as reflectors.naturally drift. This can cause problems with distributed systems that rely on good clocks. For example one commonly used revision control system can fail if it perceives the attackmodification timestamp to be successful,in the reflector must not receivefuture. If the NTP servers relied on by a RST fromhost can be subverted, either through compromising or impersonating them, then the victim in responseattacker may be able to control the SYN|ACK - however if the attack traffic sufficiently overwhelmshost's system clock. This can cause many unexpected consequences, including the serverpremature expiry of dated resources such as encryption or authentication keys. This in turn can prevent access linkto other more critical services. 2.11 Physical DoS The discussion thus far has centered on denial-of-service attacks perpetrated using the server, then packet loss will ensure that many reflectors do not receive a RST in responsenetwork. However, computer systems are only as resilient as the weakest link. It may be easier to their SYN|ACK,deny service by causing a power failure, by cutting network cables, or by simply switching a system off, and so continue to retransmit.physical security is at least as important as network security. 2.12 Social Engineering DoS The attack canweakest link may also be exacerbated by firewalls that silently drophuman. In defending against DoS, the incoming SYN|ACK without sending a RST. Care must alsopossibility of denial-of-service through social engineering should not be taken with services that relay requests. Ifneglected, such as convincing an attacker can send a requestemployee to make a proxy, andconfiguration change that proxy now attempts to connect to a victim whose address is chosen byprevents normal operation. 2.13 Legal DoS Computer systems cannot be considered in isolation from the attacker then, ifsocial and legal systems in which they operate. This document focuses primarily on the proxy repeatedly resends the request when receiving no answer, this cantechnical issues, but we note that "cease and desist" letters, government censorship, and other legal mechanisms also servetouch on denial- of-service issues. 2.14 Spam and Black-hole Lists Unsolicited commercial email, also known as an attack amplifier. Another variant"spam", can effectively cause denial-of-service to email systems. While the intent is not denial-of-service, the large amount of amplification occurs in protocols that include, withinunwanted mail can waste the protocol payload, an IP addressrecipient's time, or name of hostcause legitimate email to fail to which subsequent messages shouldbe sent. An example of such as protocol is the Session Initiation Protocol (SIP), which carries a payload defined bynoticed amongst all the Session Description Protocol (SDP). The SDP payloadbackground noise. If spam filtering software is used, some level of the SIP message conveys the IP address and portfalse positives is to which media packets, typically encoded using the Real Time Transport Protocol (RTP), are sent. To launch this attack, an attacker sends a protocol message,be expected, and setsso these messages are effectively denied service. One mechanism to reduce spam is the use of black-hole lists. The IP address within the payloadaddresses of dial-up ISPs or mail servers used to pointoriginate or relay spam are added to the attack target.black-hole lists. The recipientrecipients of the message will generate subsequent trafficmail choose to that IP address. Dependingconsult these lists and reject spam if it originates or is relayed by systems on the protocol, this attack can provide substantial amplification properties. In the specific case of SIP, if a callerlist. One significant problem with such lists is that it may be possible for an attacker to cause a victim to be black-hole listed, even if the victim was not responsible for relaying spam. Thus the black-hole list itself can be a mechanism for effecting a DoS attack. Note that every black-hole list has its own policy regarding additions, and some are less susceptible to this DoS attack than others. Consumers of black-hole list technology are advised to investigate these policies before they subscribe. 3. Attack Amplifiers Many of the attacks described above rely on sending sufficient traffic to overwhelm the victim. Such attacks are made much easier by the existence of "attack amplifiers", where an attacker can send traffic from the spoofed source address of the victim and cause larger responses to be returned to the victim. A detailed discussion of such reflection attacks can be found in . 3.1 Methods of Attack Amplification The simplest such attack was the "smurf" attack , where an ICMP echo request packet with the spoofed source address of the victim is sent to the subnet-broadcast address of a network to be used as an amplifier. Every system on that subnet then responds with an ICMP echo response that returns to the victim. Smurf attacks are no longer such a serious problem, as these days routers usually drop such packets and end-systems do not respond to them. An alternative form of attack amplifier is typified by a DNS reflection attack. An attacker sends a DNS request to a DNS server requesting resolution of a domain name. Again the source address of the request is the spoofed address of the victim. The request is carefully chosen so that the size of the response is significantly greater than the size of the request, thereby providing the amplification. As an aside, it is interesting to note that the largest DNS responses tend to be those incorporating DNSsec authentication information. This attack amplifier can only be used by an attacker with the ability to spoof the source address of the victim. However, we note that if the victim's DNS server is configured to relay requests from external clients, it may be possible to cause it to congest its own incoming network link. Another variant of attack amplifier involves amplification through retransmission. This is typified by a TCP amplification attack known as "bang.c". The attacker sends a spoofed TCP SYN with the source address of the victim to a arbitrary TCP server. The server will respond with a SYN|ACK which is sent to the victim, and when no final ACK is received to complete the handshake, the SYN|ACK will be retransmitted a number of times. Typically this attack uses a very large list of arbitrarily chosen servers as reflectors. For the attack to be successful, the reflector must not receive a RST from the victim in response to the SYN|ACK - however if the attack traffic sufficiently overwhelms the server or access link to the server, then packet loss will ensure that many reflectors do not receive a RST in response to their SYN|ACK, and so continue to retransmit. The attack can be exacerbated by firewalls that silently drop the incoming SYN| ACK without sending a RST. Care must also be taken with services that relay requests. If an attacker can send a request to a proxy, and that proxy now attempts to connect to a victim whose address is chosen by the attacker then, if the proxy repeatedly resends the request when receiving no answer, this can also serve as an attack amplifier. Another variant of amplification occurs in protocols that include, within the protocol payload, an IP address or name of host to which subsequent messages should be sent. An example of such as protocol is the Session Initiation Protocol (SIP), which carries a payload defined by the Session Description Protocol (SDP). The SDP payload of the SIP message conveys the IP address and port to which media packets, typically encoded using the Real Time Transport Protocol (RTP), are sent. To launch this attack, an attacker sends a protocol message, and sets the IP address within the payload to point to the attack target. The recipient of the message will generate subsequent traffic to that IP address. Depending on the protocol, this attack can provide substantial amplification properties. In the specific case of SIP, if a caller makes calls to high bandwidth media sources (such as a video server or streaming audio server), a single SIP INVITE packet, typically a few hundred bytes, can result in a nearly continuous stream of media packets at rates anywhere from a few kbits per second up to megabits per second. This particular attack is called the "voice hammer". Unlike the other techniques described above, this technique does not require the attacker to modify packets or even spoof their source IP address. This makes it easier to launch. This attack is prevented through careful protocol design. Protocols should, whenever possible, avoid including IP addresses or hostnames within protocol payloads as addresses to which subsequent messaging should be sent. Rather, when possible, messages should be sent to the source IP from which the protocol packet came. If such a design is not possible, the protocol should include a handshake whereby it can be positively determined that the protocol entity at that IP address or hostname does, in fact, wish to receive that subsequent messaging. That handshake itself needs to be lightweight (to avoid being the source of another DoS attack), and secured against the spoofing of the handshake response. Finally, a somewhat similar attack is possible with some protocols where where one message leads to another message that is not sent as a reply to the source address of the first message. This can be an issue with protocols to enable mobility for example, and might permit an attacker to avoid ingress filtering. Such protocols are notoriously difficult to get right. 3.2 Strategies to Mitigate Attack Amplification In general, the architectural lessons to be learnt are simple: o As far as possible, perform ingress filtering   to prevent source address spoofing. o Avoid designing protocols or mechanisms that can return significantly larger responses than the size of the request, unless a handshake is performed to validate the client's source address. Such a handshake needs to incorporate an unpredictable nonce that is secure enough to mitigate the amplification effects of the protocol. o All retransmission during initial connection setup should be performed by the client. o Proxies should not arbitrarily relay requests to destinations chosen by a client. o Avoid signaling third-party connections. Any unavoidable third- party connections setup by a signaling protocol should incorporate lightweight validation before sending significant data. 4. DoS Solutions AlthoughMitigation Strategies NOTE: This section is incomplete A general problem with DoS defense is that it is not in principle possible to distinguish between a flash- crowdflash-crowd and a DoS attack, in practice it should be possible to raise the bar high enough that an attackerattack. Indeed, having your site taken down by a flash crowd is forced to disguise their attack as legitimate traffic. This makes it muchprobably a more expensive to perpetrate an attack. In addition, the goal should be to makecommon experience than having it impossible to perpetrate an attack from an untraceable host. Thus, even though some attacks may be impossible to prevent, the victim would then have legal recourse. This does not however mean that anonymity should be impossible atDoS-ed --- so common it's acquired its own names: being Slashdotted or Farked, after the application level; merelyweb sites that the choice to interact with an anonymous party should be at the discretionare common sources of flash crowds. Thus, the other party. A guiding principle when hardening systemsfirst line of defense against DoS isattacks must be to avoid causing additional different avenues for attack. A classic example isprovision your service so that ofit can handle a mail server that verifiesforeseeable legitimate peak load. Underprovisioned sites are the "from" address of email is resolvable, which allows email from a site to be DoSed by merely preventing accesseasiest to that site's DNS servers. The guidelines below primarily concern the relatively obvious mechanismstake down. Specific strategies for DoS defense fall into two broad categories: 1. Avoiding allowing attacks that are already reasonably well understood. The aim of this document isbetter than generic resource consumption. 2. Minimizing the extent to help protocol designers and network operators understandwhich generic resource consumption attacks crowd In the stateremainder of the art, and to stimulate discussion on additional architectural solutions. Don't Create an Attack Amplifier The simplest guideline is to avoid building attack amplifiers and, as far as possible, to perform ingress filtering to prevent compromised systems onthis section, we consider specific applications of these two approaches at a subnet from spoofing the source address on packets.variety of levels of network system architecture. 4.1 Protocol Design 4.1.1 Don't Hold State for Unverified Hosts From an end-system server point of view, one simple aim is to avoid instantiating state without having completed a handshake with the client to validate their address, and as far as possible to push work and stateholding to client. There are a number of techniques that might be used to do this, including SYN-cookies  . All client-serverclient- server protocols should probably be designed to allow such techniques to be used, butused, but the enabling of the mechanism should normally be at the server's discretion to avoid unnecessary work under normal circumstances. 4.1.2 Make it Hard to Simulate a Legitimate User Other than having massive overcapacity, the only real defense against resource consumption attacks is to preferentially discriminate against attackers. The general idea is to find something that legitimate users can do but attackers can't. The most commonly proposed approaches include: 1. Puzzles: force the attacker to do some computation that would not be onerous for a single user but is too expensive to do en masse.  2. Reverse Turing Tests: specialized puzzles that are hard for machines to do but easy for humans, thus making automated attacks hard. 3. Reachability testing: force the proposed client to demonstrate that it can receive traffic at a given IP address. This makes it easier to trace attackers. All of these techniques have substantial limitations. Puzzles tend to discriminate against legitimate users with slow computers. In addition, the wide availability of "bots" means that attackers have ample computing power at their disposal. There has been substantial work in attacking Reverse Turing Tests automatically, thus making them of limited applicability. Finally, reachability testing is substantially weakened by bots because the attacker does not need to hide his source address. 4.1.3 Graceful Routing Degradation A goal with routing protocols is that of graceful degradation in overload, and automatic recovery after the source of the overload has been remedied. Some routing protocols satisfy this goal more than others. Although RIP doesn't scale well, if a router runs out of memory when receiving a RIP route, it can just drop the route and send an infinite metric to its peers. The route will later be refreshed, and if the enablingoriginal source of the mechanism should normally be atproblem has been resolved, the server's discretion to avoid unnecessary work under normal circumstances. State Lookup Complexity Any system that instantiates per-connection state should take great carerouter will now be able to implementprocess it correctly. On the state-lookup mechanismsother hand, BGP is stateful in such a way that performance can not be controlled bythe attacker. One waysense that a peer assumes you have processed or chosen to achieve thisfilter any route that it sent you. There is to use hash-tables where the hashno mechanism is keyedto refresh state in such a way thatthe attacker cannot instantiate a large number of flows inbase BGP spec, and even the same hash bucket. Avoid Livelock Most operating systems use network interruptslater route refresh option  is hard to receive data fromuse usefully in the network, which ispresence of overload. A BGP router that cannot store a good solution ifroute it received has two choices: completely restart BGP, or shutdown one or more peerings . This means that the host spends only a small amounteffects of its time handling network traffic. However, this leaves the host open to livelock , where under heavy load the OS spends all its time handling interrupts and no time doing the work neededa BGP overload are rather more severe than they need to handlebe, and so amplifies the traffic ateffect of any attack. In general, few routing protocol designs actively consider the application level. Server operating systemspossible behaviour of routers under overload conditions; this should consider using network polling at timesbe an explicit part of heavy load, rather that being interrupt-driven, andfuture routing protocol designs. Although precise details should clearly be carefully architected so that as far as reasonably possible, traffic received byleft to implementors, the OS is processedprotocol design needs to completion, or very cheaply discarded. Use Unpredictable Values for Session IDs Most recent TCP implementations use fairly good random mechanisms for allocatinggive them the TCP initial sequence numbers. In general, any dynamically allocated value used purelycapability to identify a communications session should be allocated using an unpredictable mechanism,do their job properly. 4.1.4 Autoconfiguration and Authentication Autoconfiguration mechanisms greatly ease deployment, and are increasingly necessary as this increasesthe search space for an attackernumber of networked devices grows beyond what can be managed manually. However, it should be recognised that wishes to disrupt ongoing communications. Thus the dynamically allocated portunauthenticated autoconfiguration opens up many avenues for attack. There is a clear tension between ease of configuration and security of configuration. Future autoconfiguration protocols should consider the active endneed to allow different end-systems to operate at different points in this spectrum within the same autoconfiguration framework. 4.1.5 Network Design and Configuration 4.1.6 Redundancy and Distributed Service A basic principle of a TCP connection might also be randomly allocated. With DNS,designing systems to handle failure to have redundant servers which can take over when one fails. This is equally true in the IDcase of DoS attacks, which is used to match responses with requests should alsooften focus on a given server and/or link. If service delivery points can be randomly generated. However, as the ID field is only 16 bits,distributed across the protection is rather limited, especially innetwork, then it becomes much harder to attack the face of birthday attacks.entire service. In particular, this makes attacks on a single network link more difficult. 4.1.7 Authenticate Routing Adjacencies In general, cryptographic authentication mechanisms are too costly to form the main part in DoS prevention. However, routing adjacencies are too important to risk an attacker being able to inject bad routing information, which can affect more than the router in question. Additional non-cryptographic mechanisms should then be used to avoid arbitrary end-systems being able to cause the router to spend CPU cycles on validating authentication data. For BGP, at the very least, this implies the use of TCP MD5  or IPsec authentication, combined with the TTL 255 hack  to prevent EBGP association with non-immediate neighbours. In future, this will likely imply better authentication of the routing information itself. 4.1.8 Isolate Router-to-Router Traffic As far as is feasible, router-to-router traffic should be isolated from data traffic. How this should be implemented depends on the precise technologies available, both in the router and at the link-layer.link- layer. The goal should be that failure of the link for data traffic should also cause failure for the routing traffic, but that an attacker cannot directly send packets to the control processor of the routers. A downside of this is that some diagnostic techniques (such as pinging consecutive routers to find the source of a delay) may no longer be possible. Ideally, alternative mechanisms (which do not open up additional avenues for DoS) should be designed to replace such lost techniques. Graceful Routing Degradation A goal with routing protocols is4.2 Router Implementation Issues 4.3 End-System Implementation Issues 4.3.1 State Lookup Complexity Any system that of graceful degradation in overload, and automatic recovery after the source ofinstantiates per-connection state should take great care to implement the overload has been remedied. Some routing protocols satisfy this goal more than others. Although RIP doesn't scale well, if a router runs out of memory when receivingstate-lookup mechanisms in such a RIP route, itway that performance can just drop the route and send an infinite metric to its peers. The route will laternot be refreshed, and if the original source of the problem has been resolved,controlled by the router will now be ableattacker. One way to process it correctly. Onachieve this is to use hash-tables where the other hand, BGPhash mechanism is statefulkeyed in the sense thatsuch a peer assumes you have processed or chosen to filter any routeway that it sent you. There is no mechanism to refresh state inthe base BGP spec, and evenattacker cannot instantiate a large number of flows in the later route refresh option  is hard tosame hash bucket. 220.127.116.11 Avoid Livelock Most operating systems use usefully innetwork interrupts to receive data from the presence of overload. A BGP router that cannot storenetwork, which is a route it received has two choices: completely restart BGP, or shutdown one or more peerings . This means thatgood solution if the effects ofhost spends only a BGP overload are rather more severe than they needsmall amount of its time handling network traffic. However, this leaves the host open to be,livelock , where under heavy load the OS spends all its time handling interrupts and so amplifiesno time doing the effect of any attack. In general, few routing protocol designs actively considerwork needed to handle the possible behaviour of routers under overload conditions; thistraffic at the application level. Server operating systems should be an explicit partconsider using network polling at times of future routing protocol designs. Although precise detailsheavy load, rather that being interrupt-driven, and should clearlybe left to implementors, the protocol design needs to give themcarefully architected so that as far as reasonably possible, traffic received by the capability to do their job properly. Source-Specific Multicast Source-specific multicastOS is easierprocessed to manage than ASM, and opens up many fewer avenues for DoS attack. However, ASM has many usescompletion, or very cheaply discarded. 18.104.22.168 Use Unpredictable Values for resource discovery and autoconfiguration. A prudent deployment strategy would be toSession IDs Most recent TCP implementations use SSMfairly good random mechanisms for inter-domain multicast and ASM only withinallocating the more controlled environment of an intranet.TCP initial sequence numbers. In both environments, administrative controls should be set to prevent a single receiver from joining sufficient multicast groupsgeneral, any dynamically allocated value used purely to causeidentify a state exhaustion problem incommunications session should be allocated using an unpredictable mechanism, as this increases the multicast routers. Such a threshold needs to take into accountsearch space for an attacker that some multicast congestion control mechanisms use multiple multicast groupswishes to allowdisrupt ongoing communications. Thus the receiver to select an appropriate rate. Indynamically allocated port of the future, multicast protocols mayactive end of a TCP connection might also be deployedrandomly allocated. With DNS, the ID which use shared bidirectional trees for interdomain multicast. This might allow ASMis used to match responses with requests should also be deployed withoutrandomly generated. However, as the ID field is only 16 bits, the protection is rather limited, especially in the face of birthday attacks. 4.3.2 Operational Issues 22.214.171.124 Eliminate Bad Traffic Early Many DoS vulnerabilities exhibited by current inter- domain ASM solutions. Such solutions are not currently available. Autoconfiguration and Authentication Autoconfiguration mechanisms greatly ease deployment, andattacks are increasingly necessary asgeneric bandwidth consumption attacks that operate by clogging the number of networked devices grows beyond what can be managed manually. However, it should be recognisedlink that unauthenticated autoconfiguration opens up many avenues for attack. Thereconnects the victim server to the Internet. Filtering these attacks at the server does no good because the traffic has already traversed the link which is a clear tension between ease of configuration and security of configuration. Future autoconfiguration protocols should considerthe scarce resource. Such flows need to allow different end-systems to operatebe filtered at different points in this spectrum withinsome point closer to the same autoconfiguration framework.attacker. Where possible, operators should filter out obviously bad traffic. In particular, they should perform ingress filtering . 126.96.36.199 Establish a Monitoring Framework Network operators are strongly encouraged to establish a monitoring framework to detect and log abnormal network activity. One can not defend against an attack one doesn't detect or understand. Such monitoring tools can be used to set a baseline of "normal" traffic, and can be used to determine: 1.o Aberrant flows. 2.o Type and source of the aberrant flows.flows This is extremely helpful when responding to DDoS or a flash crowd, and should be in place prior to the event. 5. Conclusions In this document we have highlighted possible avenues for DoS attack on networks and networked systems, with the aim of encouraging protocol designers and network engineers towards designs that are more robust. We have discussed partial solutions that reduce the effectiveness of attacks, and highlighted how some partial solutions can be taken advantage of by attackers to perpetrate alternative attacks. Our focus has primarily been on protocol and network architecture issues, but there are many things that network and service operators can do to lessen the threat. Further advice and information for network operators can be found in   . It is our hope that this document will spur discussion leading to architectural solutions that reduce the succeptibility of all Internet systems to denial-of-service attacks. 6. Security Considerations This entire document is about security. 7. Acknowledgements We are very grateful to Vern Paxson, Paul Vixie, Rob Thomas, Dug Song, George Jones andJones, Jari ArkkoArkko, and Geoff Huston for their constructive comments on earlier versions of this document. 7. Authors' Addresses Mark Handley Department of Computer Science University College London Gower Street London WC1E 6BT United Kingdom. Email: M.Handley@cs.ucl.ac.uk8. References  J. Abley, "Hierarchical Anycast for Global Service Distribution", http://www.isc.org/tn/isc-tn-2003-1.txt  T. Aura, P. Nikander, J. Leiwo, "DOS-resistant authentication with client puzzles", In B. Christianson, B. Crispo, and M. Roe, editors, Proceedings of the 8th International Workshop on Security Protocols, Lecture Notes in Computer Science, Cambridge, UK, April 2000.  J. Bellardo, S. Savage, "802.11 Denial-of-Service Attacks: Real Vulnerabilities and Practical Solutions", Proceedings of the USENIX Security Symposium, Washington D.C., August 2003.  S.M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April 1989.  D.J. Bernstein, "SYN Cookies", http://cr.yp.to/syncookies.html  CCAIS/RNP Alertas do Cais ALR-19112002a, "Vulnerability in the sending requests control of Bind versions 4 and 8 allows DNS spoofing", http://www.rnp.br/cais/alertas/2002/cais- ALR-19112002a.htmlALR- 19112002a.html  CERT Advisory CA-1996-01, "UDP Port Denial-of-Service Attack", Feb 1996.  CERT Advisory CA-1996-21, "TCP SYN Flooding and IP Spoofing Attacks", Sept 1996.  CERT Advisory CA-2001-09, "Statistical Weaknesses in TCP/IP Initial Sequence Numbers", May 2001.  CERT Advisory CA-1996-26, "Denial-of-Service Attack via ping", Dec 1996.  CERT Advisory CA-1998-01, "Smurf IP Denial-of-Service Attacks", http://www.cert.org/advisories/CA-1998-01.html, Jan 1998.  CERT Incident Note IN-2000-05, "'mstream' Distributed Denial of Service Tool", May 2000.  CERT/CC - "Managing the Threat of Denial of Service Attacks", http://www.cert.org/archive/pdf/Managing_DoS.pdf  CERT/CC - "Trends in Denial of Service Attack Technology", http://www.cert.org/archive/pdf/DoS_trends.pdf  D.F. Chang, R. Govindan, J. Heidemann, "An Empirical Study of Router Response to Large Routing Table Load", Proceedings of the 2nd Internet Measurement Workshop (IMW 2002), 2002.  E. Chen, "Route Refresh Capability for BGP-4", RFC 2918, September 2000  Cisco Systems, "Configuring the BGP Maximum-Prefix Feature", Cisco Document ID: 25160, http://www.cisco.com/warp/public/459/bgp- maximum-prefix.html  Scott A Crosby and Dan S Wallach, "Denial of Service via Algorithmic Complexity Attacks", Proceedings of the USENIX Security Symposium, Washington D.C., August 2003.  S. Deering, "Host extensions for IP multicasting", RFC 1112, Aug 1989.  T. Dierks, C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, Jan 1999.  D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.  P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, May 2000.  V. Gill, J. Heasley, D. Meyer, "The BGP TTL Security Hack (BTSH)", draft-gill-btsh-02.txt (work in progress), 29-May-03.  A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.  Laurent Joncheray, "Simple Active Attack Against TCP", 5th USENIX Security Symposium, 1995.  M. Lough, "A Taxonomy of Computer Attacks with Applications to Wireless", PhD thesis, Virginia Polytechnic Institute, April 2001.  Z. Mao, R. Govindan, G. Varghese, R. Katz, "Route Flap Dampening Exacerbates Internet Routing Convergence", Proceedings of ACM SIGCOMM, 2002.  D. Meyer, W. Fenner (Editors), "Multicast Source Discovery Protocol (MSDP)", draft-ietf-msdp-spec-15.txt, Work in Progress.  J. Mogul, KK. Ramakrishnan, "Eliminating Receive Livelock in an Interrupt-driven Kernel", ACM Transactions on Computer Systems, Vol 15, Number 3, pp. 217-252, 1997.  National Infrastructure Secuity Co-ordination Center (NISCC), Vulnerability Advisory 236929, April 2004, http://www.uniras.gov.uk/vuls/2004/236929/  V. Paxson, "An Analysis of Using Reflectors for Distributed Denial- of-Service Attacks", Computer Communication Review 31(3), July 2001.  Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.  Joe Stewart, "DNS Cache Poisoning - The Next Generation", Jan 27 2003, http://www.securityfocus.com/guest/17905  R. Stewart (Editor), Transmission Control Protocol security considerations, Internet Draft, April 2004, draft-ietf-tcpm- tcpsecure-00.txt  C. Villamizar, R. Chandra, R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.  P. Vixie, G. Sneeringer, M. Schleifer, "Events of 21-Oct-2002", http://f.root-servers.org/october21.txt  P. Vixie, "Securing the Edge", http://www.icann.org/committees/security/sac004.txt  D. Waitzman, C. Partridge, S.E. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, Nov 1988.  D. Wessels, "Running An Authoritative-Only BIND Nameserver", http://www.isc.org/tn/isc-tn-2002-2.txt  M. Zalewski, "Strange Attractors and TCP/IP Sequence Number Analysis", http://razor.bindview.com/publish/papers/tcpseq.html  J. Bellardo and S. Savage, "802.11 Denial-of-Service Attacks: Real Vulnerabilities and Practical Solutions", Proceedings of the 12th USENIX Security Symposium, August 2003.  L. von Ahn, M. Blum, N. Hopper, and J. Langford. CAPTCHA: Using hard AI problems for security. In Proceedings of Eurocrypt, 2003. Authors' Addresses Mark J. Handley (ed) UCL Gower Street London WC1E 6BT UK Email: M.Handley@cs.ucl.uk Eric Rescorla (ed) Network Resonance 2483 E. Bayshore #212 Palo Alto 94303 USA Email: firstname.lastname@example.org Appendix A. IAB Members at the time of this writing o Bernard Aboba o Loa Andersson o Brian Carpenter o Leslie Daigle o Patrik Faltstrom o Bob Hinden o Kurtis Lindqvist o David Meyer o Pekka Nikander o Eric Rescorla o Pete Resnick o Jonathan Rosenberg o Lixia Zhang Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.