Internet Engineering Task Force (IETF) M. Larsen
Request for Comments: 6056 Tieto
BCP: 156 F. Gont
Category: Best Current Practice UTN/FRH
ISSN: 2070-1721 January 2011
Internet Engineering Task Force (IETF) M. Larsen
Request for Comments: 6056 Tieto
BCP: 156 F. Gont
Category: Best Current Practice UTN/FRH
ISSN: 2070-1721 January 2011
Recommendations for Transport-Protocol Port Randomization
传输协议端口随机化建议
Abstract
摘要
During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers).
在过去几年中，人们已经意识到了一些可以针对传输控制协议（TCP）和类似协议执行的“盲”攻击。这些攻击的后果从吞吐量降低到连接中断或数据损坏。这些攻击依赖于攻击者猜测或知道标识要攻击的传输协议实例的五个元组（协议、源地址、目标地址、源端口、目标端口）的能力。本文档介绍了选择客户端端口号的一些简单而有效的方法，从而减少了攻击者猜测确切值的可能性。虽然这并不能替代用于保护传输协议实例的加密方法，但前面提到的端口选择算法提供了改进的安全性，只需很少的努力，并且没有任何密钥管理开销。本文档中描述的算法是可以增量部署的本地策略，并且不会违反可能从中受益的任何传输协议的规范，例如TCP、UDP、UDP lite、流控制传输协议（SCTP）、数据报拥塞控制协议（DCCP）和RTP（前提是RTP应用程序明确表示RTP和RTCP端口号）。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6056.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6056.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 5
2.2. Ephemeral Port Selection . . . . . . . . . . . . . . . . . 6
2.3. Collision of instance-ids . . . . . . . . . . . . . . . . 7
3. Obfuscating the Ephemeral Port Selection . . . . . . . . . . . 8
3.1. Characteristics of a Good Algorithm for the
Obfuscation of the Ephemeral Port Selection . . . . . . . 8
3.2. Ephemeral Port Number Range . . . . . . . . . . . . . . . 10
3.3. Algorithms for the Obfuscation of the Ephemeral Port
Selection . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Algorithm 1: Simple Port Randomization Algorithm . . . 11
3.3.2. Algorithm 2: Another Simple Port Randomization
Algorithm . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3. Algorithm 3: Simple Hash-Based Port Selection
Algorithm . . . . . . . . . . . . . . . . . . . . . . 14
3.3.4. Algorithm 4: Double-Hash Port Selection Algorithm . . 16
3.3.5. Algorithm 5: Random-Increments Port Selection
Algorithm . . . . . . . . . . . . . . . . . . . . . . 18
3.4. Secret-Key Considerations for Hash-Based Port
Selection Algorithms . . . . . . . . . . . . . . . . . . . 19
3.5. Choosing an Ephemeral Port Selection Algorithm . . . . . . 20
4. Interaction with Network Address Port Translation (NAPT) . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Survey of the Algorithms in Use by Some Popular
Implementations . . . . . . . . . . . . . . . . . . . 28
A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Traditional Ephemeral Port Range . . . . . . . . . . . . . 5
2.2. Ephemeral Port Selection . . . . . . . . . . . . . . . . . 6
2.3. Collision of instance-ids . . . . . . . . . . . . . . . . 7
3. Obfuscating the Ephemeral Port Selection . . . . . . . . . . . 8
3.1. Characteristics of a Good Algorithm for the
Obfuscation of the Ephemeral Port Selection . . . . . . . 8
3.2. Ephemeral Port Number Range . . . . . . . . . . . . . . . 10
3.3. Algorithms for the Obfuscation of the Ephemeral Port
Selection . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Algorithm 1: Simple Port Randomization Algorithm . . . 11
3.3.2. Algorithm 2: Another Simple Port Randomization
Algorithm . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3. Algorithm 3: Simple Hash-Based Port Selection
Algorithm . . . . . . . . . . . . . . . . . . . . . . 14
3.3.4. Algorithm 4: Double-Hash Port Selection Algorithm . . 16
3.3.5. Algorithm 5: Random-Increments Port Selection
Algorithm . . . . . . . . . . . . . . . . . . . . . . 18
3.4. Secret-Key Considerations for Hash-Based Port
Selection Algorithms . . . . . . . . . . . . . . . . . . . 19
3.5. Choosing an Ephemeral Port Selection Algorithm . . . . . . 20
4. Interaction with Network Address Port Translation (NAPT) . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Survey of the Algorithms in Use by Some Popular
Implementations . . . . . . . . . . . . . . . . . . . 28
A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 28
Recently, awareness has been raised about a number of "blind" attacks (i.e., attacks that can be performed without the need to sniff the packets that correspond to the transport protocol instance to be attacked) that can be performed against the Transmission Control Protocol (TCP) [RFC0793] and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption [RFC5927] [RFC4953] [Watson].
最近，人们已经意识到可以针对传输控制协议（TCP）[RFC0793]和类似协议执行的一些“盲”攻击（即，可以在不需要嗅探与要攻击的传输协议实例相对应的数据包的情况下执行的攻击）。这些攻击的后果包括吞吐量降低、连接中断或数据损坏[RFC5927][RFC4953][Watson]。
All these attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Source port, Destination Address, Destination Port) that identifies the transport protocol instance to be attacked.
所有这些攻击都依赖于攻击者猜测或知道标识要攻击的传输协议实例的五个元组（协议、源地址、源端口、目标地址、目标端口）的能力。
Services are usually located at fixed, "well-known" ports [IANA] at the host supplying the service (the server). Client applications connecting to any such service will contact the server by specifying the server IP address and service port number. The IP address and port number of the client are normally left unspecified by the client application and thus are chosen automatically by the client networking stack. Ports chosen automatically by the networking stack are known as ephemeral ports [Stevens].
服务通常位于提供服务的主机（服务器）上的固定“知名”端口[IANA]。连接到任何此类服务的客户端应用程序将通过指定服务器IP地址和服务端口号与服务器联系。客户端应用程序通常不指定客户端的IP地址和端口号，因此由客户端网络堆栈自动选择。网络堆栈自动选择的端口称为临时端口[Stevens]。
While the server IP address, the well-known port, and the client IP address may be known by an attacker, the ephemeral port of the client is usually unknown and must be guessed.
虽然攻击者可能知道服务器IP地址、已知端口和客户端IP地址，但客户端的临时端口通常是未知的，必须猜测。
This document describes a number of algorithms for the selection of ephemeral port numbers, such that the possibility of an off-path attacker guessing the exact value is reduced. They are not a replacement for cryptographic methods of protecting a transport-protocol instance such as IPsec [RFC4301], the TCP MD5 signature option [RFC2385], or the TCP Authentication Option [RFC5925]. For example, they do not provide any mitigation in those scenarios in which the attacker is able to sniff the packets that correspond to the transport protocol instance to be attacked. However, the proposed algorithms provide improved resistance to off-path attacks with very little effort and without any key management overhead.
本文档描述了一些用于选择临时端口号的算法，从而减少了路径外攻击者猜测确切值的可能性。它们不能替代保护传输协议实例的加密方法，如IPsec[RFC4301]、TCP MD5签名选项[RFC2385]或TCP身份验证选项[RFC5925]。例如，在攻击者能够嗅探与要攻击的传输协议实例相对应的数据包的情况下，它们不提供任何缓解措施。然而，所提出的算法在不增加任何密钥管理开销的情况下，只需很少的努力就可以提高对非路径攻击的抵抗能力。
The mechanisms described in this document are local modifications that may be incrementally deployed, and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550] (provided the RTP application explicitly signals the RTP and RTCP port numbers with, e.g., [RFC3605]).
本文档中描述的机制是可以增量部署的本地修改，并且不违反可能从中受益的任何传输协议的规范，例如TCP[RFC0793]、UDP[RFC0768]、SCTP[RFC4960]、DCCP[RFC4340]、UDP lite[RFC3828]和RTP[RFC3550]（前提是RTP应用程序明确地向RTP和RTCP端口号发送信号，例如[RFC3605]）。
Since these mechanisms are obfuscation techniques, focus has been on a reasonable compromise between the level of obfuscation and the ease of implementation. Thus, the algorithms must be computationally efficient and not require substantial state.
由于这些机制都是模糊处理技术，所以重点放在模糊处理级别和易于实现之间的合理折衷上。因此，算法必须具有计算效率，并且不需要大量的状态。
We note that while the technique of mitigating "blind" attacks by obfuscating the ephemeral port selection is well-known as "port randomization", the goal of the algorithms described in this document is to reduce the chances of an attacker guessing the ephemeral ports selected for new transport protocol instances, rather than to actually produce mathematically random sequences of ephemeral ports.
我们注意到，虽然通过混淆临时端口选择来缓解“盲”攻击的技术被称为“端口随机化”，但本文中描述的算法的目标是减少攻击者猜测为新传输协议实例选择的临时端口的机会，而不是实际产生数学上随机的短暂端口序列。
Throughout this document, we will use the term "transport-protocol instance" as a general term to refer to an instantiation of a transport protocol (e.g., a "connection" in the case of connection-oriented transport protocols) and the term "instance-id" as a short-handle to refer to the group of values that identify a transport-protocol instance (e.g., in the case of TCP, the five-tuple {Protocol, IP Source Address, TCP Source Port, IP Destination Address, TCP Destination Port}).
在本文档中，我们将使用术语“传输协议实例”作为通用术语来指代传输协议的实例化（例如，在面向连接的传输协议的情况下为“连接”），并使用术语“实例id”作为短句柄来指代标识传输协议实例的一组值（例如，在TCP的情况下，五元组{协议，IP源地址，TCP源端口，IP目标地址，TCP目标端口}）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The Internet Assigned Numbers Authority (IANA) assigns the unique parameters and values used in protocols developed by the Internet Engineering Task Force (IETF), including well-known ports [IANA]. IANA has reserved the following use of the 16-bit port range of TCP and UDP:
互联网分配号码管理局（IANA）分配互联网工程任务组（IETF）开发的协议中使用的唯一参数和值，包括知名端口[IANA]。IANA已保留TCP和UDP的16位端口范围的以下用途：
o The Well-Known Ports, 0 through 1023.
o 众所周知的端口，0到1023。
o The Registered Ports, 1024 through 49151
o 注册端口，1024到49151
o The Dynamic and/or Private Ports, 49152 through 65535
o 动态和/或专用端口，49152到65535
The dynamic port range defined by IANA consists of the 49152-65535 range, and is meant for the selection of ephemeral ports.
IANA定义的动态端口范围包括49152-65535范围，用于选择临时端口。
As each communication instance is identified by the five-tuple {protocol, local IP address, local port, remote IP address, remote port}, the selection of ephemeral port numbers must result in a unique five-tuple.
由于每个通信实例都由五元组{protocol，local IP address，local port，remote IP address，remote port}标识，因此临时端口号的选择必须产生唯一的五元组。
Selection of ephemeral ports such that they result in unique instance-ids (five-tuples) is handled by some implementations by having a per-protocol global "next_ephemeral" variable that is equal to the previously chosen ephemeral port + 1, i.e., the selection process is:
一些实现通过使用一个每协议全局“next_ephemeral”变量（该变量等于先前选择的临时端口+1）来处理临时端口的选择，以使其产生唯一的实例ID（五个元组），即，选择过程为：
/* Initialization at system boot time. Could be random */
next_ephemeral = min_ephemeral;
/* Initialization at system boot time. Could be random */
next_ephemeral = min_ephemeral;
/* Ephemeral port selection function */
count = max_ephemeral - min_ephemeral + 1;
/* Ephemeral port selection function */
count = max_ephemeral - min_ephemeral + 1;
do {
port = next_ephemeral;
if (next_ephemeral == max_ephemeral) {
next_ephemeral = min_ephemeral;
} else {
next_ephemeral++;
}
do {
port = next_ephemeral;
if (next_ephemeral == max_ephemeral) {
next_ephemeral = min_ephemeral;
} else {
next_ephemeral++;
}
if (check_suitable_port(port)) return port;
如果（检查合适的_端口（端口））返回端口；
count--;
计数--；
} while (count > 0);
} while (count > 0);
return ERROR;
返回误差；
Traditional BSD Port Selection Algorithm
传统的BSD端口选择算法
Note: check_suitable_port() is a function that checks whether the resulting port number is acceptable as an ephemeral port. That is, it checks whether the resulting port number is unique and may, in addition, check that the port number is not in use for a connection in the LISTEN or CLOSED states and that the port number is not in the list of port numbers that should not be allocated as ephemeral ports. In BSD-derived systems, the check_suitable_port() would correspond to the in_pcblookup_local() function, where all the necessary checks would be performed.
注意：check_suggest_port（）是一个函数，用于检查生成的端口号是否可以接受为临时端口。也就是说，它检查生成的端口号是否唯一，并且还可以检查端口号是否未用于侦听或关闭状态下的连接，以及端口号是否不在不应分配为临时端口的端口号列表中。在BSD派生的系统中，check_-property_-port（）将对应于In_-pcblookup_-local（）函数，其中将执行所有必要的检查。
This algorithm works adequately provided that the number of transport-protocol instances (for each transport protocol) that have a lifetime longer than it takes to exhaust the total ephemeral port range is small, so that collisions of instance-ids are rare.
如果生存期长于耗尽整个临时端口范围所需时间的传输协议实例（对于每个传输协议）数量较少，则此算法可以充分发挥作用，因此实例ID的冲突很少。
However, this method has the drawback that the "next_ephemeral" variable and thus the ephemeral port range is shared between all transport-protocol instances, and the next ports chosen by the client are easy to predict. If an attacker operates an "innocent" server to which the client connects, it is easy to obtain a reference point for the current value of the "next_ephemeral" variable. Additionally, if an attacker could force a client to periodically establish, e.g., a new TCP connection to an attacker-controlled machine (or through an attacker-observable path), the attacker could subtract consecutive source port values to obtain the number of outgoing TCP connections established globally by the target host within that time period (up to wrap-around issues and instance-id collisions, of course).
然而，这种方法的缺点是“next_ephemeral”变量和临时端口范围在所有传输协议实例之间共享，并且客户端选择的下一个端口很容易预测。如果攻击者操作客户端所连接的“无辜”服务器，则很容易获得“next_ephemeral”变量当前值的参考点。此外，如果攻击者可以强制客户端定期建立新的TCP连接，例如，与攻击者控制的机器（或通过攻击者可观察的路径）建立新的TCP连接，攻击者可以减去连续的源端口值，以获得目标主机在该时间段内全局建立的传出TCP连接数（当然，最多可以是环绕问题和实例id冲突）。
While it is possible for the ephemeral port selection algorithm to verify that the selected port number results in a instance-id that is not currently in use by that system, the resulting five-tuple may still be in use at a remote system. For example, consider a scenario in which a client establishes a TCP connection with a remote web server, and the web server performs the active close on the connection. While the state information for this connection will disappear at the client side (that is, the connection will be moved to the fictional CLOSED state), the instance-id will remain in the TIME-WAIT state at the web server for 2*MSL (Maximum Segment Lifetime). If the same client tried to create a new incarnation of the previous connection (that is, a connection with the same instance-id as the one in the TIME_WAIT state at the server), an instance-id "collision" would occur. The effect of these collisions range from connection-establishment failures to TIME-WAIT state assassination (with the potential of data corruption) [RFC1337]. In scenarios in which a specific client establishes TCP connections with a specific service at a server, these problems become evident. Therefore, an ephemeral port selection algorithm should ideally minimize the rate of instance-id collisions.
虽然临时端口选择算法可以验证所选端口号是否导致该系统当前未使用的实例id，但生成的五元组可能仍在远程系统中使用。例如，考虑一个场景，其中客户端与远程Web服务器建立TCP连接，并且Web服务器在连接上执行活动关闭。虽然此连接的状态信息将在客户端消失（即，连接将移动到虚构的关闭状态），但实例id将在web服务器上保持2*MSL（最大段生存期）的等待状态。如果同一个客户端尝试创建前一个连接的新版本（即，与服务器上处于TIME_WAIT状态的连接具有相同实例id的连接），则会发生实例id“冲突”。这些冲突的影响范围从连接建立失败到时间等待状态刺杀（可能导致数据损坏）[RFC1337]。在特定客户机与服务器上的特定服务建立TCP连接的场景中，这些问题变得很明显。因此，理想情况下，临时端口选择算法应将实例id冲突的速率降至最低。
A simple approach to minimize the rate of these collisions would be to choose port numbers incrementally, so that a given port number would not be reused until the rest of the port numbers in the ephemeral port range have been used for a transport protocol instance. However, if a single global variable were used to keep track of the last ephemeral port selected, ephemeral port numbers would be trivially predictable, thus making it easier for an off-path
将这些冲突的速率降至最低的一种简单方法是以增量方式选择端口号，以便在临时端口范围内的其余端口号用于传输协议实例之前，不会重用给定的端口号。但是，如果使用单个全局变量来跟踪最后一个选定的临时端口，临时端口号将是可预测的，从而使非路径更容易实现
attacker to "guess" the instance-id in use by a target transport-protocol instance. Sections 3.3.3 and 3.3.4 describe algorithms that select port numbers incrementally, while still making it difficult for an off-path attacker to predict the ephemeral ports used for future transport-protocol instances.
攻击者“猜测”目标传输协议实例正在使用的实例id。第3.3.3节和第3.3.4节描述了增量选择端口号的算法，同时仍然使非路径攻击者难以预测用于未来传输协议实例的临时端口。
A simple but inefficient approach to minimize the rate of collisions of instance-ids would be, e.g., in the case of TCP, for both endpoints of a TCP connection to keep state about recent connections (e.g., have both endpoints end up in the TIME-WAIT state).
将实例ID的冲突率降至最低的简单但低效的方法是，例如，在TCP的情况下，TCP连接的两个端点保持最近连接的状态（例如，使两个端点都处于等待状态）。
3.1. Characteristics of a Good Algorithm for the Obfuscation of the Ephemeral Port Selection
3.1. 一种好的短时端口选择模糊处理算法的特点
There are several factors to consider when designing an algorithm for selecting ephemeral ports, which include:
当设计短暂端口的算法时，需要考虑几个因素，包括：
o Minimizing the predictability of the ephemeral port numbers used for future transport-protocol instances.
o 最小化用于未来传输协议实例的临时端口号的可预测性。
o Minimizing collisions of instance-ids.
o 最小化实例ID的冲突。
o Avoiding conflict with applications that depend on the use of specific port numbers.
o 避免与依赖于使用特定端口号的应用程序发生冲突。
Given the goal of improving the transport protocol's resistance to attack by obfuscation of the instance-id selection, it is key to minimize the predictability of the ephemeral ports that will be selected for new transport-protocol instances. While the obvious approach to address this requirement would be to select the ephemeral ports by simply picking a random value within the chosen port number range, this straightforward policy may lead to collisions of instance-ids, which could lead to the interoperability problems (e.g., delays in the establishment of new connections, failures in connection establishment, or data corruption) discussed in Section 2.3. As discussed in Section 1, it is worth noting that while the technique of mitigating "blind" attacks by obfuscating the ephemeral port selection is well-known as "port randomization", the goal of the algorithms described in this document is to reduce the chances that an attacker will guess the ephemeral ports selected for new transport-protocol instances, rather than to actually produce sequences of mathematically random ephemeral port numbers.
由于目标是通过混淆实例id选择来提高传输协议的抗攻击能力，因此将为新传输协议实例选择的临时端口的可预测性降至最低是关键。虽然解决此需求的明显方法是通过简单地在所选端口号范围内随机选取一个值来选择临时端口，但这种简单的策略可能会导致实例ID冲突，从而导致互操作性问题（例如，新连接建立延迟、连接建立失败或数据损坏）如第2.3节所述。如第1节所述，值得注意的是，通过混淆临时端口选择来缓解“盲”攻击的技术被称为“端口随机化”，本文档中所述算法的目标是减少攻击者猜测为新传输协议实例选择的临时端口的机会，而不是实际生成数学上随机的临时端口号序列。
It is also worth noting that, provided adequate algorithms are in use, the larger the range from which ephemeral ports are selected, the smaller the chances of an attacker are to guess the selected port number.
还值得注意的是，如果使用了足够的算法，选择临时端口的范围越大，攻击者猜测所选端口号的机会就越小。
In scenarios in which a specific client establishes transport-protocol instances with a specific service at a server, the problems described in Section 2.3 become evident. A good algorithm to minimize the collisions of instance-ids would consider the time a given five-tuple was last used, and would avoid reusing the last recently used five-tuples. A simple approach to minimize the rate of collisions would be to choose port numbers incrementally, so that a given port number would not be reused until the rest of the port numbers in the ephemeral port range have been used for a transport-protocol instance. However, if a single global variable were used to keep track of the last ephemeral port selected, ephemeral port numbers would be trivially predictable.
在特定客户端在服务器上使用特定服务建立传输协议实例的场景中，第2.3节中描述的问题变得显而易见。一个很好的算法来最小化实例ID的冲突将考虑最后一个给定的五元组的使用时间，并且将避免重用最近使用的五个元组。最小化冲突率的一种简单方法是以增量方式选择端口号，以便在临时端口范围内的其余端口号用于传输协议实例之前，不会重用给定的端口号。但是，如果使用单个全局变量来跟踪最后一个选定的临时端口，临时端口号将很难预测。
It is important to note that a number of applications rely on binding specific port numbers that may be within the ephemeral port range. If such an application were run while the corresponding port number were in use, the application would fail. Therefore, ephemeral port selection algorithms avoid using those port numbers.
需要注意的是，许多应用程序依赖于绑定特定的端口号，这些端口号可能在临时端口范围内。如果在使用相应的端口号时运行此类应用程序，则应用程序将失败。因此，临时端口选择算法避免使用这些端口号。
Port numbers that are currently in use by a TCP in the LISTEN state should not be allowed for use as ephemeral ports. If this rule is not complied with, an attacker could potentially "steal" an incoming connection to a local server application in at least two different ways. Firstly, an attacker could issue a connection request to the victim client at roughly the same time the client tries to connect to the victim server application [CPNI-TCP] [TCP-SEC]. If the SYN segment corresponding to the attacker's connection request and the SYN segment corresponding to the victim client "cross each other in the network", and provided the attacker is able to know or guess the ephemeral port used by the client, a TCP "simultaneous open" scenario would take place, and the incoming connection request sent by the client would be matched with the attacker's socket rather than with the victim server application's socket. Secondly, an attacker could specify a more specific socket than the "victim" socket (e.g., specify both the local IP address and the local TCP port), and thus incoming SYN segments matching the attacker's socket would be delivered to the attacker, rather than to the "victim" socket (see Section 10.1 of [CPNI-TCP]).
不允许将TCP当前正在侦听状态下使用的端口号用作临时端口。如果不遵守此规则，攻击者可能会以至少两种不同的方式“窃取”到本地服务器应用程序的传入连接。首先，攻击者可以在客户端尝试连接到受害者服务器应用程序[CPNI-TCP][TCP-SEC]的同时向受害者客户端发出连接请求。如果与攻击者的连接请求相对应的SYN段和与受害者客户端相对应的SYN段“在网络中相互交叉”，并且如果攻击者能够知道或猜测客户端使用的临时端口，则会发生TCP“同时打开”的情况，客户端发送的传入连接请求将与攻击者的套接字相匹配，而不是与受害者服务器应用程序的套接字相匹配。其次，攻击者可以指定比“受害者”套接字更具体的套接字（例如，同时指定本地IP地址和本地TCP端口），因此与攻击者套接字匹配的传入SYN段将传递给攻击者，而不是“受害者”套接字（见[CPNI-TCP]第10.1节）。
It should be noted that most applications based on popular implementations of the TCP API (such as the Sockets API) perform "passive opens" in three steps. Firstly, the application obtains a file descriptor to be used for inter-process communication (e.g., by
应该注意的是，大多数基于流行的TCP API实现的应用程序（如Sockets API）通过三个步骤执行“被动打开”。首先，应用程序获得用于进程间通信的文件描述符（例如，通过
issuing a socket() call). Secondly, the application binds the file descriptor to a local TCP port number (e.g., by issuing a bind() call), thus creating a TCP in the fictional CLOSED state. Thirdly, the aforementioned TCP is put in the LISTEN state (e.g., by issuing a listen() call). As a result, with such an implementation of the TCP API, even if port numbers in use for TCPs in the LISTEN state were not allowed for use as ephemeral ports, there is a window of time between the second and the third steps in which an attacker could be allowed to select a port number that would be later used for listening to incoming connections. Therefore, these implementations of the TCP API should enforce a stricter requirement for the allocation of port numbers: port numbers that are in use by a TCP in the LISTEN or CLOSED states should not be allowed for allocation as ephemeral ports [CPNI-TCP] [TCP-SEC].
发出套接字（）调用）。其次，应用程序将文件描述符绑定到本地TCP端口号（例如，通过发出bind（）调用），从而在虚构的关闭状态下创建TCP。第三，上述TCP被置于侦听状态（例如，通过发出LISTEN（）调用）。因此，在TCP API的这种实现中，即使侦听状态下TCP使用的端口号不允许用作临时端口，在第二步和第三步之间有一个时间窗口，允许攻击者选择一个端口号，该端口号稍后将用于侦听传入连接。因此，TCP API的这些实现应该对端口号的分配实施更严格的要求：TCP在侦听或关闭状态下使用的端口号不应被允许分配为临时端口[CPNI-TCP][TCP-SEC]。
The aforementioned issue does not affect SCTP, since most SCTP implementations do not allow a socket to be bound to the same port number unless a specific socket option (SCTP_REUSE_PORT) is issued on the socket (i.e., this behavior needs to be explicitly allowed beforehand). An example of a typical SCTP socket API can be found in [SCTP-SOCKET].
上述问题不影响SCTP，因为大多数SCTP实现不允许将套接字绑定到相同的端口号，除非在套接字上发出特定的套接字选项（SCTP_重用_端口）（即，需要事先明确允许此行为）。典型的SCTP套接字API示例可在[SCTP-socket]中找到。
DCCP is not affected by the exploitation of "simultaneous opens" to "steal" incoming connections, as the server and the client state machines are different [RFC4340]. However, it may be affected by the vector involving binding a more specific socket. As a result, those tuples {local IP address, local port, Service Code} that are in use by a local socket should not be allowed for allocation as ephemeral ports.
DCCP不受利用“同时打开”来“窃取”传入连接的影响，因为服务器和客户端状态机不同[RFC4340]。然而，它可能受到涉及绑定更特定套接字的向量的影响。因此，本地套接字正在使用的元组{本地IP地址、本地端口、服务代码}不应被允许分配为临时端口。
As mentioned in Section 2.1, the dynamic ports consist of the range 49152-65535. However, ephemeral port selection algorithms should use the whole range 1024-65535.
如第2.1节所述，动态端口的范围为49152-65535。但是，临时端口选择算法应使用整个范围1024-65535。
This range includes the IANA Registered Ports; thus, some of these port numbers may be needed for providing a particular service at the local host, which could result in the problems discussed in Section 3.1. As a result, port numbers that may be needed for providing a particular service at the local host SHOULD NOT be included in the pool of port numbers available for ephemeral port randomization. If the host does not provide a particular service, the port can be safely allocated to ordinary processes.
此范围包括IANA注册的端口；因此，在本地主机上提供特定服务可能需要其中一些端口号，这可能导致第3.1节中讨论的问题。因此，在本地主机上提供特定服务可能需要的端口号不应包括在可用于临时端口随机化的端口号池中。如果主机不提供特定服务，则可以将端口安全地分配给普通进程。
A possible workaround for this potential problem would be to maintain a local list of the port numbers that should not be allocated as ephemeral ports. Thus, before allocating a port number, the
这个潜在问题的一个可能的解决方法是维护一个本地端口号列表，该列表不应分配为临时端口。因此，在分配端口号之前
ephemeral port selection function would check this list, avoiding the allocation of ports that may be needed for specific applications. Rather than naively excluding all the registered ports, administrators should identify services that may be offered by the local host and SHOULD exclude only the corresponding registered ports.
临时端口选择功能将检查此列表，避免分配特定应用程序可能需要的端口。管理员不应天真地排除所有已注册的端口，而应确定本地主机可能提供的服务，并应仅排除相应的已注册端口。
Ephemeral port selection algorithms SHOULD use the largest possible port range, since this reduces the chances of an off-path attacker of guessing the selected port numbers.
临时端口选择算法应使用尽可能大的端口范围，因为这减少了非路径攻击者猜测所选端口号的机会。
Ephemeral port selection algorithms SHOULD obfuscate the selection of their ephemeral ports, since this helps to mitigate a number of attacks that depend on the attacker's ability to guess or know the five-tuple that identifies the transport-protocol instance to be attacked.
临时端口选择算法应混淆其临时端口的选择，因为这有助于减轻许多攻击，这些攻击取决于攻击者猜测或知道标识要攻击的传输协议实例的五元组的能力。
The following subsections describe a number of algorithms that could be implemented in order to obfuscate the selection of ephemeral port numbers.
以下小节描述了一些可以实现的算法，以混淆临时端口号的选择。
In order to address the security issues discussed in Sections 1 and 2.2, a number of systems have implemented simple ephemeral port number randomization, as follows:
为了解决第1节和第2.2节中讨论的安全问题，许多系统实施了简单的临时端口号随机化，如下所示：
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count = num_ephemeral;
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count = num_ephemeral;
do {
if(check_suitable_port(port))
return next_ephemeral;
do {
if(check_suitable_port(port))
return next_ephemeral;
if (next_ephemeral == max_ephemeral) {
next_ephemeral = min_ephemeral;
} else {
next_ephemeral++;
}
if (next_ephemeral == max_ephemeral) {
next_ephemeral = min_ephemeral;
} else {
next_ephemeral++;
}
count--;
} while (count > 0);
count--;
} while (count > 0);
return ERROR;
返回误差；
Algorithm 1
算法1
Note: random() is a function that returns a 32-bit pseudo-random unsigned integer number. Note that the output needs to be unpredictable, and typical implementations of POSIX random() function do not necessarily meet this requirement. See [RFC4086] for randomness requirements for security.
注意：random（）是一个返回32位伪随机无符号整数的函数。请注意，输出需要是不可预测的，POSIX random（）函数的典型实现不一定满足此要求。有关安全性的随机性要求，请参见[RFC4086]。
All the variables (in this and all the algorithms discussed in this document) are unsigned integers.
所有变量（本文档中以及本文档中讨论的所有算法）都是无符号整数。
Since the initially chosen port may already be in use with IP addresses and server port that are identical to the ones being used for the socket for which the ephemeral port is to be selected, the resulting five-tuple might not be unique. Therefore, multiple ports may have to be tried and verified against all existing transport-protocol instances before a port can be chosen.
由于最初选择的端口可能已经与IP地址和服务器端口一起使用，这些IP地址和服务器端口与要为其选择临时端口的套接字使用的IP地址和服务器端口相同，因此生成的五元组可能不唯一。因此，在选择端口之前，可能必须根据所有现有传输协议实例尝试和验证多个端口。
Web proxy servers, Network Address Port Translators (NAPTs) [RFC2663], and other middleboxes aggregate multiple peers into the same port space and thus increase the population of used ephemeral ports, and hence the chances of collisions of instance-ids. However, [Allman] has shown that at least in the network scenarios used for measuring the collision properties of the algorithms described in this document, the collision rate resulting from the use of the aforementioned middleboxes is nevertheless very low.
Web代理服务器、网络地址端口转换器（NAPT）[RFC2663]和其他中间件将多个对等点聚合到同一端口空间中，从而增加使用的临时端口的数量，从而增加实例ID发生冲突的机会。然而，[Allman]已经表明，至少在用于测量本文所述算法的冲突属性的网络场景中，由于使用上述中间盒而导致的冲突率仍然非常低。
Since this algorithm performs port selection without taking into account the port numbers previously chosen, it has the potential of reusing port numbers too quickly, thus possibly leading to collisions of instance-ids. Even if a given instance-id is verified to be unique by the port selection algorithm, the instance-id might still be in use at the remote system. In such a scenario, a connection request could possibly fail ([Silbersack] describes this problem for the TCP case).
由于此算法执行端口选择时不考虑先前选择的端口号，因此可能会过快地重用端口号，从而可能导致实例ID冲突。即使端口选择算法验证了给定实例id的唯一性，该实例id仍可能在远程系统中使用。在这种情况下，连接请求可能会失败（[Silbersack]针对TCP案例描述了此问题）。
However, this algorithm is biased towards the first available port after a sequence of unavailable port numbers. If the local list of registered port numbers that should not be allocated as ephemeral ports (as described in Section 3.2) is significant, an attacker may actually have a significantly better chance of guessing a port number.
但是，该算法偏向于一系列不可用端口号之后的第一个可用端口。如果不应分配为临时端口（如第3.2节所述）的注册端口号的本地列表非常重要，则攻击者实际上可能更有机会猜测端口号。
This algorithm selects ephemeral port numbers randomly and thus reduces the chances that an attacker will guess the ephemeral port selected for a target transport-protocol instance. Additionally, it prevents attackers from obtaining the number of outgoing transport-protocol instances (e.g., TCP connections) established by the client in some period of time.
该算法随机选择临时端口号，从而减少攻击者猜测为目标传输协议实例选择的临时端口的机会。此外，它还可以防止攻击者获取客户端在一段时间内建立的传出传输协议实例数（例如TCP连接）。
The following pseudo-code illustrates another algorithm for selecting a random port number, in which in the event a local instance-id collision is detected, another port number is selected randomly:
以下伪代码说明了选择随机端口号的另一种算法，在该算法中，如果检测到本地实例id冲突，则随机选择另一个端口号：
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count = num_ephemeral;
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count = num_ephemeral;
do {
if(check_suitable_port(port))
return next_ephemeral;
do {
if(check_suitable_port(port))
return next_ephemeral;
next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count--;
} while (count > 0);
next_ephemeral = min_ephemeral + (random() % num_ephemeral);
count--;
} while (count > 0);
return ERROR;
返回误差；
Algorithm 2
算法2
When there are a large number of port numbers already in use for the same destination endpoint, this algorithm might be unable (with a very small remaining probability) to select an ephemeral port (i.e., it would return "ERROR"), even if there are still a few port numbers available that would result in unique five-tuples. However, the results in [Allman] have shown that in common scenarios, one port choice is enough, and in most cases where more than one choice is needed, two choices suffice. Therefore, in those scenarios this would not be problem.
当有大量端口号已用于同一目的地端点时，此算法可能无法（以非常小的剩余概率）选择临时端口（即，它将返回“错误”），即使仍然有一些端口号可用，这将导致唯一的五元组。然而，[Allman]中的结果表明，在常见场景中，一个端口选择就足够了，在大多数情况下，需要多个端口选择时，两个端口选择就足够了。因此，在这些场景中，这不会是问题。
We would like to achieve the port-reuse properties of the traditional BSD port selection algorithm (described in Section 2.2), while at the same time achieve the unpredictability properties of Algorithm 1 and Algorithm 2.
我们希望实现传统BSD端口选择算法（如第2.2节所述）的端口重用特性，同时实现算法1和算法2的不可预测特性。
Ideally, we would like a "next_ephemeral" value for each set of (local IP address, remote IP addresses, remote port), so that the port-reuse frequency is the lowest possible. Each of these "next_ephemeral" variables should be initialized with random values within the ephemeral port range and, together, these would thus separate the ephemeral port space of the transport-protocol instances on a "per-destination endpoint" basis (this "separation of the ephemeral port space" means that transport-protocol instances with different remote endpoints will not have different sequences of port numbers, i.e., will not be part of the same ephemeral port sequence as in the case of the traditional BSD ephemeral port selection algorithm). Since we do not want to maintain in memory all these "next_ephemeral" values, we propose an offset function F() that can be computed from the local IP address, remote IP address, remote port, and a secret key. F() will yield (practically) different values for each set of arguments, i.e.:
理想情况下，我们希望每组（本地IP地址、远程IP地址、远程端口）都有一个“下一个临时”值，以便端口重用频率尽可能低。应使用临时端口范围内的随机值初始化这些“下一个临时”变量中的每一个，因此，这些变量一起将在“每个目的地端点”的基础上分离传输协议实例的临时端口空间（“临时端口空间的分离”）意味着具有不同远程端点的传输协议实例将不会具有不同的端口号序列，即，与传统BSD临时端口选择算法的情况不同，不会是同一临时端口序列的一部分）。由于我们不希望在内存中保留所有这些“下一个临时”值，因此我们提出了一个偏移量函数F（），它可以根据本地IP地址、远程IP地址、远程端口和密钥进行计算。F（）将为每一组参数生成（实际上）不同的值，即：
/* Initialization at system boot time. Could be random. */
next_ephemeral = 0;
/* Initialization at system boot time. Could be random. */
next_ephemeral = 0;
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
offset = F(local_IP, remote_IP, remote_port, secret_key);
count = num_ephemeral;
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
offset = F(local_IP, remote_IP, remote_port, secret_key);
count = num_ephemeral;
do {
port = min_ephemeral +
(next_ephemeral + offset) % num_ephemeral;
do {
port = min_ephemeral +
(next_ephemeral + offset) % num_ephemeral;
next_ephemeral++;
next_ephemeral++;
if(check_suitable_port(port)) return port;
如果（检查合适的_端口（端口））返回端口；
count--;
计数--；
} while (count > 0);
} while (count > 0);
return ERROR;
返回误差；
Algorithm 3
算法3
In other words, the function F() provides a "per-destination endpoint" fixed offset within the global ephemeral port range. Both the "offset" and "next_ephemeral" variables may take any value within the storage type range since we are restricting the resulting port in a similar way as in Algorithm 1 (described in Section 3.3.1). This allows us to simply increment the "next_ephemeral" variable and rely on the unsigned integer to wrap around.
换句话说，函数F（）在全局临时端口范围内提供“每个目标端点”的固定偏移量。“offset”和“next_ephemeral”变量都可以采用存储类型范围内的任何值，因为我们以与算法1（第3.3.1节中所述）类似的方式限制生成的端口。这使我们可以简单地递增“next_ephemeral”变量，并依赖无符号整数进行换行。
The function F() should be a cryptographic hash function like MD5 [RFC1321]. The function should use both IP addresses, the remote port, and a secret key value to compute the offset. The remote IP address is the primary separator and must be included in the offset calculation. The local IP address and remote port may in some cases be constant and thus not improve the ephemeral port space separation; however, they should also be included in the offset calculation.
函数F（）应该是类似MD5[RFC1321]的加密哈希函数。函数应该同时使用IP地址、远程端口和密钥值来计算偏移量。远程IP地址是主要分隔符，必须包含在偏移量计算中。在某些情况下，本地IP地址和远程端口可能是恒定的，因此不会改善临时端口空间分离；但是，它们也应包括在偏移计算中。
Cryptographic algorithms stronger than, e.g., MD5 should not be necessary, given that Algorithm 3 is simply a technique for the obfuscation of the selection of ephemeral ports. The secret should be chosen to be as random as possible (see [RFC4086] for recommendations on choosing secrets).
考虑到算法3只是一种模糊选择临时端口的技术，因此不需要比MD5更强的加密算法。机密的选择应尽可能随机（有关选择机密的建议，请参阅[RFC4086]）。
Note that on multiuser systems, the function F() could include user-specific information, thereby providing protection not only on a host-to-host basis, but on a user to service basis. In fact, any identifier of the remote entity could be used, depending on availability and the granularity requested. With SCTP, both hostnames and alternative IP addresses may be included in the association negotiation, and either of these could be used in the offset function F().
请注意，在多用户系统上，函数F（）可以包括用户特定的信息，从而不仅在主机到主机的基础上，而且在用户到服务的基础上提供保护。事实上，可以使用远程实体的任何标识符，这取决于可用性和请求的粒度。使用SCTP，主机名和备用IP地址都可以包含在关联协商中，并且可以在偏移量函数F（）中使用其中任何一个。
When multiple unique identifiers are available, any of these can be chosen as input to the offset function F() since they all uniquely identify the remote entity. However, in cases like SCTP where the ephemeral port must be unique across all IP address permutations, we should ideally always use the same IP address to get a single starting offset for each association negotiation with a given remote entity to minimize the possibility of collisions. A simple numerical sorting of the IP addresses and always using the numerically lowest could achieve this. However, since most protocols will generally report the same IP addresses in the same order in each association setup, this sorting is most likely not necessary and the "first one" can simply be used.
当有多个唯一标识符可用时，可以选择其中任何一个作为偏移函数F（）的输入，因为它们都唯一地标识远程实体。然而，在像SCTP这样的情况下，临时端口必须在所有IP地址排列中都是唯一的，理想情况下，我们应该始终使用相同的IP地址为与给定远程实体的每次关联协商获得单个起始偏移量，以将冲突的可能性降至最低。对IP地址进行简单的数字排序并始终使用数字最低的地址可以实现这一点。然而，由于大多数协议通常会在每个关联设置中以相同的顺序报告相同的IP地址，因此这种排序很可能是不必要的，可以简单地使用“第一个”。
The ability of hostnames to uniquely define hosts can be discussed, and since SCTP always includes at least one IP address, we recommend using this as input to the offset function F() and ignoring hostname chunks when searching for ephemeral ports.
可以讨论主机名唯一定义主机的能力，并且由于SCTP始终至少包含一个IP地址，因此建议将其用作偏移函数F（）的输入，并在搜索临时端口时忽略主机名块。
It should be noted that, as this algorithm uses a global counter ("next_ephemeral") for selecting ephemeral ports, if an attacker could, e.g., force a client to periodically establish a new TCP connection to an attacker-controlled machine (or through an attacker-observable path), the attacker could subtract consecutive source port values to obtain the number of outgoing TCP connections established globally by the target host within that time period (up to wrap-around issues and five-tuple collisions, of course).
应该注意的是，由于该算法使用全局计数器（“next_ephemeral”）来选择临时端口，如果攻击者可以（例如）强制客户端定期建立与攻击者控制的机器（或通过攻击者可观察的路径）的新TCP连接，攻击者可以减去连续的源端口值，以获得目标主机在该时间段内全局建立的传出TCP连接数（当然，最多可出现环绕问题和五个元组冲突）。
A trade-off between maintaining a single global "next_ephemeral" variable and maintaining 2**N "next_ephemeral" variables (where N is the width of the result of F()) could be achieved as follows. The system would keep an array of TABLE_LENGTH short integers, which would provide a separation of the increment of the "next_ephemeral" variable. This improvement could be incorporated into Algorithm 3 as follows:
在维护单个全局“下一个临时”变量和维护2**N“下一个临时”变量（其中N是F（）结果的宽度）之间的权衡可以实现如下。系统将保留一个表长度短整数数组，这将提供“下一个临时”变量增量的分隔。该改进可并入算法3，如下所示：
/* Initialization at system boot time */
for(i = 0; i < TABLE_LENGTH; i++)
table[i] = random() % 65536;
/* Initialization at system boot time */
for(i = 0; i < TABLE_LENGTH; i++)
table[i] = random() % 65536;
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
offset = F(local_IP, remote_IP, remote_port, secret_key1);
index = G(local_IP, remote_IP, remote_port, secret_key2);
count = num_ephemeral;
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
offset = F(local_IP, remote_IP, remote_port, secret_key1);
index = G(local_IP, remote_IP, remote_port, secret_key2);
count = num_ephemeral;
do {
port = min_ephemeral + (offset + table[index]) % num_ephemeral;
table[index]++;
do {
port = min_ephemeral + (offset + table[index]) % num_ephemeral;
table[index]++;
if(check_suitable_port(port)) return port;
如果（检查合适的_端口（端口））返回端口；
count--;
计数--；
} while (count > 0);
} while (count > 0);
return ERROR;
返回误差；
Algorithm 4
算法4
"table[]" could be initialized with mathematically random values, as indicated by the initialization code in pseudo-code above. The function G() should be a cryptographic hash function like MD5 [RFC1321]. It should use both IP addresses, the remote port, and a secret key value to compute a value between 0 and (TABLE_LENGTH-1). Alternatively, G() could take an "offset" as input, and perform the exclusive-or (XOR) operation between all the bytes in "offset".
“表[]”可以用数学上随机的值初始化，如上面伪代码中的初始化代码所示。函数G（）应该是类似MD5[RFC1321]的加密哈希函数。它应该同时使用IP地址、远程端口和密钥值来计算介于0和（表_LENGTH-1）之间的值。或者，G（）可以将“offset”作为输入，并在“offset”中的所有字节之间执行异或（XOR）操作。
The array "table[]" assures that successive transport-protocol instances with the same remote endpoint will use increasing ephemeral port numbers. However, incrementation of the port numbers is separated into TABLE_LENGTH different spaces, and thus the port-reuse frequency will be (probabilistically) lower than that of Algorithm 3. That is, a new transport-protocol instance with some remote endpoint will not necessarily cause the "next_ephemeral" variable corresponding to other endpoints to be incremented.
数组“table[]”确保具有相同远程端点的连续传输协议实例将使用越来越多的临时端口号。然而，端口号的增量被分成不同的表长度空间，因此端口重用频率（概率）将低于算法3。也就是说，具有某个远程端点的新传输协议实例不一定会导致与其他端点对应的“next_ephemeral”变量递增。
It is interesting to note that the size of "table[]" does not limit the number of different port sequences, but rather separates the *increments* into TABLE_LENGTH different spaces. The port sequence will result from adding the corresponding entry of "table[]" to the variable "offset", which selects the actual port sequence (as in Algorithm 3). [Allman] has found that a TABLE_LENGTH of 10 can
有趣的是，注意到“table[]”的大小并没有限制不同端口序列的数量，而是将*增量*分隔为不同的table_长度空间。端口序列是将“table[]”的相应条目添加到变量“offset”中的结果，该变量选择实际的端口序列（如算法3所示）。[Allman]发现长度为10的桌子可以
result in an improvement over Algorithm 3. Further increasing the TABLE_LENGTH will increase the unpredictability of the resulting port number, and possibly further decrease the collision rate.
结果改进了算法3。进一步增加表_长度将增加结果端口号的不可预测性，并可能进一步降低冲突率。
An attacker can perform traffic analysis for any "increment space" into which the attacker has "visibility" -- namely, the attacker can force the client to establish a transport-protocol instance whose G(offset) identifies the target "increment space". However, the attacker's ability to perform traffic analysis is very reduced when compared to the traditional BSD algorithm (described in Section 2.2) and Algorithm 3. Additionally, an implementation can further limit the attacker's ability to perform traffic analysis by further separating the increment space (that is, using a larger value for TABLE_LENGTH).
攻击者可以对攻击者具有“可见性”的任何“增量空间”执行流量分析——即，攻击者可以强制客户端建立一个传输协议实例，其G（偏移量）标识目标“增量空间”。但是，与传统的BSD算法（如第2.2节所述）和算法3相比，攻击者执行流量分析的能力大大降低。此外，通过进一步分离增量空间（即，使用较大的表长度值），实现可以进一步限制攻击者执行流量分析的能力。
[Allman] introduced another port selection algorithm, which offers a middle ground between the algorithms that select ephemeral ports independently at random (such as those described in Sections 3.3.1 and 3.3.2), and those that offer obfuscation with less randomization (such as those described in Sections 3.3.3 and 3.3.4).
[Allman]介绍了另一种端口选择算法，它在随机独立选择临时端口的算法（如第3.3.1节和第3.3.2节所述）和随机性较小的混淆算法（如第3.3.3节和第3.3.4节所述）之间提供了一个中间地带。
/* Initialization code at system boot time. */
next_ephemeral = random() % 65536; /* Initialization value */
N = 500; /* Determines the trade-off */
/* Initialization code at system boot time. */
next_ephemeral = random() % 65536; /* Initialization value */
N = 500; /* Determines the trade-off */
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
/* Ephemeral port selection function */
num_ephemeral = max_ephemeral - min_ephemeral + 1;
count = num_ephemeral;
计数=短暂数；
do {
next_ephemeral = next_ephemeral + (random() % N) + 1;
port = min_ephemeral + (next_ephemeral % num_ephemeral);
do {
next_ephemeral = next_ephemeral + (random() % N) + 1;
port = min_ephemeral + (next_ephemeral % num_ephemeral);
if(check_suitable_port(port)) return port;
如果（检查合适的_端口（端口））返回端口；
count--;
} while (count > 0);
count--;
} while (count > 0);
return ERROR;
返回误差；
Algorithm 5
算法5
This algorithm aims at producing a monotonically increasing sequence to prevent the collision of instance-ids, while avoiding the use of fixed increments, which would lead to trivially predictable sequences. The value "N" allows for direct control of the trade-off between the level of unpredictability and the port-reuse frequency. The smaller the value of "N", the more similar this algorithm is to the traditional BSD port selection algorithm (described in Section 2.2). The larger the value of "N", the more similar this algorithm is to the algorithm described in Section 3.3.1 of this document.
该算法旨在生成一个单调递增的序列，以防止实例ID之间的冲突，同时避免使用固定增量，这将导致不可预测的序列。值“N”允许直接控制不可预测性级别和端口重用频率之间的权衡。“N”的值越小，该算法与传统的BSD端口选择算法（如第2.2节所述）越相似。“N”的值越大，该算法与本文件第3.3.1节中描述的算法越相似。
When the port numbers wrap, there is the risk of collisions of instance-ids. Therefore, "N" should be selected according to the following criteria:
当端口号换行时，存在实例ID冲突的风险。因此，应根据以下标准选择“N”：
o It should maximize the wrapping time of the ephemeral port space.
o 它应该最大限度地延长临时端口空间的包装时间。
o It should minimize collisions of instance-ids.
o 它应该最小化实例ID的冲突。
o It should maximize the unpredictability of selected port numbers.
o 它应该最大限度地提高所选端口号的不可预测性。
Clearly, these are competing goals, and the decision of which value of "N" to use is a trade-off. Therefore, the value of "N" should be configurable so that system administrators can make the trade-off for themselves.
显然，这些都是相互竞争的目标，决定使用“N”的哪个值是一种权衡。因此，“N”的值应该是可配置的，以便系统管理员可以自己进行权衡。
Every complex manipulation (like MD5) is no more secure than the input values, and in the case of ephemeral ports, the secret key. If an attacker is aware of which cryptographic hash function is being used by the victim (which we should expect), and the attacker can obtain enough material (e.g., ephemeral ports chosen by the victim), the attacker may simply search the entire secret-key space to find matches.
每一个复杂的操作（如MD5）都不比输入值更安全，对于临时端口，则是密钥。如果攻击者知道受害者正在使用哪个加密散列函数（我们应该知道），并且攻击者可以获得足够的资料（例如，受害者选择的临时端口），则攻击者可以简单地搜索整个密钥空间以查找匹配项。
To protect against this, the secret key should be of a reasonable length. Key lengths of 128 bits should be adequate.
为了防止出现这种情况，密钥的长度应该合理。128位的密钥长度应足够。
Another possible mechanism for protecting the secret key is to change it after some time. If the host platform is capable of producing reasonably good random data, the secret key can be changed automatically.
保护密钥的另一种可能机制是在一段时间后更改密钥。如果主机平台能够产生相当好的随机数据，则可以自动更改密钥。
Changing the secret will cause abrupt shifts in the chosen ephemeral ports, and consequently collisions may occur. That is, upon changing the secret, the "offset" value (see Sections 3.3.3 and 3.3.4) used
更改秘密将导致所选临时端口发生突然变化，从而可能发生冲突。也就是说，在更改机密时，使用“偏移”值（见第3.3.3节和第3.3.4节）
for each destination endpoint will be different from that computed with the previous secret, thus leading to the selection of a port number recently used for connecting to the same endpoint.
对于每个目的地，端点将不同于使用前一个秘密计算的端点，从而导致选择最近用于连接到同一端点的端口号。
Thus, the change in secret key should be done with consideration and could be performed whenever one of the following events occur:
因此，应考虑更改密钥，并且可以在发生以下事件之一时执行更改：
o The system is being bootstrapped.
o 系统正在引导。
o Some predefined/random time has expired.
o 某些预定义/随机时间已过期。
o The secret key has been used sufficiently often that it should be regarded as insecure now.
o 密钥已经被频繁使用，现在应该认为是不安全的。
o There are few active transport-protocol instances (i.e., possibility of a collision is low).
o 活动传输协议实例很少（即，冲突的可能性很低）。
o System load is low (i.e., the performance overhead of local collisions is tolerated).
o 系统负载较低（即，允许本地冲突的性能开销）。
o There is enough random data available to change the secret key (pseudo-random changes should not be done).
o 有足够的随机数据可用于更改密钥（不应进行伪随机更改）。
[Allman] is an empirical study of the properties of the algorithms described in this document, which has found that all the algorithms described in this document offer low collision rates -- at most 0.3%. That is, in those network scenarios assessed by [Allman], all of the algorithms described in this document perform well in terms of collisions of instance-ids. However, these results may vary depending on the characteristics of network traffic and the specific network setup.
[Allman]是对本文所述算法性能的实证研究，发现本文所述的所有算法都提供了较低的碰撞率——最多0.3%。也就是说，在[Allman]评估的那些网络场景中，本文描述的所有算法在实例ID冲突方面都表现良好。但是，这些结果可能因网络流量的特征和特定的网络设置而异。
The algorithm described in Section 2.2 is the traditional ephemeral port selection algorithm implemented in BSD-derived systems. It generates a global sequence of ephemeral port numbers, which makes it trivial for an attacker to predict the port number that will be used for a future transport protocol instance. However, it is very simple and leads to a low port-reuse frequency.
第2.2节中描述的算法是在BSD衍生系统中实现的传统瞬时端口选择算法。它会生成一个临时端口号的全局序列，这使得攻击者无法预测将用于未来传输协议实例的端口号。但是，它非常简单，导致端口重用频率较低。
Algorithm 1 and Algorithm 2 have the advantage that they provide actual randomization of the ephemeral ports. However, they may increase the chances of port number collisions, which could lead to the failure of a connection establishment attempt. [Allman] found that these two algorithms show the largest collision rates (among all the algorithms described in this document).
算法1和算法2的优点是它们提供了临时端口的实际随机化。但是，它们可能会增加端口号冲突的机会，从而导致连接建立尝试失败。[Allman]发现这两种算法显示了最大的碰撞率（在本文描述的所有算法中）。
Algorithm 3 provides complete separation in local and remote IP addresses and remote port space, and only limited separation in other dimensions (see Section 3.4). However, implementations should consider the performance impact of computing the cryptographic hash used for the offset.
算法3在本地和远程IP地址以及远程端口空间中提供完全分离，在其他维度中仅提供有限的分离（见第3.4节）。然而，实现应该考虑计算用于偏移的加密散列的性能影响。
Algorithm 4 improves Algorithm 3, usually leading to a lower port-reuse frequency, at the expense of more processor cycles used for computing G(), and additional kernel memory for storing the array "table[]".
算法4改进了算法3，通常导致更低的端口重用频率，代价是计算G（）时使用更多的处理器周期，以及存储数组“table[]”的额外内核内存。
Algorithm 5 offers middle ground between the simple randomization algorithms (Algorithm 1 and Algorithm 2) and the hash-based algorithms (Algorithm 3 and Algorithm 4). The upper limit on the random increments (the value "N" in the pseudo-code included in Section 3.3.5) controls the trade-off between randomization and port-reuse frequency.
算法5提供了简单随机化算法（算法1和算法2）和基于散列的算法（算法3和算法4）之间的中间地带。随机增量的上限（第3.3.5节中包含的伪代码中的值“N”）控制随机化和端口重用频率之间的权衡。
Finally, a special case that may preclude the utilization of Algorithm 3 and Algorithm 4 should be analyzed. There exist some applications that contain the following code sequence:
最后，应分析可能妨碍使用算法3和算法4的特殊情况。存在一些包含以下代码序列的应用程序：
s = socket();
bind(s, IP_address, port = *);
s = socket();
bind(s, IP_address, port = *);
In some BSD-derived systems, the call to bind() will result in the selection of an ephemeral port number. However, as neither the remote IP address nor the remote port will be available to the ephemeral port selection function, the hash function F() used in Algorithm 3 and Algorithm 4 will not have all the required arguments, and thus the result of the hash function will be impossible to compute. Transport protocols implementing Algorithm 3 or Algorithm 4 should consider using Algorithm 2 when facing the scenario just described.
在某些BSD派生的系统中，对bind（）的调用将导致选择临时端口号。但是，由于临时端口选择函数既不能使用远程IP地址也不能使用远程端口，因此算法3和算法4中使用的哈希函数F（）将不具有所有必需的参数，因此无法计算哈希函数的结果。实现算法3或算法4的传输协议在考虑刚才描述的场景时，应该考虑使用算法2。
An alternative to this behavior would be to implement "lazy binding" in response to the bind() call. That is, selection of an ephemeral port would be delayed until, e.g., connect() or send() are called. Thus, at that point the ephemeral port is actually selected, all the necessary arguments for the hash function F() are available, and therefore Algorithm 3 and Algorithm 4 could still be used in this scenario. This algorithm has been implemented by Linux [Linux].
此行为的另一种选择是实现“惰性绑定”以响应bind（）调用。也就是说，临时端口的选择将延迟，直到调用connect（）或send（）为止。因此，此时实际选择了临时端口，哈希函数F（）的所有必要参数都可用，因此算法3和算法4仍然可以在该场景中使用。该算法已经在Linux[Linux]上实现。
Network Address Port Translation (NAPT) translates both the network address and transport-protocol port number, thus allowing the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address [RFC2663].
网络地址端口转换（NAPT）转换网络地址和传输协议端口号，从而允许将多个专用主机的传输标识符多路复用为单个外部地址的传输标识符[RFC2663]。
In those scenarios in which a NAPT is present between the two endpoints of a transport-protocol instance, the obfuscation of the ephemeral port selection (from the point of view of the external network) will depend on the ephemeral port selection function at the NAPT. Therefore, NAPTs should consider obfuscating the selection of ephemeral ports by means of any of the algorithms discussed in this document.
在传输协议实例的两个端点之间存在NAPT的场景中，临时端口选择的混淆（从外部网络的角度来看）将取决于NAPT的临时端口选择功能。因此，NAPTs应该考虑通过本文档中讨论的任何算法混淆短暂端口的选择。
A NAPT that does not implement port preservation [RFC4787] [RFC5382] SHOULD obfuscate selection of the ephemeral port of a packet when it is changed during translation of that packet.
未实现端口保留[RFC4787][RFC5382]的NAPT应在数据包转换期间更改数据包的临时端口时混淆该数据包的临时端口选择。
A NAPT that does implement port preservation SHOULD obfuscate the ephemeral port of a packet only if the port must be changed as a result of the port being already in use for some other session.
只有当由于端口已用于其他会话而必须更改端口时，实现端口保留的NAPT才应混淆数据包的临时端口。
A NAPT that performs parity preservation and that must change the ephemeral port during translation of a packet SHOULD obfuscate the ephemeral ports. The algorithms described in this document could be easily adapted such that the parity is preserved (i.e., force the lowest order bit of the resulting port number to 0 or 1 according to whether even or odd parity is desired).
执行奇偶校验保护且在数据包转换期间必须更改临时端口的NAPT应混淆临时端口。本文档中描述的算法可以很容易地进行调整，以保持奇偶校验（即，根据是否需要奇偶校验，强制结果端口号的最低阶位为0或1）。
Some applications allocate contiguous ports and expect to see contiguous ports in use at their peers. Clearly, this expectation might be difficult to accommodate at a NAPT, since some port numbers might already be in use by other sessions, and thus an alternative port might need to be selected, thus resulting in a non-contiguous port number sequence (see Section 4.2.3 of [RFC4787]). A NAPT that implements a simple port randomization algorithm (such as Algorithm 1, Algorithm 2, or Algorithm 5) is likely to break this assumption, even if the endpoint selecting an ephemeral port does select ephemeral ports that are contiguous. However, since a number of different ephemeral port selection algorithms have been implemented by deployed NAPTs, any application that relies on any specific ephemeral port selection algorithm at the NAPT is likely to suffer interoperability problems when a NAPT is present between the two endpoints of a transport-protocol instance. Nevertheless, some of the algorithms described in this document (namely Algorithm 3 and Algorithm 4) select consecutive ephemeral ports such that they are
一些应用程序分配连续端口，并期望在其对等端看到连续端口正在使用。显然，这种期望可能难以在NAPT上实现，因为某些端口号可能已经被其他会话使用，因此可能需要选择替代端口，从而导致非连续端口号序列（见[RFC4787]第4.2.3节）。实现简单端口随机化算法（如算法1、算法2或算法5）的NAPT可能会打破这一假设，即使选择临时端口的端点确实选择了连续的临时端口。然而，由于部署的NAPT已经实现了许多不同的临时端口选择算法，因此当传输协议实例的两个端点之间存在NAPT时，任何依赖于NAPT处的任何特定临时端口选择算法的应用程序都可能遇到互操作性问题。尽管如此，本文中描述的一些算法（即算法3和算法4）选择连续的临时端口，以便
contiguous (except when one of the port numbers needed to produce a contiguous sequence is already in use by some other NAPT session). Therefore, a NAPT willing to produce sequences of contiguous port numbers should consider implementing Algorithm 3 or Algorithm 4 of this document. Section 3.5 provides further guidance in choosing a port selection algorithm.
连续（除非生成连续序列所需的一个端口号已被其他某个NAPT会话使用）。因此，愿意产生连续端口号序列的NAPT应该考虑实现该文档的算法3或算法4。第3.5节提供了选择端口选择算法的进一步指导。
It should be noted that in some network scenarios, a NAPT may naturally obscure ephemeral port selections simply due to the vast range of services with which it establishes connections and to the overall rate of the traffic [Allman].
应该注意的是，在一些网络场景中，NAPT可能会自然地模糊临时端口选择，这仅仅是因为NAPT建立连接的服务范围广泛，以及总体流量速率[Allman]。
Obfuscating the ephemeral port selection is no replacement for cryptographic mechanisms, such as IPsec [RFC4301], in terms of protecting transport-protocol instances against blind attacks.
在保护传输协议实例免受盲攻击方面，混淆临时端口选择并不能替代加密机制，如IPsec[RFC4301]。
An eavesdropper that can monitor the packets that correspond to the transport-protocol instance to be attacked could learn the IP addresses and port numbers in use (and also sequence numbers, etc.) and easily perform an attack. Obfuscation of the ephemeral port selection does not provide any additional protection against this kind of attack. In such situations, proper authentication mechanisms such as those described in [RFC4301] should be used.
可以监视与要攻击的传输协议实例对应的数据包的窃听者可以了解正在使用的IP地址和端口号（以及序列号等），并轻松执行攻击。对临时端口选择的模糊处理不会提供任何额外的保护来抵御此类攻击。在这种情况下，应使用[RFC4301]中所述的适当身份验证机制。
This specification recommends including the whole range 1024-65535 for the selection of ephemeral ports, and suggests that an implementation maintains a list of those port numbers that should not be made available for ephemeral port selection. If the list of port numbers that are not available is significant, Algorithm 1 may be highly biased and generate predictable ports, as noted in Section 3.3.1. In particular, if the list of IANA Registered Ports is accepted as the local list of port numbers that should not be made available, certain ports may result with 500 times the probability of other ports. Systems that support numerous applications resulting in large lists of unavailable ports, or that use the IANA Registered Ports without modification, MUST NOT use Algorithm 1.
本规范建议包括整个范围的1024-65535用于选择临时端口，并建议实现维护不应用于临时端口选择的端口号列表。如第3.3.1节所述，如果不可用的端口号列表很重要，则算法1可能会有很大偏差，并生成可预测的端口。特别是，如果IANA注册的端口列表被接受为不应提供的本地端口号列表，则某些端口的概率可能是其他端口的500倍。支持大量应用程序导致大量不可用端口列表的系统，或未经修改就使用IANA注册端口的系统，不得使用算法1。
If the local offset function F() (in Algorithm 3 and Algorithm 4) results in identical offsets for different inputs at greater frequency than would be expected by chance, the port-offset mechanism proposed in this document would have a reduced effect.
如果本地偏移函数F（）（在算法3和算法4中）导致不同输入的相同偏移频率高于预期频率，则本文档中提出的端口偏移机制将降低效果。
If random numbers are used as the only source of the secret key, they should be chosen in accordance with the recommendations given in [RFC4086].
如果随机数用作密钥的唯一来源，则应根据[RFC4086]中给出的建议选择随机数。
If an attacker uses dynamically assigned IP addresses, the current ephemeral port offset (Algorithm 3 and Algorithm 4) for a given five-tuple can be sampled and subsequently used to attack an innocent peer reusing this address. However, this is only possible until a re-keying happens as described above. Also, since ephemeral ports are only used on the client side (e.g., the one initiating the transport-protocol communication), both the attacker and the new peer need to act as servers in the scenario just described. While servers using dynamic IP addresses exist, they are not very common, and with an appropriate re-keying mechanism the effect of this attack is limited.
如果攻击者使用动态分配的IP地址，则可以对给定五元组的当前瞬时端口偏移量（算法3和算法4）进行采样，并随后用于攻击重用此地址的无辜对等方。然而，这只有在如上所述的重新键控发生之前是可能的。此外，由于临时端口仅在客户端使用（例如，启动传输协议通信的端口），因此攻击者和新对等方都需要在刚才描述的场景中充当服务器。虽然存在使用动态IP地址的服务器，但这些服务器并不常见，并且通过适当的密钥更新机制，这种攻击的效果是有限的。
The offset function used in Algorithm 3 and Algorithm 4 was inspired by the mechanism proposed by Steven Bellovin in [RFC1948] for defending against TCP sequence number attacks.
算法3和算法4中使用的偏移量函数受Steven Bellovin在[RFC1948]中提出的防御TCP序列号攻击的机制的启发。
The authors would like to thank (in alphabetical order) Mark Allman, Jari Arkko, Matthias Bethke, Stephane Bortzmeyer, Brian Carpenter, Vincent Deffontaines, Ralph Droms, Lars Eggert, Pasi Eronen, Gorry Fairhurst, Adrian Farrel, Guillermo Gont, David Harrington, Alfred Hoenes, Avshalom Houri, Charlie Kaufman, Amit Klein, Subramanian Moonesamy, Carlos Pignataro, Tim Polk, Kacheong Poon, Pasi Sarolahti, Robert Sparks, Randall Stewart, Joe Touch, Michael Tuexen, Magnus Westerlund, and Dan Wing for their valuable feedback on draft versions of this document.
作者要感谢（按字母顺序排列）马克·奥尔曼、贾里·阿尔科、马蒂亚斯·贝特克、斯蒂芬·博茨迈耶、布赖恩·卡彭特、文森特·德方丹、拉尔夫·德罗姆斯、拉尔斯·艾格特、帕西·埃隆、戈里·费尔赫斯特、阿德里安·法雷尔、吉列莫·冈特、大卫·哈林顿、阿尔弗雷德·霍恩斯、阿夫沙洛姆·霍里、查理·考夫曼、阿米特·克莱恩、苏伯拉曼尼·穆内萨米、，Carlos Pignataro、Tim Polk、Kacheong Poon、Pasi Sarolahti、Robert Sparks、Randall Stewart、Joe Touch、Michael Tuexen、Magnus Westerlund和Dan Wing感谢他们对本文件草稿的宝贵反馈。
The authors would like to thank Alfred Hoenes for his admirable effort in improving the quality of this document.
作者要感谢Alfred Hoenes为提高本文件质量所做的令人钦佩的努力。
The authors would like to thank FreeBSD's Mike Silbersack for a very fruitful discussion about ephemeral port selection techniques.
作者要感谢FreeBSD的Mike Silbersack对短暂端口选择技术进行了非常富有成效的讨论。
Fernando Gont's attendance to IETF meetings was supported by ISOC's "Fellowship to the IETF" program.
费尔南多·冈特出席IETF会议得到了ISOC“IETF奖学金”计划的支持。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605]Huitema，C.，“会话描述协议（SDP）中的实时控制协议（RTCP）属性”，RFC3605，2003年10月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，和G.Fairhurst，“轻量级用户数据报协议（UDP Lite）”，RFC 38282004年7月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]Guha，S.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月。
[Allman] Allman, M., "Comments On Selecting Ephemeral Ports", ACM Computer Communication Review, 39(2), 2009.
[Allman]Allman，M.，“关于选择临时端口的评论”，ACM计算机通信评论，39（2），2009年。
[CPNI-TCP] Gont, F., "CPNI Technical Note 3/2009: Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/ tn-03-09-security-assessment-TCP.pdf>.
[CPNI-TCP]Gont，F.，“CPNI技术说明3/2009：传输控制协议（TCP）的安全评估”，2009年<http://www.cpni.gov.uk/Docs/ tn-03-09-security-assessment-TCP.pdf>。
[FreeBSD] The FreeBSD Project, <http://www.freebsd.org>.
[FreeBSD]FreeBSD项目<http://www.freebsd.org>.
[IANA] "IANA Port Numbers", <http://www.iana.org/assignments/port-numbers>.
[IANA]“IANA端口号”<http://www.iana.org/assignments/port-numbers>.
[Linux] The Linux Project, <http://www.kernel.org>.
[Linux]Linux项目<http://www.kernel.org>.
[NetBSD] The NetBSD Project, <http://www.netbsd.org>.
[NetBSD]NetBSD项目<http://www.netbsd.org>.
[OpenBSD] The OpenBSD Project, <http://www.openbsd.org>.
[OpenBSD]OpenBSD项目<http://www.openbsd.org>.
[OpenSolaris] OpenSolaris, <http://www.opensolaris.org>.
[OpenSolaris]OpenSolaris<http://www.opensolaris.org>.
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
[RFC1337]Braden，B.，“TCP中的等待时间暗杀危险”，RFC 1337，1992年5月。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953]Touch，J.“保护TCP免受欺骗攻击”，RFC 4953，2007年7月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927]Gont，F.，“针对TCP的ICMP攻击”，RFC 5927，2010年7月。
[SCTP-SOCKET] Stewart, R., Poon, K., Tuexen, M., Lei, P., and V. Yasevich, V., "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Work in Progress, January 2011.
[SCTP-SOCKET]Stewart，R.，Poon，K.，Tuexen，M.，Lei，P.，和V.Yasevich，V.，“流控制传输协议（SCTP）的套接字API扩展”，正在进行的工作，2011年1月。
[Silbersack] Silbersack, M., "Improving TCP/IP security through randomization without sacrificing interoperability", EuroBSDCon 2005 Conference.
[Silbersack]Silbersack，M.“在不牺牲互操作性的情况下通过随机化改进TCP/IP安全性”，EuroBSDCon 2005年会议。
[Stevens] Stevens, W., "Unix Network Programming, Volume 1: Networking APIs: Socket and XTI", Prentice Hall, 1998.
[Stevens]Stevens，W.，“Unix网络编程，第1卷：网络API:Socket和XTI”，Prentice Hall，1998年。
[TCP-SEC] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", Work in Progress, February 2010.
[TCP-SEC]Gont，F.，“传输控制协议（TCP）的安全评估”，正在进行的工作，2010年2月。
[Watson] Watson, P., "Slipping in the Window: TCP Reset Attacks", CanSecWest 2004 Conference.
[Watson]Watson，P.，“在窗口中滑动：TCP重置攻击”，CanSecWest 2004年会议。
Appendix A. Survey of the Algorithms in Use by Some Popular Implementations
附录A.一些流行实现中使用的算法概览
FreeBSD 8.0 implements Algorithm 1, and in response to this document now uses a "min_port" of 10000 and a "max_port" of 65535 [FreeBSD].
FreeBSD 8.0实现算法1，作为对本文档的响应，现在使用10000的“最小端口”和65535的“最大端口”[FreeBSD]。
Linux 2.6.15-53-386 implements Algorithm 3, with MD5 as the hash algorithm. If the algorithm is faced with the corner-case scenario described in Section 3.5, Algorithm 1 is used instead [Linux].
Linux 2.6.15-53-386实现算法3，MD5作为哈希算法。如果算法面临第3.5节所述的极端情况，则使用算法1[Linux]。
NetBSD 5.0.1 does not obfuscate its ephemeral port numbers. It selects ephemeral port numbers from the range 49152-65535, starting from port 65535, and decreasing the port number for each ephemeral port number selected [NetBSD].
NetBSD 5.0.1不会混淆其短暂的端口号。它从端口65535开始，从范围49152-65535中选择临时端口号，并减少所选每个临时端口号的端口号[NetBSD]。
OpenBSD 4.2 implements Algorithm 1, with a "min_port" of 1024 and a "max_port" of 49151. [OpenBSD]
OpenBSD4.2实现了算法1，“最小端口”为1024，“最大端口”为49151。[OpenBSD]
OpenSolaris 2009.06 implements Algorithm 1, with a "min_port" of 32768 and a "max_port" of 65535 [OpenSolaris].
OpenSolaris 2009.06实现算法1，“最小端口”为32768，“最大端口”为65535[OpenSolaris]。
Authors' Addresses
作者地址
Michael Vittrup Larsen Tieto Skanderborgvej 232 Aarhus DK-8260 Denmark
Michael Vittrup Larsen Tieto Skanderborgvej 232奥胡斯DK-8260丹麦
Phone: +45 8938 5100
EMail: michael.larsen@tieto.com
Phone: +45 8938 5100
EMail: michael.larsen@tieto.com
Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
阿根廷布宜诺斯艾利斯省费尔南多·冈特国家技术大学/学院地区哈多·埃瓦里斯托·卡里戈2644哈多1706
Phone: +54 11 4650 8472
EMail: fernando@gont.com.ar
Phone: +54 11 4650 8472
EMail: fernando@gont.com.ar