Network Working Group J. Touch
Request for Comments: 4953 USC/ISI
Category: Informational July 2007
Network Working Group J. Touch
Request for Comments: 4953 USC/ISI
Category: Informational July 2007
Defending TCP Against Spoofing Attacks
保护TCP免受欺骗攻击
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 (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections.
最近对核心互联网基础设施潜在攻击的分析表明，TCP连接更容易受到虚假重置（RST）的攻击，这些重置是用伪造的IP源地址发送的（欺骗）。TCP始终容易受到此类RST欺骗攻击的影响，这些攻击通过检查RST序列号是否在当前接收窗口内以及通过混淆TCP端点和端口号来间接保护。对于通常位于可预测端口对之上的已知端点对，例如BGP或web服务器与已知大规模缓存之间的端点对，连接的路径带宽延迟乘积的增加已经充分增加了接收窗口空间，路径外第三方可以强行生成可行的RST序列号。攻击的易感性随着带宽的平方而增加，因此对于最近的高速网络来说是一个严重的漏洞。本文件针对这一漏洞，讨论了在传输级别提出的解决方案及其固有的挑战，以及现有的网络级别解决方案及其部署的可行性。本文档重点介绍因欺骗TCP段而导致的漏洞，并包括对TCP连接上的相关ICMP欺骗攻击的讨论。
Table of Contents
目录
1. Introduction ....................................................3
2. Background ......................................................4
2.1. Review of TCP Windows ......................................5
2.2. Recent BGP Attacks Using TCP RSTs ..........................6
2.3. TCP RST Vulnerability ......................................6
2.4. What Changed - the Ever-Opening Advertised Receive Window ..7
3. Proposed Solutions and Mitigations .............................10
3.1. Transport Layer Solutions .................................10
3.1.1. TCP MD5 Authentication .............................11
3.1.2. TCP RST Window Attenuation .........................11
3.1.3. TCP Timestamp Authentication .......................12
3.1.4. Other TCP Cookies ..................................13
3.1.5. Other TCP Considerations ...........................13
3.1.6. Other Transport Protocol Solutions .................14
3.2. Network Layer (IP) Solutions ..............................14
3.2.1. Address Filtering ..................................15
3.2.2. IPsec ..............................................16
4. ICMP ...........................................................17
5. Issues .........................................................18
5.1. Transport Layer (e.g., TCP) ...............................18
5.2. Network Layer (IP) ........................................19
5.3. Application Layer .........................................21
5.4. Link Layer ................................................21
5.5. Issues Discussion .........................................21
6. Security Considerations ........................................22
7. Conclusions ....................................................23
8. Acknowledgments ................................................23
9. Informative References .........................................24
1. Introduction ....................................................3
2. Background ......................................................4
2.1. Review of TCP Windows ......................................5
2.2. Recent BGP Attacks Using TCP RSTs ..........................6
2.3. TCP RST Vulnerability ......................................6
2.4. What Changed - the Ever-Opening Advertised Receive Window ..7
3. Proposed Solutions and Mitigations .............................10
3.1. Transport Layer Solutions .................................10
3.1.1. TCP MD5 Authentication .............................11
3.1.2. TCP RST Window Attenuation .........................11
3.1.3. TCP Timestamp Authentication .......................12
3.1.4. Other TCP Cookies ..................................13
3.1.5. Other TCP Considerations ...........................13
3.1.6. Other Transport Protocol Solutions .................14
3.2. Network Layer (IP) Solutions ..............................14
3.2.1. Address Filtering ..................................15
3.2.2. IPsec ..............................................16
4. ICMP ...........................................................17
5. Issues .........................................................18
5.1. Transport Layer (e.g., TCP) ...............................18
5.2. Network Layer (IP) ........................................19
5.3. Application Layer .........................................21
5.4. Link Layer ................................................21
5.5. Issues Discussion .........................................21
6. Security Considerations ........................................22
7. Conclusions ....................................................23
8. Acknowledgments ................................................23
9. Informative References .........................................24
Analysis of the Internet infrastructure has recently demonstrated a new version of a vulnerability in BGP connections between core routers using an attack based on RST spoofing from off-path attackers [9][10][48]. The attack itself is not new, having been documented nearly six years earlier [20]. Such connections, typically using TCP, can be susceptible to off-path third-party reset (RST) segments with forged source addresses (spoofed), which terminate the TCP connection. BGP routers react to a terminated TCP connection in various ways, which can amplify the impact of an attack, ranging from restarting the connection to deciding that the other router is unreachable and thus flushing the BGP routes [37]. This sort of attack affects other protocols besides BGP, involving any long-lived connection between well-known endpoints. The impact on the Internet infrastructure can be substantial (especially for the BGP case), and warrants immediate attention.
对互联网基础设施的分析最近表明，核心路由器之间的BGP连接中存在一个新版本的漏洞，该漏洞使用了一种基于RST欺骗的攻击，该攻击来自非路径攻击者[9][10][48]。这次袭击本身并不是什么新鲜事，早在六年前就有记录[20]。此类连接（通常使用TCP）容易受到具有伪造源地址（伪造）的非路径第三方重置（RST）段的影响，从而终止TCP连接。BGP路由器以各种方式对终止的TCP连接作出反应，这会放大攻击的影响，从重新启动连接到确定无法访问其他路由器，从而刷新BGP路由[37]。这种攻击会影响除BGP之外的其他协议，包括已知端点之间的任何长寿命连接。对互联网基础设施的影响可能是巨大的（尤其是BGP案件），需要立即予以关注。
TCP, like many other protocols, can be susceptible to these off-path third-party spoofing attacks. Such attacks rely on the increase of commodity platforms supporting public access to previously privileged resources, such as system-level (i.e., root) access. Given such access, it is trivial for anyone to generate a packet with any header desired.
与许多其他协议一样，TCP也容易受到这些非路径第三方欺骗攻击的影响。此类攻击依赖于支持公众访问以前享有特权的资源（如系统级（即根）访问）的商品平台的增加。考虑到这种访问，任何人生成具有任何所需报头的数据包都是微不足道的。
This, coupled with the lack of sufficient address filtering to drop such spoofed traffic, can increase the potential for off-path third-party spoofing attacks [9][10][48]. Proposed solutions include the deployment of existing Internet network and transport security as well as modifications to transport protocols that reduce its vulnerability to generated attacks [13][15][20][36][46].
再加上缺乏足够的地址过滤来丢弃此类欺骗流量，可能会增加路径外第三方欺骗攻击的可能性[9][10][48]。建议的解决方案包括部署现有的互联网网络和传输安全，以及修改传输协议，以降低其对生成的攻击的脆弱性[13][15][20][36][46]。
One way to defeat spoofing is to validate the segments of a connection, either at the transport level or the network level. TCP with MD5 extensions provides this authentication at the transport level, and IPsec provides authentication at the network level [20][24][27]. In both cases, their deployment overhead may be prohibitive, e.g., it may not be feasible for public services, such as web servers, to be configured with the appropriate certificate authorities of large numbers of peers (for IPsec using the Internet Key Exchange Protocol (IKE)), or shared secrets (for IPsec in shared-secret mode, or TCP/MD5), because many clients may need to be configured rapidly without external assistance. Services located on public web servers connecting to large-scale caches or BGP with larger numbers of peers can fall into this category.
击败欺骗的一种方法是在传输级别或网络级别验证连接段。带有MD5扩展的TCP在传输级别提供此身份验证，IPsec在网络级别提供身份验证[20][24][27]。在这两种情况下，它们的部署开销可能是禁止性的，例如，公共服务（如web服务器）可能无法配置大量对等方的适当证书颁发机构（对于使用Internet密钥交换协议（IKE）的IPsec）或共享机密（对于共享机密模式的IPsec，或TCP/MD5），因为许多客户端可能需要在没有外部帮助的情况下快速配置。位于公共web服务器上、连接到大规模缓存或具有大量对等方的BGP的服务可以属于此类别。
The remainder of this document outlines the recent attack scenario in detail and describes and compares a variety of solutions, including existing solutions based on TCP/MD5 and IPsec, as well as recently proposed solutions, including modifications to TCP's RST processing [36], modifications to TCP's timestamp processing [34], and modifications to IPsec and TCP/MD5 keying [45]. This document focuses on spoofing of TCP segments, although a discussion of related spoofing of ICMP packets based on spoofed TCP contents is also discussed.
本文档的其余部分详细概述了最近的攻击场景，并描述和比较了各种解决方案，包括基于TCP/MD5和IPsec的现有解决方案，以及最近提出的解决方案，包括对TCP的RST处理的修改[36]，对TCP的时间戳处理的修改[34]，以及对IPsec和TCP/MD5密钥的修改[45]。本文主要讨论TCP段的欺骗，但也讨论了基于欺骗TCP内容的ICMP数据包的相关欺骗。
Note that the description of these attacks is not new; attacks using RSTs on BGP have been known since 1998, and were the reason for the development of TCP/MD5 [20]. The recent attack scenario was first documented by Convery at a NANOG (North American Network Operators' Group) meeting in 2003, but that analysis assumed the entire sequence space (2^32 packets) needed to be covered for an attack to succeed [10]. Watson's more detailed analysis discovered that a single packet anywhere in the current window could succeed at an attack [48]. This document adds the observation that susceptibility to attack is directly proportional to the square of bandwidth, due to the coupling between the linear increase in receive window size and linear increase in rate of a potential attack, as well as comparing the variety of more recent proposals, including modifications to TCP, use of IPsec, and use of TCP/MD5 to resist such attacks.
请注意，对这些攻击的描述并不新鲜；自1998年以来，人们就知道在BGP上使用RST进行攻击，这也是TCP/MD5发展的原因[20]。Convery在2003年的NANOG（北美网络运营商小组）会议上首次记录了最近的攻击场景，但该分析假设攻击需要覆盖整个序列空间（2^32个数据包）才能成功[10]。Watson更详细的分析发现，当前窗口中任何位置的单个数据包都可能在攻击中成功[48]。本文件还指出，由于接收窗口大小的线性增加和潜在攻击率的线性增加之间的耦合，以及比较各种最新方案，包括对TCP的修改、IPsec的使用、，并使用TCP/MD5来抵御此类攻击。
The recent analysis of potential attacks on BGP has again raised the issue of TCP's vulnerability to off-path third-party spoofing attacks [9][10][48]. A variety of such attacks have been known for several years, including sending RSTs, SYNs, and even ACKs in an attempt to affect an existing connection or to load down servers. These attacks often combine external knowledge (e.g., to indicate the IP addresses to attack, the destination port number, and sometimes the Initial Sequence Number (ISN)) with brute-force capabilities enabled by modern computers and network bandwidths (e.g., to scan all source ports or an entire window space). Overall, such attacks are countered by the use of some form of authentication at the network (e.g., IPsec), transport (e.g., SYN cookies, TCP/MD5), or other layers. TCP already includes a weak form of such authentication in its check of segment sequence numbers against the current receiver window. Increases in the bandwidth-delay product for certain long connections have sufficiently weakened this type of weak authentication to make reliance on it inadvisable.
最近对BGP潜在攻击的分析再次提出了TCP易受非路径第三方欺骗攻击的问题[9][10][48]。多年来，人们已经知道了各种此类攻击，包括发送RST、SYN，甚至ACK，试图影响现有连接或加载服务器。这些攻击通常将外部知识（例如，指示要攻击的IP地址、目标端口号，有时还包括初始序列号（ISN））与现代计算机和网络带宽启用的暴力能力（例如，扫描所有源端口或整个窗口空间）相结合。总的来说，通过在网络（如IPsec）、传输（如SYN Cookie、TCP/MD5）或其他层使用某种形式的身份验证来反击此类攻击。TCP在根据当前接收器窗口检查段序列号时已经包含了这种弱形式的身份验证。某些长连接的带宽延迟乘积的增加已经充分削弱了这种弱身份验证类型，使依赖它变得不可取。
Before proceeding, it is useful to review the terminology and components of TCP's windowing algorithm. TCP connections have three kinds of windows [1][35]:
在继续之前，回顾一下TCP窗口算法的术语和组件是很有用的。TCP连接有三种类型的窗口[1][35]：
o Send window (SND.WND): the latest send window size.
o 发送窗口（SND.WND）：最新的发送窗口大小。
o Receive window (RCV.WND): the latest advertised receive window size.
o 接收窗口（RCV.WND）：最新公布的接收窗口大小。
o Congestion window (CWND): the window determined by congestion feedback that limits how much of RCV.WND can be in-flight in a round-trip time.
o 拥塞窗口（CWND）：由拥塞反馈确定的窗口，限制在往返时间内RCV.WND的飞行量。
For TCP connections in most modern implementations, SND.WND and RCV.WND are the size of the corresponding send and receive socket buffers, and are configurable using socket buffer resizing commands.
对于大多数现代实现中的TCP连接，SND.WND和RCV.WND是相应的发送和接收套接字缓冲区的大小，可以使用套接字缓冲区大小调整命令进行配置。
CWND determines how much data can be in transit in a round-trip time, SND.WND determines how much data the sender is willing to store on its side for possible retransmission due to loss, and RCV.WND determines the ability of the receiver to accommodate that loss and reorder received packets. CWND never grows beyond RCV.WND.
CWND确定在往返时间内可以传输多少数据，SND.WND确定发送方愿意在其一侧存储多少数据以备由于丢失而可能的重新传输，RCV.WND确定接收方适应该丢失和重新排列接收到的数据包的能力。CWND永远不会超过RCV.WND。
High bandwidth-delay product networks need CWND to be sufficiently large to accommodate as much data as can be in transit in a round trip time; otherwise, their performance will suffer. As a result, it is recommended that users and various automatic programs increase RCV.WND to at least the size of bandwidth*delay (the bandwidth-delay product) [23][38].
高带宽延迟产品网络需要CWND足够大，以容纳往返时间内传输的尽可能多的数据；否则，他们的表现将受到影响。因此，建议用户和各种自动程序将RCV.WND至少增加到带宽*延迟（带宽延迟乘积）[23][38]的大小。
As the bandwidth-delay product of the network increases, however, such increases in the advertised receive window can cause increased susceptibility to spoofing attacks, as the remainder of this document shows. This assumes, however, that the receive window size (e.g., via increased receive socket buffer configuration) is increased with the increased bandwidth-delay product; if not, then connection performance will degrade, but susceptibility to spoofing attacks will increase only linearly (with the rate at which the attacker can send spoofed packets), not as the square of the bandwidth. Note that either increase depends on the receive window itself, and is independent of the congestion state or amount of data transmitted.
然而，随着网络带宽延迟乘积的增加，广告接收窗口的这种增加可能会导致欺骗攻击的易感性增加，如本文档其余部分所示。然而，这假设接收窗口大小（例如，通过增加的接收套接字缓冲配置）随着带宽延迟乘积的增加而增加；如果不是，则连接性能将降低，但对欺骗攻击的敏感性将仅线性增加（攻击者可以发送欺骗数据包的速率），而不是带宽的平方。请注意，这两种增加都取决于接收窗口本身，并且与拥塞状态或传输的数据量无关。
BGP represents a particular vulnerability to spoofing attacks because it uses TCP connectivity to infer routability, so losing a TCP connection with a BGP peer can result in the flushing of routes to that peer [37].
BGP是一种特殊的易受欺骗攻击的漏洞，因为它使用TCP连接来推断可路由性，因此失去与BGP对等方的TCP连接可能会导致刷新到该对等方的路由[37]。
Until six years ago, such connections were assumed difficult to attack because they were described by a few comparatively obscure parameters [20]. Most TCP connections are protected by multiple levels of obfuscation except at the endpoints of the connection:
直到六年前，人们还认为这种连接很难被攻击，因为它们是由一些相对模糊的参数描述的[20]。除连接的端点外，大多数TCP连接都受到多级模糊处理的保护：
o Both endpoint addresses are usually not well-known; although server addresses are advertised, clients are somewhat anonymous.
o 两个端点地址通常都不为人所知；虽然公布了服务器地址，但客户机在某种程度上是匿名的。
o Both port numbers are usually not well-known; the server's is usually advertised (representing the service), but the client's is typically sufficiently unpredictable to an off-path third-party.
o 两个端口号通常都不为人所知；服务器的通常是广告的（代表服务），但是客户端的通常对于非路径第三方来说是不可预测的。
o Valid sequence number space is not well-known.
o 有效的序列号空间不是众所周知的。
o Connections are relatively short-lived and valid sequence space changes, so any attempt to guess (e.g., by external knowledge or brute force) the above information is unlikely to be useful.
o 连接是相对短暂且有效的序列空间变化，因此任何猜测（例如，通过外部知识或暴力）上述信息的尝试都不太可能有用。
BGP represents an exception to the above criteria (though not the only case). Both endpoints can be well-known, or guessed using hints from part of an AS path. The destination port is typically fixed to indicate the BGP service. The source port used by a BGP router is sometimes fixed and advertised to enable firewall configuration; even when not fixed, there are only approximately 65,000 valid source ports, which thus may be exhaustively attacked. Connections are long- lived, and, as noted before, some BGP implementations interpret successive TCP connection failures as routing failures, discarding the corresponding routing information. In addition, the valid sequence number space once thought to provide some protection has been significantly weakened by increasing advertised receive window sizes.
BGP代表上述标准的例外情况（尽管不是唯一的情况）。这两个端点都可以是已知的，也可以使用AS路径部分的提示进行猜测。目标端口通常是固定的，以指示BGP服务。BGP路由器使用的源端口有时是固定的，并公布以启用防火墙配置；即使未修复，也只有大约65000个有效源端口，因此可能会受到彻底的攻击。连接是长期存在的，如前所述，一些BGP实现将连续的TCP连接故障解释为路由故障，丢弃相应的路由信息。此外，通过增加广告接收窗口的大小，一度被认为提供某种保护的有效序列号空间已被显著削弱。
TCP has a known vulnerability to third-party spoofed segments. SYN flooding consumes server resources in half-open connections, affecting the server's ability to open new connections [4][11]. ACK spoofing can cause connections to transmit too much data too quickly, creating network congestion and segment loss, causing connections to slow to a crawl. In the most recent attacks on BGP, RSTs cause connections to be dropped. As noted earlier, some BGP
TCP存在已知的针对第三方欺骗段的漏洞。SYN泛洪会在半开放连接中消耗服务器资源，影响服务器打开新连接的能力[4][11]。ACK欺骗会导致连接传输太多数据太快，造成网络拥塞和网段丢失，导致连接速度减慢到爬行状态。在最近对BGP的攻击中，RST导致连接断开。如前所述，一些BGP
implementations interpret TCP connection termination, or a series of such failures, as a network failure [37]. This causes routers to drop the BGP routing information already exchanged, in addition to inhibiting their ongoing exchanges, thus amplifying the impact of the attack. The result can affect routing paths throughout the Internet.
实现将TCP连接终止或一系列此类故障解释为网络故障[37]。这会导致路由器丢弃已经交换的BGP路由信息，并抑制它们正在进行的交换，从而放大攻击的影响。结果可能会影响整个Internet的路由路径。
The dangerous effects of RSTs on TCP have been known for many years, even when used by the legitimate endpoints of a connection. TCP RSTs cause the receiver to drop all connection state; because the source is not required to maintain a TIME_WAIT state, such a RST can cause premature reuse of address/port pairs, potentially allowing segments from a previous connection to contaminate the data of a new connection, known as TIME_WAIT assassination [8]. In this case, assassination occurs inadvertently as the result of duplicate segments from a legitimate source, and can be avoided by blocking RST processing while in TIME_WAIT. However, assassination can be useful to deliberately reduce the state held at servers; this requires that the source of the RSTs go into TIME_WAIT state to avoid such hazards, and that RSTs are not blocked in the TIME_WAIT state [12].
RST对TCP的危险影响已经知道很多年了，即使是在连接的合法端点使用RST时也是如此。TCP RST导致接收器放弃所有连接状态；因为源不需要保持时间等待状态，这样的RST可能会导致地址/端口对的过早重用，可能会允许来自以前连接的段污染新连接的数据，称为时间等待刺杀[8]。在这种情况下，由于来自合法源的重复段而无意中发生刺杀，并且可以通过在TIME_WAIT期间阻塞RST处理来避免刺杀。然而，暗杀有助于故意减少服务器上的状态；这要求RST的源进入TIME_WAIT状态以避免此类危险，并且RST在TIME_WAIT状态下不被阻塞[12]。
Firewalls and load balancers, so-called 'middleboxes', sometimes emit RSTs on behalf of transited connections to optimize server performance, as noted in RFC 3360 [14]. This is effectively an on-path RST attack in which the RSTs are sent for benign or beneficial intent. There are numerous hazards with such use of RSTs, outlined in that RFC.
防火墙和负载平衡器，即所谓的“中间盒”，有时会代表传输连接发出RST以优化服务器性能，如RFC 3360[14]中所述。这实际上是一种路径上RST攻击，其中RST是出于善意或有益的目的而发送的。该RFC中概述了RST的使用存在许多危险。
RSTs represent a hazard to TCP, especially when completely unvalidated. Fortunately, there are a number of obfuscation mechanisms that make it difficult for off-path third parties to forge (spoof) valid RSTs, as noted earlier. We have already shown it is easy to learn both endpoint addresses and ports for some protocols, notably BGP. The final obfuscation is the segment sequence number.
RST会对TCP造成危害，尤其是在完全未经验证的情况下。幸运的是，如前所述，有许多混淆机制使得非路径第三方难以伪造（欺骗）有效的RST。我们已经展示了了解某些协议的端点地址和端口很容易，尤其是BGP。最后的混淆是段序列号。
TCP segments include a sequence number, which enables out-of-order receiver processing as well as duplicate detection. The sequence number space is also used to manage congestion, and indicates the index of the next byte to be transmitted or received. For RSTs, this is relevant because legitimate RSTs use the next sequence number in the transmitter window, and the receiver checks that incoming RSTs have a sequence number in the expected receive window. Such processing is intended to eliminate duplicate segments (somewhat moot for RSTs, though), and to drop RSTs that were part of previous connections.
TCP段包括一个序列号，该序列号支持无序接收器处理以及重复检测。序列号空间还用于管理拥塞，并指示要发送或接收的下一个字节的索引。对于RST，这是相关的，因为合法RST使用发送器窗口中的下一个序列号，并且接收器检查传入RST在预期接收窗口中是否具有序列号。这种处理的目的是消除重复的段（不过对于RST来说有些毫无意义），并删除以前连接中的RST。
TCP uses two window mechanisms, a primary mechanism for reordering and congestion control (which uses a space of 32 bits), and a secondary mechanism that scales this window [23][35]. The valid advertised receive window is a fraction, not to exceed approximately half, of this space, or ~2 billion (2 * 10^9, i.e., 2E9 or 2 U.S. billion). Under typical configurations, the majority of TCP connections open to a very small fraction of this space, e.g., 10,000-60,000(approximately 5-100 segments). This is because the advertised receive window typically matches the receive socket buffer size. It is recommended that this buffer be tuned to match the needs of the connection, either manually or by automatic external means [38].
TCP使用两种窗口机制，一种主要机制用于重新排序和拥塞控制（使用32位的空间），另一种次要机制用于扩展此窗口[23][35]。有效的广告接收窗口是该空间的一小部分，不超过大约一半，或约20亿（2*10^9，即2E9或20亿美元）。在典型配置下，大多数TCP连接只开放到该空间的一小部分，例如10000-60000（约5-100段）。这是因为播发的接收窗口通常与接收套接字缓冲区大小匹配。建议手动或通过自动外部方式调整该缓冲区，以满足连接的需要[38]。
On a low-loss path, the advertised receive window should be configured to match the path bandwidth-delay product, including buffering delays (assume 1 packet/hop) [38]. Many paths in the Internet have end-to-end bandwidths of under 1 Mbps, latencies under 100 ms, and are under 15 hops, resulting in fairly small advertised receive windows as above (under 35,000 bytes). Under these conditions, and further assuming that the initial sequence number is suitably (pseudo-randomly) chosen, a valid guessed sequence number would have odds of 1 in 57,000 of falling within the advertised receive window. Put differently, a blind (i.e., off-path) attacker would need to send 57,000 RSTs with suitably spaced sequence number guesses within one round-trip time to successfully reset a connection. At 1 Mbps, 57,000 (40 byte) RSTs would take only 20 seconds to transmit, but this presumes that both IP addresses and both ports are known. Absent knowledge of the source port, an off-path spoofer would need to try at least the entire range of 49152- 65535, or 16,384 different ports, resulting in an attack that would take over 91 hours. Because most TCP connections are comparatively short-lived, even this moderate variation in the source port is sufficient for such environments, although further port randomization may be recommended [29].
在低损耗路径上，广告接收窗口应配置为与路径带宽延迟乘积相匹配，包括缓冲延迟（假设1个包/跳）[38]。Internet中的许多路径的端到端带宽低于1Mbps，延迟低于100ms，跳数低于15跳，因此广告接收窗口非常小（低于35000字节）。在这些条件下，并且进一步假设适当地（伪随机地）选择初始序列号，有效的猜测序列号在广告接收窗口内的概率为57000分之一。换言之，盲（即，非路径）攻击者需要在一个往返时间内发送57000个RST，并进行适当间隔的序列号猜测，以成功重置连接。在1 Mbps时，57000（40字节）RST仅需20秒即可传输，但这假定两个IP地址和两个端口都已知。在不知道源端口的情况下，非路径欺骗者需要尝试至少整个范围内的49152-65535或16384个不同端口，从而导致需要91小时以上的攻击。由于大多数TCP连接的寿命相对较短，因此即使源端口中的这种适度变化也足以用于此类环境，尽管可能建议进一步的端口随机化[29]。
Recent use of high bandwidth paths of 10 Gbps and higher results in bandwidth-delay products over 125 MB -- approximately 1/10 of TCP's overall maximum advertised receive window size (i.e., assuming the receive socket buffers are increased as much as possible) excluding scale, assuming the receiver allocates sufficient buffering (as discussed in Section 2). Even under networks that are ten times slower (1 Gbps), the active advertised receive window covers 1/100th of the overall window size. At these speeds, it takes only 10-100 packets, or less than 32 microseconds, to correctly guess a valid sequence number and kill a connection. A table of corresponding exposure to various amounts of RSTs is shown below, for various line rates, assuming the more conventional 100-ms latencies (though even 100 ms is large for BGP cases):
最近使用的10 Gbps及以上的高带宽路径导致带宽延迟乘积超过125 MB——约为TCP整体最大广告接收窗口大小（即，假设接收套接字缓冲区尽可能增加）的1/10，不包括规模，假设接收器分配了足够的缓冲（如第2节所述）。即使在速度慢十倍（1 Gbps）的网络下，活动的播发接收窗口覆盖了整个窗口大小的1/100。在这些速度下，只需10-100个数据包，或不到32微秒，即可正确猜测有效序列号并终止连接。下面显示了针对不同线路速率的不同RST的对应暴露表，假设更为复杂常规100毫秒延迟（尽管对于BGP病例，即使100毫秒也大）：
BW BW*delay RSTs needed Time needed
------------------------------------------------------------
10 Gbps 125 MB 35 1 us (microsecond)
1 Gbps 12.5 MB 344 110 us
100 Mbps 1.25 MB 3,436 10 ms (millisecond)
10 Mbps 0.125 MB 34,360 1 second
1 Mbps 0.0125 MB 343,598 2 minutes
100 Kbps 0.00125 MB 3,435,974 3 hours
BW BW*delay RSTs needed Time needed
------------------------------------------------------------
10 Gbps 125 MB 35 1 us (microsecond)
1 Gbps 12.5 MB 344 110 us
100 Mbps 1.25 MB 3,436 10 ms (millisecond)
10 Mbps 0.125 MB 34,360 1 second
1 Mbps 0.0125 MB 343,598 2 minutes
100 Kbps 0.00125 MB 3,435,974 3 hours
Figure 1: Time needed to kill a connection
图1：终止连接所需的时间
This table demonstrates that the effect of bandwidth on the vulnerability is squared; for every increase in bandwidth, there is a linear decrease in the number of sequence number guesses needed, as well as a linear decrease in the time needed to send a set of guesses. Notably, as inter-router link bandwidths approach 1 Mbps, an 'exhaustive' attack becomes practical. Checking that the RST sequence number is somewhere in the advertised receive window, out of the overall maximum receive window (2^32), is an insufficient obfuscation.
此表表明，带宽对漏洞的影响是平方的；对于带宽的每一次增加，所需的序列号猜测的数量都会线性减少，发送一组猜测所需的时间也会线性减少。值得注意的是，随着路由器间链路带宽接近1Mbps，“穷举”攻击变得切实可行。检查RST序列号是否在播发接收窗口中的某个位置，在整个最大接收窗口（2^32）之外，是一种不充分的混淆。
Note that this table makes a number of assumptions:
请注意，此表作出了一些假设：
1. The overall bandwidth-delay product is relatively fixed.
1. 总带宽延迟乘积相对固定。
2. Traffic losses are negligible (insufficient to affect the congestion window over the duration of most of the connection).
2. 流量损失可以忽略不计（不足以在大部分连接期间影响拥塞窗口）。
3. The advertised receive window is a large fraction of the overall maximum receive window size, e.g., because the receive socket buffers are set to match a large bandwidth-delay product.
3. 广告接收窗口是整体最大接收窗口大小的很大一部分，例如，因为接收套接字缓冲区被设置为匹配大带宽延迟产品。
4. The attack bandwidth is similar to the end-to-end path bandwidth.
4. 攻击带宽类似于端到端路径带宽。
Of these assumptions, the last two are more notable. The issue of receive socket buffers was discussed in Section 2. Figure 1 summarized the time to a successful attack based on large advertised receive windows, but many current commercial routers have limits of 128 KB for large devices, 32 KB for medium, and as little as 4 KB for modest ones. Figure 2 shows the time and bandwidths needed to accomplish an attack on BGP sessions in the time shown for 100-ms latencies; for even short-range network latencies (10 ms), these sessions can be still be attacked over short timescales (minutes to hours).
在这些假设中，后两个更值得注意。第2节讨论了接收套接字缓冲区的问题。图1总结了基于大型广告接收窗口的成功攻击的时间，但当前许多商用路由器对大型设备的限制为128 KB，对中型设备的限制为32 KB，对小型设备的限制为4 KB。图2显示了在100毫秒延迟时间内完成对BGP会话的攻击所需的时间和带宽；即使是短距离网络延迟（10毫秒），这些会话仍可能在短时间内（几分钟到几小时）受到攻击。
Receive
BW Buffer Size RSTs needed Time needed
------------------------------------------------------------
10 Mbps 0.128 MB 33,555 1 second
3 Mbps 0.032 MB 134,218 40 seconds
300 Kbps 0.004 MB 1,073,742 1 hour
Receive
BW Buffer Size RSTs needed Time needed
------------------------------------------------------------
10 Mbps 0.128 MB 33,555 1 second
3 Mbps 0.032 MB 134,218 40 seconds
300 Kbps 0.004 MB 1,073,742 1 hour
Figure 2: Time needed to kill a connection with limited buffers
图2：使用有限缓冲区终止连接所需的时间
The issue of the attack bandwidth is considered reasonable as follows:
攻击带宽的问题被认为是合理的，如下所示：
1. RSTs are substantially easier to send than data; they can be precomputed and they are smaller than data packets (40 bytes).
1. RST比数据更容易发送；它们可以预先计算，并且比数据包（40字节）小。
2. Although susceptible connections use somewhat less ubiquitous high-bandwidth paths, the attack may be distributed, at which point only the ingress link of the attack is the primary limitation.
2. 尽管易受影响的连接使用不太普遍的高带宽路径，但攻击可能是分布式的，此时只有攻击的入口链路是主要限制。
3. For the purposes of the above table, we assume that the ingress at the attack has the same bandwidth as the path, as an approximation.
3. 出于上表的目的，作为近似值，我们假设攻击处的入口与路径具有相同的带宽。
The previous sections discussed the nature of the recent attacks on BGP due to the vulnerability of TCP to RST spoofing attacks, due largely to recent increases in the fraction of the TCP advertised receive window space in use for a single, long-lived connection.
前几节讨论了最近针对BGP的攻击的性质，这是由于TCP易受RST欺骗攻击的影响，这主要是由于最近用于单个长期连接的TCP广告接收窗口空间的比例增加所致。
TCP currently authenticates received RSTs using the address and port pair numbers, and checks that the sequence number is inside the valid receiver window. The previous section demonstrated how TCP has become more vulnerable to RST spoofing attacks due to the increases in the receive window size. There are a number of current and proposed solutions to this vulnerability, all attempting to provide evidence that a received RST is legitimate.
TCP当前使用地址和端口对号对接收到的RST进行身份验证，并检查序列号是否在有效的接收器窗口内。上一节演示了由于接收窗口大小的增加，TCP如何变得更容易受到RST欺骗攻击。目前有许多针对该漏洞的解决方案，所有这些解决方案都试图提供证据证明收到的RST是合法的。
The transport layer represents the last place that segments can be authenticated before they affect connection management. TCP has a variety of current and proposed mechanisms to increase the authentication of segments, protecting against both off-path and on-path third-party spoofing attacks. Other transport protocols, such as SCTP and DCCP, also have limited antispoofing mechanisms.
传输层表示在段影响连接管理之前可以对其进行身份验证的最后一个位置。TCP有各种现有的和建议的机制来增加段的身份验证，防止路径外和路径上的第三方欺骗攻击。其他传输协议，如SCTP和DCCP，也具有有限的防冒充机制。
An extension to TCP supporting MD5 authentication was developed in 1998 specifically to authenticate BGP connections (although it can be used for any TCP connection) [20]. The extension relies on a pre-shared secret key to authenticate the entire TCP segment, including the data, TCP header, and TCP pseudo-header (certain fields of the IP header). All segments are protected, including RSTs, to be accepted only when their signature matches. This option, although widely deployed in Internet routers, is considered undeployable for widespread use because the need for pre-shared keys [3][30]. It further is considered computationally expensive for either hosts or routers due to the overhead of MD5 [43][44].
支持MD5认证的TCP扩展于1998年开发，专门用于认证BGP连接（尽管它可以用于任何TCP连接）[20]。扩展依赖于预共享密钥来验证整个TCP段，包括数据、TCP头和TCP伪头（IP头的某些字段）。所有段都受到保护，包括RST，只有在其签名匹配时才被接受。此选项虽然广泛部署在Internet路由器中，但由于需要预共享密钥[3][30]，因此被认为无法广泛使用。此外，由于MD5[43][44]的开销，主机或路由器的计算成本更高。
There are also concerns about the use of MD5 due to recent collision-based attacks [22]. Similar concerns exist for SHA-1, and the IETF is currently evaluating how these attacks impact the recommendation for using these hashes, both in TCP/MD5 and in the IPsec suite. For the purposes of this discussion, the particular algorithm used in either protocol suite is not the focus, and there is ongoing work to allow TCP/MD5 to evolve to a more general TCP security option [6][47].
由于最近基于冲突的攻击，人们还担心MD5的使用[22]。SHA-1也存在类似的问题，IETF目前正在评估这些攻击如何影响在TCP/MD5和IPsec套件中使用这些哈希的建议。在本次讨论中，两个协议套件中使用的特定算法都不是重点，目前正在开展工作，以使TCP/MD5能够发展为更通用的TCP安全选项[6][47]。
A recent proposal extends TCP to further constrain received RST to match the expected next sequence number [36]. This restores TCP's resistance to spurious RSTs, effectively limiting the receive window for RSTs to a single number. As a result, an attacker would need to send 2^32 different packets to brute-force guess the sequence number (worst case, the average would be half that); this makes TCP's vulnerability to attack independent of the size of the receive window (RCV.WND). The extension further modifies the RST receiver to react to incorrectly-numbered RSTs, by sending a zero-length ACK. If the RST source is legitimate, upon receipt of an ACK, the closed source would presumably emit a RST with the sequence number matching the ACK, correctly resetting the intended recipient. This modification changes TCP's control processing, adding to its complexity and thus potentially affecting its correctness (in contrast to adding MD5 signatures, which is orthogonal to TCP control processing altogether). For example, there may be complications between RSTs of different connections between the same pair of endpoints because RSTs flush the TIME-WAIT (as mentioned earlier). Further, this proposal modifies TCP so that, under some circumstances, a RST causes a reply (an ACK), in violation of generally accepted practice, if not gentle recommendation -- although this can be omitted, allowing timeouts to suffice. The advantage to this proposal is that it can be deployed incrementally and has benefit to the endpoint on which it is
最近的一项提案扩展了TCP，以进一步限制接收到的RST与预期的下一个序列号匹配[36]。这恢复了TCP对虚假RST的抵抗能力，有效地将RST的接收窗口限制为单个数字。因此，攻击者需要发送2^32个不同的数据包，以暴力猜测序列号（最坏情况下，平均值为该序列号的一半）；这使得TCP的攻击漏洞与接收窗口（RCV.WND）的大小无关。扩展进一步修改RST接收机，通过发送零长度ACK来对编号不正确的RST作出反应。如果RST源是合法的，则在收到ACK后，关闭的源可能会发出序列号与ACK匹配的RST，从而正确重置预期的接收者。这种修改改变了TCP的控制处理，增加了其复杂性，从而可能影响其正确性（与添加MD5签名相反，MD5签名与TCP控制处理完全正交）。例如，同一对端点之间不同连接的RST之间可能会出现复杂情况，因为RST刷新了等待时间（如前所述）。此外，该提案修改了TCP，因此，在某些情况下，RST会导致回复（ACK），这违反了普遍接受的惯例，如果不是温和的建议的话——尽管这可以省略，允许超时就足够了。此方案的优点是可以增量部署，并且对其所在的端点有利
deployed. The other advantage to this proposal is that the window attenuation described here makes the vulnerability to spoofed RST packets independent of the size of the receive window.
部署。该方案的另一个优点是，此处描述的窗口衰减使得针对欺骗RST数据包的漏洞与接收窗口的大小无关。
A variant of this proposal uses a different value to attenuate the window of viable RSTs. It requires RSTs to carry the initial sequence number rather than the next expected sequence number, i.e., the value negotiated on connection establishment [42][49]. This proposal has the advantage of using an explicitly negotiated value, but at the cost of changing the behavior of an unmodified endpoint to a currently valid RST. It would thus be more difficult, without additional mechanism, to deploy incrementally.
该方案的一个变体使用不同的值来衰减可行RST的窗口。它要求RST携带初始序列号，而不是下一个预期序列号，即连接建立时协商的值[42][49]。此方案的优点是使用显式协商的值，但代价是将未修改端点的行为更改为当前有效的RST。因此，如果没有额外的机制，增量部署将更加困难。
Another variant of this proposal involves increasing TCP's window space, rather than decreasing the valid range for RSTs, i.e., increasing the sequence space from 32 bits to 64 bits. This has the equivalent effect -- the ratio of the valid sequence numbers for any segment to the overall sequence number space is significantly reduced. The use of the larger space, as with current schemes to establish weak authentication using initial sequence numbers (ISNs), is contingent on using suitably random values for the ISN. Such randomness adds additional complexity to TCP both in specification and implementation, and provides only very weak authentication. Such a modification is not obviously backward compatible, and would be thus difficult to deploy.
该方案的另一个变体涉及增加TCP的窗口空间，而不是减少RST的有效范围，即将序列空间从32位增加到64位。这具有相同的效果——任何段的有效序列号与整个序列号空间的比率都会显著降低。与当前使用初始序列号（ISN）建立弱身份验证的方案一样，较大空间的使用取决于对ISN使用适当的随机值。这种随机性增加了TCP在规范和实现方面的额外复杂性，并且只提供非常弱的身份验证。这种修改显然不向后兼容，因此很难部署。
A converse variant of increasing TCP's window space is to decrease the receive window (RCV.WND) explicitly, which would further reduce the effectiveness of spoofed RSTs with random sequence numbers. This alternative may reduce the throughput of the connection, if the advertised receive window is smaller than the bandwidth-delay product of the connection.
增加TCP窗口空间的一个相反变体是显式减少接收窗口（RCV.WND），这将进一步降低随机序列号欺骗RST的有效性。如果播发的接收窗口小于连接的带宽延迟乘积，则该替代方案可以降低连接的吞吐量。
Another way to authenticate TCP segments is via its timestamp option, using the value as a sort of authentication [34]. This requires that the receiver TCP discard segments whose timestamp is outside the accepted window, which is derived from the timestamps of other packets from the same connection. This technique uses an existing TCP option, but also requires modified TCP control processing (with the same caveats) and may be difficult to deploy incrementally without further modifications. Additionally, the timestamp value may be easier to guess because it can be derived predictably, either assuming it represents actual time at the host, or by probing the host using unrelated benign traffic.
验证TCP段的另一种方法是通过其时间戳选项，使用该值作为一种身份验证[34]。这要求接收方TCP丢弃其时间戳在已接受窗口之外的段，该窗口是从来自同一连接的其他数据包的时间戳派生的。此技术使用现有的TCP选项，但也需要修改TCP控制处理（具有相同的注意事项），并且可能很难在没有进一步修改的情况下增量部署。此外，时间戳值可能更容易猜测，因为它可以被预测地导出，假设它代表主机上的实际时间，或者通过使用不相关的良性流量探测主机。
All of the above techniques are variants of cookies, otherwise meaningless data whose value is used to validate the packet. In the case of MD5 checksums, the cookie is computed based on a shared secret. Note that even a signature can be guessed, and presents a 1 in 2^(signature length) probability of attack. The primary difference is that MD5 signatures are effectively one-time cookies, not predictable based on on-path snooping, because they are dependent on packet data and thus do not repeat. Window attenuation sequence numbers can be guessed by snooping the sequence number of current packets of an existing connection, and timestamps can be guessed even less directly, either by separate benign connections or by assuming they roughly correlate to local time. These variants of cookies are similar in spirit to TCP SYN cookies, again patching a vulnerability to off-path third-party spoofing attacks based on a (fairly weak, excepting MD5) form of authentication. Another form of cookie is the source port itself, which can be randomized but provides only 16 bits of protection (65,000 combinations), which may be exhaustively attacked. This can be combined with destination port randomization as well, but that would require a separate coordination mechanism (so both parties know which ports to use), which is equivalent to (and as infeasible for large-scale deployments as) exchanging a shared secret [39].
上述所有技术都是cookie的变体，否则，这些cookie的值将用于验证数据包的无意义数据。在MD5校验和的情况下，cookie是基于共享秘密计算的。请注意，即使是一个签名也可以猜测，并表示1/2^（签名长度）的攻击概率。主要区别在于MD5签名实际上是一次性cookie，基于路径窥探无法预测，因为它们依赖于数据包数据，因此不会重复。窗口衰减序列号可以通过窥探现有连接的当前数据包的序列号来猜测，时间戳可以通过单独的良性连接或假设它们大致与本地时间相关来猜测，甚至更不直接。这些cookie的变体在精神上类似于TCP SYN cookies，再次修补了一个漏洞，使其能够抵御基于（相当弱，MD5除外）身份验证形式的非路径第三方欺骗攻击。cookie的另一种形式是源端口本身，它可以随机化，但只提供16位保护（65000个组合），可能会受到彻底的攻击。这也可以与目标端口随机化相结合，但这需要一个单独的协调机制（以便双方都知道要使用哪个端口），这相当于（对于大规模部署来说也是不可行的）交换共享秘密[39]。
The analysis of the potential for RST spoofing above assumes that the advertised receive window is opened to the maximum extent suggested by the bandwidth-delay product of the end-to-end path, and that the window is opened to an appreciable fraction of the overall sequence number space. As noted earlier, for most common cases, connections are too brief or over bandwidths too low for such a large window to be useful. Expanding TCP's sequence number space is a direct way to further avoid such vulnerability, even for long connections over emerging bandwidths. If either manual tuning or automatic tuning of the advertised receive window (via receive buffer tuning) is not provided, this is not an issue (although connection performance will suffer) [38].
对上述RST欺骗可能性的分析假设广告接收窗口被打开到端到端路径的带宽延迟乘积所建议的最大程度，并且窗口被打开到整个序列号空间的可观部分。如前所述，对于大多数常见的情况，连接太短或带宽太低，以至于如此大的窗口无法使用。扩展TCP的序列号空间是进一步避免此类漏洞的直接方法，即使对于新兴带宽上的长连接也是如此。如果未提供播发接收窗口的手动调谐或自动调谐（通过接收缓冲区调谐），则这不是问题（尽管连接性能会受到影响）[38]。
It may be sufficient for the endpoint to limit the advertised receive window by deliberately leaving it small. If the receive socket buffer is limited, e.g., to the ubiquitous default of 64 KB, the advertised receive window will not be as vulnerable even for very long connections over very high bandwidths. The vulnerability will grow linearly with the increased network speed, but not as the square. The consequence is lower sustained throughput, where only one window's worth of data per round-trip time (RTT) is exchanged.
端点可以通过故意将播发的接收窗口保持较小来限制该窗口。如果接收套接字缓冲区受到限制（例如，普遍默认值为64 KB），则播发的接收窗口即使在非常高的带宽上进行非常长的连接，也不会那么容易受到攻击。该漏洞将随着网络速度的增加而线性增长，但不会呈平方增长。其结果是较低的持续吞吐量，即每个往返时间（RTT）只交换一个窗口的数据。
This will keep the connection open longer; for long-lived connections with continuous sourced data, this may continue to present an attack opportunity, albeit a sparse and slow-moving target. For the most recent case where BGP data is being exchanged between Internet routers, the data is bursty and the aggregate traffic may be small (i.e., unlikely to cover a substantial portion of the sequence space, even if long-lived), so smaller advertised receive windows (via small receiver buffers) may, in some cases, sufficiently address the immediate problem. This assumes that the routing tables can be exchanged quickly enough with bandwidth reduced due to the smaller buffers, or perhaps that the advertised receive window is opened only during a large burst exchange (e.g., via some other signal between the two routers, or a time-based signal, though either would be nonstandard).
这将使连接保持更长的打开时间；对于具有连续源数据的长期连接，这可能继续提供攻击机会，尽管目标稀疏且移动缓慢。对于在互联网路由器之间交换BGP数据的最新情况，数据是突发的，并且聚合流量可能很小（即，即使是长期的，也不太可能覆盖大部分序列空间），因此在某些情况下，较小的广告接收窗口（通过小型接收器缓冲区）可能，充分解决眼前的问题。这假设路由表可以足够快地交换，带宽由于较小的缓冲器而减少，或者可能广告接收窗口仅在大突发交换期间打开（例如，通过两个路由器之间的某个其他信号，或者基于时间的信号，尽管两者都是非标准的）。
Segment authentication has been addressed at the transport layer in other protocols. Both SCTP and DCCP include cookies for connection establishment and use them to authenticate a variety of other control messages [28][41]. The inclusion of such mechanism at the transport protocol, although emerging as standard practice, complicates the design and implementation of new protocols [32]. As new attacks are discovered (SYN floods, RSTs, etc.), each protocol must be modified individually to compensate. A network solution may be more appropriate and efficient.
在其他协议中，段身份验证已在传输层解决。SCTP和DCCP都包含用于建立连接的cookie，并使用它们对各种其他控制消息进行身份验证[28][41]。在传输协议中包含这种机制，虽然作为标准实践出现，但会使新协议的设计和实现复杂化[32]。当发现新的攻击（SYN洪水、RST等）时，必须单独修改每个协议以进行补偿。网络解决方案可能更合适、更有效。
It should be noted that RST attacks, which rely on brute-force, are relatively easy for intrusion detection software to detect at the TCP layer. Any connection that receives a large number of invalid -- outside-window -- RSTs might have subsequent RSTs blocked, to defeat such attacks. This would have the side-effect of blocking legitimate RSTs to that connection, which might then interfere with cleaning up the transport state between the endpoint peers. This side-effect, coupled with the increased monitoring load, might render such solutions undesirable in the general case, but they might usefully be applied to special cases, e.g., for BGP for routers.
应该注意的是，RST攻击依赖暴力，入侵检测软件在TCP层相对容易检测到。任何接收大量无效（窗口外）RST的连接都可能会阻止后续RST，以抵御此类攻击。这将产生阻止连接的合法RST的副作用，这可能会干扰清理端点对等点之间的传输状态。这种副作用，再加上增加的监控负载，可能会使这种解决方案在一般情况下不受欢迎，但它们可以有效地应用于特殊情况，例如路由器的BGP。
There are two primary variants of network layer solutions to spoofing: address filtering and IPsec. Address filtering is an indirect system that relies on other parties to filter packets sent upstream of an attack, but does not necessarily require participation of the packet source. IPsec requires cooperation between the endpoints wanting to avoid attack on their connection, which currently involves preexisting shared knowledge of either a shared key or shared certificate authority.
有两种主要的网络层欺骗解决方案：地址过滤和IPsec。地址过滤是一种间接系统，它依赖于其他方过滤攻击上游发送的数据包，但不一定需要数据包源的参与。IPsec需要端点之间的合作，以避免对其连接的攻击，这目前涉及共享密钥或共享证书颁发机构的现有共享知识。
Address filtering is often proposed as an alternative to protocol mechanisms to defeat IP source address spoofing [2][13]. Address filtering restricts traffic from downstream sources across transit networks based on the IP source address. A kind of filtering already occurs at the endpoints of a connection, because attack messages must match the socket pair to succeed; again, note that such attacks require knowing the entire socket pair, and are unlikely except in particular cases. This section discusses filtering based on address only, typically done at the borders of an AS.
地址过滤通常被提议作为协议机制的替代方案，以挫败IP源地址欺骗[2][13]。地址过滤根据IP源地址限制来自传输网络下游源的流量。一种过滤已经在连接的端点发生，因为攻击消息必须匹配套接字对才能成功；再次注意，此类攻击需要知道整个套接字对，除非在特定情况下，否则不太可能发生。本节讨论仅基于地址的过滤，通常在AS的边界处进行。
It can also restrict core-to-edge paths to reject traffic that should have originated further toward the edge. It cannot restrict traffic from edges lacking filtering through the core to a particular edge. As a result, each border router must perform the appropriate filtering for overall protection to result; failure of any border router to filter defeats the protection of all participants inside the border, and potentially those outside as well. Address filtering at the border can protect those inside the border from some kinds of spoofing, i.e., connections among those inside a border, because only interior addresses should originate inside the border. It cannot, however, protect connections including endpoints outside the border (i.e., those that traverse the AS boundary) except to restrict where the traffic enters from, e.g., if it expected from one AS and not another.
它还可以限制核心到边缘的路径，以拒绝本应更靠近边缘的流量。它不能限制从缺少核心过滤的边缘到特定边缘的流量。因此，每个边界路由器必须执行适当的过滤，以实现整体保护；任何边界路由器过滤失败都会破坏对边界内所有参与者的保护，也可能破坏对边界外所有参与者的保护。边界上的地址过滤可以保护边界内的地址不受某种欺骗的影响，即边界内的地址之间的连接，因为只有内部地址应该起源于边界内。但是，它不能保护连接，包括边界外的端点（即，穿过AS边界的端点），除非限制流量从何处进入，例如，如果预期来自一个AS而不是另一个AS。
As a result, address filtering is not a local solution that can be deployed to protect communicating pairs, but rather relies on a distributed infrastructure of trusted gateways filtering forged traffic where it enters the network. It is not feasible for local, incremental deployment, but may be applicable to connections among those inside the protected border in some scenarios. Applying filtering can also be useful to reduce the network load of spoofed traffic [31].
因此，地址过滤不是一种可用于保护通信对的本地解决方案，而是依赖于一个分布式可信网关基础设施来过滤进入网络的伪造流量。这对于本地增量部署不可行，但在某些情况下可能适用于受保护边界内的连接。应用过滤也有助于减少伪造流量的网络负载[31]。
A more recent variant of address filtering checks the IP TTL (Time to Live) field, relying on the TTL set by the other end of the connection [15]. This technique has been used to provide filtering for BGP. It assumes the connection source TTL is set to 255; packets at the receiver are checked for TTL=255, and others are dropped. This restricts traffic to one hop upstream of the receiver (i.e., a BGP router), but those hops could include other user programs at those nodes (e.g., the BGP router's peer) or any traffic those nodes accept via tunnels -- because tunnels need not decrement TTLs, notably for "bump in the wire" (BITW) or BITW-equivalent scenarios [33] (see also Section 5.1 of [15] and [16]). TTL filtering works only where all traffic from the other end of the tunnel is trusted,
地址过滤的最新变体根据连接另一端设置的TTL检查IP TTL（生存时间）字段[15]。该技术已用于为BGP提供过滤。它假定连接源TTL设置为255；在接收器处检查数据包的TTL=255，并丢弃其他数据包。这将通信量限制在接收器（即BGP路由器）上游的一个跃点，但这些跃点可能包括这些节点（例如BGP路由器的对等节点）上的其他用户程序或这些节点通过隧道接受的任何通信量——因为隧道不必减少TTL，特别是对于“线路中的碰撞”（BITW）或BITW等效场景[33]（另请参见[15]和[16]的第5.1节。）TTL过滤仅在隧道另一端的所有流量都可信的情况下工作，
i.e., where it does not originate or transit spoofed traffic. The use of TTL rather than link or network security also assumes an untampered point-to-point link, where no other traffic can be spoofed onto a link.
i、 例如，它不是源于或传输伪造的流量。TTL而非链路或网络安全的使用还假设了无阻尼点对点链路，在该链路上不能欺骗任何其他流量。
This method of filtering works best where traffic originates one hop away, so that the address filtering is based on the trust of only directly-connected (tunneled or otherwise) nodes. Like conventional address filtering, this reduces spoofing traffic in general, but is not considered a reliable security mechanism because it relies on distributed filtering (e.g., the fact that upstream nodes do not terminate tunnels arbitrarily).
这种过滤方法在流量从一跳开始时效果最好，因此地址过滤仅基于直接连接（隧道或其他）节点的信任。与传统的地址过滤一样，这通常会减少欺骗流量，但并不被视为可靠的安全机制，因为它依赖于分布式过滤（例如，上游节点不会任意终止隧道）。
TCP is susceptible to RSTs, but also to other off-path and on-path spoofing attacks, including SYN attacks. Other transport protocols, such as UDP and RTP are equally susceptible. Although emerging transport protocols attempt to defeat such attacks at the transport layer, such attacks take advantage of network layer identity spoofing. The packet is coming from an endpoint that is spoofing another endpoint, either upstream or somewhere else in the Internet. IPsec was designed specifically to establish and enforce authentication of a packet's source and contents in order to most directly and explicitly address this security vulnerability.
TCP易受RST攻击，但也易受其他非路径和路径欺骗攻击，包括SYN攻击。其他传输协议（如UDP和RTP）也同样易受影响。尽管新兴的传输协议试图在传输层击败此类攻击，但此类攻击利用了网络层身份欺骗。数据包来自一个端点，该端点正在欺骗另一个端点，无论是上游还是Internet上的其他地方。IPsec专门设计用于建立和强制验证数据包的源和内容，以便最直接和明确地解决此安全漏洞。
The larger problem with IPsec is that of key distribution and use. IPsec is often cumbersome, and has only recently been supported in many end-system operating systems. More importantly, it relies on preshared keys, signed X.509 certificates, or a trusted third-party (e.g., Kerberos) key infrastructure to establish and exchange keying information (e.g., via IKE). Each of these issues presents challenges when using IPsec to secure traffic to a well-known server, whose clients may not support IPsec or may not have registered with a previously-known certificate authority (CA).
IPsec更大的问题是密钥的分发和使用。IPsec通常很麻烦，直到最近才在许多终端系统操作系统中得到支持。更重要的是，它依赖预共享密钥、已签名的X.509证书或受信任的第三方（如Kerberos）密钥基础设施来建立和交换密钥信息（如通过IKE）。当使用IPsec保护到已知服务器的流量时，这些问题中的每一个都会带来挑战，该服务器的客户端可能不支持IPsec，或者可能没有向以前已知的证书颁发机构（CA）注册。
These keying challenges are being addressed in the IETF in ways that will enable servers secure associations with other parties without advance coordination [45][46]. This can be especially useful for publicly-available servers, or for protecting connections to servers that -- for whatever reason -- have not or will not deploy conventional IPsec certificates (i.e., core Internet BGP routers).
IETF解决了这些关键问题，使服务器能够在无需事先协调的情况下与其他方安全关联[45][46]。这对于公开可用的服务器特别有用，或者对于保护到服务器的连接（无论出于何种原因）特别有用，因为这些服务器没有或不会部署传统的IPsec证书（即，核心Internet BGP路由器）。
Just as spoofed TCP packets can terminate a connection, so too can spoofed ICMP packets. ICMP can be used to launch a variety of attacks on TCP including connection resets, path-MTU attacks, and can also be used to attack the host with non-TCP 'ping of death' and 'smurf attacks', etc. [40]. ICMP thus represents a substantial threat to TCP, but this is not the focus of this document, although a number of protections are discussed below because some are comparable to TCP anti-spoofing techniques. Note also that ICMP attacks on TCP assume that the socket pair is known by the attacker, which is unlikely except for a subset of services between pairs of widely-known endpoints.
就像伪造的TCP数据包可以终止连接一样，伪造的ICMP数据包也可以终止连接。ICMP可用于对TCP发起各种攻击，包括连接重置、路径MTU攻击，也可用于对主机进行非TCP“死亡ping”和“smurf攻击”等攻击[40]。因此，ICMP对TCP构成了重大威胁，但这不是本文档的重点，尽管下文讨论了一些保护措施，因为有些保护措施与TCP反欺骗技术相当。还要注意，TCP上的ICMP攻击假定攻击者知道套接字对，这是不可能的，除了广为人知的端点对之间的服务子集。
TCP headers can be included inside certain ICMP messages [7]. There have been recent suggestions to validate the sequence number of TCP headers when they occur inside ICMP messages [18]. This sequence checking is similar to checks that would occur for conventional data packets in TCP, but is being proposed in the spirit of the RST window attenuation described in Section 3.1.2.
TCP头可以包含在某些ICMP消息中[7]。最近有人建议，当TCP头出现在ICMP消息中时，验证其序列号[18]。该序列检查类似于TCP中传统数据包的检查，但是根据第3.1.2节所述RST窗口衰减的精神提出的。
Some such checks may be reasonable, especially where they parallel the validations already performed by TCP processing, notably where they emulate the semantics of such processing. For example, the TCP checksum should be validated (if the entire TCP segment is contained in the ICMP message) before any fields of the TCP header are examined, to avoid reacting to corrupted packets. Similarly, if the TCP MD5 option is present, its signature should probably be validated before considering the contents of the message. Such validation can ensure that the packet was not corrupted prior to the ICMP generation (checksum), that the packet was one sent by the source (IPsec or TCP/MD5 authenticated), or that the packet was not in the network for an excess of 2*MSL (valid sequence number).
一些这样的检查可能是合理的，特别是当它们与TCP处理已经执行的验证并行时，尤其是当它们模拟这种处理的语义时。例如，在检查TCP头的任何字段之前，应验证TCP校验和（如果整个TCP段包含在ICMP消息中），以避免对损坏的数据包作出反应。类似地，如果存在TCP MD5选项，则在考虑消息内容之前，可能应该验证其签名。这种验证可以确保数据包在ICMP生成（校验和）之前没有损坏，数据包是由源发送的（IPsec或TCP/MD5已验证），或者数据包在网络中的长度不超过2*MSL（有效序列号）。
ICMP presents a particular challenge because some messages can reset a connection more easily -- with less validation -- than even some spoofed TCP segments. One other proposed alternative is to change TCP's reaction to ICMPs after a connection is established; that may leave TCP susceptible during connection establishment and modifies TCP's reaction to certain valid network events [19]. This considers the context-sensitivity of ICMP messages, as does IPsec in some tunneled configurations, but the recommendations are ambiguous regarding such filtering [27].
ICMP带来了一个特殊的挑战，因为某些消息甚至比某些伪造的TCP段更容易重置连接，而验证更少。另一个建议的替代方案是在建立连接后改变TCP对ICMP的反应；这可能会使TCP在连接建立期间易受影响，并修改TCP对某些有效网络事件的反应[19]。这考虑了ICMP消息的上下文敏感性，就像某些隧道配置中的IPsec一样，但关于此类过滤的建议不明确[27]。
Ultimately, requiring TCP ICMP messages to be 'in window' may be insufficient protection, as this document shows for spoofed data. ICMP packets can be authenticated when originating at known, trusted endpoints, such as endpoints of connections or routers in known
最终，要求TCP ICMP消息“在窗口中”可能不足以提供足够的保护，正如本文档针对伪造数据所示。ICMP数据包可以在已知的受信任端点（如已知网络中连接或路由器的端点）发起时进行身份验证
domains with preexisting IPsec associations. Unfortunately, they also can originate at other places in the network. In addition, some networks filter all ICMP packets because validation may not be possible, especially because they can be injected from anywhere in a network, and so cannot be easily and locally address filtered [27]. As a result, they are not addressed separately in the issues or security considerations of this document further.
已存在IPsec关联的域。不幸的是，它们也可能起源于网络中的其他地方。此外，一些网络过滤所有ICMP数据包，因为可能无法进行验证，特别是因为它们可以从网络中的任何位置注入，因此无法轻松地进行本地地址过滤[27]。因此，在本文件的问题或安全考虑中没有单独讨论这些问题。
There are a number of existing and proposed solutions addressing the vulnerability of transport protocols in general (and TCP in specific) to off-path third-party spoofing attacks. As shown, these operate at the transport or network layer. Transport solutions require separate modification of each transport protocol, addressing network identity spoofing separately in the context of each transport association. Network solutions require distributed coordination (filtering) or can be computationally intensive and require pervasive registration of certificate authorities with every possible endpoint (authentication). This section explains these observations further.
有许多现有和拟议的解决方案解决了一般传输协议（具体而言是TCP）对非路径第三方欺骗攻击的脆弱性。如图所示，它们在传输层或网络层运行。传输解决方案需要单独修改每个传输协议，在每个传输关联的上下文中分别处理网络身份欺骗。网络解决方案需要分布式协调（过滤），或者可能需要大量计算，并且需要对每个可能的端点进行证书颁发机构的普遍注册（身份验证）。本节将进一步解释这些观察结果。
Transport solutions rely on shared cookies to authenticate segments, including data, transport header, and even pseudo-header (e.g., fixed portions of the outer IP header in TCP). Because the Internet relies on stateless network protocols, it makes sense to rely on state establishment and maintenance available in some transport layers not only for the connection but for authentication state. Three-way handshakes and heartbeats can be used to negotiate authentication state in conjunction with connection parameters, which can be stored with connection state easily.
传输解决方案依赖共享cookie来验证段，包括数据、传输头，甚至伪头（例如TCP中外部IP头的固定部分）。由于Internet依赖于无状态网络协议，因此，依赖于某些传输层中可用的状态建立和维护（不仅用于连接，还用于身份验证状态）是有意义的。三向握手和心跳可用于结合连接参数协商身份验证状态，连接参数可轻松存储在连接状态中。
As noted earlier, transport layer solutions require separate modification of all transport protocols to include authentication. Not all transport protocols support negotiated endpoint state (e.g., UDP), and legacy protocols have been notoriously difficult to safely augment. Not all authentication solutions are created equal, either, and relying on a variety of transport solutions exposes end-systems to increased potential for incorrectly specified or implemented solutions. Transport authentication has often been developed piece-wise, in response to specific attacks, e.g., SYN cookies and RST window attenuation [4][36].
如前所述，传输层解决方案需要单独修改所有传输协议，以包括身份验证。并非所有传输协议都支持协商的端点状态（例如UDP），众所周知，传统协议很难安全扩展。并非所有的身份验证解决方案都是平等创建的，并且依赖于各种传输解决方案会使终端系统面临更大的错误指定或实施解决方案的可能性。传输身份验证通常是针对特定的攻击（例如，SYN cookies和RST窗口衰减）分段开发的[4][36]。
Transport layer solutions are not only per-protocol, but often per-connection. This has both advantages and drawbacks. One advantage to transport layer solutions is that they can protect the transport protocol when lower layers have failed, e.g., due to bugs in
传输层解决方案不仅针对每个协议，而且通常针对每个连接。这既有优点也有缺点。传输层解决方案的一个优点是，当较低层出现故障时（例如，由于系统中的错误），它们可以保护传输协议
implementation. TCP already includes a variety of packet validation mechanisms to protect in these cases, e.g., checking that RSTs are in-window. More strict checks can increase the protections provided, e.g., to protect against misaddressed RSTs that end up in-window (via TCPsecure) or to protect against connection interruption due to RSTs, SYNs, or data injection from misaddressed packets (TCP/MD5) [36].
实施TCP已经包含了各种数据包验证机制，以在这些情况下进行保护，例如，检查RST是否在窗口中。更严格的检查可以增加所提供的保护，例如，防止最终出现在窗口中的地址错误的RST（通过TCPsecure）或防止由于RST、SYN或来自地址错误的数据包（TCP/MD5）的数据注入而导致的连接中断[36]。
Another advantage is that transport layer protections can be more specifically limited to a particular connection. Because each connection negotiates its state separately, that state can be more specifically tied to that connection. This is both an advantage and a drawback. It can make it easier to tie security to an individual connection, although in practice a shared secret or certificate will generally be shared across multiple connections.
另一个优点是传输层保护可以更具体地限于特定连接。因为每个连接单独协商其状态，所以该状态可以更具体地绑定到该连接。这既是优点也是缺点。它可以更容易地将安全性绑定到单个连接，尽管在实践中，共享的秘密或证书通常会在多个连接之间共享。
As a drawback, each transport connection needs to negotiate and maintain authentication state separately. Some overhead is not amortized over multiple connections, e.g., overheads in packet exchanges, whereas other overheads are not amortized over different transport protocols, e.g., design and implementation complexity -- both as would be the case in a network layer solution. Because the authentication happens later in packet processing than is required, additional endpoint resources may be needlessly consumed, e.g., in demultiplexing received packets, indexing connection identifiers, and continuing to buffer spoofed packets, etc., only to be dropped later at the transport layer.
缺点是，每个传输连接都需要单独协商和维护身份验证状态。一些开销不会在多个连接上摊销，例如，数据包交换中的开销，而其他开销不会在不同的传输协议上摊销，例如，设计和实现的复杂性——这两种情况在网络层解决方案中都是如此。由于认证在分组处理中发生的时间晚于所需时间，因此额外的端点资源可能会被不必要地消耗，例如，在解复用接收的分组、索引连接标识符以及继续缓冲伪造的分组等过程中，只会稍后在传输层丢弃。
A network layer solution avoids the hazards of multiple transport variants, using a single shared endpoint authentication mechanism early in receiver packet processing to discard unauthenticated packets at the network layer instead. This defeats spoofing entirely because spoofing involves masquerading as another endpoint, and network layer security validates the endpoint as the source of the packets it emits. Such a network level solution protects all transport protocols as a result, including both legacy and emerging protocols, and reduces the complexity of these protocols as well. A shared solution also reduces protocol overhead, and decouples the management (and refreshing) of authentication state from that of individual transport connections. Finally, a network layer solution protects not only the transport layer but the network layer as well, e.g., from IGMP, and some kinds of ICMP (Section 4), spoofing attacks.
网络层解决方案避免了多个传输变体的危险，在接收器数据包处理的早期使用单一共享端点身份验证机制，在网络层丢弃未经身份验证的数据包。这将完全击败欺骗，因为欺骗涉及伪装成另一个端点，并且网络层安全性将端点验证为它发出的数据包的源。这样的网络级解决方案保护了所有传输协议，包括传统协议和新兴协议，并降低了这些协议的复杂性。共享解决方案还可以减少协议开销，并将身份验证状态的管理（和刷新）与单个传输连接的管理（和刷新）分离。最后，网络层解决方案不仅保护传输层，还保护网络层，例如，防止IGMP和某些类型的ICMP（第4节）欺骗攻击。
The IETF Proposed Standard protocol for network layer authentication is IPsec [27]. IPsec specifies the overall architecture, including header authentication (AH) [25] and encapsulation (ESP) modes [26].
IETF提出的用于网络层身份验证的标准协议是IPsec[27]。IPsec指定了总体架构，包括标头身份验证（AH）[25]和封装（ESP）模式[26]。
AH authenticates both the IP header and IP data, whereas ESP authenticates only the IP data (e.g., transport header and payload). AH is being phased out since ESP is more efficient and the Security Parameters Index (SPI) includes sufficient information to verify the IP header anyway [27]. These two modes describe the security applied to individual packets within the IPsec system; key exchange and management is performed either out-of-band (via pre-shared keys) or by an automated key exchange protocol, e.g., IKE [24].
AH认证IP报头和IP数据，而ESP仅认证IP数据（例如，传输报头和有效负载）。AH正在逐步淘汰，因为ESP效率更高，而且安全参数索引（SPI）包含足够的信息来验证IP头[27]。这两种模式描述了应用于IPsec系统内单个数据包的安全性；密钥交换和管理可在带外（通过预共享密钥）或通过自动密钥交换协议（如IKE）执行[24]。
IPsec already provides authentication of an IP header and its data contents sufficient to defeat both on-path and off-path third-party spoofing attacks. IKE can configure authentication between two endpoints on a per-endpoint, per-protocol, or per-connection basis, as desired. IKE also can perform automatic periodic re-keying, further defeating crypto-analysis based on snooping (clandestine data collection). The use of IPsec is already commonly strongly recommended for protected infrastructure.
IPsec已经提供了IP头及其数据内容的身份验证，足以抵御路径内和路径外的第三方欺骗攻击。IKE可以根据需要在每个端点、每个协议或每个连接的基础上配置两个端点之间的身份验证。IKE还可以执行自动周期性重设密钥，进一步击败基于窥探（秘密数据收集）的加密分析。对于受保护的基础结构，通常强烈建议使用IPsec。
Existing IPsec is not appropriate for many deployments. It is computationally intensive both in key management and individual packet authentication [43]. This computational overhead can be prohibitive, and so often requires additional hardware, especially in commercial routers. As importantly, IKE is not anonymous; keys can be exchanged between parties only if they trust each other's X.509 certificates, trust some other third-party to help with key generation (e.g., Kerberos), or pre-share a key. These certificates provide identification (the other party knows who you are) only where the certificates themselves are signed by certificate authorities (CAs) that both parties already trust. To a large extent, the CAs themselves are the pre-shared keys that help IKE establish security association keys, which are then used in the authentication algorithms.
现有IPsec不适用于许多部署。它在密钥管理和单个数据包认证方面都是计算密集型的[43]。这种计算开销可能令人望而却步，因此通常需要额外的硬件，特别是在商用路由器中。同样重要的是，艾克不是匿名的；只有当双方信任彼此的X.509证书、信任其他第三方帮助生成密钥（例如Kerberos）或预共享密钥时，才能在双方之间交换密钥。这些证书仅在证书本身由双方已经信任的证书颁发机构（CA）签署的情况下提供身份证明（另一方知道您是谁）。在很大程度上，CA本身是帮助IKE建立安全关联密钥的预共享密钥，然后在认证算法中使用这些密钥。
Alternative mechanisms are under development to address this limitation, to allow publicly-accessible servers to secure connections to clients not known in advance, or to allow unilateral relaxation of identity validation so that the remaining protections of IPsec can be made available [45][46]. In particular, these mechanisms can prevent a client (but without knowing who that client is) from being affected by spoofing from other clients, even when the attackers are on the same communications path.
正在开发替代机制来解决这一限制，允许公开访问的服务器保护与事先未知的客户端的连接，或者允许单方面放宽身份验证，以便可以提供IPsec的其余保护[45][46]。特别是，这些机制可以防止客户端（但不知道该客户端是谁）受到来自其他客户端的欺骗的影响，即使攻击者位于同一通信路径上。
IPsec, although widely available both in commercial routers and commodity end-systems, is not often used except between parties that already have a preexisting relationship (employee/employer, between two ISPs, etc.). Servers to anonymous clients (e.g., customer/ business) or more open services (e.g., BGP, where routers may have large numbers of peers) are unmanageable, due to the breadth and flux
IPsec虽然在商用路由器和商品终端系统中广泛可用，但除了在已经存在关系的各方（雇员/雇主、两个ISP之间等）之间，通常不使用IPsec。匿名客户端（例如，客户/企业）或更开放的服务（例如，BGP，路由器可能有大量对等点）的服务器由于其广度和流量而无法管理
of CAs. New endpoints cannot establish IPsec associations with such servers unless their own certificate is signed by a CA already trusted by the server. Different servers -- even within the same overall system (e.g., BGP) -- often cannot or will not trust overlapping subsets of CAs in general.
中科院院士。新端点无法与此类服务器建立IPsec关联，除非它们自己的证书已由服务器信任的CA签名。不同的服务器——即使在同一个整体系统（例如BGP）中——通常不能或不会信任CA的重叠子集。
There are a number of application layer authentication mechanisms, often implicit within end-to-end encryption. Application layer security (e.g., TLS, SSH, or MD5 checksums within a BGP stream) provides the ultimate protection of application data from all intermediaries, including network routers as well as exposure at other layers in the end-systems. This is the only way to ultimately protect the application data.
有许多应用层身份验证机制，通常隐含在端到端加密中。应用层安全性（例如，BGP流中的TLS、SSH或MD5校验和）提供了来自所有中介的应用程序数据的最终保护，包括网络路由器以及终端系统中其他层的暴露。这是最终保护应用程序数据的唯一方法。
Application authentication cannot protect either the network or transport protocols from spoofing attacks, however. Spoofed packets interfere with network processing or reset transport connections before the application checks the data. Authentication needs to winnow these packets and drop them before they interfere at these lower layers.
但是，应用程序身份验证无法保护网络或传输协议免受欺骗攻击。在应用程序检查数据之前，伪造的数据包会干扰网络处理或重置传输连接。身份验证需要筛选这些数据包并在它们干扰这些较低层之前丢弃它们。
An alternate application layer solution would involve resilience to reset connections. If the application can recover from such connection interruptions, then such attacks have less impact. Unfortunately, attackers still affect the application, e.g., in the cost of restarting connections, delays until connections are restarted, or increased connection establishment messages on the network. Some applications -- notably BGP -- even interpret TCP connection reliability as an indicator of route path stability, which is why attacks on BGP have such substantial consequences.
另一种应用层解决方案将涉及重置连接的恢复能力。如果应用程序可以从这种连接中断中恢复，那么这种攻击的影响较小。不幸的是，攻击者仍然会影响应用程序，例如重新启动连接的成本、重新启动连接之前的延迟或网络上连接建立消息的增加。一些应用程序——特别是BGP——甚至将TCP连接可靠性解释为路由路径稳定性的指标，这就是为什么对BGP的攻击会产生如此严重的后果。
Link layer security operates separately on each hop of an Internet. Such security can be critical in protecting link resources, such as bandwidth and link management protocols. Protection at this layer cannot suffice for network or transport layers, because it cannot authenticate the endpoint source of a packet. Link authentication ensures only the source of the current link hop where it is examined.
链路层安全性在Internet的每个跃点上分别运行。这种安全性在保护链路资源（如带宽和链路管理协议）时非常关键。此层的保护不能满足网络层或传输层的要求，因为它无法验证数据包的端点源。链接身份验证确保只检查当前链接跃点的来源。
The issues raised in this section suggest that there are challenges with all solutions to transport protection from spoofing attacks. This raises the potential need for alternate security levels. While it is already widely recognized that security needs to occur
本节中提出的问题表明，所有解决方案都存在防止欺骗攻击的传输保护难题。这就增加了对备用安全级别的潜在需求。虽然人们已经广泛认识到需要进行安全保护
simultaneously at many protocol layers, there also may be utility in supporting a variety of strengths at a single layer. For example, IPsec already supports a variety of algorithms (MD5, SHA1, etc., for authentication), but always assumes that:
同时，在许多协议层上，还可以在单个层上支持各种强度。例如，IPsec已经支持多种算法（用于身份验证的MD5、SHA1等），但始终假定：
1. The entire body of the packet is secured.
1. 包的整个主体都是安全的。
2. Security associations are established only where identity is authenticated by a known certificate authority or other pre-shared key.
2. 只有当身份由已知的证书颁发机构或其他预共享密钥进行身份验证时，才会建立安全关联。
3. Both on-path and off-path third-party spoofing attacks must be defeated.
3. 必须击败路径内和路径外的第三方欺骗攻击。
These assumptions are prohibitive, especially in many cases of spoofing attacks. For spoofing, the primary issue is whether packets are coming from the same party the server can reach. Only the IP header is fundamentally in question, so securing the entire packet (1) is computational overkill. It is sufficient to authenticate the other party as "a party you have exchanged packets with", rather than establishing their trusted identity ("Bill" vs. "Bob") as in (2). Finally, many cookie systems use clear-text (unencrypted), fixed cookie values, providing reasonable (1 in 2^{cookie-size}) protection against off-path third-party spoof attacks, but not addressing on-path attacks at all. Such potential solutions are discussed in the Better Than Nothing Security (BTNS) documents [5][45][46]. Note also that NULL Encryption in IPsec applies a variant of this cookie, where the SPI is the cookie, and no further encryption is applied [17].
这些假设是禁止的，特别是在许多欺骗攻击的情况下。对于欺骗，主要问题是数据包是否来自服务器可以到达的同一方。从根本上讲，只有IP报头是有问题的，因此保护整个数据包（1）是计算过度。将另一方认证为“与您交换数据包的一方”就足够了，而不是像（2）中那样建立他们的可信身份（“Bill”vs“Bob”）。最后，许多cookie系统使用明文（未加密）固定cookie值，提供合理（1/2 ^{cookie size}）的保护以抵御非路径第三方欺骗攻击，但根本不解决路径攻击。此类潜在解决方案在优于无的安全（BTNS）文件[5][45][46]中进行了讨论。还请注意，IPsec中的NULL加密应用了此cookie的一个变体，其中SPI是cookie，不应用进一步的加密[17]。
This entire document focuses on increasing the security of transport protocols and their resistance to spoofing attacks. Security is addressed throughout.
整个文档的重点是提高传输协议的安全性及其对欺骗攻击的抵抗力。安全问题贯穿始终。
This document describes a number of techniques for defeating spoofing attacks. Those relying on clear-text cookies, either explicit or implicit (e.g., window sequence attenuation) do not protect from on-path spoofing attacks, since valid values can be learned from prior traffic. Those relying on true authentication algorithms are stronger, protecting even from on-path attacks, because the authentication hash in a single packet approaches the behavior of "one-time" cookies.
本文档介绍了一些击败欺骗攻击的技术。那些依赖明文cookie（无论是显式的还是隐式的（例如，窗口序列衰减））的人不能防止路径欺骗攻击，因为可以从以前的流量中学习有效值。那些依赖真实身份验证算法的人更强大，甚至可以防止路径上的攻击，因为单个数据包中的身份验证哈希接近“一次性”cookie的行为。
The security of various levels of the protocol stack is addressed. Spoofing attacks are fundamentally identity masquerading, so we believe the most appropriate solutions defeat these at the network layer, where end-to-end identity lies. Some transport protocols
讨论了协议栈的各个层次的安全性。欺骗攻击从根本上说是身份伪装，因此我们认为最合适的解决方案可以在网络层（端到端身份所在）击败这些攻击。一些传输协议
subsume endpoint identity information from the network layer (e.g., TCP pseudo-headers), whereas others establish per-connection identity based on exchanged nonces (e.g., SCTP). It is reasonable, if not recommended, to address security at all layers of the protocol stack.
包含来自网络层的端点标识信息（例如，TCP伪头），而其他人则基于交换的nonce（例如，SCTP）建立每个连接标识。如果不建议，在协议栈的所有层上解决安全问题是合理的。
Note that Network Address Translators (NATs) and other middleboxes complicate the design and deployment of techniques to defeat spoofing attacks. Devices such as these, that modify IP and/or TCP headers in-transit, generate traffic equivalent to a spoofing attack, and thus should be inhibited by antispoofing mechanisms. Details of these middlebox-related problems are out of scope for this document, but issues thereof are addressed in RFCs and emerging documents that discuss the interactions between such devices and the Internet architecture, e.g., [21]. Fortunately, many of the most critical TCP-based connections -- in particular, those supporting routing protocols like BGP -- do not traverse such middleboxes, and are not affected by this limitation.
请注意，网络地址转换器（NAT）和其他中间盒使击败欺骗攻击的技术的设计和部署复杂化。此类设备在传输过程中修改IP和/或TCP报头，产生相当于欺骗攻击的流量，因此应通过反欺骗机制加以抑制。这些与中间包相关的问题的详细信息不在本文件的范围内，但相关问题在RFC和讨论此类设备与互联网架构之间交互的新兴文件中进行了讨论，例如[21]。幸运的是，许多最关键的基于TCP的连接——特别是那些支持路由协议（如BGP）的连接——不会穿越此类中间盒，并且不受此限制的影响。
This document describes the details of the recent BGP spoofing attacks involving spurious RSTs, which could be used to shutdown TCP connections. It summarizes and discusses a variety of current and proposed solutions at various protocol layers.
本文档详细介绍了最近涉及虚假RST的BGP欺骗攻击，这些攻击可用于关闭TCP连接。它总结并讨论了各种协议层的当前和拟议解决方案。
This document was inspired by discussions in the TCPM WG <http://www.ietf.org/html.charters/tcpm-charter.html> about the recent spoofed RST attacks on BGP routers, including R. Stewart's document (whose author list has since evolved) [36][42]. The analysis of the attack issues, alternate solutions, and the anonymous security proposed solutions were the result of discussions on that list as well as with USC/ISI's T. Faber, A. Falk, G. Finn, and Y. Wang. R. Atkinson suggested the UDP variant of TCP/MD5, P. Goyette suggested using the ISN to seed TCP/MD5, and L. Wood suggested using the ISN to validate RSTs. Other improvements are due to the input of various members of the IETF's TCPM WG, notably detailed feedback from F. Gont, P. Savola, and A. Hoenes.
本文件受TCPM工作组讨论的启发<http://www.ietf.org/html.charters/tcpm-charter.html>关于最近针对BGP路由器的欺骗RST攻击，包括R.Stewart的文档（其作者列表已经演变）[36][42]。对攻击问题、替代解决方案和匿名安全建议解决方案的分析是该列表以及USC/ISI的T.Faber、A.Falk、G.Finn和Y.Wang讨论的结果。R.Atkinson建议使用TCP/MD5的UDP变体，P.Goyette建议使用ISN为TCP/MD5种子，L.Wood建议使用ISN验证RST。其他改进得益于IETF TCPM工作组各成员的投入，特别是F.Gont、P.Savola和A.Hoenes的详细反馈。
This document was prepared using 2-Word-v2.0.template.dot.
本文件使用2-Word-v2.0.template.dot编制。
[1] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[1] Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[2] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[2] Baker，F.和P.Savola，“多址网络的入口过滤”，BCP 84，RFC 37042004年3月。
[3] Bellovin, S. and A. Zinin, "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", RFC 4278, January 2006.
[3] Bellovin，S.和A.Zinin，“关于TCP MD5签名选项（RFC 2385）和BGP-4规范的标准成熟度差异”，RFC 4278，2006年1月。
[4] Bernstein, D., "SYN cookies", 1997, <http://cr.yp.to/syncookies.html>.
[4] Bernstein，D.，“SYN cookies”，1997年<http://cr.yp.to/syncookies.html>.
[5] Better Than Nothing Security [BTNS] WG web pages, <http://www.postel.org/anonsec>.
[5] 总比没有好安全[BTNS]工作组网页<http://www.postel.org/anonsec>.
[6] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O. Wheeler, "Authentication for TCP-based Routing and Management Protocols", Work in Progress, February 2007.
[6] Bonica，R.，Weis，B.，Viswanathan，S.，Lange，A.，和O.Wheeler，“基于TCP的路由和管理协议的认证”，正在进行的工作，2007年2月。
[7] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[7] Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[8] Braden, R., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
[8] Braden，R.，“TCP中的等待时间暗杀危险”，RFC 1337，1992年5月。
[9] CERT alert: "Technical Cyber Security Alert TA04-111A: Vulnerabilities in TCP", April 20, 2004, <http://www.us-cert.gov/cas/techalerts/TA04-111A.html>.
[9] 证书警报：“技术网络安全警报TA04-111A：TCP漏洞”，2004年4月20日<http://www.us-cert.gov/cas/techalerts/TA04-111A.html>.
[10] Convery, S., and M. Franz, "BGP Vulnerability Testing: Separating Fact from FUD", 2003, <http://www.nanog.org/mtg-0306/pdf/franz.pdf>.
[10] Convery，S.和M.Franz，“BGP漏洞测试：从FUD中分离事实”，2003年<http://www.nanog.org/mtg-0306/pdf/franz.pdf>.
[11] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", Work in Progress, May 2007.
[11] Eddy，W.，“TCP SYN洪泛攻击和常见缓解措施”，正在进行的工作，2007年5月。
[12] Faber, T., J. Touch, and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999, pp. 1573- 1583, Mar. 1999.
[12] Faber，T.，J.Touch和W.Yue，“TCP中的时间等待状态及其对繁忙服务器的影响”，Proc。《1999年信息通讯》，第1573-1583页，1999年3月。
[13] 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.
[13] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[14] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[14] Floyd，S.，“不适当的TCP重置被认为是有害的”，BCP 60，RFC 3360，2002年8月。
[15] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[15] Gill，V.，Heasley，J.，和D.Meyer，“广义TTL安全机制（GTSM）”，RFC 3682，2004年2月。
[16] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", Work in Progress, June 2007.
[16] Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，Ed.，和C.Pignataro，“广义TTL安全机制（GTSM）”，正在进行的工作，2007年6月。
[17] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[17] Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[18] Gont, F., "ICMP attacks against TCP", Work in Progress, May 2007.
[18] Gont，F.，“针对TCP的ICMP攻击”，正在进行的工作，2007年5月。
[19] Gont, F., "TCP's Reaction to Soft Errors", Work in Progress, June 2007.
[19] Gont，F.，“TCP对软错误的反应”，正在进行的工作，2007年6月。
[20] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[20] Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[21] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[21] Holdrege，M.和P.Srisuresh，“IP网络地址转换器的协议复杂性”，RFC 3027，2001年1月。
[22] Housley, R., Post to IETF Discussion mailing list regarding his IETF 64 Security Area presentation, ID=7.0.0.10.2.20051124135914.00f50558@vigilsec.com, Nov. 24, 2005, <http://www1.ietf.org/ mail-archive/ietf/Current/maillist.html>.
[22] Housley，R.，就其IETF 64安全区域演示向IETF讨论邮件列表发帖，ID=7.0.0.10.2.20051124135914。00f50558@vigilsec.com，2005年11月24日<http://www1.ietf.org/ 邮件存档/ietf/Current/maillist.html>。
[23] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[23] Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[24] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[24] Kaufman，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[25] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[25] Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[26] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[26] Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[27] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[27] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[28] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[28] Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC4340，2006年3月。
[29] Larsen, M., and F. Gont, "Port Randomization", Work in Progress, February 2007.
[29] Larsen，M.和F.Gont，“港口随机化”，正在进行的工作，2007年2月。
[30] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[30] Leech，M.，“TCP MD5签名选项的密钥管理注意事项”，RFC 3562，2003年7月。
[31] Moore, D., G. Voelker, and S. Savage, "Inferring Internet Denial-of-Service Activity", Proc. Usenix Security Symposium, Aug. 2001.
[31] Moore，D.，G.Voelker和S.Savage，“推断互联网拒绝服务活动”，Proc。Usenix安全研讨会，2001年8月。
[32] O'Malley, S. and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, October 1991.
[32] O'Malley，S.和L.Peterson，“TCP扩展被认为是有害的”，RFC 1263，1991年10月。
[33] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[33] Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[34] Poon, K., "Use of TCP timestamp option to defend against blind spoofing attack", Work in Progress, October 2004.
[34] Poon，K.，“使用TCP时间戳选项防御盲欺骗攻击”，正在进行的工作，2004年10月。
[35] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[35] 《传输控制协议》，标准7，RFC 793，1981年9月。
[36] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, July 2007.
[36] Ramaiah，A.，Stewart，R.，和M.Dalal，“提高TCP对窗口盲攻击的鲁棒性”，正在进行的工作，2007年7月。
[37] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[37] Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[38] Semke, J., J. Mahdavi, and M. Mathis, "Automatic TCP Buffer Tuning", ACM SIGCOMM '98/ Computer Communication Review, volume 28, number 4, Oct. 1998.
[38] Semke，J.，J.Mahdavi和M.Mathis，“自动TCP缓冲区调整”，ACM SIGCOMM'98/计算机通信评论，第28卷，第4期，1998年10月。
[39] Shepard, T., "Reassign Port Number option for TCP", Work in Progress, July 2004.
[39] Shepard，T.，“为TCP重新分配端口号选项”，正在进行的工作，2004年7月。
[40] Shirey, R., "Internet Security Glossary, Version 2", Work in Progress, November 2006.
[40] Shirey，R.，“互联网安全词汇表，第2版”，正在进行的工作，2006年11月。
[41] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[41] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[42] TCPM: IETF TCPM Working Group and mailing list, <http://www.ietf.org/html.charters/tcpm-charter.html>.
[42] TCPM:IETF TCPM工作组和邮件列表<http://www.ietf.org/html.charters/tcpm-charter.html>.
[43] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
[43] Touch，J.，“MD5性能报告”，RFC1810，1995年6月。
[44] Touch, J., "Performance Analysis of MD5", Proc. Sigcomm 1995, pp. 77-86, Mar. 1999.
[44] Touch，J.，“MD5的性能分析”，过程。Sigcomm 1995，第77-86页，1999年3月。
[45] Touch, J., "ANONsec: Anonymous Security to Defend Against Spoofing Attacks", Work in Progress, May 2004.
[45] Touch，J.，“ANONsec：匿名安全以防御欺骗攻击”，正在进行的工作，2004年5月。
[46] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Work in Progress, February 2007.
[46] Touch，J.，Black，D.，和Y.Wang，“比没有更好的安全性（BTNS）的问题和适用性声明”，正在进行的工作，2007年2月。
[47] Touch, J. and A. Mankin, "The TCP Simple Authentication Option", Work in Progress, July 2007.
[47] Touch，J.和A.Mankin，“TCP简单身份验证选项”，正在进行的工作，2007年7月。
[48] Watson, P., "Slipping in the Window: TCP Reset attacks", Presentation at 2004 CanSecWest, <http://cansecwest.com/csw04archive.html>.
[48] Watson，P.，“在窗口中滑动：TCP重置攻击”，在2004年CanSecWest上的演讲<http://cansecwest.com/csw04archive.html>.
[49] Wood, L., Post to TCPM mailing list regarding use of ISN in RSTs, ID=Pine.GSO.4.50.0404232249570.5889- 100000@argos.ee.surrey.ac.uk, Apr. 23, 2004, <http://www1.ietf.org/mail-archive/web/tcpm/current/ msg00213.html>.
[49] Wood，L.，向TCPM邮寄关于在RSTs中使用ISN的邮件列表，ID=Pine.GSO.4.50.040423229570.5889-100000@argos.ee.surrey.ac.uk，2004年4月23日<http://www1.ietf.org/mail-archive/web/tcpm/current/ msg00213.html>。
Author's Addresses
作者地址
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
Joe Touch USC/ISI 4676美国加利福尼亚州玛丽娜·德雷海军部路90292-6695号。
Phone: +1 (310) 448-9151
Fax: +1 (310) 448-9300
EMail: touch@isi.edu
URI: http://www.isi.edu/touch
Phone: +1 (310) 448-9151
Fax: +1 (310) 448-9300
EMail: touch@isi.edu
URI: http://www.isi.edu/touch
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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编辑功能的资金目前由互联网协会提供。