Network Working Group S. Floyd
Request for Comments: 3360 ICIR
BCP: 60 August 2002
Category: Best Current Practice
Network Working Group S. Floyd
Request for Comments: 3360 ICIR
BCP: 60 August 2002
Category: Best Current Practice
Inappropriate TCP Resets Considered Harmful
不适当的TCP重置被认为是有害的
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document is being written because there are a number of firewalls in the Internet that inappropriately reset a TCP connection upon receiving certain TCP SYN packets, in particular, packets with flags set in the Reserved field of the TCP header. In this document we argue that this practice is not conformant with TCP standards, and is an inappropriate overloading of the semantics of the TCP reset. We also consider the longer-term consequences of this and similar actions as obstacles to the evolution of the Internet infrastructure.
之所以编写本文档，是因为Internet上有许多防火墙在接收到某些TCP SYN数据包时不适当地重置了TCP连接，特别是在TCP报头的保留字段中设置了标志的数据包。在本文中，我们认为这种做法不符合TCP标准，是TCP重置语义的不适当重载。我们还认为，这种长期行为的后果和类似的行动阻碍了互联网基础设施的发展。
TCP uses the RST (Reset) bit in the TCP header to reset a TCP connection. Resets are appropriately sent in response to a connection request to a nonexistent connection, for example. The TCP receiver of the reset aborts the TCP connection, and notifies the application [RFC793, RFC1122, Ste94].
TCP使用TCP头中的RST（重置）位重置TCP连接。例如，在响应对不存在的连接的连接请求时，可以适当地发送重置。重置的TCP接收器中止TCP连接，并通知应用程序[RFC793、RFC1122、Ste94]。
Unfortunately, a number of firewalls and load-balancers in the current Internet send a reset in response to a TCP SYN packet that use flags from the Reserved field in the TCP header. Section 3 below discusses the specific example of firewalls that send resets in response to TCP SYN packets from ECN-capable hosts.
不幸的是，当前Internet中的许多防火墙和负载平衡器会发送一个重置，以响应使用TCP报头中保留字段的标志的TCP SYN数据包。下面的第3节讨论了防火墙的具体示例，这些防火墙发送重置以响应来自支持ECN的主机的TCP SYN数据包。
This document is being written to inform administrators of web servers and firewalls of this problem, in an effort to encourage the deployment of bug-fixes [FIXES]. A second purpose of this document is to consider the longer-term consequences of such middlebox behavior on the more general evolution of protocols in the Internet.
编写本文档的目的是向web服务器和防火墙的管理员通知此问题，以鼓励部署错误修复[修复]。本文的第二个目的是考虑这种中间框行为对互联网中协议的更一般演进的长期后果。
2. The history of TCP resets.
2. TCP重置的历史记录。
This section gives a brief history of the use of the TCP reset in the TCP standards, and argues that sending a reset in response to a SYN packet that uses bits from the Reserved field of the TCP header is non-compliant behavior.
本节简要介绍了TCP标准中使用TCP重置的历史，并论证了发送重置以响应使用TCP报头保留字段位的SYN数据包是不符合规定的行为。
RFC 793 contained the original specification of TCP in September, 1981 [RFC793]. This document defined the RST bit in the TCP header, and explained that reset was devised to prevent old duplicate connection initiations from causing confusion in TCP's three-way handshake. The reset is also used when a host receives data for a TCP connection that no longer exists.
RFC793于1981年9月包含TCP的原始规范[RFC793]。本文档定义了TCP报头中的RST位，并解释了重置是为了防止旧的重复连接启动在TCP的三向握手中造成混乱。当主机接收到不再存在的TCP连接的数据时，也会使用重置。
RFC 793 states the following, in Section 5:
RFC 793在第5节中陈述了以下内容：
"As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case."
“作为一般规则，每当一个显然不适用于当前连接的段到达时，必须发送重置（RST）。如果不清楚情况是否如此，则不得发送重置。”
RFC 1122 "amends, corrects, and supplements" RFC 793. RFC 1122 says nothing specific about sending resets, or not sending resets, in response to flags in the TCP Reserved field.
RFC 1122“修订、纠正和补充”RFC 793。RFC1122没有具体说明发送重置或不发送重置以响应TCP保留字段中的标志。
Thus, there is nothing in RFC 793 or RFC 1122 that suggests that it is acceptable to send a reset simply because a SYN packet uses Reserved flags in the TCP header, and RFC 793 explicitly forbids sending a reset for this reason.
因此，RFC 793或RFC 1122中没有任何内容表明发送重置是可以接受的，因为SYN数据包在TCP报头中使用保留标志，并且RFC 793明确禁止为此发送重置。
RFC 793 and RFC 1122 both include Jon Postel's famous robustness principle, also from RFC 791: "Be liberal in what you accept, and conservative in what you send." RFC 1122 reiterates that this robustness principle "is particularly important in the Internet layer, where one misbehaving host can deny Internet service to many other hosts." The discussion of the robustness principle in RFC 1122 also states that "adaptability to change must be designed into all levels of Internet host software". The principle "be liberal in what you accept" doesn't carry over in a clear way (if at all) to the world of firewalls, but the issue of "adaptability to change" is crucial nevertheless. The challenge is to protect legitimate security interests without completely blocking the ability of the Internet to evolve to support new applications, protocols, and functionality.
RFC 793和RFC 1122都包含了Jon Postel著名的健壮性原则，也是来自RFC 791：“接受的内容要自由，发送的内容要保守。”RFC 1122重申，这一健壮性原则“在互联网层尤其重要，在互联网层，一个行为不端的主机可以拒绝向许多其他主机提供互联网服务。”RFC 1122中对健壮性原则的讨论还指出，“必须在所有级别的Internet主机软件中设计对变化的适应性”。“在你所接受的事情上要自由”的原则并没有以一种明确的方式（如果有的话）延续到防火墙的世界，但是“适应变化”的问题仍然是至关重要的。挑战在于保护合法的安全利益，而不完全阻止互联网发展以支持新的应用程序、协议和功能的能力。
RFC 793 says that the Reserved field in the TCP header is reserved for future use, and must be zero. A rephrasing more consistent with the rest of the document would have been to say that the Reserved field should be zero when sent and ignored when received, unless specified otherwise by future standards actions. However, the phrasing in RFC 793 does not permit sending resets in response to TCP packets with a non-zero Reserved field, as is explained in the section above.
RFC 793表示TCP标头中的保留字段保留供将来使用，并且必须为零。与文档其余部分更一致的重新表述是，保留字段在发送时应为零，在接收时应忽略，除非未来的标准操作另有规定。然而，RFC 793中的措辞不允许发送重置，以响应具有非零保留字段的TCP数据包，如上一节所述。
RFC 2979 on the Behavior of and Requirements for Internet Firewalls [RFC2979], an Informational RFC, contains the following:
关于互联网防火墙的行为和要求的RFC 2979[RFC2979]，一个信息RFC，包含以下内容：
"Applications have to continue to work properly in the presence of firewalls. This translates into the following transparency rule: The introduction of a firewall and any associated tunneling or access negotiation facilities MUST NOT cause unintended failures of legitimate and standards-compliant usage that would work were the firewall not present."
“应用程序必须在有防火墙的情况下继续正常工作。这转化为以下透明度规则：引入防火墙和任何相关的隧道或访问协商设施不得导致在没有防火墙的情况下正常工作的合法和符合标准的使用出现意外故障."
"A necessary corollary to this requirement is that when such failures do occur it is incumbent on the firewall and associated software to address the problem: Changes to either implementations of existing standard protocols or the protocols themselves MUST NOT be necessary."
“这一要求的必然结果是，当发生此类故障时，防火墙和相关软件有责任解决该问题：必须更改现有标准协议的实现或协议本身。”
"Note that this requirement only applies to legitimate protocol usage and gratuitous failures -- a firewall is entitled to block any sort of access that a site deems illegitimate, regardless of whether or not the attempted access is standards-compliant."
请注意，此要求仅适用于合法的协议使用和无故的故障——防火墙有权阻止站点认为非法的任何类型的访问，无论尝试的访问是否符合标准
We would note that RFC 2979 is an Informational RFC. RFC 2026 on Internet Standards Process says the following in Section 4.2.2: "An `Informational' specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation" [RFC2026].
我们注意到RFC 2979是一个信息RFC。RFC 2026关于互联网标准的过程在第4.2.2节中说：“发布的`信息'规范用于互联网社区的一般信息，并不代表互联网社区的共识或建议”[RFC2026]。
Some firewalls and hosts send resets in response to SYN packets as a congestion control mechanism, for example, when their listen queues are full. These resets are sent without regard to the contents of the TCP Reserved field. Possibly in response to the use of resets as
某些防火墙和主机发送重置以响应SYN数据包作为拥塞控制机制，例如，当其侦听队列已满时。发送这些重置时不考虑TCP保留字段的内容。可能是为了响应使用重置作为
a congestion control mechanism, several popular TCP implementations immediately resend a SYN packet in response to a reset, up to four times.
作为一种拥塞控制机制，几个流行的TCP实现会立即重新发送SYN数据包，以响应重置，最多四次。
We would recommend that the TCP reset not be used as a congestion control mechanism, because this overloads the semantics of the reset message, and inevitably leads to more aggressive behavior from TCP implementations in response to a reset. We would suggest that simply dropping the SYN packet is the most effective response to congestion. The TCP sender will retransmit the SYN packet, using the default value for the Retransmission Timeout (RTO), backing-off the retransmit timer after each retransmit.
我们建议不要将TCP重置用作拥塞控制机制，因为这会使重置消息的语义过载，并不可避免地导致TCP实现在响应重置时出现更激进的行为。我们认为，简单地丢弃SYN数据包是对拥塞最有效的响应。TCP发送方将使用重传超时（RTO）的默认值重传SYN数据包，并在每次重传后退出重传计时器。
RFC 793 includes the following in Section 5:
RFC 793在第5节中包括以下内容：
"If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection, a reset is sent and connection goes to the CLOSED state."
如果传入段的安全级别、分区或优先级与连接请求的级别、分区和优先级不完全匹配，则会发送重置，连接将进入关闭状态
The "precedence" refers to the (old) Precedence field in the (old) ToS field in the IP header. The "security" and "compartment" refer to the obsolete IP Security option. When it was written, this was consistent with the guideline elsewhere in RFC 793 that resets should only be sent when a segment arrives which apparently is not intended for the current connection.
“优先级”是指IP头中（旧）ToS字段中的（旧）优先级字段。“安全”和“隔间”指的是过时的IP安全选项。在编写时，这与RFC 793中其他地方的指南一致，即只有当显然不适用于当前连接的段到达时，才应发送重置。
RFC 2873 on "TCP Processing of the IPv4 Precedence Field" discusses specific problems raised by the sending of resets when the precedence field has changed [RFC2873]. RFC 2873, currently a Proposed Standard, specifies that TCP must ignore the precedence of all received segments, and must not send a reset in response to changes in the precedence field. We discuss this here to clarify that this issue never permitted the sending of a reset in response to a segment with a non-zero TCP Reserved field.
关于“IPv4优先字段的TCP处理”的RFC 2873讨论了优先字段发生更改时发送重置引起的具体问题[RFC2873]。RFC 2873，目前提议的标准，规定TCP必须忽略所有接收段的优先级，并且不得发送重置以响应优先级字段中的更改。我们在这里讨论这个问题是为了澄清，这个问题从来都不允许发送重置来响应具有非零TCP保留字段的段。
RFC 1122 says the following in Section 4.2.2.5 about TCP options [RFC1122]:
RFC 1122在第4.2.2.5节中对TCP选项[RFC1122]作了如下说明：
"A TCP MUST be able to receive a TCP option in any segment. A TCP MUST ignore without error any TCP option it does not implement, assuming that the option has a length field (all TCP options defined
TCP必须能够在任何段中接收TCP选项。TCP必须毫无错误地忽略它未实现的任何TCP选项，假设该选项有一个长度字段（定义了所有TCP选项）
in the future will have length fields). TCP MUST be prepared to handle an illegal option length (e.g., zero) without crashing; a suggested procedure is to reset the connection and log the reason."
将来将有长度字段）。TCP必须准备好在不崩溃的情况下处理非法的选项长度（例如，零）；建议的步骤是重置连接并记录原因。“
This makes sense, as a TCP receiver is unable to interpret the rest of the data on a segment that has a TCP option with an illegal option length. Again, we discuss this here to clarify that this issue never permitted the sending of a reset in response to a segment with a non-zero TCP Reserved field.
这是有意义的，因为TCP接收器无法解释具有非法选项长度的TCP选项的段上的其余数据。同样，我们在这里讨论这个问题是为了澄清，这个问题从来都不允许发送重置来响应具有非零TCP保留字段的段。
This section has a brief explanation of ECN (Explicit Congestion Notification) in general, and the ECN-setup SYN packet in particular.
本节简要介绍了ECN（显式拥塞通知），特别是ECN设置SYN数据包。
The Internet is based on end-to-end congestion control, and historically the Internet has used packet drops as the only method for routers to indicate congestion to the end nodes. ECN is a recent addition to the IP architecture to allow routers to set a bit in the IP packet header to inform end-nodes of congestion, instead of dropping the packet. ECN requires the cooperation of the transport end-nodes.
互联网是基于端到端拥塞控制的，历史上，互联网使用丢包作为路由器向端节点指示拥塞的唯一方法。ECN是最近添加到IP架构中的一种，它允许路由器在IP数据包报头中设置一个位来通知终端节点拥塞，而不是丢弃数据包。ECN需要传输端节点的合作。
The ECN specification, RFC 2481, was an Experimental RFC from January 1999 until June 2001, when a revised document [RFC3168] was approved as Proposed Standard. More information about ECN is available from the ECN Web Page [ECN].
ECN规范RFC 2481从1999年1月到2001年6月是一个试验性RFC，当时修订文件[RFC3168]被批准为拟定标准。有关ECN的更多信息，请访问ECN网页[ECN]。
The use of ECN with TCP requires that both TCP end-nodes have been upgraded to support the use of ECN, and that both end-nodes agree to use ECN with this particular TCP connection. This negotiation of ECN support between the two TCP end-nodes uses two flags that have been allocated from the Reserved field in the TCP header [RFC2481].
将ECN与TCP一起使用要求两个TCP端节点都已升级以支持ECN的使用，并且两个端节点都同意将ECN与此特定TCP连接一起使用。这两个TCP端节点之间的ECN支持协商使用从TCP头[RFC2481]中的保留字段分配的两个标志。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: The previous definition of bytes 13 and 14 of the TCP header.
图1:TCP头字节13和14的先前定义。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: The current definition of bytes 13 and 14 of the TCP Header, from RFC 3168.
图2:RFC3168中TCP头字节13和14的当前定义。
The two ECN flags in the TCP header are defined from the last two bits in the Reserved field of the TCP header. Bit 9 in the Reserved field of the TCP header is designated as the ECN-Echo flag (ECE), and Bit 8 is designated as the Congestion Window Reduced (CWR) flag. To negotiate ECN usage, the TCP sender sends an "ECN-setup SYN packet", a TCP SYN packet with the ECE and CWR flags set. If the TCP host at the other end wishes to use ECN for this connection, then it sends an "ECN-setup SYN-ACK packet", a TCP SYN packet with the ECE flag set and the CWR flag not set. Otherwise, the TCP host at the other end returns a SYN-ACK packet with neither the ECE nor the CWR flag set.
TCP标头中的两个ECN标志是根据TCP标头保留字段中的最后两位定义的。TCP报头保留字段中的第9位被指定为ECN回波标志（ECE），第8位被指定为拥塞窗口缩减（CWR）标志。为了协商ECN的使用，TCP发送方发送一个“ECN设置SYN数据包”，一个设置了ECE和CWR标志的TCP SYN数据包。如果另一端的TCP主机希望将ECN用于此连接，则它将发送“ECN setup SYN-ACK数据包”，即设置ECE标志且未设置CWR标志的TCP SYN数据包。否则，另一端的TCP主机返回既没有设置ECE也没有设置CWR标志的SYN-ACK数据包。
So now back to TCP resets. When a TCP host negotiating ECN sends an ECN-setup SYN packet, an old TCP implementation is expected to ignore those flags in the Reserved field, and to send a plain SYN-ACK packet in response. However, there are some broken firewalls and load-balancers in the Internet that instead respond to an ECN-setup SYN packet with a reset. Following the deployment of ECN-enabled end nodes, there were widespread complaints that ECN-capable hosts could not access a number of websites [Kelson00]. This has been investigated by the Linux community, and by the TBIT project [TBIT] in data taken from September, 2000, up to March, 2002, and has been discussed in an article in Enterprise Linux Today [Cou01]. Some of the offending equipment has been identified, and a web page [FIXES] contains a list of non-compliant products and the fixes posted by the vendors. In March 2002, six months after ECN was approved as Proposed Standard, ECN-setup SYN packets were answered by a reset from 203 of the 12,364 web sites tested, and ECN-setup SYN packets were dropped for 420 of the web sites. Installing software that blocks packets using flags in TCP's Reserved field is considerably easier than uninstalling that software later on.
现在回到TCP重置。当协商ECN的TCP主机发送ECN setup SYN数据包时，旧的TCP实现将忽略保留字段中的那些标志，并发送普通SYN-ACK数据包作为响应。但是，Internet上有一些损坏的防火墙和负载平衡器，它们会用重置来响应ECN setup SYN数据包。在部署了支持ECN的终端节点之后，人们普遍抱怨支持ECN的主机无法访问许多网站[Kelson00]。Linux社区和TBIT项目[TBIT]在2000年9月至2002年3月的数据中对此进行了调查，并在《今日企业Linux》[Cou01]的一篇文章中进行了讨论。一些违规设备已经被识别，一个网页[FIXES]包含不符合要求的产品和供应商发布的修复程序的列表。2002年3月，在ECN被批准为拟议标准六个月后，12364个测试网站中的203个网站对ECN setup SYN数据包进行了重置，420个网站的ECN setup SYN数据包被丢弃。安装使用TCP保留字段中的标志阻止数据包的软件要比以后卸载该软件容易得多。
3.1. ECN: The Work-Around.
3.1. ECN：工作环境。
A work-around for maintaining connectivity in the face of the broken equipment was described in [Floyd00], and has been specified in RFC 3168 as a procedure that may be included in TCP implementations. We describe this work-around briefly below.
[Floyd00]中描述了在设备损坏时保持连接的解决方法，RFC 3168中已将其指定为TCP实现中可能包含的程序。我们在下面简要介绍这项工作。
To provide robust connectivity even in the presence of faulty equipment, a TCP host that receives a reset in response to the transmission of an ECN-setup SYN packet may resend the SYN with CWR and ECE cleared. This would result in a TCP connection being established without using ECN. This also has the unfortunate result of the ECN-capable TCP host not responding properly to the first valid reset. If a second reset is sent in response to the second SYN, which had CWR and ECE cleared, then the TCP host should respond properly by aborting the connection.
为了即使在存在故障设备的情况下也提供健壮的连接，接收到响应于ECN setup SYN数据包传输的重置的TCP主机可以在CWR和ECE清除的情况下重新发送SYN。这将导致在不使用ECN的情况下建立TCP连接。这还有一个不幸的结果，即支持ECN的TCP主机没有正确响应第一次有效重置。如果第二个SYN已清除CWR和ECE，则发送第二次重置以响应该SYN，则TCP主机应通过中止连接来正确响应。
Similarly, a host that receives no reply to an ECN-setup SYN within the normal SYN retransmission timeout interval may resend the SYN and any subsequent SYN retransmissions with CWR and ECE cleared. To overcome normal packet loss that results in the original SYN being lost, the originating host may retransmit one or more ECN-setup SYN packets before giving up and retransmitting the SYN with the CWR and ECE bits cleared.
类似地，在正常SYN重传超时间隔内未收到对ECN设置SYN的回复的主机可以在清除CWR和ECE的情况下重新发送SYN和任何后续SYN重传。为了克服导致原始SYN丢失的正常分组丢失，发起主机可以在放弃并在清除CWR和ECE位的情况下重新传输SYN之前重新传输一个或多个ECN setup SYN分组。
Some TCP implementors have so far decided not to deploy these workarounds, for the following reasons:
到目前为止，由于以下原因，一些TCP实现者决定不部署这些变通方法：
* The work-arounds would result in ECN-capable hosts not responding properly to the first valid reset received in response to a SYN packet.
* 这些解决方法将导致支持ECN的主机无法正确响应响应SYN数据包而接收到的第一个有效重置。
* The work-arounds would limit ECN functionality in environments without broken equipment, by disabling ECN where the first SYN or SYN-ACK packet was dropped in the network.
* 解决办法将通过在网络中丢弃第一个SYN或SYN-ACK数据包的情况下禁用ECN，从而限制ECN在没有损坏设备的环境中的功能。
* The work-arounds in many cases would involve a delay of six seconds or more before connectivity is established with the remote server, in the case of broken equipment that drops ECN-setup SYN packets. By accommodating this broken equipment, the work-arounds have been judged as implicitly accepting both this delay and the broken equipment that would be causing this delay.
* 在许多情况下，如果设备损坏，导致ECN setup SYN数据包丢失，在与远程服务器建立连接之前，解决方法可能需要延迟6秒或更长时间。通过容纳这些损坏的设备，工作环境被判定为隐含地接受了这一延迟以及可能导致这一延迟的损坏设备。
One possibility would be for such work-arounds to be configurable by the user.
一种可能性是用户可以配置这种变通方法。
One unavoidable consequence of the work-around of resending a modified SYN packet in response to a reset is to further erode the semantics of the TCP reset. Thus, when a box sends a reset, the TCP host receiving that reset does not know if the reset was sent simply because of the ECN-related flags in the TCP header, or because of some more fundamental problem. Therefore, the TCP host resends the TCP SYN packet without the ECN-related flags in the TCP header. The ultimate consequence of this absence of clear communications from the middlebox to the end-nodes could be an extended spiral of
为响应重置而重新发送修改的SYN数据包的一个不可避免的后果是进一步削弱TCP重置的语义。因此，当一个框发送重置时，接收重置的TCP主机不知道重置是否仅仅因为TCP报头中的ECN相关标志而发送，或者是因为一些更基本的问题。因此，TCP主机重新发送TCP SYN数据包，而不在TCP报头中使用ECN相关标志。这种从中间盒到终端节点之间缺乏清晰通信的最终结果可能是一个螺旋式的扩展
communications specified for transport protocols, as end nodes attempt to sacrifice as little functionality as possible in the process of determining which packets will and will not be forwarded to the other end. This is discussed in more detail in Section 6.1 below.
为传输协议指定的通信，因为终端节点在确定哪些数据包将转发到另一端和哪些数据包将不转发到另一端的过程中，试图牺牲尽可能少的功能。下文第6.1节对此进行了更详细的讨论。
4. On Combating Obstacles to the Proper Evolution of the Internet Infrastructure
4. 打击互联网基础设施适当发展的障碍
One of the reasons that this issue of inappropriate resets is important (to me) is that it has complicated the deployment of ECN in the Internet (though it has fortunately not blocked the deployment completely). It has also added an unnecessary obstacle to the future effectiveness of ECN.
（对我来说）这个不适当重置问题之所以重要的原因之一是它使ECN在Internet上的部署变得复杂（尽管幸运的是它没有完全阻止部署）。它还为电子计算机网络的未来有效性增加了不必要的障碍。
However, a second, more general reason why this issue is important is that the presence of equipment in the Internet that rejects valid TCP packets limits the future evolution of TCP, completely aside from the issue of ECN. That is, the widespread deployment of equipment that rejects TCP packets that use Reserved flags in the TCP header could effectively prevent the deployment of new mechanisms that use any of these Reserved flags. It doesn't matter if these new mechanisms have the protection of Experimental or Proposed Standard status from the IETF, because the broken equipment in the Internet does not stop to look up the current status of the protocols before rejecting the packets. TCP is good, and useful, but it would be a pity for the deployment of broken equipment in the Internet to result in the "freezing" of TCP in its current state, without the ability to use the Reserved flags in the future evolution of TCP.
然而，这个问题之所以重要的第二个更一般的原因是，互联网上存在拒绝有效TCP数据包的设备限制了TCP的未来发展，完全不包括ECN问题。也就是说，广泛部署拒绝在TCP报头中使用保留标志的TCP数据包的设备可以有效地防止部署使用这些保留标志中任何一个的新机制。这些新机制是否具有IETF的实验或拟议标准状态保护并不重要，因为互联网中的损坏设备在拒绝数据包之前不会停止查找协议的当前状态。TCP是好的、有用的，但如果在Internet上部署损坏的设备，导致TCP在其当前状态下“冻结”，而无法在TCP未来的演进中使用保留标志，那将是一个遗憾。
In the specific case of middleboxes that block TCP SYN packets attempting to negotiate ECN, the work-around described in Section 3.1 is sufficient to ensure that end-nodes could still establish connectivity. However, there are likely to be additional uses of the TCP Reserved Field standardized in the next year or two, and these additional uses might not coexist quite as successfully with middleboxes that send resets. Consider the difficulties that could result if a path changes in the middle of a connection's lifetime, and the middleboxes on the old and new paths have different policies about exactly which flags in the TCP Reserved field they would and would not block.
在阻止TCP SYN数据包尝试协商ECN的特定情况下，第3.1节中描述的解决方法足以确保终端节点仍然可以建立连接。然而，在未来一两年内，TCP保留字段的标准化可能会有更多的使用，并且这些额外的使用可能不会与发送重置的中间盒成功共存。考虑如果路径在连接的生命周期中间改变会导致的困难，并且旧路径和新路径上的中间框有不同的策略，确切地说，它们将在TCP保留字段中精确地标记哪些标记，而不会阻止。
Taking the wider view, the existence of web servers or firewalls that send inappropriate resets is only one example of functionality in the Internet that restricts the future evolution of the Internet. The impact of all of these small restrictions taken together presents a considerable obstacle to the development of the Internet architecture.
从更广泛的角度来看，发送不适当重置的web服务器或防火墙的存在只是互联网功能限制互联网未来发展的一个例子。所有这些小限制的影响加在一起对互联网体系结构的发展构成了相当大的障碍。
One lesson for designers of transport protocols is that transport protocols will have to protect themselves from the unknown and seemingly arbitrary actions of firewalls, normalizers, and other middleboxes in the network. For the moment, for TCP, this means sending a non-ECN-setup SYN when a reset is received in response to an ECN-setup SYN packet. Defensive actions on the side of transport protocols could include using Reserved flags in the SYN packet before using them in data traffic, to protect against middleboxes that block packets using those flags. It is possible that transport protocols will also have to add additional checks during the course of the connection lifetime to check for interference from middleboxes along the path.
传输协议设计者的一个教训是，传输协议必须保护自己不受防火墙、规范化器和网络中其他中间盒的未知和看似任意的操作的影响。目前，对于TCP，这意味着在接收到响应ECN setup SYN数据包的重置时发送非ECN setup SYN。传输协议方面的防御措施可能包括在数据通信中使用SYN数据包中的保留标志之前，先在SYN数据包中使用这些标志，以防止使用这些标志阻止数据包的中间包。传输协议可能还必须在连接生存期内添加额外的检查，以检查路径上来自中间盒的干扰。
The ECN standards document, RFC 3168, contains an extensive discussion in Section 18 on "Possible Changes to the ECN Field in the Network", but includes the following about possible changes to the TCP header:
ECN标准文件RFC 3168在第18节“网络中ECN字段的可能更改”中包含了广泛的讨论，但包括以下关于TCP标头可能更改的内容：
"This document does not consider potential dangers introduced by changes in the transport header within the network. We note that when IPsec is used, the transport header is protected both in tunnel and transport modes [ESP, AH]."
“该文档不考虑网络中传输头的更改引入的潜在危险。我们注意到，当使用IPSec时，传输头在隧道和传输模式中都受到保护[ESP，AH]。”
With the current modification of transport-level headers in the network by firewalls (as discussed below in Section 6.2), future protocol designers might no longer have the luxury of ignoring the possible impact of changes to the transport header within the network.
随着防火墙当前对网络中传输级报头的修改（如下文第6.2节所述），未来的协议设计者可能不再有机会忽略网络中传输报头更改的可能影响。
Transport protocols will also have to respond in some fashion to an ICMP code of "Communication Administratively Prohibited" if middleboxes start to use this form of the ICMP Destination Unreachable message to indicate that the packet is using functionality not allowed [RFC1812].
如果中间盒开始使用这种形式的ICMP目的地不可到达消息来指示数据包正在使用不允许的功能，则传输协议还必须以某种方式响应ICMP代码“通信管理禁止”[RFC1812]。
Given that some middleboxes are going to drop some packets because they use functionality not allowed by the middlebox, the larger issue remains of how middleboxes should communicate the reason for this action to the end-nodes, if at all. One suggestion, for consideration in more depth in a separate document, would be that firewalls send an ICMP Destination Unreachable message with the code "Communication Administratively Prohibited" [B01].
考虑到一些中间盒将丢弃一些数据包，因为它们使用了中间盒不允许的功能，更大的问题仍然是中间盒应如何将此操作的原因传达给终端节点（如果有的话）。一个建议是，防火墙发送一个ICMP目的地不可访问的消息，代码为“通信管理禁止”[B01]，以便在单独的文档中进行更深入的考虑。
We acknowledge that this is not an ideal solution, for several reasons. First, middleboxes along the reverse path might block these ICMP messages. Second, some firewall operators object to explicit communication because it reveals too much information about security policies. And third, the response of transport protocols to such an ICMP message is not yet specified.
我们承认，出于若干原因，这不是一个理想的解决办法。首先，反向路径上的中间盒可能会阻止这些ICMP消息。其次，一些防火墙运营商反对显式通信，因为它暴露了太多关于安全策略的信息。第三，尚未指定传输协议对此类ICMP消息的响应。
However, an ICMP "Administratively Prohibited" message could be a reasonable addition, for firewalls willing to use explicit communication. One possibility, again to be explored in a separate document, would be for the ICMP "Administratively Prohibited" message to be modified to convey additional information to the end host.
然而，对于愿意使用显式通信的防火墙来说，ICMP“管理禁止”消息可能是合理的添加。另一种可能性是修改ICMP“行政禁止”信息，以便向终端主机传达更多信息，这一可能性也将在单独的文件中探讨。
We would note that this document does not consider middleboxes that block complete transport protocols. We also note that this document is not addressing firewalls that send resets in response to a TCP SYN packet to a firewalled-off TCP port. Such a use of resets seems consistent with the semantics of TCP reset. This document is only considering the problems caused by middleboxes that block specific packets within a transport protocol when other packets from that transport protocol are forwarded by the middlebox unaltered.
我们注意到，该文档不考虑阻止完整传输协议的中间框。我们还注意到，本文档并不是针对响应TCP SYN数据包向防火墙关闭的TCP端口发送重置的防火墙。这种重置的使用似乎与TCP重置的语义一致。本文档仅考虑当来自传输协议的其他数据包由中间盒未经更改地转发时，中间盒阻止传输协议内特定数据包所引起的问题。
One complication is that once a mechanism is installed in a firewall to block a particular functionality, it can take considerable effort for network administrators to "un-install" that block. It has been suggested that tweakable settings on firewalls could make recovery from future incidents less painful all around. Again, because this document does not address more general issues about firewalls, the issue of greater firewall flexibility, and the attendant possible security risks, belongs in a separate document.
一个复杂的问题是，一旦在防火墙中安装了阻止特定功能的机制，网络管理员就需要花费相当大的努力才能“卸载”该阻止。有人建议，防火墙上可调整的设置可以减少从未来事件中恢复的痛苦。同样，由于本文档没有解决有关防火墙的更一般性问题，因此更大的防火墙灵活性问题以及随之而来的可能安全风险属于单独的文档。
Given a firewall that has decided to drop TCP packets that use reserved bits in the TCP header, one question is whether the firewall should also send a Reset, in order to prevent the TCP connection from consuming unnecessary resources at the TCP sender waiting for the retransmit timeout. We would argue that whether or not the firewall feels compelled to drop the TCP packet, it is not appropriate to send a TCP reset. Sending a TCP reset in response to prohibited functionality would continue the current overloading of the semantics of the TCP reset in a way that could be counterproductive all around.
考虑到防火墙已决定丢弃使用TCP报头中保留位的TCP数据包，一个问题是防火墙是否也应发送重置，以防止TCP连接在等待重新传输超时的TCP发送方消耗不必要的资源。我们认为，无论防火墙是否觉得必须丢弃TCP数据包，发送TCP重置都是不合适的。发送TCP重置以响应禁止的功能将继续当前TCP重置语义的过载，这可能会适得其反。
As an example, Section 2.3 has already observed that some firewalls send resets in response to TCP SYN packets as a congestion control mechanism. Possibly in response to this (or perhaps in response to something else), some popular TCP implementations immediately resend a SYN packet in response to a reset, up to four times. Other TCP
例如，第2.3节已经观察到一些防火墙发送重置以响应TCP SYN数据包作为拥塞控制机制。可能是为了响应这种情况（或者可能是为了响应其他情况），一些流行的TCP实现会立即重新发送SYN数据包以响应重置，最多四次。其他TCP
implementations, in conformance to the standards, don't resend SYN packets after receiving a reset. The more aggressive TCP implementations increase congestion for others, but also increase their own chances of eventually getting through. Giving these fluid semantics for the TCP reset, one might expect more TCP implementations to start resending SYN packets in response to a reset, completely apart from any issues having to do with ECN. Obviously, this weakens the effectiveness of the reset when used for its original purpose, of responding to TCP packets that apparently are not intended for the current connection.
按照标准，实现在接收到重置后不重新发送SYN数据包。更激进的TCP实现增加了其他人的拥塞，但也增加了他们自己最终通过的机会。考虑到TCP重置的这些流动语义，人们可能会期望更多的TCP实现开始重新发送SYN数据包以响应重置，而与任何与ECN有关的问题完全无关。显然，这削弱了重置的有效性，当重置用于其原始目的时，即响应显然不用于当前连接的TCP数据包。
If we add to this mix the use of the TCP reset by firewalls in response to TCP packets using reserved bits in the TCP header, this muddies the waters further. Because TCP resets could be sent due to congestion, or to prohibited functionality, or because a packet was received from a previous TCP connection, TCP implementations (or, more properly, TCP implementors) would now have an incentive to be even more persistent in resending SYN packets in response to TCP resets. In addition to the incentive mentioned above of resending TCP SYN packets to increase one's odds of eventually getting through in a time of congestion, the TCP reset might have been due to prohibited functionality instead of congestion, so the TCP implementation might resend SYN packets in different forms to determine exactly which functionality is being prohibited. Such a continual changing of the semantics of the TCP reset could be expected to lead to a continued escalation of measures and countermeasures between firewalls and end-hosts, with little productive benefit to either side.
如果我们将防火墙使用TCP重置来响应TCP数据包（使用TCP报头中的保留位）的使用添加到这个混合中，那么这会进一步搅乱局面。由于TCP重置可能由于拥塞或禁止的功能而发送，或者因为从以前的TCP连接接收到数据包，TCP实现（或者更恰当地说，TCP实现者）现在有了一个动机，即为了响应TCP重置而重新发送SYN数据包时更加持久。除了上述重新发送TCP SYN数据包以增加在拥塞时最终通过的几率的激励之外，TCP重置可能是由于禁用的功能而不是拥塞，因此，TCP实现可能会以不同的形式重新发送SYN数据包，以准确确定禁止哪些功能。TCP重置语义的这种持续变化可能会导致防火墙和终端主机之间的措施和对策不断升级，对任何一方都没有什么生产性好处。
It could be argued that *dropping* the TCP SYN packet due to the use of prohibited functionality leads to overloading of the semantics of a packet drop, in the same way that the reset leads to overloading the semantics of a reset. This is true; from the viewpoint of end-system response to messages with overloaded semantics, it would be preferable to have an explicit indication about prohibited functionality (for those firewalls for some reason willing to use explicit indications). But given a firewall's choice between sending a reset or just dropping the packet, we would argue that just dropping the packet does less damage, in terms of giving an incentive to end-hosts to adopt counter-measures. It is true that just dropping the packet, without sending a reset, results in delay for the TCP connection in resending the SYN packet without the prohibited functionality. However, sending a reset has the undesirable longer-term effect of giving an incentive to future TCP implementations to add more baroque combinations of resending SYN packets in response to a reset, because the TCP sender can't tell if the reset is for a standard reason, for congestion, or for the prohibited functionality of option X or reserved bit Y in the TCP header.
可以认为，由于使用禁止功能而*丢弃*TCP SYN数据包会导致数据包丢弃语义过载，与重置导致重置语义过载的方式相同。这是真的；从终端系统对具有重载语义的消息的响应的角度来看，最好有一个关于禁止功能的明确指示（对于出于某种原因愿意使用明确指示的防火墙）。但考虑到防火墙在发送重置或丢弃数据包之间的选择，我们会认为丢弃数据包造成的损害较小，这会激励终端主机采取应对措施。确实，在不发送重置的情况下丢弃数据包会导致TCP连接在没有禁止功能的情况下重新发送SYN数据包时出现延迟。然而，发送重置具有不希望的长期效果，即激励未来的TCP实现添加更多巴洛克式的重新发送SYN数据包组合以响应重置，因为TCP发送方无法判断重置是否出于标准原因、拥塞，或用于TCP标头中选项X或保留位Y的禁用功能。
In addition to firewalls that send resets in response to ECN-setup SYN packets and firewalls that drop ECN-setup SYN packets, there also exist firewalls that by default zero the flags in the TCP Reserved field, including the two flags used for ECN. We note that in some cases this could have unintended and undesirable consequences.
除了响应ECN setup SYN数据包发送重置的防火墙和丢弃ECN setup SYN数据包的防火墙外，还存在默认情况下将TCP保留字段中的标志归零的防火墙，包括用于ECN的两个标志。我们注意到，在某些情况下，这可能会产生意想不到的不良后果。
If a firewall zeros the ECN-related flags in the TCP header in the initial SYN packet, then the TCP connection will be set up without using ECN, and the ECN-related flags in the TCP header will be sent zeroed-out in all of the subsequent packets in this connection. This will accomplish the firewall's purpose of blocking ECN, while allowing the TCP connection to proceed efficiently and smoothly without using ECN.
如果防火墙将初始SYN数据包中TCP报头中的ECN相关标志归零，则TCP连接将在不使用ECN的情况下建立，并且TCP报头中的ECN相关标志将在该连接中的所有后续数据包中发送归零。这将实现防火墙阻止ECN的目的，同时允许TCP连接在不使用ECN的情况下高效、顺利地进行。
If for some reason the ECN-related flags in the TCP header aren't zeroed in the initial SYN packet from host A to host B, but the firewall does zero those flags in the responding SYN/ACK packet from host B to host A, the consequence could be to subvert end-to-end congestion control for this connection. The ECN specifications were not written to ensure robust operation in the presence of the arbitrary zeroing of TCP header fields within the network, because it didn't occur to the authors of the protocol at the time that this was a requirement in protocol design.
如果出于某种原因，TCP报头中的ECN相关标志在从主机A到主机B的初始SYN数据包中没有归零，但防火墙在从主机B到主机A的响应SYN/ACK数据包中没有归零这些标志，则结果可能会破坏此连接的端到端拥塞控制。编写ECN规范并不是为了确保在网络中存在TCP头字段任意归零的情况下稳健运行，因为协议的作者在协议设计时没有想到这是一项要求。
Similarly, if the ECN-related flags in the TCP header are not zeroed in either the SYN or the SYN/ACK packet, but the firewall does zero these flags in later packets in that TCP connection, this could also have the unintended consequence of subverting end-to-end congestion control for this connection. The details of these possible interactions are not crucial for this document, and are described in the appendix. However, our conclusion, both for the ECN-related flags in the TCP header and for future uses of the four other bits in the TCP Reserved field, would be that if it is required for firewalls to be able to block the use of a new function being added to a protocol, this is best addressed in the initial design phase by joint cooperation between the firewall community and the protocol designers.
类似地，如果TCP报头中的ECN相关标志在SYN或SYN/ACK数据包中未归零，但防火墙在该TCP连接中的后续数据包中未归零这些标志，则这也可能会产生颠覆此连接的端到端拥塞控制的意外后果。这些可能相互作用的细节对本文件并不重要，附录中对此进行了描述。然而，对于TCP报头中与ECN相关的标志以及TCP保留字段中其他四位的未来使用，我们的结论是，如果防火墙需要能够阻止使用添加到协议中的新功能，在最初的设计阶段，最好通过防火墙社区和协议设计者之间的联合合作来解决这一问题。
Our conclusion is that it is not conformant with current standards for a firewall, load-balancer, or web-server to respond with a reset to a TCP SYN packet simply because the packet uses flags in the TCP Reserved field. More specifically, it is not conformant to respond with a reset to a TCP SYN packet simply because the ECE and CWR flags are set in the IP header. We would urge vendors to make available
我们的结论是，仅仅因为TCP SYN数据包使用TCP保留字段中的标志，防火墙、负载平衡器或web服务器响应TCP SYN数据包的重置不符合当前标准。更具体地说，仅仅因为在IP报头中设置了ECE和CWR标志，所以用对TCP SYN数据包的重置来响应是不一致的。我们将敦促供应商提供
fixes for any nonconformant code, and we could urge ISPs and system administrators to deploy these fixes in their web servers and firewalls.
我们可以敦促ISP和系统管理员在其web服务器和防火墙中部署这些修复程序。
We don't claim that it violates any standard for middleboxes to arbitrarily drop packets that use flags in the TCP Reserved field, but we would argue that behavior of this kind, without a clear method for informing the end-nodes of the reasons for these actions, could present a significant obstacle to the development of TCP. More work is clearly needed to reconcile the conflicting interests of providing security while at the same time allowing the careful evolution of Internet protocols.
我们并不认为，在TCP保留字段中任意丢弃使用标志的数据包违反了任何中间包标准，但我们认为，如果没有明确的方法将这些操作的原因告知终端节点，这种行为可能会对TCP的发展造成重大障碍。显然需要做更多的工作来调和提供安全性的利益冲突，同时允许互联网协议的谨慎演变。
This document results from discussions and activity by many people, so I will refrain from trying to acknowledge all of them here. My specific thanks go to Ran Atkinson, Steve Bellovin, Alex Cannara, Dennis Ferguson, Ned Freed, Mark Handley, John Klensin, Allison Mankin, Jitendra Padhye, Vern Paxson, K. K. Ramakrishnan, Jamal Hadi Salim, Pekka Savola, Alex Snoeren, and Dan Wing for feedback on this document, and to the End-to-End Research Group, the IAB, and the IESG for discussion of these issues. I thank Mikael Olsson for numerous rounds of feedback. I also thank the members of the Firewall Wizards mailing list for feedback (generally of disagreement) on an earlier draft of this document.
本文件是许多人讨论和活动的结果，因此我在此不再试图承认所有这些内容。我特别感谢Ran Atkinson、Steve Bellovin、Alex Cannara、Dennis Ferguson、Ned Freed、Mark Handley、John Klesins、Allison Mankin、Jitendra Padhye、Vern Paxson、K.K.Ramakrishnan、Jamal Hadi Salim、Pekka Savola、Alex Snoren和Dan Wing对本文件的反馈，以及端到端研究小组IAB，以及IESG对这些问题的讨论。我感谢米凯尔·奥尔森的多次反馈。我还感谢Firewall Wizards邮件列表的成员对本文档早期草稿的反馈（通常是不一致的）。
Email discussions with a number of people, including Dax Kelson, Alexey Kuznetsov, Kacheong Poon, David Reed, Jamal Hadi-Salim, and Venkat Venkatsubra, have addressed the issues raised by non-conformant equipment in the Internet that does not respond to TCP SYN packets with the ECE and CWR flags set. We thank Mark Handley, Jitentra Padhye, and others for discussions on the TCP initialization procedures.
与许多人（包括Dax Kelson、Alexey Kuznetsov、Kacheong Poon、David Reed、Jamal Hadi Salim和Venkat Venkatsubra）的电子邮件讨论解决了互联网上不符合要求的设备所引发的问题，这些设备不响应设置ECE和CWR标志的TCP SYN数据包。我们感谢Mark Handley、Jitentra Padhye和其他人对TCP初始化过程的讨论。
[RFC793] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议-DARPA互联网程序协议规范”，STD 7，RFC 793，1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求——通信层”，标准3，RFC 1122，1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[RFC2481]Ramakrishnan，K.和S.Floyd，“向IP添加明确拥塞通知（ECN）的提案”，RFC 2481，1999年1月。
[RFC2873] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP Processing of the IPv4 Precedence Field, RFC 2873, June 2000.
[RFC2873]Xiao，X.，Hannan，A.，Paxson，V.，和E.Crabbe，“IPv4优先字段的TCP处理，RFC 28732000年6月。
[RFC2979] Freed, N., " Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979]弗里德，N.，“互联网防火墙的行为和要求”，RFC 2979，2000年10月。
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[B01] Bellovin, S., "A "Reason" Field for ICMP "Administratively Prohibited" Messages", Work in Progress.
[B01]Bellovin，S.，ICMP“行政禁止”消息的“原因”字段，正在进行中。
[Cou01] Scott Courtney, Why Can't My 2.4 Kernel See Some Web Sites?, Enterprise Linux Today, Apr 17, 2001. URL "http://eltoday.com/article.php3?ltsn=2001-04-17-001-14- PS".
[Cou01]Scott Courtney，为什么我的2.4内核看不到一些网站？，《今日企业Linux》，2001年4月17日。URL“http://eltoday.com/article.php3?ltsn=2001-04-17-001-14-PS”。
[ECN] "The ECN Web Page", URL "http://www.icir.org/floyd/ecn.html".
[ECN]“ECN网页”，URLhttp://www.icir.org/floyd/ecn.html".
[FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL "http://gtf.org/garzik/ecn/".
[FIXES]Linux下的ECN非官方供应商支持页面，URL“http://gtf.org/garzik/ecn/".
[Floyd00] Sally Floyd, Negotiating ECN-Capability in a TCP connection, October 2, 2000, email to the end2end-interest mailing list. URL "http://www.icir.org/floyd/papers/ECN.Oct2000.txt".
[Floyd00]Sally Floyd，在TCP连接中协商ECN能力，2000年10月2日，通过电子邮件发送至End2 End interest邮件列表。URL“http://www.icir.org/floyd/papers/ECN.Oct2000.txt".
[Kelson00] Dax Kelson, note sent to the Linux kernel mailing list, September 10, 2000.
[Kelson00]Dax Kelson，注意发送到Linux内核邮件列表，2000年9月10日。
[QUESO] Toby Miller, Intrusion Detection Level Analysis of Nmap and Queso, August 30, 2000. URL "http://www.securityfocus.com/infocus/1225".
[QUESO]Toby Miller，Nmap和QUESO的入侵检测级别分析，2000年8月30日。URL“http://www.securityfocus.com/infocus/1225".
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[Ste94]Stevens，W.“TCP/IP图解，第1卷：协议”，Addison-Wesley，1994年。
[SFO01] FreeBSD ipfw Filtering Evasion Vulnerability, Security Focus Online, January 23, 2001. URL "http://www.securityfocus.com/bid/2293".
[SFO01]FreeBSD ipfw过滤规避漏洞，安全关注在线，2001年1月23日。URL“http://www.securityfocus.com/bid/2293".
[TBIT] Jitendra Padhye and Sally Floyd, Identifying the TCP Behavior of Web Servers, SIGCOMM, August 2001. URL "http://www.icir.org/tbit/".
[TBIT]Jitendra Padhye和Sally Floyd，识别Web服务器的TCP行为，SIGCOMM，2001年8月。URL“http://www.icir.org/tbit/".
One general risk of using Reserved flags in TCP is the risk of providing additional information about the configuration of the host in question. However, TCP is sufficiently loosely specified as it is, with sufficiently many variants and options, that port-scanning tools such as Nmap and Queso do rather well in identifying the configuration of hosts even without the use of Reserved flags.
在TCP中使用保留标志的一个常见风险是提供有关主机配置的附加信息的风险。但是，TCP的指定非常松散，有足够多的变体和选项，因此端口扫描工具（如Nmap和Queso）即使不使用保留标志也能很好地识别主机的配置。
The security considerations and all other considerations of a possible ICMP Destination Unreachable message with the code "Communication Administratively Prohibited" will be discussed in a separate document.
代码为“通信管理禁止”的可能ICMP目的地不可访问消息的安全注意事项和所有其他注意事项将在单独的文件中讨论。
The traditional concern of firewalls is to prevent unauthorized access to systems, to prevent DoS attacks and other attacks from subverting the end-user terminal, and to protect end systems from buggy code. We are aware of one security vulnerability reported from the use of the Reserved flags in the TCP header [SFO01]. A packet filter intended only to let through packets in established connections can let pass a packet not in an established connection if the packet has the ECE flag set in the reserved field. "Exploitation of this vulnerability may allow for unauthorized remote access to otherwise protected services." It is also possible that an implementation of TCP could appear that has buggy code associated with the use of Reserved flags in the TCP header, but we are not aware of any such implementation at the moment.
防火墙的传统关注点是防止未经授权访问系统，防止DoS攻击和其他攻击破坏最终用户终端，并保护最终系统不受错误代码的影响。我们知道，由于使用TCP标头[SFO01]中的保留标志，报告了一个安全漏洞。如果包在保留字段中设置了ECE标志，则仅用于让已建立连接中的包通过的包过滤器可以让未建立连接的包通过。“利用此漏洞可允许对其他受保护的服务进行未经授权的远程访问。”还可能出现TCP实现，该实现可能包含与TCP标头中保留标志的使用相关联的错误代码，但我们目前尚未发现任何此类实现。
Unfortunately, misconceived security concerns are one of the reasons for the problems described in this document in the first place. An August, 2000, article on "Intrusion Detection Level Analysis of Nmap and Queso" described the port-scanning tool Queso as sending SYN packets with the last two Reserved bits in the TCP header set, and said the following: "[QUESO] is easy to identify, if you see [these two Reserved bits and the SYN bit] set in the 13th byte of the TCP header, you know that someone has malicious intentions for your network." As is documented on the TBIT Web Page, the middleboxes
不幸的是，误解的安全问题是本文档中首先描述的问题的原因之一。2000年8月，一篇关于“Nmap和Queso的入侵检测级别分析”的文章描述了端口扫描工具Queso发送带有TCP头集中最后两个保留位的SYN数据包，并说：“[Queso]很容易识别，如果您看到[这两个保留位和SYN位]设置在TCP头的第13个字节中，您知道有人对您的网络有恶意。”正如TBIT网页上记录的，中间框
that block SYNs using the two ECN-related Reserved flags in the TCP header do not block SYNs using other Reserved flags in the TCP header.
使用TCP标头中两个ECN相关保留标志的阻止SYN不会阻止使用TCP标头中其他保留标志的SYN。
One lesson appears to be that anyone can effectively "attack" a new TCP function simply by using that function in their publicly-available port-scanning tool, thus causing middleboxes of all kinds to block the use of that function.
一个教训似乎是，任何人只要在其公开可用的端口扫描工具中使用新的TCP功能，就可以有效地“攻击”该功能，从而导致各种中间盒阻止该功能的使用。
In this section we first show that if the ECN-related flags in the TCP header aren't zeroed in the initial SYN packet from Host A to Host B, but are zeroed in the responding SYN/ACK packet from Host B to Host A, the consequence could be to subvert end-to-end congestion control for this connection.
在本节中，我们首先说明，如果TCP报头中与ECN相关的标志在从主机A到主机B的初始SYN数据包中没有归零，而是在从主机B到主机A的响应SYN/ACK数据包中归零，那么结果可能会破坏此连接的端到端拥塞控制。
Assume that the ECN-setup SYN packet from Host A is received by Host B, but the ECN-setup SYN/ACK from Host B is modified by a firewall in the network to a non-ECN-setup SYN/ACK, as in Figure 3 below. RFC 3168 does not specify that the ACK packet in any way should echo the TCP flags received in the SYN/ACK packet, because it had not occurred to the designers that these flags would be modified within the network.
假设主机B接收到来自主机A的ECN setup SYN数据包，但来自主机B的ECN setup SYN/ACK被网络中的防火墙修改为非ECN setup SYN/ACK，如下图3所示。RFC 3168未指定ACK数据包以任何方式应回显SYN/ACK数据包中接收到的TCP标志，因为设计者没有想到这些标志会在网络中被修改。
Host A Firewall or router Host B
-----------------------------------------------------------------
Sends ECN-setup SYN ----------------> Receives ECN-setup SYN
<- Sends ECN-setup SYN/ACK
<- Firewall zeros flags
Receives non-ECN-setup SYN/ACK
Sends ACK and data ----------------> Receives ACK and data
<- Sends data packet with ECT
<- Router sets CE
Receives data packet with ECT and CE
Host A Firewall or router Host B
-----------------------------------------------------------------
Sends ECN-setup SYN ----------------> Receives ECN-setup SYN
<- Sends ECN-setup SYN/ACK
<- Firewall zeros flags
Receives non-ECN-setup SYN/ACK
Sends ACK and data ----------------> Receives ACK and data
<- Sends data packet with ECT
<- Router sets CE
Receives data packet with ECT and CE
Figure 3: ECN-related flags in SYN/ACK packet cleared in network.
图3：在网络中清除SYN/ACK数据包中的ECN相关标志。
Following RFC 3168, Host A has received a non-ECN-setup SYN/ACK packet, and must not set ECT on data packets. Host B, however, does not know that Host A has received a non-ECN-setup SYN/ACK packet, and Host B may set ECT on data packets. RFC 3168 does not require Host A to respond properly to data packets received from Host B with the ECT and CE codepoints set in the IP header. Thus, the data sender, Host B, might never be informed about the congestion encountered in the network, thus violating end-to-end congestion control.
在RFC 3168之后，主机A已接收到非ECN设置SYN/ACK数据包，并且不得在数据包上设置ECT。然而，主机B不知道主机A已接收到非ECN设置SYN/ACK分组，并且主机B可在数据分组上设置ECT。RFC 3168不要求主机A使用IP报头中设置的ECT和CE代码点正确响应从主机B接收的数据包。因此，数据发送方主机B可能永远不会被告知网络中遇到的拥塞，从而违反端到端拥塞控制。
Next we show that if the ECN-related flags in the TCP header are not zeroed in either the SYN or the SYN/ACK packet, but the firewall does zero these flags in later packets in that TCP connection, this could also have the unintended consequence of subverting end-to-end congestion control for this connection. Figure 4 shows this scenario.
接下来，我们将说明，如果TCP报头中的ECN相关标志在SYN或SYN/ACK数据包中未归零，但防火墙在该TCP连接的后续数据包中确实归零了这些标志，那么这也可能会产生破坏该连接的端到端拥塞控制的意外后果。图4显示了这个场景。
Host A Firewall or router Host B
-----------------------------------------------------------------
Sends ECN-setup SYN ----------------> Receives ECN-setup SYN
Receives ECN-setup SYN/ACK <------------ Sends ECN-setup SYN/ACK
Sends ACK and data ----------------> Receives ACK and data
<- Sends data packet with ECT
<- Router sets CE
Receives data packet with ECT and CE
Sends ACK with ECE ->
Firewall resets ECE ->
Receives plain ACK
Host A Firewall or router Host B
-----------------------------------------------------------------
Sends ECN-setup SYN ----------------> Receives ECN-setup SYN
Receives ECN-setup SYN/ACK <------------ Sends ECN-setup SYN/ACK
Sends ACK and data ----------------> Receives ACK and data
<- Sends data packet with ECT
<- Router sets CE
Receives data packet with ECT and CE
Sends ACK with ECE ->
Firewall resets ECE ->
Receives plain ACK
Figure 4: ECN-related flags in ACK packet cleared in network.
图4：网络中清除的ACK数据包中的ECN相关标志。
The ECN-related flags are not changed by the network in the ECN-setup SYN and SYN/ACK packets for the scenario in Figure 4, and both end nodes are free to use ECN, and to set the ECT flag in the ECN field in the IP header. However, if the firewall clears the ECE flag in the TCP header in ACK packets from Node A to Node B, then Node B will never hear about the congestion that its earlier data packets encountered in the network, thus subverting end-to-end congestion control for this connection.
对于图4中的场景，网络不会更改ECN设置SYN和SYN/ACK数据包中与ECN相关的标志，两个终端节点都可以自由使用ECN，并在IP报头的ECN字段中设置ECT标志。但是，如果防火墙清除从节点A到节点B的ACK数据包中TCP报头中的ECE标志，则节点B将永远不会听到其早期数据包在网络中遇到的拥塞，从而破坏此连接的端到端拥塞控制。
Additional complications will arise when/if the use of the ECN nonce in TCP becomes standardized in the IETF [RFC3168], as this could involve the specification of an additional flag from the TCP Reserved field for feedback from the TCP data receiver to the TCP data sender. The primary motivation for the ECN nonce is to allow mechanisms for the data sender to verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set.
当/如果在IETF[RFC3168]中对TCP中的ECN nonce的使用变得标准化，则会出现额外的复杂情况，因为这可能涉及从TCP保留字段指定额外的标志，用于从TCP数据接收器反馈到TCP数据发送者。ECN nonce的主要动机是允许数据发送方的机制验证网络元素没有擦除CE码点，并且数据接收方正确地向发送方报告接收到具有CE码点集的数据包。
There are no IANA considerations in this document.
本文件中没有IANA注意事项。
Sally Floyd ICIR (ICSI Center for Internet Research)
Sally Floyd ICIR（ICSI互联网研究中心）
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。