Network Working Group M. Handley, Ed.
Request for Comments: 4732 UCL
Category: Informational E. Rescorla, Ed.
Network Resonance
Internet Architecture Board
IAB
November 2006
Network Working Group M. Handley, Ed.
Request for Comments: 4732 UCL
Category: Informational E. Rescorla, Ed.
Network Resonance
Internet Architecture Board
IAB
November 2006
Internet Denial-of-Service Considerations
Internet拒绝服务注意事项
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This document provides an overview of possible avenues for denial-of-service (DoS) 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.
本文档概述了对Internet系统进行拒绝服务（DoS）攻击的可能途径。其目的是鼓励协议设计者和网络工程师进行更稳健的设计。我们将讨论降低攻击有效性的部分解决方案，以及一些解决方案如何在无意中打开其他漏洞。
Table of Contents
目录
1. Introduction ....................................................3
2. An Overview of Denial-of-Service Threats ........................4
2.1. DoS Attacks on End-Systems .................................4
2.1.1. Exploiting Poor Software Quality ....................4
2.1.2. Application Resource Exhaustion .....................5
2.1.3. Operating System Resource Exhaustion ................6
2.1.4. Triggered Lockouts and Quota Exhaustion .............7
2.2. DoS Attacks on Routers .....................................8
2.2.1. Attacks on Routers through Routing Protocols ........8
2.2.2. IP Multicast-based DoS Attacks ......................9
2.2.3. Attacks on Router Forwarding Engines ...............10
2.3. Attacks on Ongoing Communications .........................11
2.4. Attacks Using the Victim's Own Resources ..................12
2.5. DoS Attacks on Local Hosts or Infrastructure ..............12
2.6. DoS Attacks on Sites through DNS ..........................15
2.7. DoS Attacks on Links ......................................16
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 .............................................18
2.12. Social Engineering DoS ...................................19
2.13. Legal DoS ................................................19
2.14. Spam and Black-Hole Lists ................................19
3. Attack Amplifiers ..............................................20
3.1. Methods of Attack Amplification ...........................20
3.2. Strategies to Mitigate Attack Amplification ...............22
4. DoS Mitigation Strategies ......................................22
4.1. Protocol Design ...........................................23
4.1.1. Don't Hold State for Unverified Hosts ..............23
4.1.2. Make It Hard to Simulate a Legitimate User .........23
4.1.3. Graceful Routing Degradation .......................24
4.1.4. Autoconfiguration and Authentication ...............24
4.2. Network Design and Configuration ..........................25
4.2.1. Redundancy and Distributed Service .................25
4.2.2. Authenticate Routing Adjacencies ...................25
4.2.3. Isolate Router-to-Router Traffic ...................26
4.3. Router Implementation Issues ..............................26
4.3.1. Checking Protocol Syntax and Semantics .............26
4.3.2. Consistency Checks .................................27
4.3.3. Enhance Router Robustness through
Operational Adjustments ............................28
4.3.4. Proper Handling of Router Resource Exhaustion ......28
4.4. End-System Implementation Issues ..........................29
4.4.1. State Lookup Complexity ............................29
4.4.2. Operational Issues .................................30
5. Conclusions ....................................................30
1. Introduction ....................................................3
2. An Overview of Denial-of-Service Threats ........................4
2.1. DoS Attacks on End-Systems .................................4
2.1.1. Exploiting Poor Software Quality ....................4
2.1.2. Application Resource Exhaustion .....................5
2.1.3. Operating System Resource Exhaustion ................6
2.1.4. Triggered Lockouts and Quota Exhaustion .............7
2.2. DoS Attacks on Routers .....................................8
2.2.1. Attacks on Routers through Routing Protocols ........8
2.2.2. IP Multicast-based DoS Attacks ......................9
2.2.3. Attacks on Router Forwarding Engines ...............10
2.3. Attacks on Ongoing Communications .........................11
2.4. Attacks Using the Victim's Own Resources ..................12
2.5. DoS Attacks on Local Hosts or Infrastructure ..............12
2.6. DoS Attacks on Sites through DNS ..........................15
2.7. DoS Attacks on Links ......................................16
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 .............................................18
2.12. Social Engineering DoS ...................................19
2.13. Legal DoS ................................................19
2.14. Spam and Black-Hole Lists ................................19
3. Attack Amplifiers ..............................................20
3.1. Methods of Attack Amplification ...........................20
3.2. Strategies to Mitigate Attack Amplification ...............22
4. DoS Mitigation Strategies ......................................22
4.1. Protocol Design ...........................................23
4.1.1. Don't Hold State for Unverified Hosts ..............23
4.1.2. Make It Hard to Simulate a Legitimate User .........23
4.1.3. Graceful Routing Degradation .......................24
4.1.4. Autoconfiguration and Authentication ...............24
4.2. Network Design and Configuration ..........................25
4.2.1. Redundancy and Distributed Service .................25
4.2.2. Authenticate Routing Adjacencies ...................25
4.2.3. Isolate Router-to-Router Traffic ...................26
4.3. Router Implementation Issues ..............................26
4.3.1. Checking Protocol Syntax and Semantics .............26
4.3.2. Consistency Checks .................................27
4.3.3. Enhance Router Robustness through
Operational Adjustments ............................28
4.3.4. Proper Handling of Router Resource Exhaustion ......28
4.4. End-System Implementation Issues ..........................29
4.4.1. State Lookup Complexity ............................29
4.4.2. Operational Issues .................................30
5. Conclusions ....................................................30
6. Security Considerations ........................................31
7. Acknowledgements ...............................................31
8. Normative References ...........................................31
9. Informative References .........................................32
Appendix A. IAB Members at the Time of This Writing ...............36
6. Security Considerations ........................................31
7. Acknowledgements ...............................................31
8. Normative References ...........................................31
9. Informative References .........................................32
Appendix A. IAB Members at the Time of This Writing ...............36
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.
拒绝服务（DoS）攻击是一种攻击，其中一台或多台计算机以受害者为目标，试图阻止受害者进行有用的工作。受害者可以是网络服务器、客户端或路由器、网络链路或整个网络、个人互联网用户或使用互联网开展业务的公司、互联网服务提供商（ISP）、国家或其任何组合或变体。拒绝服务攻击可能涉及未经授权访问网络或计算资源，但在本文档中，我们主要关注拒绝服务攻击本身不涉及损害受害者计算设施的情况。
Because of the closed context of the original ARPANET and NSFNet, no consideration was given to denial-of-service attacks in the original Internet Architecture. As a result, almost all Internet services are vulnerable to denial-of-service attacks of sufficient scale. In most cases, sufficient scale can be achieved by compromising enough end-hosts (typically using a virus or worm) or routers, and using those compromised hosts to perpetrate the attack. Such an attack is known as a Distributed Denial-of-Service (DDoS) attack. However, there are also many cases where a single well-connected end-system can perpetrate a successful DoS attack.
由于原始ARPANET和NSFNet的封闭环境，在原始Internet体系结构中未考虑拒绝服务攻击。因此，几乎所有互联网服务都容易受到足够规模的拒绝服务攻击。在大多数情况下，通过危害足够多的终端主机（通常使用病毒或蠕虫）或路由器，并使用这些受损主机实施攻击，可以实现足够的规模。这种攻击称为分布式拒绝服务（DDoS）攻击。然而，也有许多情况下，单个连接良好的终端系统可以成功实施DoS攻击。
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 强调可能的攻击途径，并通过这样做鼓励协议设计者和网络工程师进行更稳健的设计。
o To discuss partial solutions that reduce the effectiveness of attacks.
o 讨论降低攻击有效性的部分解决方案。
o To highlight how some partial solutions can be taken advantage of by attackers to perpetrate alternative attacks.
o 强调攻击者如何利用部分解决方案实施替代攻击。
This last point appears to be a recurrent theme in DoS, and highlights the lack of proper architectural solutions. It is our hope that this document will help initiate informed debate about future architectural solutions that might be feasible and cost-effective for deployment.
这最后一点似乎是DoS中经常出现的主题，并强调了缺乏适当的体系结构解决方案。我们希望，本文档将有助于就未来的体系结构解决方案展开知情的辩论，这些解决方案对于部署来说可能是可行且经济高效的。
In addition, it is our hope that this document will spur discussion leading to architectural solutions that reduce the susceptibility of all Internet systems to denial-of-service attacks.
此外，我们希望本文档将引发讨论，从而形成架构解决方案，降低所有Internet系统对拒绝服务攻击的敏感性。
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.
我们注意到，原则上不可能区分足够微妙的DoS攻击和flash群组（其中意外的大量但非恶意的流量具有与DoS攻击相同的效果）。虽然这是事实，但此类恶意攻击通常比迄今为止看到的许多原始攻击更昂贵。因此，防御DoS并不是要防止所有可能的攻击，而是要将恶意流量的门槛提高到足够高的程度。
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.
但是，还需要注意的是，并非所有的DoS问题都是恶意的。失败的链接、flash群组、错误配置的机器人和许多其他原因都可能导致资源耗尽问题，因此总体目标应该是对各种形式的过载保持鲁棒性。
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.
在本节中，我们将讨论各种可能的DoS攻击。这份清单不可能详尽无遗，但其目的是对需要防范的各种可能性提供一个良好的概述。
We do not provide descriptions of any attacks that are not already publicly well documented.
我们不提供任何尚未公开记录的攻击的描述。
We first discuss attacks on end-systems. An end-system in this context is typically a PC or network server, but it can also include any communication endpoint. For example, a router also is an end-system from the point of view of terminating TCP connections for BGP [10] or ssh [46].
我们首先讨论对终端系统的攻击。在此上下文中，终端系统通常是PC或网络服务器，但也可以包括任何通信端点。例如，从终止BGP[10]或ssh[46]的TCP连接的角度来看，路由器也是终端系统。
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.
对终端系统最简单的DoS攻击利用终端系统本身的软件质量差，导致软件崩溃。例如，缓冲区溢出攻击可能会危害终端系统，但即使缓冲区溢出无法用于获取访问，通常也可能会覆盖内存并导致软件崩溃。原则上，此类漏洞会影响使用网络提供的数据的任何软件。因此，不仅web服务器可能存在潜在的漏洞，而且还可能使web服务器向其提供数据的后端软件（如数据库）崩溃。
Software crashes due to poor coding affect not only 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 [21]. 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.
由于糟糕的编码导致的软件崩溃不仅会影响应用软件，还会影响操作系统内核本身。一个经典的例子是所谓的“死亡之平”，它在1996年广为人知[21]。当发送单个碎片化ICMP回送请求数据包时，该漏洞导致许多流行操作系统崩溃，该数据包的碎片总数超过IPv4数据包中允许的65535字节。
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.
虽然拒绝服务攻击（如死亡ping）是一个重要问题，但它们不是一个重要的体系结构问题。一旦发现这样的攻击，相关代码就可以很容易地修补，问题就消失了。但我们应该注意，随着越来越多的软件嵌入，重要的是不要失去在此类系统中升级软件的可能性。
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 可用内存。
o The CPU cycles available.
o 可用的CPU周期。
o The disk space available to the application.
o 应用程序可用的磁盘空间。
o The number of processes or threads or both that the application is permitted to use.
o 允许应用程序使用的进程数或线程数或两者。
o The configured maximum number of simultaneous connections the application is permitted.
o 允许应用程序同时连接的最大配置数。
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.
有些资源是自我更新的：CPU周期属于这一类——如果攻击停止，就会有更多的CPU周期可用。
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) in order to limit the impact of exhaustion.
这个问题已经被理解了很多年，通常的做法是将日志和传入的电子邮件存储在单独的磁盘分区（Unix系统上为/var）中，以限制耗尽的影响。
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 attacker's 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.
一些资源受到配置的限制：进程的最大数量和同时连接的最大数量通常不是硬限制，而是配置的限制。此类限制的目的显然是在应用程序出现错误时允许机器执行其他任务。然而，需要非常小心地选择适当的限制。例如，如果一台机器的唯一任务是作为FTP服务器，那么将最大同时连接数设置为大大少于该机器所能提供的服务将使攻击者的工作更容易。但是，将限制设置得太高可能会允许攻击者导致机器崩溃（由于操作系统在处理资源耗尽方面的设计不佳）或允许livelock（见下文），这通常是更不理想的故障模式。
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.
从概念上讲，操作系统资源耗尽和应用程序资源耗尽非常相似。但是，在应用程序资源耗尽的情况下，操作系统可能能够保护其他任务不受DoS攻击的影响。在操作系统本身资源耗尽的情况下，问题可能更具灾难性。
Perhaps the best-known DoS attack on an operating system is the TCP SYN-flood [19], 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.
可能操作系统上最著名的DoS攻击是TCP SYN洪水[19]，它本质上是一种内存耗尽攻击。攻击者向受害者发送大量TCP SYN数据包，请求连接设置，但随后未完成连接设置。受害者实例化状态以处理传入连接。如果攻击者实例化状态的速度比受害者超时的速度快，那么受害者将耗尽可用于保存TCP状态的内存，因此无法为合法的TCP连接设置尝试提供服务。在某些实现中，由于为半开放连接使用了一个小的专用存储空间，这使得攻击比其他方式更容易，从而加剧了此问题。对于编码错误的操作系统，资源耗尽也可能导致系统崩溃。
An alternative TCP DoS attack is the Ack-flood [23], 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
另一种TCP DoS攻击是Ack洪水[23]，它本质上是针对受害者的CPU耗尽攻击。攻击者向受害者发送TCP数据包，假装来自从未建立的连接。具有大量未完成连接的繁忙服务器需要检查数据包对应的连接。一些TCP实现实现了这一点
search rather inefficiently, and so the attacker could use all the victim's CPU resources servicing these packets rather than servicing legitimate requests.
搜索效率很低，因此攻击者可以使用受害者的所有CPU资源来服务这些数据包，而不是服务合法请求。
We note that strong authentication mechanisms do not necessarily 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耗尽攻击。事实上，使用加密方法设计不当的身份验证机制会加剧问题。如果这种身份验证机制允许攻击者在丢弃数据包之前向受害者提供需要相对昂贵的加密身份验证的数据包，那么这会使攻击者的CPU耗尽攻击变得更容易。
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:
CPU耗尽攻击还可能因操作系统对传入网络流量处理不当而加剧。在没有恶意流量的情况下，理想的操作系统应如下所示：
o As incoming traffic increases, the useful work done by the OS should increase until some resource (such as the CPU) is saturated.
o 随着传入流量的增加，操作系统所做的有用工作应该增加，直到某些资源（如CPU）饱和。
o From this point on, as incoming traffic continues to increase the useful work done should be constant.
o 从这一点开始，随着传入流量的不断增加，所做的有用工作应该是不变的。
However, this is often not the case. Many systems suffer from livelock [33] 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.
然而，情况往往并非如此。许多系统都会受到livelock[33]的影响，饱和后，增加负载会导致所做的有用功减少。造成这种情况的一个原因是，系统花费越来越多的时间来处理永远不会被处理的数据包的网络中断，因此这些数据包用于的应用程序的可用时间越来越少。
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.
许多用户身份验证机制试图通过在少量身份验证失败后将用户锁定在外来防止密码猜测攻击。如果攻击者能够猜测或发现用户的ID，他们可能会触发这种机制，锁定合法用户。
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.
使用保护机制拒绝服务的另一种方法是耗尽配额。这可能在商业托管的小型web服务器的情况下最为常见，其中服务器与托管公司签订了合同，允许每天的固定流量。攻击者可能会迅速耗尽此配额，并导致服务暂停。对其他形式的配额也可能进行类似的攻击。
In the absence of such quotas, if the victim is charged for their network traffic, a financial denial-of-service may be possible.
在没有此类配额的情况下，如果对受害者的网络流量进行收费，则可能会发生财务拒绝服务。
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 command and control access ports. In the case of a router, these attacks may cause the router to stall, or may cause the router to cease processing routing packets. Even if the router does not stop servicing routing packets, it may become sufficiently slow that routing protocols time out. In any of these circumstances, the consequence of routing failure is not only that the router ceases to forward traffic, but also that it causes routing protocol churn that may have further side effects.
许多可以针对终端系统发起的拒绝服务攻击也可以针对IP路由器的控制处理器发起，例如，通过淹没命令和控制访问端口。在路由器的情况下，这些攻击可能导致路由器暂停，或者可能导致路由器停止处理路由数据包。即使路由器没有停止为路由数据包提供服务，它也可能变得足够慢，以至于路由协议超时。在任何一种情况下，路由失败的后果不仅是路由器停止转发流量，而且还导致路由协议的混乱，这可能会产生进一步的副作用。
An example of such a side effect is caused by BGP route flap damping [11], 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 [31]. This suppression likely causes the networks served by those routes to become unreachable.
这种副作用的一个例子是由BGP路由活门阻尼[11]引起的，其目的是减少全局路由抖动。如果攻击者可以导致BGP路由搅动，则路由抖动阻尼可能会导致抖动路由被抑制[31]。这种抑制可能导致这些路由所服务的网络变得不可访问。
A DoS attack on the router control processor might also prevent the router from 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.
路由器控制处理器上的DoS攻击也可能会阻止路由器得到有效管理。这可能会阻止采取缓解DoS攻击的措施，并且可能会阻止诊断问题的原因。
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. This requires the ability to send traffic from addresses that might plausibly have generated the relevant routing messages, which is somewhat difficult with interior routing protocols but fairly easy with External Border Gateway Protocol (eBGP), for instance.
除了作为终端系统的角色外，大多数路由器都运行动态路由协议。路由协议本身可用于在路由器或路由器网络上发起DoS攻击。这需要能够从可能生成相关路由消息的地址发送通信量，这在内部路由协议中有点困难，但在外部边界网关协议（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 [26]. 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.
路由器网络上最简单的攻击是使用足够多的路由使路由表过载，从而导致路由器内存不足，或者路由器没有足够的CPU处理路由[26]。我们注意到，根据网络中各种路由器的分布和容量，这种攻击可能不会压倒攻击路由器附近的路由器，但可能会导致网络中其他地方出现问题。
Some routing protocol implementations allow limits to be configured on the maximum number of routes to be heard from a neighbor [27].
一些路由协议实现允许对从邻居听到的最大路由数进行限制[27]。
However, limits often make the problem worse rather than better, by making it possible for the attacker to push out legitimate routes with spoofed routes, thus creating an easy form of DoS attack.
然而，限制常常使问题变得更糟，而不是更好，因为它使攻击者有可能用伪造的路由推出合法的路由，从而创建一种简单的DoS攻击形式。
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 fail to reach the legitimate destination.
更微妙的拒绝服务攻击可能针对网络而不是目标发起。在某些情况下，不一致路由信息的传播可能导致流量循环。如果攻击者可以在繁忙的路径上造成这种情况，则循环流量可能会造成严重拥塞，并无法到达合法的目的地。
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 routers 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.
在过去，存在不同代路由器对路由协议规范进行不同解释的情况。特别是，BGP指定在发生错误的情况下，应该删除BGP对等。然而，如果网络中的一些路由器将特定路由视为有效，而其他路由器将该路由视为无效，则可能在互联网中的某个点注入BGP路由，并导致在互联网中的许多其他位置丢弃对等。与上面的许多示例不同，虽然这样的问题可能是一个严重的短期问题，但这不是一个基本的体系结构问题。一旦问题被理解，部署修补路由代码可以永久解决问题。
There are essentially two forms of IP multicast: traditional Any-Source Multicast (ASM), as specified in RFC 1112 [4] 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.
IP多播基本上有两种形式：RFC 1112[4]中规定的传统任意源多播（ASM），其中多个源可以发送到同一个多播组；以及源特定多播（SSM），其中接收方必须同时指定IP源地址和组地址。这两种形式的多播提供了完全不同的拒绝服务可能性。
ASM protocols such as PIM-SM [6], MSDP [32], and DVMRP [12] typically cause some routers to instantiate routing state at the time a packet is sent to a multicast group. They do this to ensure that the traffic goes to the group receivers and not to non-receivers. Such protocols are particularly vulnerable to DoS attacks, as an attacker that sends to many multicast groups may cause 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协议，如PIM-SM[6]、MSDP[32]和DVMRP[12]通常会导致一些路由器在将数据包发送到多播组时实例化路由状态。他们这样做是为了确保流量流向组接收方，而不是非接收方。此类协议特别容易受到DoS攻击，因为发送到多个多播组的攻击者可能会导致多播路由表爆炸（从而导致控制处理器内存耗尽）和多播转发表耗尽（从而导致转发卡内存耗尽或抖动）。
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.
ASM还允许攻击者将流量发送到与合法流量相同的组，从而可能导致网络拥塞并拒绝向合法组提供服务。
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.
SSM不允许发送方发送到任意组，除非接收方已请求通信量。因此，SSM不可能对多播路由状态进行基于发送方的攻击。但是，与ASM一样，接收器仍然可以加入大量多播组，导致路由器保持大量多播路由状态，从而可能导致内存耗尽，从而拒绝对合法流量的服务。
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.
在IPv6中，主机需要在某些情况下发送ICMP数据包过大或参数问题消息，即使目标地址是多播地址。如果攻击者可以将自己放置在多播树中的适当位置，例如，具有未知但必须的目标选项的数据包可能会对声称的发送者生成大量响应。
With IPv4, the same problem exists with multicast ICMP Echo Request packets, but these are somewhat easier to filter.
对于IPv4，多播ICMP回送请求数据包也存在同样的问题，但这些数据包更容易过滤。
The examples above should not be taken as exhaustive. These are actually specific cases of a general problem that can happen when a multicast/broadcast request solicits a reply from a large number of nodes.
上述例子不应被视为详尽无遗。这些实际上是当多播/广播请求请求从大量节点请求回复时可能发生的一般问题的特定情况。
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.
路由器供应商实现了许多不同的包转发机制，但从广义上讲，它们分为两类：使用转发缓存的机制和不使用转发缓存的机制。对于转发缓存，转发引擎不保存完整的路由表，而只保存转发表的当前活动子集。
Many modern routers use a loosely coupled architecture, where one or more control processors handle the routing protocols and communicate over an internal network link to special-purpose forwarding engines, which actually forward the data traffic. In such architectures, it may be possible for an attacker to overwhelm the communications link between the control processor and the forwarding engine. This is possible 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.
攻击者可以通过多种方式触发转发引擎和控制处理器之间的通信。最简单的方法是让攻击者简单地发送到路由器的IP地址，但原则上这应该相对容易防止在转发引擎上使用过滤。另一种方法可能是使路由器使用“慢路径”转发数据包。这包括从转发路由器发送需要特别注意的数据包；如果转发引擎不够智能，无法执行这种转发，那么它通常会将数据包传递给控制处理器。在使用转发缓存的路由器中，可能会通过抖动转发缓存来过载内部通信。最后，转发引擎和控制处理器之间任何形式的数据触发通信都可能导致此类问题。某些多播路由协议（包括PIM-SM）包含许多可能存在问题的数据触发事件。
The effects of overloading such internal communications are hard to predict and are 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 auto-install access control list (ACL) entries, perhaps by triggering a response from an intrusion detection system, then it may be possible to exhaust the ACL resources on the router. This might prevent future attacks from being filtered, or worse, cause ACL processing to be handled by the route processor.
最后，如果攻击者可能通过触发入侵检测系统的响应来生成流量，使路由器自动安装访问控制列表（ACL）条目，则可能会耗尽路由器上的ACL资源。这可能会阻止将来的攻击被过滤，或者更糟，导致ACL处理由路由处理器处理。
Instead of attacking the end-system itself, it is also possible for an attacker 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 [29]. Such attacks are not
攻击者也有可能中断正在进行的通信，而不是攻击终端系统本身。如果攻击者能够观察到TCP连接，那么他们就相对容易伪造数据包来重置该连接或取消该连接的同步，从而无法取得进一步的进展[29]。这样的袭击并不严重
prevented by transport or application-level security mechanisms such as TLS [5] or ssh, because the authentication takes place after TCP has finished processing the packets.
由于身份验证是在TCP处理完数据包之后进行的，因此被传输或应用程序级安全机制（如TLS[5]或ssh）阻止。
If an attacker cannot observe a TCP connection, but can infer that such a connection exists, it is theoretically possible to reset or de-synchronize that connection by spoofing packets into the connection. However, this might require an excessively large number of spoofed packets to guess both the port of the active end of the TCP connection (in most cases, the port of the passive end 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 [41] [20], then such attacks have been found to be feasible [34]. Advice as to how to reduce the vulnerability in the specific case of TCP is available in [37].
如果攻击者无法观察TCP连接，但可以推断存在此类连接，则理论上可以通过向连接中欺骗数据包来重置或取消同步该连接。但是，这可能需要大量伪造的数据包来猜测TCP连接的主动端端口（在大多数情况下，被动端的端口是可预测的）和当前有效的TCP序列号。然而，由于一些操作系统在选择动态选择的端口或TCP初始序列号[41][20]时没有很好地实现可预测的算法，因此发现此类攻击是可行的[34]。[37]中提供了关于如何减少TCP特定情况下的漏洞的建议。
An attacker might be able to significantly reduce the throughput of a connection by sending spoofed ICMP source quench packets, although most modern operating systems should ignore such packets. However, care should be taken in the design of future transport and signaling protocols to avoid the introduction of similar mechanisms that could be exploited.
通过发送伪造的ICMP源猝灭数据包，攻击者可能会显著降低连接的吞吐量，尽管大多数现代操作系统应该忽略此类数据包。然而，在设计未来的传输和信令协议时应注意避免引入可能被利用的类似机制。
Instead of directly overloading the victim, it may be possible to cause the victim or a machine on the same subnet as the victim to overload itself.
可能会导致受害者或与受害者位于同一子网上的计算机自身过载，而不是直接使受害者过载。
An example of such an attack is documented in [18], where the attacker spoofs the source address on a packet sent to the victim's UDP echo port. The source address is that of another machine that is running a UDP chargen server (a chargen server sends a character pattern back to the originating source). The result is that the two machines bounce packets back and forth as fast as they can, overloading either the network between them or one of the end-systems itself.
[18]中记录了此类攻击的一个示例，攻击者在发送到受害者的UDP回显端口的数据包上伪造源地址。源地址是运行UDP chargen服务器的另一台计算机的地址（chargen服务器将字符模式发送回原始源）。结果是这两台机器以尽可能快的速度来回反弹数据包，使它们之间的网络或其中一个终端系统本身过载。
There are a number of attacks that might only be performed by a local attacker.
有许多攻击可能仅由本地攻击者执行。
An attacker with access to a subnet may be able to prevent other local hosts from accessing the network at all by simply exhausting the address pool allocated by a Dynamic Host Configuration Protocol (DHCP) server. This requires being able to spoof the MAC address of
通过耗尽动态主机配置协议（DHCP）服务器分配的地址池，可以访问子网的攻击者可能会阻止其他本地主机访问网络。这需要能够欺骗的MAC地址
an ethernet or wireless card, but this is quite feasible with certain hardware and operating systems.
以太网或无线网卡，但这在某些硬件和操作系统中是非常可行的。
An alternative DHCP-based attack is simply to respond faster than the legitimate DHCP server, and to give out an address that is not useful to the victim.
另一种基于DHCP的攻击只是响应速度比合法的DHCP服务器快，并给出对受害者没有用处的地址。
These sorts of bootstrapping attacks tend to be difficult to avoid because most of the time trust relationships are established after IP communication has already been established.
这些类型的自举攻击往往难以避免，因为大多数情况下，信任关系是在IP通信已经建立之后建立的。
Similar attacks are possible through ARP spoofing [16]; an attacker 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. This attack might also potentially be used to block traffic from the victim by engaging screening or flap-dampening algorithms in the switch, depending on the switch design.
类似的攻击可能通过ARP欺骗[16]；攻击者可以在受害者之前响应ARP请求，并阻止流量到达受害者。一些品牌的以太网交换机允许更简单的攻击：只需从受害者的MAC地址发送，交换机就会将发送给受害者的流量重定向到攻击者的端口。根据交换机的设计，此攻击还可能通过在交换机中使用屏蔽或襟翼阻尼算法来阻止来自受害者的流量。
It may be possible to cause broadcast storms [16] on a local LAN by sending a stream of unicast IP packets to the broadcast MAC address. Some hosts on the LAN may then attempt to forward the packets to the correct MAC address, greatly amplifying the traffic on the LAN.
通过向广播MAC地址发送单播IP数据包流，可以在本地LAN上引起广播风暴[16]。局域网上的一些主机可能会尝试将数据包转发到正确的MAC地址，从而大大放大局域网上的流量。
802.11 wireless networks provide many opportunities to deny service to other users. In some cases, the lack of defenses against DoS was a deliberate choice--because 802.11 operates on unlicensed spectrum it was assumed that there would be sources of interference and that producing intentional radio-level jamming would be trivial. Thus, the amount of DoS protection possible at higher levels was minimal.
802.11无线网络提供了许多拒绝向其他用户提供服务的机会。在某些情况下，缺乏对拒绝服务的防御是一种深思熟虑的选择——因为802.11是在未经许可的频谱上运行的，因此假定会有干扰源，并且产生有意的无线电级干扰是微不足道的。因此，在更高级别上可能的DoS保护量是最小的。
Nevertheless, some of the weaknesses of the protocols against more sophisticated attacks are worth noting. The most prominent of these is that association is unprotected, thus allowing rogue access points (APs) to solicit notifications that would otherwise have gone to legitimate APs.
尽管如此，针对更复杂攻击的协议的一些弱点值得注意。其中最突出的是关联是不受保护的，因此允许恶意接入点（AP）请求通知，否则这些通知会转到合法AP。
The SSID field provides effectively no defense against this kind of attack. Unless encryption is enabled, it is trivial to announce the presence of a base station (or even of an ad-hoc mode host) with the same network name (SSID) as the legitimate basestation. Even adding authentication and encryption a la 802.1X and 802.11i may not help much in this respect. The SSID space is unmanaged, so everyone is free to put anything they want in the SSID field. Most host stacks don't deal gracefully with this. Moreover, SSIDs are very often set to the manufacturer's default, making them highly predictable.
SSID字段无法有效防御此类攻击。除非启用了加密，否则宣布存在与合法基站具有相同网络名称（SSID）的基站（甚至是特设模式主机）是很简单的。即使在la 802.1X和802.11i中添加身份验证和加密，在这方面也可能没有多大帮助。SSID空间是非托管的，因此每个人都可以在SSID字段中自由放置他们想要的任何内容。大多数主机堆栈不能很好地处理这个问题。此外，SSID通常设置为制造商的默认值，使其具有高度可预测性。
Some 802.11 basestations have limited memory for the number of associations they can support. If this is exceeded, they may drop all associations. In an attempt to forestall this problem, some APs advertise their load so as to enable stations to choose APs that are less loaded. However, crude implementations of these algorithms can result in instability.
一些802.11基站的内存有限，无法支持多个关联。如果超过此值，他们可能会删除所有关联。为了避免这个问题，一些AP公布了它们的负载，以便使站点能够选择负载较少的AP。然而，这些算法的粗略实现可能会导致不稳定性。
Finally, as the authentication in 802.11 takes place at a comparatively high level in the stack, it is possible to simply deauthenticate or disassociate the victim from the basestation, even if Wired Equivalent Privacy (WEP) is in use [30]. Bellardo and Savage [15] describe some simple remedies that reduce the effectiveness of such attacks. While IEEE 802.11w will protect Deauthenticate or Disassociate frames, this attack is still possible via forging of Association frames.
最后，由于802.11中的身份验证在堆栈中的较高级别上进行，因此即使使用有线等效隐私（WEP），也可以简单地取消对受害者的身份验证或解除受害者与基站的关联[30]。Bellardo和Savage[15]描述了一些降低此类攻击有效性的简单补救措施。虽然IEEE 802.11w将保护取消验证或解除关联的帧，但这种攻击仍然可能通过伪造关联帧进行。
What all these attacks have in common is that they exploit vulnerabilities in the link auto-configuration mechanisms. In a wireless network, it is necessary for a station to detect the presence of APs in order to choose which one to connect to. In 802.11, this is handled via the Beacon and Probe Request/Response mechanisms.
所有这些攻击的共同点是，它们利用链接自动配置机制中的漏洞进行攻击。在无线网络中，站点有必要检测AP的存在，以便选择要连接的AP。在802.11中，这是通过信标和探测请求/响应机制来处理的。
Beacons cannot easily be encrypted, because the station needs to utilize them prior to authentication in order to discover which APs it may wish to communicate with. Since authentication can only occur after interpreting the Beacon, an encrypted Beacon would present a chicken-egg problem: you can't obtain a key to decrypt the Beacon until completing authentication, and you may not be able to figure out which AP to authenticate with prior to decrypting the Beacon. Note that in principle you could encrypt Beacons with a shared (per-AP) key but this would require each station to trial-decrypt beacons until it finds one that matches up to whatever shared authentication secret it had. This is not particularly convenient.
信标不容易加密，因为站点需要在身份验证之前使用信标，以便发现它希望与哪些AP通信。由于身份验证只能在解释信标后进行，因此加密信标将出现一个鸡蛋问题：在完成身份验证之前，您无法获得密钥来解密信标，并且在解密信标之前，您可能无法确定要与哪个AP进行身份验证。请注意，原则上您可以使用共享（每个AP）密钥对信标进行加密，但这将要求每个站点尝试解密信标，直到找到一个与它拥有的任何共享身份验证密钥相匹配的信标。这并不特别方便。
As a result, discussions of Beacon frame security have largely focused on authentication of Beacon frames, not encryption. Even here, solutions are difficult. While it may be possible for a station to validate a Beacon *after* authentication (either by checking a Message Integrity Check (MIC) computed with the group key provided by the AP or verifying the Beacon parameters during the 4-way handshake), doing so *before* authentication may require synchronization of keys between APs within an SSID.
因此，信标帧安全性的讨论主要集中在信标帧的身份验证，而不是加密。即使在这里，解决方案也很难。虽然站点可以在*认证之后*验证信标（通过检查使用AP提供的组密钥计算的消息完整性检查（MIC）或在4路握手期间验证信标参数），但在*认证之前*验证可能需要在SSID内的AP之间同步密钥。
In today's Internet, DNS is of sufficient importance that if access to a site's DNS servers is denied, the site is effectively unreachable, even if there is no actual communication problem with the site itself.
在当今的互联网中，DNS非常重要，如果拒绝访问站点的DNS服务器，则该站点实际上是无法访问的，即使站点本身没有实际的通信问题。
Many of the attacks on end-systems described above can be perpetrated on DNS servers. As servers go, DNS servers are not particularly vulnerable to DoS. So long as a DNS server has sufficient memory, a modern host can usually respond very rapidly to DNS requests for which it is authoritative. This was demonstrated in October 2002 when the root nameservers were subjected to a very large DoS attack [38]. A number of the root nameservers have since been replicated using anycast [1] to further improve their resistance to DoS. However, it is important for authoritative servers to have relaying disabled, or it is possible for an attacker to force the DNS servers to hold state [40].
上述对终端系统的许多攻击都可以在DNS服务器上实施。随着服务器的运行，DNS服务器不会特别容易受到DoS攻击。只要DNS服务器有足够的内存，现代主机通常可以非常快速地响应其授权的DNS请求。这一点在2002年10月得到了证明，当时根名称服务器受到了非常大的DoS攻击[38]。此后，使用anycast[1]复制了许多根名称服务器，以进一步提高它们对DoS的抵抗能力。但是，授权服务器禁用中继非常重要，否则攻击者可能会强制DNS服务器保持状态[40]。
Many of the routing attacks can also be used against DNS servers by targeting the routing for the server. If the DNS server is co-located with the site for which is authoritative, then the fact that the DNS server is also unavailable is of secondary importance. However, if all the DNS servers are made unavailable, this may cause email to that site to bounce rather than being stored while the mail servers are unreachable, so distribution of DNS server locations is important.
许多路由攻击还可以通过针对DNS服务器的路由来针对该服务器。如果DNS服务器与具有权威性的站点位于同一位置，则DNS服务器也不可用的事实是次要的。但是，如果所有DNS服务器都不可用，这可能会导致发送到该站点的电子邮件反弹，而不是在无法访问邮件服务器时存储，因此分发DNS服务器位置非常重要。
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.
在与DNS服务器之间的链接上造成网络拥塞可能会产生与结束系统攻击或路由攻击类似的影响，导致DNS无法获得答案，并有效地拒绝访问正在服务的站点。
We note that if an attacker can deny external access to all the DNS servers for a site, this will not only cause email to that site to be dropped, but it will also cause email from that site to be dropped. This is because recent versions of mail transfer agents such as sendmail will drop email if the mail originates from a domain that does not exist. This is a classic example of unexpected consequences. Sendmail performs this check as an anti-spam measure, and spam itself can be viewed as a form of DoS attack. Thus, defending against one DoS attack opens up the vulnerability that allows another DoS attack. If a receiving implementation is using a black-hole list (see Section 2.14) served by DNS, an attacker can also mount a DoS attack by attacking the black-hole server.
我们注意到，如果攻击者可以拒绝外部访问某个站点的所有DNS服务器，这不仅会导致发送到该站点的电子邮件被删除，还会导致该站点的电子邮件被删除。这是因为，如果邮件来自不存在的域，则最新版本的邮件传输代理（如sendmail）将丢弃电子邮件。这是一个典型的意外后果的例子。Sendmail将此检查作为反垃圾邮件措施执行，而垃圾邮件本身可以被视为DoS攻击的一种形式。因此，防御一个DoS攻击会打开允许另一个DoS攻击的漏洞。如果接收实现使用DNS提供的黑洞列表（参见第2.14节），攻击者还可以通过攻击黑洞服务器来发起DoS攻击。
Finally, a data corruption attack is possible if a site's nameserver is permitted to relay requests from untrusted third parties [40]. The attacker issues a query for the data he wishes to corrupt, and the victim's nameserver relays the request to the authoritative nameserver. The request contains a 16-bit ID that is used to match up the response with the request. If the attacker spoofs sufficient response packets from the authoritative nameserver just before the official response arrives, each containing a forged response and a different DNS ID, then there is a reasonable chance that one of the forged responses will have the correct DNS ID. The incorrect data will then be believed and cached by the victim's nameserver, so giving the incorrect response to future queries. The probability of the attack can further be increased if the attacker issues many different requests for the same data with different DNS IDs, because many nameserver implementations will issue relayed requests with different DNS IDs, and so the response only has to match any one of these request IDs [17] [36].
最后，如果允许站点的名称服务器中继来自不受信任的第三方的请求，则可能发生数据损坏攻击[40]。攻击者对他希望破坏的数据发出查询，受害者的名称服务器将请求转发给权威名称服务器。请求包含一个16位ID，用于将响应与请求匹配。如果攻击者在正式响应到达之前从权威名称服务器欺骗足够的响应数据包，每个数据包包含伪造响应和不同的DNS ID，然后，其中一个伪造的响应很有可能具有正确的DNS ID。然后，受害者的名称服务器将相信并缓存错误的数据，从而为将来的查询提供错误的响应。如果攻击者使用不同的DNS ID对同一数据发出许多不同的请求，则攻击的概率会进一步增加，因为许多名称服务器实现将使用不同的DNS ID发出中继请求，因此响应只需匹配这些请求ID中的任何一个[17][36]。
The use of anycast for DNS services makes it even more vulnerable to spoofing attacks. An attacker who can convince the ISP to accept an anycast route to his fake DNS server can arrange to receive requests and generate fake responses. Anycast DNS also makes DoS attacks on DNS easier. The idea is to disable one of the DNS servers while maintaining the BGP route to that server. This creates failures for any client that is routed to the (now defunct) server.
对DNS服务使用anycast使其更容易受到欺骗攻击。如果攻击者能够说服ISP接受到其伪DNS服务器的选播路由，则可以安排接收请求并生成伪响应。Anycast DNS还使DNS上的DoS攻击更容易。我们的想法是禁用其中一个DNS服务器，同时维护到该服务器的BGP路由。这会为路由到（现已失效）服务器的任何客户端创建故障。
The simplest DoS attack is to simply send enough non-congestion-controlled traffic such that a link becomes excessively congested, and legitimate traffic suffers unacceptably high packet loss.
最简单的DoS攻击就是简单地发送足够多的非拥塞控制流量，使得链路变得过度拥塞，合法流量遭受不可接受的高数据包丢失。
Under some circumstances, the effect of such a link DoS can be much more extensive. We have already discussed the effects of denying access to a DNS server. Congesting a link might also cause a routing protocol to drop an adjacency if sufficient routing packets are lost, potentially greatly amplifying the effects of the attack. Good router implementations will prioritize the transmission of routing packets, but this is not a total panacea. If routers are peered across a shared medium such as ethernet, it may be possible to congest the medium sufficiently that routing packets are still lost.
在某些情况下，这种链接的影响可能更广泛。我们已经讨论了拒绝访问DNS服务器的影响。如果丢失了足够多的路由数据包，阻塞链路还可能导致路由协议丢弃邻接，从而可能极大地放大攻击的影响。好的路由器实现将优先考虑路由数据包的传输，但这并不是一个完全的灵丹妙药。如果路由器通过共享介质（如以太网）进行窥视，则可能会使该介质充分拥塞，以致路由数据包仍然丢失。
Even if a link DoS does not cause routing packets to be lost, it may prevent remote access to a router using ssh or Simple Network Management Protocol (SNMP) [48]. This might make the router unmanageable, or prevent the attack from being correctly diagnosed.
即使链路DoS不会导致路由数据包丢失，也可能会阻止使用ssh或简单网络管理协议（SNMP）远程访问路由器[48]。这可能会使路由器无法管理，或阻止正确诊断攻击。
The prioritization of routing packets can itself cause a DoS problem. If the attacker can cause a large amount of routing flux, it may be possible for a router to send routing packets at a high enough rate that normal traffic is effectively excluded. However, this is unlikely except on low-bandwidth links.
路由数据包的优先级划分本身可能导致拒绝服务问题。如果攻击者可以造成大量路由流量，路由器可能会以足够高的速率发送路由数据包，从而有效排除正常流量。然而，除了在低带宽链路上，这是不可能的。
Finally, it may be possible for an attacker to deny access to a link by causing the router to generate sufficient monitoring or report traffic that the link is filled. SNMP traps are one possible vector for such an attack, as they are not normally congestion controlled.
最后，攻击者可能会通过使路由器生成足够的监控或报告链路已填充的通信量来拒绝对链路的访问。SNMP陷阱是此类攻击的一个可能载体，因为它们通常不受拥塞控制。
Attackers with physical access to multiple access links can easily bring down the link. This is particularly easy to mount and difficult to counter with wireless networks.
对多个访问链路具有物理访问权限的攻击者可以轻松关闭该链路。这特别容易安装，并且难以通过无线网络进行对抗。
Firewalls are intended to defend the systems behind them against attack. In that they restrict the traffic that can reach those systems, they may also aid in defending against denial-of-service attacks. However, under some circumstances the firewall itself may also be used as a weapon in a DoS attack.
防火墙旨在保护其背后的系统免受攻击。由于它们限制了可以到达这些系统的流量，因此它们还可以帮助防御拒绝服务攻击。然而，在某些情况下，防火墙本身也可能被用作DoS攻击的武器。
There are many different types of firewall, but generally speaking they fall into stateful and stateless classes. The state here refers to whether the firewall holds state for the active flows traversing the firewall. Stateless firewalls generally can only be attacked by attempting to exhaust the processing resources of the firewall. Stateful firewalls can be attacked by sending traffic that causes the firewall to hold excessive state or state that has pathological structure.
有许多不同类型的防火墙，但一般来说，它们分为有状态类和无状态类。此处的状态是指防火墙是否保持穿越防火墙的活动流的状态。无状态防火墙通常只能通过尝试耗尽防火墙的处理资源来受到攻击。有状态防火墙可以通过发送导致防火墙保持过多状态或具有病态结构的状态的流量受到攻击。
In the case of excessive state, the firewall simply runs out of memory, and can no longer instantiate the state required to pass legitimate flows. Most firewalls will then fail disconnected, causing denial-of-service to the systems behind the firewall.
在状态过多的情况下，防火墙只会耗尽内存，无法再实例化通过合法流所需的状态。然后，大多数防火墙将无法断开连接，从而导致防火墙后面的系统拒绝服务。
In the case of pathological structure, the attacker sends traffic that causes the firewall's data structures to exhibit worst-case behaviour. An example of this would be when the firewall uses hash tables to look up forwarding state, and the attacker can predict the hash function used. The attacker may then be able to cause a large amount of flow state to hash to the same bucket, which causes the firewall's lookup performance to change from O(1) to O(n), where n is the number of flows the attacker can instantiate [28]. Thus, the attacker can cause forwarding performance to degrade to the point where service is effectively denied to the legitimate traffic traversing the firewall.
在病理结构的情况下，攻击者发送的流量会导致防火墙的数据结构表现出最坏的行为。例如，防火墙使用哈希表查找转发状态，攻击者可以预测使用的哈希函数。然后，攻击者可能会导致大量流状态散列到同一个bucket，从而导致防火墙的查找性能从O（1）更改为O（n），其中n是攻击者可以实例化的流数[28]。因此，攻击者可以导致转发性能降低，从而有效地拒绝通过防火墙的合法流量提供服务。
Intrusion detection systems (IDSs) suffer from similar problems to firewalls. It may be possible for an attacker to cause the IDS to exhaust its available processing power, to run out of memory, or to instantiate state with pathological structure. Unlike a firewall, an IDS will normally fail open, which will not deny service to the systems protected by the IDS. However, it may mean that subsequent attacks that the IDS would have detected will be missed.
入侵检测系统（IDSs）面临着与防火墙类似的问题。攻击者可能会导致IDS耗尽其可用处理能力、耗尽内存或使用病态结构实例化状态。与防火墙不同，IDS通常会失效开放，不会拒绝为受IDS保护的系统提供服务。但是，这可能意味着IDS可能检测到的后续攻击将丢失。
Some IDSs are reactive; that is, on detection of a hostile event they react to block subsequent traffic from the hostile system, or to terminate an ongoing connection from that system. It may be possible for an attacker to spoof packets from a legitimate system, and hence cause the IDS to believe that system is hostile. The IDS will then cause traffic from the legitimate system to be blocked, hence denying service to it. The effect can be particularly bad if the legitimate system is a router, DNS server, or other system whose performance is essential for the operation of a large number of other systems.
一些IDS是被动的；也就是说，在检测到恶意事件时，他们会做出反应，阻止来自恶意系统的后续通信，或终止来自该系统的持续连接。攻击者可能会从合法系统中欺骗数据包，从而使IDS相信系统是恶意的。然后，IDS将导致来自合法系统的流量被阻止，从而拒绝向其提供服务。如果合法系统是路由器、DNS服务器或其性能对大量其他系统的运行至关重要的其他系统，则影响可能特别糟糕。
Network time servers are generally not considered security-critical services, but under some circumstances NTP servers might be used to perpetrate a DoS attack.
网络时间服务器通常不被视为安全关键型服务，但在某些情况下，NTP服务器可能被用于实施DoS攻击。
The most obvious such attack is to DoS the NTP servers themselves. Many end-systems have rather poor clock accuracy and so, without access to network time, their clock will 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 modification timestamp to be in the future.
最明显的此类攻击是DoS NTP服务器本身。许多终端系统的时钟精度相当差，因此，如果没有网络时间，它们的时钟自然会漂移。这可能会导致依赖良好时钟的分布式系统出现问题。例如，如果一个常用的修订控制系统认为修改时间戳在将来，它可能会失败。
If the NTP servers relied on by a host can be subverted, either through compromising or impersonating them, then the attacker may be able to control the host's system clock. This can cause many unexpected consequences, including the premature expiry of dated resources such as encryption or authentication keys. This in turn can prevent access to other more critical services.
如果主机所依赖的NTP服务器可以通过破坏或模拟被破坏，则攻击者可能能够控制主机的系统时钟。这可能会导致许多意外后果，包括过期资源（如加密或身份验证密钥）过早过期。这反过来又会阻止访问其他更重要的服务。
The discussion thus far has centered on denial-of-service attacks perpetrated using the network. However, computer systems are only as resilient as the weakest link. It may be easier to deny service by causing a power failure, by cutting network cables, or by simply switching a system off, and so physical security is at least as important as network security. Physical attacks can also serve as
到目前为止，讨论的重点是使用网络实施的拒绝服务攻击。然而，计算机系统的弹性仅与最薄弱的环节相同。通过导致电源故障、切断网络电缆或简单地关闭系统来拒绝服务可能更容易，因此物理安全至少与网络安全同等重要。物理攻击也可以作为
entry points for non-physical DoS, for instance, by reducing the resources available to deal with overcapacity.
非物理DoS的入口点，例如，通过减少可用于处理产能过剩的资源。
The weakest link may also be human. In defending against DoS, the possibility of denial-of-service through social engineering should not be neglected, such as convincing an employee to make a configuration change that prevents normal operation.
最薄弱的环节也可能是人。在防御DoS时，不应忽视通过社会工程拒绝服务的可能性，例如说服员工进行阻止正常运行的配置更改。
Computer systems cannot be considered in isolation from the social and legal systems in which they operate. This document focuses primarily on the technical issues, but we note that "cease and desist" letters, government censorship, and other legal mechanisms also touch on denial-of-service issues.
计算机系统不能脱离其运行的社会和法律系统来考虑。本文件主要关注技术问题，但我们注意到，“停止”信函、政府审查和其他法律机制也涉及拒绝服务问题。
Unsolicited commercial email, also known as "spam", can effectively cause denial-of-service to email systems. While the intent is not denial-of-service, the large amount of unwanted mail can waste the recipient's time or cause legitimate email to fail to be noticed amongst all the background noise. If spam filtering software is used, some level of false positives is to be expected, and so these messages are effectively denied service.
未经请求的商业电子邮件，也称为“垃圾邮件”，可以有效地导致电子邮件系统拒绝服务。虽然目的不是拒绝服务，但大量不需要的邮件可能会浪费收件人的时间，或导致合法邮件在所有背景噪音中无法被注意到。如果使用垃圾邮件过滤软件，可能会出现一定程度的误报，因此这些邮件会被有效地拒绝服务。
One mechanism to reduce spam is the use of black-hole lists. The IP addresses of dial-up ISPs or mail servers used to originate or relay spam are added to black-hole lists. The recipients of mail choose to consult these lists and reject spam if it originates or is relayed by systems on the list. One significant problem with such lists is that it may be possible for an attacker to cause a victim to be black-hole-listed, even if the victim was not responsible for relaying spam. Thus, the black-hole list itself can be a mechanism for effecting a DoS attack. Note that every black-hole list has its own policy regarding additions, and some are less susceptible to this DoS attack than others. Consumers of black-hole list technology are advised to investigate these policies before they subscribe. Similar considerations apply to feeds of bad BGP bad route advertisements.
减少垃圾邮件的一种机制是使用黑洞列表。用于发起或转发垃圾邮件的拨号ISP或邮件服务器的IP地址被添加到黑洞列表中。邮件收件人选择查阅这些列表，并拒绝来自列表上的系统或由列表上的系统转发的垃圾邮件。此类列表的一个重要问题是，攻击者可能导致受害者被列入黑洞列表，即使受害者不负责转发垃圾邮件。因此，黑洞列表本身可能是实施DoS攻击的一种机制。请注意，每个黑洞列表都有自己的添加策略，有些黑洞列表比其他黑洞列表更不容易受到DoS攻击。建议黑洞列表技术的消费者在订阅之前调查这些政策。类似的考虑也适用于坏BGP坏路由广告的源。
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 [35].
上面描述的许多攻击都依赖于发送足够的流量来压倒受害者。由于“攻击放大器”的存在，此类攻击变得更加容易，攻击者可以从受害者伪造的源地址发送流量，并导致向受害者返回更大的响应。有关此类反射攻击的详细讨论，请参见[35]。
The simplest such attack was the "smurf" attack [22], 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.
最简单的此类攻击是“smurf”攻击[22]，其中带有受害者伪造源地址的ICMP回送请求包被发送到网络的子网广播地址，用作放大器。然后，该子网上的每个系统都会以返回给受害者的ICMP回显响应进行响应。Smurf攻击不再是一个严重的问题，因为现在路由器通常会丢弃这样的数据包，而终端系统不会响应它们。
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.
另一种攻击放大器形式是DNS反射攻击。攻击者向DNS服务器发送DNS请求，请求解析域名。同样，请求的源地址是受害者的伪造地址。仔细选择请求，使响应的大小明显大于请求的大小，从而提供放大。另一方面，值得注意的是，最大的DNS响应往往是那些包含DNSsec身份验证信息的响应。此攻击放大器只能由能够欺骗受害者源地址的攻击者使用。但是，我们注意到，如果受害者的DNS服务器配置为中继来自外部客户端的请求，则可能会导致其自身的传入网络链路拥塞。
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 an arbitrary TCP server. The server will respond with a SYN|ACK that 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.
攻击放大器的另一种变体涉及通过重传进行放大。这是典型的TCP放大攻击，称为“bang.c”。攻击者向任意TCP服务器发送带有受害者源地址的伪造TCP SYN。服务器将用发送给受害者的SYN | ACK进行响应，当没有收到完成握手的最终ACK时，SYN | ACK将被重新传输多次。通常，此攻击使用大量任意选择的服务器作为反射器。为了使攻击成功，反射器不得接收来自受害者的响应SYN | ACK的RST。但是，如果攻击流量足以淹没服务器或服务器的访问链路，则数据包丢失将确保许多反射器不会收到响应其SYN | ACK的RST，从而继续重新传输。防火墙在不发送RST的情况下无声地丢弃传入的SYN | ACK，这会加剧攻击。
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 a protocol is the Session Initiation Protocol (SIP) [50], which carries a payload defined by the Session Description Protocol (SDP) [51]. 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) [52], are sent.
放大的另一个变体出现在协议中，该协议在协议有效负载中包括后续消息应发送到的主机的IP地址或名称。这种协议的一个例子是会话发起协议（SIP）[50]，它承载由会话描述协议（SDP）[51]定义的有效载荷。SIP消息的SDP有效载荷传送通常使用实时传输协议（RTP）[52]编码的媒体分组发送到的IP地址和端口。
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".
要发起此攻击，攻击者会发送一条协议消息，并将有效负载内的IP地址设置为指向攻击目标。邮件收件人将生成该IP地址的后续通信量。根据协议的不同，这种攻击可以提供大量的放大特性。在SIP的特定情况下，如果呼叫者呼叫高带宽媒体源（例如视频服务器或流式音频服务器），单个SIP INVITE数据包（通常为几百字节）可以产生几乎连续的媒体数据包流，其速率从每秒几kbit到每秒兆比特不等。这种特殊的攻击被称为“语音锤”。
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.
与上述其他技术不同，此技术不需要攻击者修改数据包，甚至不需要伪造其源IP地址。这使它更容易启动。
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.
通过仔细的协议设计可以防止这种攻击。协议应尽可能避免将IP地址或主机名包含在协议有效负载中，作为后续消息应发送到的地址。相反，如果可能，应该将消息发送到协议包来自的源IP。如果这种设计不可能，则协议应包括握手，由此可以肯定地确定该IP地址或主机名处的协议实体实际上希望接收该后续消息。该握手本身需要是轻量级的（以避免成为另一个DoS攻击的来源），并防止握手响应的欺骗。
Finally, a somewhat similar attack is possible with some protocols 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.
例如，启用移动性的协议存在问题，可能允许攻击者避免进入过滤。众所周知，这样的协议很难获得正确的结果。
In general, the architectural lessons to be learnt are simple:
一般来说，要学习的建筑课程很简单：
o As far as possible, perform ingress filtering [7] [39] to prevent source address spoofing.
o 尽可能执行入口过滤[7][39]，以防止源地址欺骗。
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 避免设计能够返回比请求大小大得多的响应的协议或机制，除非执行握手以验证客户端的源地址。这样的握手需要包含一个不可预测的nonce，该nonce足够安全，以减轻协议的放大效应。
o All retransmission during initial connection setup should be performed by the client.
o 初始连接设置期间的所有重传应由客户端执行。
o Proxies should not arbitrarily relay requests to destinations chosen by a client.
o 代理不应该任意地将请求中继到客户端选择的目的地。
o Avoid signaling third-party connections. Any unavoidable third-party connections set up by a signaling protocol should incorporate lightweight validation before sending significant data.
o 避免向第三方连接发送信号。通过信令协议建立的任何不可避免的第三方连接都应该在发送重要数据之前包含轻量级验证。
A general problem with DoS defense is that it is not in principle possible to distinguish between a flash crowd and a DoS attack. Indeed, having your site taken down by a flash crowd is probably a more common experience than having it DoS-ed -- so common it has acquired its own names: being Slashdotted or Farked, after the web sites that are common sources of flash crowds. Thus, the first line of defense against DoS attacks must be to provision your service so that it can handle a foreseeable legitimate peak load. Underprovisioned sites are the easiest to take down.
拒绝服务防御的一个普遍问题是，原则上不可能区分flash群组和拒绝服务攻击。事实上，让你的网站被flash用户群删除可能比让它被删除更为常见——这种情况非常普遍，以至于它有了自己的名字：在flash用户群的常见来源网站之后，被删除或删除。因此，防御DoS攻击的第一道防线必须是提供您的服务，以便它能够处理可预见的合法峰值负载。设施不足的场地最容易拆除。
Specific strategies for DoS defense fall into two broad categories:
DoS防御的具体策略分为两大类：
1. Avoiding allowing attacks that are better than generic resource consumption.
1. 避免允许比一般资源消耗更好的攻击。
2. Minimizing the extent to which generic resource consumption attacks crowd out legitimate users.
2. 将一般资源消耗攻击排挤合法用户的程度降至最低。
In the remainder of this section, we consider specific applications of these two approaches at a variety of levels of network system architecture.
在本节的其余部分中，我们考虑这两种方法在各种层次的网络系统体系结构中的具体应用。
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 [2] [14]. All client-server protocols should probably be designed to allow such techniques to be used, but the enabling of the mechanism should normally be at the server's discretion to avoid unnecessary work under normal circumstances.
从终端系统服务器的角度来看，一个简单的目标是避免在没有与客户机完成握手以验证其地址的情况下实例化状态，并尽可能将工作和状态保持推送到客户机。有许多技术可以用来实现这一点，包括SYN cookies[2][14]。所有客户机-服务器协议可能都应设计为允许使用此类技术，但该机制的启用通常应由服务器自行决定，以避免在正常情况下进行不必要的工作。
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 [14].
1. 谜题：迫使攻击者进行一些计算，这些计算对于单个用户来说并不繁重，但总体来说成本太高[14]。
2. Reverse Turing tests: specialized puzzles that are hard for machines to do but easy for humans, thus making automated attacks hard [13].
2. 反向图灵测试：机器很难完成但人类很容易完成的特殊谜题，因此很难进行自动攻击[13]。
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.
3. 可达性测试：强制建议的客户端证明它可以在给定的IP地址接收流量。这使得追踪攻击者变得更容易。
All of these techniques have substantial limitations. Puzzles tend to discriminate against legitimate users with slow computers. In addition, the wide availability of remotely controlled compromised machines ("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.
所有这些技术都有很大的局限性。谜题往往会歧视电脑速度慢的合法用户。此外，远程控制的受损机器（“机器人”）的广泛可用性意味着攻击者拥有足够的计算能力。在自动攻击反向图灵测试方面已经做了大量的工作，从而使它们的适用性受到限制。最后，由于攻击者不需要隐藏其源地址，所以机器人程序大大削弱了可达性测试。
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 [53] 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 original source of the problem has been resolved, the router will now be able to process it correctly.
路由协议的一个目标是在过载情况下优雅地退化，并在过载源被修复后自动恢复。一些路由协议比其他路由协议更能满足这一目标。尽管RIP[53]的可扩展性不好，但如果路由器在接收RIP路由时内存不足，它可以直接丢弃路由并向其对等方发送无限度量。稍后将刷新路由，如果问题的原始来源已解决，路由器现在将能够正确处理它。
On the other hand, BGP is stateful in the sense that a peer assumes you have processed or chosen to filter any route that it sent you. There is no mechanism to refresh state in the base BGP spec, and even the later route refresh option [3] is hard to use in the presence of overload. A BGP router that cannot store a route it received has two choices: completely restart BGP or shut down one or more peerings [26]. This means that the effects of a BGP overload are rather more severe than they need to be, and so amplifies the effect of any attack.
另一方面，BGP是有状态的，因为对等方认为您已经处理或选择过滤它发送给您的任何路由。基本BGP规范中没有刷新状态的机制，即使是稍后的路由刷新选项[3]也很难在过载情况下使用。无法存储接收到的路由的BGP路由器有两种选择：完全重新启动BGP或关闭一个或多个对等网络[26]。这意味着BGP过载的影响比需要的更严重，因此会放大任何攻击的影响。
In general, few routing protocol designs actively consider the possible behaviour of routers under overload conditions; this should be an explicit part of future routing protocol designs. Although precise details should clearly be left to implementors, the protocol design needs to give them the capability to do their job properly.
一般来说，很少的路由协议设计在过载情况下主动考虑路由器的可能行为；这应该是未来路由协议设计的明确部分。虽然精确的细节应该明确地留给实现者，但协议设计需要让他们能够正确地完成工作。
Autoconfiguration mechanisms greatly ease deployment, and are increasingly necessary as the number of networked devices grows beyond what can be managed manually. However, it should be recognised that unauthenticated autoconfiguration opens up many avenues for attack. There is a clear tension between ease of configuration and security of configuration, especially because there are environments in which it is desirable for units to operate with effectively no authentication (e.g., airport hotspots). Future autoconfiguration protocols should consider the need to allow different end-systems to operate at different points in this spectrum within the same autoconfiguration framework. However, this also implies that the network elements should avoid acting for unauthenticated hosts, instead just letting them access the network more or less directly.
自动配置机制极大地简化了部署，并且随着网络设备数量的增长超过了可以手动管理的范围，自动配置机制变得越来越必要。但是，应该认识到，未经验证的自动配置打开了许多攻击途径。配置的易用性和配置的安全性之间存在明显的紧张关系，特别是因为在某些环境中，部队需要在没有身份验证的情况下有效运行（例如，机场热点）。未来的自动配置协议应该考虑在同一自动配置框架内允许不同终端系统在该频谱中的不同点操作的必要性。然而，这也意味着网元应该避免为未经验证的主机执行操作，而只是让它们或多或少直接访问网络。
In general, networks should be provisioned with private, out-of-band access to console or control ports so that such control facilities will be available in the face of a DoS attack launched against either the control or data plane of the (in-band) network. Typically, such out-of-band networks are provisioned on a separate infrastructure for exactly this purpose. Out-of-band access is a crucial capability for DoS mitigation, since many of the typical redundancy and capacity management techniques (such as prioritizing routing or network management traffic) fail during such attacks. In addition, many redundancy protocols such as VRRP [47] can fail during such attacks as they may be unable to keep adjacencies alive.
一般来说，应为网络提供对控制台或控制端口的专用带外访问，以便在面对针对（带内）网络的控制或数据平面发起的DoS攻击时，此类控制设施可用。通常，这种带外网络正是为此目的而在单独的基础设施上配置的。带外访问是DoS缓解的关键能力，因为许多典型的冗余和容量管理技术（如优先路由或网络管理流量）在此类攻击期间失败。此外，许多冗余协议（如VRRP[47]）在此类攻击期间可能会失败，因为它们可能无法保持邻接活动。
There are several default configuration settings that can also be exploited to generate several of the attacks outlined in this document. For example, some vendors may have features such as IP redirect, directed broadcast, and proxy ARP enabled by default. Similar defaults, such as publicly readable SNMP [48] communities (e.g., "public") can be used to reveal otherwise confidential information to a prospective attacker. Finally, other unauthenticated configuration management protocols such as TFTP [49] should be avoided if possible; at the very least access to TFTP configuration archives should be protected and TFTP should be filtered at administrative boundaries. Finally, since many of the password encryption techniques used by router vendors are reversible, keeping such passwords on a configuration archive (as part of a configuration file), even in the encrypted form written by the router, can lead to unauthorized access if the archive is compromised.
还可以利用几个默认配置设置来生成本文档中概述的几种攻击。例如，某些供应商可能在默认情况下启用了IP重定向、定向广播和代理ARP等功能。类似的默认设置，例如公开可读的SNMP[48]社区（例如，“public”）可用于向潜在攻击者透露机密信息。最后，如有可能，应避免使用其他未经验证的配置管理协议，如TFTP[49]；至少应该保护对TFTP配置档案的访问，并且应该在管理边界对TFTP进行过滤。最后，由于路由器供应商使用的许多密码加密技术都是可逆的，因此将此类密码保存在配置档案（作为配置文件的一部分）中，即使是以路由器编写的加密形式保存，如果档案遭到破坏，也会导致未经授权的访问。
A basic principle of designing systems to handle failure is to have redundant servers that can take over when one fails. This is equally true in the case of DoS attacks, which often focus on a given server and/or link. If service delivery points can be distributed across the network, then it becomes much harder to attack the entire service. In particular, this makes attacks on a single network link more difficult.
设计处理故障的系统的一个基本原则是拥有冗余服务器，在出现故障时可以接管。在DoS攻击的情况下也是如此，DoS攻击通常集中在给定的服务器和/或链接上。如果服务交付点可以分布在网络上，那么攻击整个服务就变得更加困难。特别是，这使得对单个网络链路的攻击更加困难。
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
通常，加密身份验证机制的成本太高，无法构成DoS预防的主要部分。但是，路由邻接太重要了，攻击者无法冒注入错误路由信息的风险，这可能会影响到更多的路由器。然后应使用其他非加密机制
used to avoid arbitrary end-systems being able to cause the router to spend CPU cycles on validating authentication data.
用于避免任意终端系统导致路由器在验证身份验证数据上花费CPU周期。
For BGP, at the very least, this implies the use of TCP MD5 [9] or IPsec authentication, combined with the GTSM [8] to prevent eBGP association with non-immediate neighbors. In the future, this will likely imply better authentication of the routing information itself.
对于BGP，这至少意味着使用TCP MD5[9]或IPsec身份验证，并结合GTSM[8]来防止eBGP与非直接邻居关联。在将来，这可能意味着路由信息本身的身份验证会更好。
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. 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.
这样做的一个缺点是，某些诊断技术（如ping连续路由器以查找延迟源）可能不再可行。理想情况下，应设计替代机制（不会为DoS开辟额外的途径）来取代这种丢失的技术。
Because a router can be considered as an end-system, it can potentially benefit from all the prevention mechanisms prescribed for end-system implementation. However, one basic distinction between a router and a host is that the former implements routing protocols and forwards data, which in turn lead to additional router-specific implementation considerations. The issues described below are meant to be illustrative and not exhaustive.
因为路由器可以被视为终端系统，所以它可能会受益于为终端系统实现规定的所有预防机制。然而，路由器和主机之间的一个基本区别是前者实现路由协议并转发数据，这反过来又导致额外的路由器特定实现考虑。下面描述的问题旨在说明问题，而不是详尽无遗。
Protocol syntax defines the formation of the protocol messages and the rules of exchanges. The questions addressed by protocol syntax checking includes, but is not limited to, the following:
协议语法定义协议消息的形成和交换规则。协议语法检查解决的问题包括但不限于以下内容：
1. Who sent the message?
1. 谁发的信息？
2. Does the content conform to the protocol format?
2. 内容是否符合协议格式？
3. Was the message sent with correct timing?
3. 消息发送的时间是否正确？
The first step in protocol syntax verification is to ensure that an incoming message was sent by a legitimate party. There are multiple ways to perform this check. One can verify the source IP address and even the MAC address of the message. Utilizing the fact that eBGP peers are normally directly connected, one can also check the TTL value in a packet and discard any BGP updates packet whose TTL is less than some maximum value (typically, max TTL - 1) [8]. Cryptographic authentication should also be used whenever available to verify that an incoming message is indeed from an expected sender. For BGP, at the very least, this implies the use of TCP MD5 [9] or IPsec authentication.
协议语法验证的第一步是确保传入消息由合法方发送。执行此检查有多种方法。可以验证消息的源IP地址，甚至MAC地址。利用eBGP对等点通常直接连接的事实，还可以检查数据包中的TTL值，并丢弃TTL小于某个最大值（通常为最大TTL-1）的任何BGP更新数据包[8]。只要可用，也应使用加密身份验证来验证传入消息是否确实来自预期的发送方。对于BGP，这至少意味着使用TCP MD5[9]或IPsec身份验证。
In addition to the sender verification, it is also important to check the syntax of a received routing message, as opposed to assuming that all messages came in a correct format. It happened in the past that routers crashed upon receiving ill-formed routing messages. Such faults will be prevented by performing rigorous syntax checking.
除了发送方验证之外，检查收到的路由消息的语法也很重要，而不是假设所有消息的格式都正确。过去，路由器在收到格式错误的路由消息时崩溃。通过执行严格的语法检查可以防止此类故障。
Protocol semantics define the meaning of the message content, the interpretation of the values, and the actions to be taken according to the content. Here is a simple example of using semantic checking. When a link failure causes a router in Autonomous System (AS) A to send a peer router B a withdrawal message for prefix P, B should make sure that any alternative path it finds to reach P does not go through A. This simple check is shown to significantly improve BGP convergence time in many cases [42].
协议语义定义消息内容的含义、值的解释以及根据内容采取的操作。下面是一个使用语义检查的简单示例。当链路故障导致自治系统（AS）a中的路由器向对等路由器B发送前缀P的退出消息时，B应确保其找到的到达P的任何替代路径不经过a。在许多情况下，此简单检查可显著提高BGP收敛时间[42]。
Another example of using semantic checking against false routing injection is described in [44]. The basic idea is to attach to the route announcement for prefix P a list of the valid origin ASes. Due to the rich connectivity in today's Internet topology, a remote AS will receive routing updates from multiple different paths and can check to see whether each update carries the identical origin AS list. Although a false origin may announce reachability to P, or alter the origin AS list, it would be difficult, if not impossible, to block the correct updates from propagating out, and thus remote ASes can detect the existence of false updates by observing the inconsistency of the received origin AS lists for P. Research studies show that the "allowed origin list" test can effectively detect the majority of falsely originated updates.
[44]中描述了针对错误路由注入使用语义检查的另一个示例。其基本思想是在前缀P的路由公告中附加一个有效源ASE的列表。由于当今互联网拓扑中的丰富连接性，远程AS将从多个不同路径接收路由更新，并可以检查每个更新是否携带相同的源AS列表。尽管虚假来源可能会宣布P的可达性，或将来源更改为列表，但如果不是不可能的话，也很难阻止正确的更新向外传播，因此远程ASE可以通过观察接收到的来源为P列表的不一致性来检测虚假更新的存在。研究表明“允许源代码列表”测试可以有效地检测大多数错误源代码的更新。
Generally speaking, verifying the validity of BGP routes can be challenging because BGP is policy driven and policies of individual ISPs are not known in most cases. But assuming that policies do not change in short time scale, in principle one could verify new updates against observed routes from the recent past, which reflect the
一般来说，验证BGP路由的有效性可能具有挑战性，因为BGP是策略驱动的，并且在大多数情况下，单个ISP的策略是未知的。但假设政策不会在短时间内改变，原则上可以根据最近观察到的路线验证新的更新，这反映了
routing policies in place. Research work is needed to explore this direction.
路由策略已到位。探索这一方向需要开展研究工作。
Note that while the above steps are all fairly simple and don't really "bulletproof" the protocol, each adds some degree of protection. As such, the combination of the above techniques can result in an effective reduction in the probability of undetected faults.
请注意，虽然上述步骤都相当简单，并且不能真正“防弹”协议，但每个步骤都增加了一定程度的保护。因此，上述技术的组合可有效降低未检测故障的概率。
There exist a number of configuration tunings that can enhance robustness of BGP operations. One example is to let BGP peers coordinate the setting of a limit on the number of prefixes that one BGP speaker will send to its peer [43]. Although such a check does not validate the prefix owned by each peer, it can prevent false announcements of large numbers of invalid routes. Had all BGP routers been configured with this simple checking earlier, several large-scale routing outages in the past could have been prevented. Note, however, that care must be taken with hard limits of this type because they can be used to mount a DoS because implementations often discard excess routes indiscriminately, thus potentially causing black-holing of correct routes.
存在许多可以增强BGP操作健壮性的配置调整。一个例子是让BGP对等方协调设置一个BGP说话者将发送给其对等方的前缀数量限制[43]。尽管这样的检查不会验证每个对等方拥有的前缀，但它可以防止大量无效路由的错误通知。如果所有的BGP路由器都在早些时候配置了这种简单的检查，那么过去几次大规模的路由中断本来是可以避免的。但是，请注意，必须注意这种类型的硬限制，因为它们可用于装载DoS，因为实现通常会不加区别地丢弃多余的路由，从而可能导致正确路由的黑洞。
Another example of useful configuration tuning is to adjust the BGP's KeepAlive and Hold Timer values to minimize BGP peering session resets. Previous measurements show that heavy traffic load, such as those caused by worms, can cause BGP KeepAlive messages to be delayed or dropped, which in turn cause BGP peering session breakdown. Such load-induced session breaks and re-establishments can lead to an excessive amount of BGP updates during the periods when stable routing is needed most.
另一个有用的配置调整示例是调整BGP的KeepAlive和Hold定时器值，以最小化BGP对等会话重置。以前的测量表明，重流量负载（如蠕虫引起的负载）会导致BGP KeepAlive消息延迟或丢弃，进而导致BGP对等会话中断。这种由负载引起的会话中断和重新建立可能会导致在最需要稳定路由的期间BGP更新过多。
In addition to the resource exhaustion problems that are generally apply to all end-systems, as described in Section 2, router implementations must also take special care in handling resource exhaustions when they occur in order to keep the router operating despite the problem. For example, under normal operations a router does not require a large cache to hold outstanding ARP requests because the replies are normally received within a few milliseconds. However, certain conditions can lead to ARP cache exhaustion, for example, during a virus attack where many packets are sent to non-existing IP addresses, thus there are no ARP replies to the requests for those addresses. Such phenomena have happened in the past and led to routers failing to forward packets.
除了通常适用于所有终端系统的资源耗尽问题外，如第2节所述，路由器实现还必须特别注意处理资源耗尽问题，以便在出现问题时保持路由器运行。例如，在正常操作下，路由器不需要大型缓存来保存未完成的ARP请求，因为应答通常在几毫秒内收到。但是，某些情况可能导致ARP缓存耗尽，例如，在病毒攻击期间，许多数据包被发送到不存在的IP地址，因此对这些地址的请求没有ARP响应。这种现象在过去曾经发生过，并导致路由器无法转发数据包。
Another example is queue management. Many high-end routers are designed so that most packets can be handled purely in specialized processors (Application-Specific Integrated Circuit (ASICs), Field Programmable Gate-Arrays (FPGAs), etc.). However, exceptional packets must be routed to a supporting general purpose CPU for handling. On some such systems, it may be possible mount a low-effort DoS attack by saturating the queues between the specialized hardware and the supporting processor.
另一个例子是队列管理。许多高端路由器的设计使得大多数数据包可以在专用处理器（专用集成电路（ASIC）、现场可编程门阵列（FPGA）等）中处理。但是，异常数据包必须路由到支持的通用CPU进行处理。在某些这样的系统上，通过使专用硬件和支持处理器之间的队列饱和，可能会发起低强度的DoS攻击。
So the attack vector on routers/network devices is a low packets-per-second (PPS) queue saturation attack on the ASIC's raw queue structure. The countermeasure here is to have multiple such queues designed in such a way that it's difficult for an attacker to arrange to fill multiple queues [45].
因此，路由器/网络设备上的攻击向量是ASIC的原始队列结构的低分组/秒（PPS）队列饱和攻击。这里的对策是设计多个这样的队列，使得攻击者很难安排填充多个队列[45]。
Any system that instantiates per-connection state should take great care to implement state-lookup mechanisms in such a way that performance cannot be controlled by the attacker. One way to achieve this is to use hash tables where the hash mechanism is keyed in such a way that the attacker cannot instantiate a large number of flows in the same hash bucket.
任何实例化每个连接状态的系统都应该非常小心地以攻击者无法控制性能的方式实现状态查找机制。实现这一点的一种方法是使用哈希表，其中哈希机制的键控方式使得攻击者无法在同一个哈希桶中实例化大量流。
Most operating systems use network interrupts to receive data from the network, which is a good solution if the host spends only a small amount of its time handling network traffic. However, this leaves the host open to livelock [33], where under heavy load the OS spends all its time handling interrupts and no time doing the work needed to handle the traffic at the application level. Server operating systems should consider using network polling at times of heavy load, rather than being interrupt-driven, and should be carefully architected so that as far as reasonably possible, traffic received by the OS is processed to completion or very cheaply discarded.
大多数操作系统使用网络中断来接收来自网络的数据，如果主机只花费少量时间处理网络流量，这是一个很好的解决方案。然而，这使得主机对livelock开放[33]，在高负载情况下，操作系统将所有时间都花在处理中断上，而没有时间做处理应用程序级流量所需的工作。服务器操作系统应该考虑在重载时使用网络轮询，而不是中断驱动，并且应该仔细地架构，以便尽可能合理地处理OS接收的流量完成或非常便宜地丢弃。
Most recent TCP implementations use fairly good random mechanisms for allocating the TCP initial sequence numbers. In general, any dynamically allocated value used purely to identify a communication session should be allocated using an unpredictable mechanism, as this increases the search space for an attacker that wishes to disrupt ongoing communications. Thus, the dynamically allocated port of the active end of a TCP connection might also be randomly allocated.
最新的TCP实现使用相当好的随机机制来分配TCP初始序列号。通常，任何纯粹用于识别通信会话的动态分配值都应使用不可预测的机制进行分配，因为这会增加希望中断正在进行的通信的攻击者的搜索空间。因此，TCP连接的活动端的动态分配端口也可能是随机分配的。
With DNS, the ID that is used to match responses with requests should also be randomly generated. However, as the ID field is only 16 bits, the protection is rather limited.
对于DNS，用于将响应与请求匹配的ID也应随机生成。然而，由于ID字段只有16位，因此保护相当有限。
Many DoS attacks are generic bandwidth consumption attacks that operate by clogging the link that connects the victim server to the Internet. Filtering these attacks at the server does no good because the traffic has already traversed the link that is the scarce resource. Such flows need to be filtered at some point closer to the attacker. Where possible, operators should filter out obviously bad traffic. In particular, they should perform ingress filtering [7].
许多DoS攻击是一般带宽消耗攻击，通过阻塞将受害者服务器连接到Internet的链接进行操作。在服务器上过滤这些攻击没有任何好处，因为流量已经通过了稀缺资源的链接。这些流需要在更靠近攻击者的某个点进行过滤。在可能的情况下，运营商应过滤掉明显的不良流量。特别是，它们应该执行入口过滤[7]。
Network operators are strongly encouraged to establish a monitoring framework to detect and log abnormal network activity. One cannot defend against an attack that one doesn't detect or understand. Such monitoring tools can be used to set a baseline of "normal" traffic, and can be used to detect aberrant flows and determine the type and source of the aberrant flows. This is extremely helpful when responding to distributed DoS attacks or a flash crowd, and should be in place prior to the event.
强烈鼓励网络运营商建立监测框架，以检测和记录异常网络活动。一个人无法抵御自己无法察觉或理解的攻击。此类监控工具可用于设置“正常”流量的基线，并可用于检测异常流量和确定异常流量的类型和来源。这在响应分布式DoS攻击或flash群组时非常有用，并且应该在事件发生之前准备好。
In this document, we have highlighted possible avenues for DoS attacks 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.
在本文件中，我们强调了对网络和联网系统进行DoS攻击的可能途径，目的是鼓励协议设计者和网络工程师进行更稳健的设计。我们讨论了降低攻击有效性的部分解决方案，并强调了攻击者如何利用部分解决方案实施替代攻击。
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 [24] [39] [25].
我们主要关注协议和网络架构问题，但网络和服务运营商可以做很多事情来减轻威胁。有关网络运营商的进一步建议和信息，请参见[24][39][25]。
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.
我们希望本文档将引发讨论，从而形成架构解决方案，降低所有Internet系统对拒绝服务攻击的可接受性。
This entire document is about security.
整个文档都是关于安全性的。
We are very grateful to Vern Paxson, Paul Vixie, Rob Thomas, Dug Song, George Jones, Jari Arkko, Geoff Huston, and Barry Greene for their constructive comments on earlier versions of this document.
我们非常感谢Vern Paxson、Paul Vixie、Rob Thomas、Dag Song、George Jones、Jari Arkko、Geoff Huston和Barry Greene对本文件早期版本的建设性意见。
[1] J. Abley, "Hierarchical Anycast for Global Service Distribution", http://www.isc.org/index.pl?/pubs/tn/ index.pl?tn=isc-tn-2003-1.txt.
[1] J.Abley，“全球服务分发的分层选播”，http://www.isc.org/index.pl?/pubs/tn/ index.pl？tn=isc-tn-2003-1.txt。
[2] D.J. Bernstein, "SYN Cookies", http://cr.yp.to/syncookies.html.
[2] D.J.Bernstein，“SYN Cookies”，http://cr.yp.to/syncookies.html.
[3] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000.
[3] 陈，E，“BGP-4的路由刷新能力”，RFC 2918，2000年9月。
[4] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[4] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[5] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[6] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[6] Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 4601，2006年8月。
[7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[7] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[8] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[8] Gill，V.，Heasley，J.，和D.Meyer，“广义TTL安全机制（GTSM）”，RFC 3682，2004年2月。
[9] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[9] Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[10] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[10] Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[11] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[11] Villamizar，C.，Chandra，R.，和R.Govindan，“BGP路线襟翼阻尼”，RFC 2439，1998年11月。
[12] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[12] Waitzman，D.，Partridge，C.和S.Deering，“距离向量多播路由协议”，RFC 1075，1988年11月。
[13] L. von Ahn, M. Blum, N. Hopper, and J. Langford. CAPTCHA: Using hard AI problems for security. In Proceedings of Eurocrypt, 2003.
[13] L.冯·安、M.布鲁姆、N.霍珀和J.朗福德。验证码：使用人工智能硬问题进行安全性验证。《欧洲密码会议录》，2003年。
[14] 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.
[14] T.Aura，P.Nikander，J.Leiwo，“具有客户端谜题的拒绝服务认证”，载于B.Christianson，B.Crispo和M.Roe，编辑，第八届安全协议国际研讨会论文集，计算机科学讲稿，英国剑桥，2000年4月。
[15] 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.
[15] J.Bellardo，S.Savage，“802.11拒绝服务攻击：真正的漏洞和实际解决方案”，USENIX安全研讨会论文集，华盛顿特区，2003年8月。
[16] S.M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April 1989.
[16] S.M.Bellovin，“TCP/IP协议套件中的安全问题”，《计算机通信评论》，第19卷，第2期，第32-48页，1989年4月。
[17] CCAIS/RNP Alertas do Cais ALR-19112002a, "Vulnerability in the sending requests control of Bind versions 4 and 8 allows DNS spoofing", http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html.
[17] CCAIS/RNP Alertas do Cais ALR-19112002a，“绑定版本4和8的发送请求控制中存在允许DNS欺骗的漏洞”，http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html.
[18] CERT Advisory CA-1996-01, "UDP Port Denial-of-Service Attack", Feb 1996.
[18] CERT咨询CA-1996-01，“UDP端口拒绝服务攻击”，1996年2月。
[19] CERT Advisory CA-1996-21, "TCP SYN Flooding and IP Spoofing Attacks", Sept 1996.
[19] CERT咨询CA-1996-21，“TCP SYN洪泛和IP欺骗攻击”，1996年9月。
[20] CERT Advisory CA-2001-09, "Statistical Weaknesses in TCP/IP Initial Sequence Numbers", May 2001.
[20] CERT咨询CA-2001-09，“TCP/IP初始序列号的统计缺陷”，2001年5月。
[21] CERT Advisory CA-1996-26, "Denial-of-Service Attack via ping", Dec 1996.
[21] CERT咨询CA-1996-26，“通过ping进行的拒绝服务攻击”，1996年12月。
[22] CERT Advisory CA-1998-01, "Smurf IP Denial-of-Service Attacks", http://www.cert.org/advisories/CA-1998-01.html, Jan 1998.
[22] 证书咨询CA-1998-01，“Smurf IP拒绝服务攻击”，http://www.cert.org/advisories/CA-1998-01.html，1998年1月。
[23] CERT Incident Note IN-2000-05, "'mstream' Distributed Denial of Service Tool", May 2000.
[23] CERT事件说明IN-2000-05，“mstream”分布式拒绝服务工具，2000年5月。
[24] CERT/CC - "Managing the Threat of Denial of Service Attacks", http://www.cert.org/archive/pdf/Managing_DoS.pdf.
[24] CERT/CC - "Managing the Threat of Denial of Service Attacks", http://www.cert.org/archive/pdf/Managing_DoS.pdf.translate error, please retry
[25] CERT/CC - "Trends in Denial of Service Attack Technology", http://www.cert.org/archive/pdf/DoS_trends.pdf.
[25] CERT/CC—“拒绝服务攻击技术的发展趋势”，http://www.cert.org/archive/pdf/DoS_trends.pdf.
[26] 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.
[26] D.F.Chang，R.Govindan，J.Heidemann，“路由器对大路由表负载响应的实证研究”，第二届互联网测量研讨会论文集（IMW 2002），2002年。
[27] Cisco Systems, "Configuring the BGP Maximum-Prefix Feature", Cisco Document ID: 25160, http://www.cisco.com/warp/public/459/bgp-maximum-prefix.html.
[27] Cisco Systems，“配置BGP最大前缀功能”，Cisco文档ID:25160，http://www.cisco.com/warp/public/459/bgp-maximum-prefix.html.
[28] 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.
[28] Scott A Crosby和Dan S Wallach，“通过算法复杂性攻击的拒绝服务”，USENIX安全研讨会论文集，华盛顿特区，2003年8月。
[29] Laurent Joncheray, "Simple Active Attack Against TCP", 5th USENIX Security Symposium, 1995.
[29] Laurent Joncheray，“针对TCP的简单主动攻击”，第五届USENIX安全研讨会，1995年。
[30] M. Lough, "A Taxonomy of Computer Attacks with Applications to Wireless", PhD thesis, Virginia Polytechnic Institute, April 2001.
[30] M.Lough，“应用于无线的计算机攻击分类”，弗吉尼亚理工学院博士论文，2001年4月。
[31] Z. Mao, R. Govindan, G. Varghese, R. Katz, "Route Flap Dampening Exacerbates Internet Routing Convergence", Proceedings of ACM SIGCOMM, 2002.
[31] 毛志强，R.戈文丹，G.瓦盖斯，R.卡茨，“路由抖动抑制加剧了互联网路由收敛”，ACM SIGCOMM会议录，2002年。
[32] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[32] Fenner，B.，Ed.，和D.Meyer，Ed.，“多播源发现协议（MSDP）”，RFC3618，2003年10月。
[33] 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.
[33] 莫格尔，KK。罗摩克里希南，“在中断驱动内核中消除接收活锁”，《计算机系统上的ACM事务》，第15卷，第3期，第217-252页，1997年。
[34] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, http://www.cansecwest.com/archives.html.
[34] Watson，P.，“在窗口中滑动：TCP重置攻击”，在2004年CanSecWest上的演讲，http://www.cansecwest.com/archives.html.
[35] V. Paxson, "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", Computer Communication Review 31(3), July 2001.
[35] V.Paxson，“使用反射器进行分布式拒绝服务攻击的分析”，《计算机通信评论》31（3），2001年7月。
[36] Joe Stewart, "DNS Cache Poisoning - The Next Generation", Jan 27 2003, http://www.lurhq.com/dnscache.pdf.
[36] Joe Stewart，“DNS缓存中毒-下一代”，2003年1月27日，http://www.lurhq.com/dnscache.pdf.
[37] Stewart, R., Ed., and M. Dalal, Ed., "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, June 2006.
[37] Stewart，R.，Ed.，和M.Dalal，Ed.，“提高TCP对窗口盲攻击的鲁棒性”，进展中的工作，2006年6月。
[38] P. Vixie, G. Sneeringer, M. Schleifer, "Events of 21-Oct-2002", http://f.root-servers.org/october21.txt.
[38] P.Vixie，G.Sneeringer，M.Schleifer，“2002年10月21日事件”，http://f.root-servers.org/october21.txt.
[39] P. Vixie, "Securing the Edge", http://www.icann.org/committees/security/sac004.txt.
[39] P.Vixie，“保护边缘”，http://www.icann.org/committees/security/sac004.txt.
[40] D. Wessels, "Running An Authoritative-Only BIND Nameserver", http://www.isc.org/index.pl?/pubs/tn/ index.pl?tn=isc-tn-2002-2.txt.
[40] D.Wessels，“运行仅限权威的绑定名称服务器”，http://www.isc.org/index.pl?/pubs/tn/ index.pl？tn=isc-tn-2002-2.txt。
[41] M. Zalewski, "Strange Attractors and TCP/IP Sequence Number Analysis", http://www.bindview.com/Services/Razor/Papers/2001/tcpseq.cfm.
[41] M.Zalewski，“奇怪吸引子和TCP/IP序列号分析”，http://www.bindview.com/Services/Razor/Papers/2001/tcpseq.cfm.
[42] D. Pei, X. Zhao, L. Wang, D. Massey, A. Mankin, F. S. Wu, and L. Zhang. Improving BGP Conver-gence Through Assertions Approach. In Proc. of IEEE INFOCOM, June 2002.
[42] 贝聿铭、赵晓阳、王磊、梅西、曼金、吴福生和张磊。通过断言方法提高BGP的收敛性。在过程中。IEEE信息网，2002年6月。
[43] Chavali, S., Radoaca, V., Miri, M., Fang, L., and S. Hares, "Peer Prefix Limits Exchange in BGP", Work in Progress, April 2004.
[43] Chavali，S.，Radoaca，V.，Miri，M.，Fang，L.，和S.Hares，“对等前缀限制BGP中的交换”，正在进行的工作，2004年4月。
[44] X. Zhao, D. Massey, A. Mankin, S.F. Wu, D. Pei, L. Wang, L. Zhang, "BGP Multiple Origin AS (MOAS) Conflicts", http://nanog.org/mtg-0110/lixia.html, 2001.
[44] X.Zhao，D.Massey，A.Mankin，S.F.Wu，D.Pei，L.Wang，L.Zhang，“BGP多源AS（MOAS）冲突”，http://nanog.org/mtg-0110/lixia.html, 2001.
[45] Cisco Systems, "Building Security Into the Hardware", ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/ Paris-Sept-04/SE14-BUILDING-SECURITY-INTO-THE-HARDWARE-c1_8_30_04.pdf, 2004.
[45] Cisco Systems，“在硬件中构建安全性”，ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/ 巴黎9月4日/SE14-BUILDING-SECURITY-INTO-THE-HARDWARE-c1_8_30_04.pdf，2004年。
[46] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[46] Ilonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 42512006年1月。
[47] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.
[47] Hinden，R.，“虚拟路由器冗余协议（VRRP）”，RFC 3768，2004年4月。
[48] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[48] Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[49] Malkin, G. and A. Harkin, "TFTP Timeout Interval and Transfer Size Options", RFC 2349, May 1998.
[49] Malkin，G.和A.Harkin，“TFTP超时间隔和传输大小选项”，RFC 2349，1998年5月。
[50] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[50] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[51] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[51] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[52] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[52] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[53] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[53] Hedrick，C.，“路由信息协议”，RFC 1058，1988年6月。
o Bernard Aboba
o 伯纳德·阿博巴
o Loa Andersson
o 安徒生酒店
o Brian Carpenter
o 布莱恩·卡彭特
o Leslie Daigle
o 莱斯利·戴格尔
o Elwyn Davies
o 埃尔温·戴维斯
o Kevin Fall
o 凯文·法尔
o Olaf Kolkman
o 奥拉夫·科尔克曼
o Kurtis Lindvist
o 库蒂斯·林德维斯特
o David Meyer
o 大卫·梅耶尔
o David Oran
o 大卫·奥兰
o Eric Rescorla
o 埃里克·雷斯科拉
o Dave Thaler
o 戴夫·泰勒
o Lixia Zhang
o 张丽霞
Authors' Addresses
作者地址
Mark J. Handley, Ed. UCL Gower Street London WC1E 6BT UK
马克·J·汉德利，英国伦敦大学学院高尔街WC1E 6BT
EMail: M.Handley@cs.ucl.ac.uk
EMail: M.Handley@cs.ucl.ac.uk
Eric Rescorla, Ed. Network Resonance 2483 E. Bayshore #212 Palo Alto 94303 USA
Eric Rescorla，Ed.网络共振2483 E.Bayshore#212 Palo Alto 94303美国
EMail: ekr@networkresonance.com
EMail: ekr@networkresonance.com
Internet Architecture Board IAB
互联网架构委员会
EMail: iab@ietf.org
EMail: iab@ietf.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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, THE IETF TRUST, 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。