Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6528 SI6 Networks / UTN-FRH
Obsoletes: 1948 S. Bellovin
Updates: 793 Columbia University
Category: Standards Track February 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6528 SI6 Networks / UTN-FRH
Obsoletes: 1948 S. Bellovin
Updates: 793 Columbia University
Category: Standards Track February 2012
ISSN: 2070-1721
Defending against Sequence Number Attacks
防御序列号攻击
Abstract
摘要
This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793.
本文档指定了一种生成TCP初始序列号（ISN）的算法，以减少非路径攻击者猜测目标连接正在使用的序列号的机会。本文件修订（并正式废除）RFC 1948，并将该文件中最初提出的ISN生成算法纳入标准轨道，正式更新RFC 793。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc6528.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6528.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Generation of Initial Sequence Numbers . . . . . . . . . . . . 3
3. Proposed Initial Sequence Number Generation Algorithm . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Address-Based Trust-Relationship Exploitation
Attacks . . . . . . . . . . . . . . . . . . . . . . . 10
A.1. Blind TCP Connection-Spoofing . . . . . . . . . . . . . . 10
Appendix B. Changes from RFC 1948 . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Generation of Initial Sequence Numbers . . . . . . . . . . . . 3
3. Proposed Initial Sequence Number Generation Algorithm . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Address-Based Trust-Relationship Exploitation
Attacks . . . . . . . . . . . . . . . . . . . . . . . 10
A.1. Blind TCP Connection-Spoofing . . . . . . . . . . . . . . 10
Appendix B. Changes from RFC 1948 . . . . . . . . . . . . . . . . 12
For a long time, the Internet has experienced a number of off-path attacks against TCP connections. These attacks have ranged from trust-relationship exploitation to denial-of-service attacks [CPNI-TCP]. Discussion of some of these attacks dates back to at least 1985, when Morris [Morris1985] described a form of attack based on guessing what sequence numbers TCP [RFC0793] will use for new connections between two known end-points.
很长一段时间以来，互联网经历了许多针对TCP连接的非路径攻击。这些攻击包括从信任关系攻击到拒绝服务攻击[CPNI-TCP]。对其中一些攻击的讨论至少可以追溯到1985年，当时Morris[Morris1985]描述了一种基于猜测TCP[RFC0793]将用于两个已知端点之间新连接的序列号的攻击形式。
In 1996, RFC 1948 [RFC1948] proposed an algorithm for the selection of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing valid sequence numbers are reduced. With the aforementioned algorithm, such attacks would remain possible if and only if the attacker already has the ability to perform "man-in-the-middle" attacks.
1996年，RFC 1948[RFC1948]提出了一种选择TCP初始序列号（ISN）的算法，从而减少了非路径攻击者猜测有效序列号的机会。使用上述算法，只有当且仅当攻击者已经能够执行“中间人”攻击时，此类攻击才有可能发生。
This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track.
本文件修订（并正式废除）RFC 1948，并将该文件中最初提出的ISN生成算法纳入标准轨道。
Section 2 provides a brief discussion of the requirements for a good ISN generation algorithm. Section 3 specifies a good ISN selection algorithm. Appendix A provides a discussion of the trust-relationship exploitation attacks that originally motivated the publication of RFC 1948 [RFC1948]. Finally, Appendix B lists the differences from RFC 1948 to this document.
第2节简要讨论了良好的ISN生成算法的要求。第3节指定了一个好的ISN选择算法。附录A讨论了最初促使RFC 1948[RFC1948]出版的信任关系攻击。最后，附录B列出了RFC 1948与本文件之间的差异。
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]中所述进行解释。
RFC 793 [RFC0793] suggests that the choice of the ISN of a connection is not arbitrary, but aims to reduce the chances of a stale segment from being accepted by a new incarnation of a previous connection. RFC 793 [RFC0793] suggests the use of a global 32-bit ISN generator that is incremented by 1 roughly every 4 microseconds.
RFC 793[RFC0793]表明，对连接的ISN的选择不是任意的，而是旨在减少旧段被以前连接的新版本接受的可能性。RFC 793[RFC0793]建议使用大约每4微秒递增1的全局32位ISN生成器。
It is interesting to note that, as a matter of fact, protection against stale segments from a previous incarnation of the connection is enforced by preventing the creation of a new incarnation of a previous connection before 2*MSL have passed since a segment corresponding to the old incarnation was last seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This is accomplished by the TIME-WAIT state and TCP's "quiet time" concept (see Appendix B of [RFC1323]).
值得注意的是，事实上，通过防止在上次看到与旧连接对应的段（其中“MSL”是最新的）2*MSL之前创建新的前一个连接，可以对来自前一个连接的旧连接段进行保护“最大段生存期”[RFC0793]）。这是通过时间等待状态和TCP的“静默时间”概念实现的（参见[RFC1323]的附录B）。
Based on the assumption that ISNs are monotonically increasing across connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an incoming SYN segment to perform "heuristics" that enable the creation of a new incarnation of a connection while the previous incarnation is still in the TIME-WAIT state (see p. 945 of [Wright1994]). This avoids an interoperability problem that may arise when a node establishes connections to a specific TCP end-point at a high rate [Silbersack2005].
基于ISN在连接间单调增加的假设，许多堆栈（例如，4.2BSD派生）使用传入SYN段的ISN执行“启发式”，从而在前一个连接仍处于等待状态时创建新的连接（见[Wright1994]第945页）。这避免了当节点以高速率建立到特定TCP端点的连接时可能出现的互操作性问题[Silbersack2005]。
Unfortunately, the ISN generator described in [RFC0793] makes it trivial for an off-path attacker to predict the ISN that a TCP will use for new connections, thus allowing a variety of attacks against TCP connections [CPNI-TCP]. One of the possible attacks that takes advantage of weak sequence numbers was first described in [Morris1985], and its exploitation was widely publicized about 10 years later [Shimomura1995]. [CERT2001] and [USCERT2001] are advisories about the security implications of weak ISN generators. [Zalewski2001] and [Zalewski2002] contain a detailed analysis of ISN generators, and a survey of the algorithms in use by popular TCP implementations.
不幸的是，[RFC0793]中描述的ISN生成器使得非路径攻击者无法预测TCP将用于新连接的ISN，从而允许针对TCP连接[CPNI-TCP]的各种攻击。[Morris1985]首次描述了利用弱序列号的一种可能的攻击，大约10年后[Shimomura1995]广泛宣传了其利用。[CERT2001]和[USCERT2001]是关于弱ISN发生器安全影响的建议。[Zalewski2001]和[Zalewski2002]包含对ISN生成器的详细分析，以及对流行TCP实现使用的算法的调查。
Simple random selection of the TCP ISNs would mitigate those attacks that require an attacker to guess valid sequence numbers. However, it would also break the 4.4BSD "heuristics" to accept a new incoming connection when there is a previous incarnation of that connection in the TIME-WAIT state [Silbersack2005].
简单地随机选择TCP iSN可以减轻那个些需要攻击者猜测有效序列号的攻击。然而，它也会打破4.4BSD的“启发式”，当连接的前一个版本处于等待状态时，接受新的传入连接[Silbersack2005]。
We can prevent sequence number guessing attacks by giving each connection -- that is, each four-tuple of (localip, localport, remoteip, remoteport) -- a separate sequence number space. Within
我们可以通过给每个连接（即每个四元组（localip、localport、remoteip、remoteport））一个单独的序列号空间来防止序列号猜测攻击。在内部
each space, the ISN is incremented according to [RFC0793]; however, there is no obvious relationship between the numbering in different spaces.
每个空格，根据[RFC0793]递增ISN；但是，不同空间中的编号之间没有明显的关系。
An obvious way to prevent sequence number guessing attacks while not breaking the 4.4BSD heuristics would be to perform a simple random selection of TCP ISNs while maintaining state for dead connections (e.g. changing the TCP state transition diagram so that both end-points of all connections go to TIME-WAIT state). That would work but would consume system memory to store the additional state. Instead, we propose an improvement to the TCP ISN generation algorithm that does not require TCP to keep state for all recently terminated connections.
在不破坏4.4BSD启发式的情况下，防止序列号猜测攻击的一个明显方法是在保持死连接状态的同时执行TCP iSN的简单随机选择（例如，更改TCP状态转换图，使所有连接的两个端点都变为TIME-WAIT状态）。这将起作用，但会消耗系统内存来存储附加状态。相反，我们提出了对TCP ISN生成算法的改进，该算法不需要TCP为所有最近终止的连接保持状态。
TCP SHOULD generate its Initial Sequence Numbers with the expression:
TCP应使用以下表达式生成其初始序列号：
ISN = M + F(localip, localport, remoteip, remoteport, secretkey)
ISN = M + F(localip, localport, remoteip, remoteport, secretkey)
where M is the 4 microsecond timer, and F() is a pseudorandom function (PRF) of the connection-id. F() MUST NOT be computable from the outside, or an attacker could still guess at sequence numbers from the ISN used for some other connection. The PRF could be implemented as a cryptographic hash of the concatenation of the connection-id and some secret data; MD5 [RFC1321] would be a good choice for the hash function.
其中M是4微秒计时器，F（）是connection-id的伪随机函数（PRF）。F（）不能从外部计算，否则攻击者仍然可以从用于其他连接的ISN中猜测序列号。PRF可以实现为连接id和一些秘密数据的串联的密码散列；MD5[RFC1321]将是哈希函数的良好选择。
The result of F() is no more secure than 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 (i.e., ISNs selected by the victim), the attacker may simply search the entire secret-key space to find matches. To protect against this, the secret key should be of a reasonable length. Key lengths of 128 bits should be adequate. The secret key can either be a true random number [RFC4086] or some per-host secret. A possible mechanism for protecting the secret key would be to change it on occasion. For example, the secret key could be changed whenever one of the following events occur:
F（）的结果并不比密钥更安全。如果攻击者知道受害者正在使用哪个加密哈希函数（我们应该知道），并且攻击者可以获得足够的材料（即受害者选择的ISNs），则攻击者可以简单地搜索整个密钥空间以查找匹配项。为了防止出现这种情况，密钥的长度应该合理。128位的密钥长度应足够。密钥可以是真随机数[RFC4086]，也可以是每个主机的一些密钥。保护密钥的一种可能机制是偶尔更改密钥。例如，只要发生以下事件之一，就可以更改密钥：
o The system is being bootstrapped (e.g., the secret key could be a combination of some secret and the boot time of the machine).
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 at that point.
o 该密钥已被频繁使用，因此此时应视为不安全密钥。
Note that changing the secret would change the ISN space used for reincarnated connections, and thus could cause the 4.4BSD heuristics to fail; to maintain safety, either dead connection state could be kept or a quiet time observed for two maximum segment lifetimes before such a change.
请注意，更改机密将更改用于转世连接的ISN空间，因此可能导致4.4BSD启发式失败；为了保持安全性，在这种改变之前，可以保持死连接状态，或者观察两个最大段寿命的安静时间。
It should be noted that while there have been concerns about the security properties of MD5 [RFC6151], the algorithm specified in this document simply aims at reducing the chances of an off-path attacker guessing the ISN of a new connection, and thus in our threat model it is not worth the effort for an attacker to try to learn the secret key. Since MD5 is faster than other "stronger" alternatives, and is used in virtually all existing implementations of this algorithm, we consider that use of MD5 in the specified algorithm is acceptable. However, implementations should consider the trade-offs involved in using functions with stronger security properties, and employ them if it is deemed appropriate.
应该注意的是，尽管对MD5[RFC6151]的安全属性存在担忧，但本文档中指定的算法只是为了减少非路径攻击者猜测新连接的ISN的机会，因此在我们的威胁模型中，攻击者不值得尝试学习密钥。由于MD5比其他“更强”的备选方案快，并且实际上在该算法的所有现有实现中使用，所以我们认为在指定算法中使用MD5是可接受的。然而，实现应该考虑在使用具有更强安全属性的函数中涉及的折衷，并且如果被认为是适当的，则使用它们。
Good sequence numbers are not a replacement for cryptographic authentication, such as that provided by IPsec [RFC4301] or the TCP Authentication Option (TCP-AO) [RFC5925]. At best, they are a palliative measure.
好的序列号不能替代加密身份验证，例如IPsec[RFC4301]或TCP身份验证选项（TCP-AO）[RFC5925]提供的序列号。充其量，它们只是一种缓和措施。
If random numbers are used as the sole source of the secret, they MUST be chosen in accordance with the recommendations given in [RFC4086].
如果随机数被用作机密的唯一来源，则必须根据[RFC4086]中给出的建议进行选择。
A security consideration that should be made about the algorithm proposed in this document is that it might allow an attacker to count the number of systems behind a Network Address Translator (NAT) [RFC3022]. Depending on the ISN generators implemented by each of the systems behind the NAT, an attacker might be able to count the number of systems behind a NAT by establishing a number of TCP connections (using the public address of the NAT) and identifying the number of different sequence number "spaces". [Gont2009] discusses how this and other information leakages at NATs could be mitigated.
关于本文中提出的算法，应该考虑的一个安全因素是，它可能允许攻击者计算网络地址转换器（NAT）后面的系统数量[RFC3022]。根据NAT后面的每个系统实现的ISN生成器，攻击者可以通过建立TCP连接数（使用NAT的公共地址）并识别不同序列号“空格”的数量来计算NAT后面的系统数。[Gont2009]讨论了如何缓解NAT中的此信息泄漏和其他信息泄漏。
An eavesdropper who can observe the initial messages for a connection can determine its sequence number state, and may still be able to launch sequence number guessing attacks by impersonating that connection. However, such an eavesdropper can also hijack existing connections [Joncheray1995], so the incremental threat is not that high. Still, since the offset between a fake connection and a given real connection will be more or less constant for the lifetime of the secret, it is important to ensure that attackers can never capture
可以观察连接的初始消息的窃听者可以确定其序列号状态，并且仍然可以通过模拟该连接来发起序列号猜测攻击。然而，这样的窃听者也可以劫持现有的连接[Joncheray1995]，因此增加的威胁并没有那么高。尽管如此，由于假连接和给定真实连接之间的偏移量在秘密的生命周期中或多或少是恒定的，因此确保攻击者永远无法捕获非常重要
such packets. Typical attacks that could disclose them include both eavesdropping and the variety of routing attacks discussed in [Bellovin1989].
这样的包。可能泄露这些信息的典型攻击包括窃听和[Bellovin1989]中讨论的各种路由攻击。
Off-path attacks against TCP connections require the attacker to guess or know the four-tuple (localip, localport, remoteip, remoteport) that identifies the target connection. TCP port number randomization [RFC6056] reduces the chances of an attacker of guessing such a four-tuple by obfuscating the selection of TCP ephemeral ports, therefore contributing to the mitigation of such attacks. [RFC6056] provides advice on the selection of TCP ephemeral ports, such that the overall protection of TCP connections against off-path attacks is improved.
针对TCP连接的非路径攻击要求攻击者猜测或知道标识目标连接的四个元组（localip、localport、remoteip、remoteport）。TCP端口号随机化[RFC6056]通过混淆TCP临时端口的选择，减少了攻击者猜测此类四元组的机会，从而有助于缓解此类攻击。[RFC6056]提供了关于选择TCP临时端口的建议，从而改进了TCP连接对非路径攻击的总体保护。
[CPNI-TCP] contains a discussion of all the currently known attacks that require an attacker to know or be able to guess the TCP sequence numbers in use by the target connection.
[CPNI-TCP]包含所有当前已知攻击的讨论，这些攻击要求攻击者知道或能够猜测目标连接正在使用的TCP序列号。
Matt Blaze and Jim Ellis contributed some crucial ideas to RFC 1948, on which this document is based. Frank Kastenholz contributed constructive comments to that memo.
Matt Blaze和Jim Ellis为RFC 1948贡献了一些重要的想法，本文件就是基于这些想法编写的。弗兰克·卡斯滕霍尔茨对该备忘录提出了建设性意见。
The authors of this document would like to thank (in chronological order) Alfred Hoenes, Lloyd Wood, Lars Eggert, Joe Touch, William Allen Simpson, Tim Shepard, Wesley Eddy, Anantha Ramaiah, and Ben Campbell for providing valuable comments on draft versions of this document.
本文件的作者（按时间顺序）感谢阿尔弗雷德·霍恩斯、劳埃德·伍德、拉尔斯·艾格特、乔·图奇、威廉·艾伦·辛普森、蒂姆·谢泼德、卫斯理·艾迪、阿南塔·拉迈亚和本·坎贝尔对本文件草案提出的宝贵意见。
Fernando Gont wishes to thank Jorge Oscar Gont, Nelida Garcia, and Guillermo Gont for their love and support, and Daniel Bellomo and Christian O'Flaherty for their support in his Internet engineering activities.
费尔南多·贡特感谢豪尔赫·奥斯卡·贡特、内丽达·加西亚和吉列尔莫·贡特对他的爱和支持，感谢丹尼尔·贝洛莫和克里斯蒂安·奥弗莱赫蒂对他的互联网工程活动的支持。
Fernando Gont's attendance to IETF meetings was supported by ISOC's "Fellowship to the IETF" program.
费尔南多·冈特出席IETF会议得到了ISOC“IETF奖学金”计划的支持。
[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月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，B.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[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月。
[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月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056]Larsen，M.和F.Gont，“传输协议端口随机化建议”，BCP 156，RFC 6056，2011年1月。
[Bellovin1989] Morris, R., "Security Problems in the TCP/IP Protocol Suite", Computer Communications Review, vol. 19, no. 2, pp. 32-48, 1989.
[Bellovin1989]Morris，R.，“TCP/IP协议套件中的安全问题”，《计算机通信评论》，第19卷，第2期，第32-48页，1989年。
[CERT2001] CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in TCP/IP Initial Sequence Numbers", http://www.cert.org/advisories/CA-2001-09.html, 2001.
[CERT2001]CERT，“CERT咨询CA-2001-09：TCP/IP初始序列号的统计缺陷”，http://www.cert.org/advisories/CA-2001-09.html, 2001.
[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", http://www.gont.com.ar/ papers/tn-03-09-security-assessment-TCP.pdf, 2009.
[CPNI-TCP]CPNI，“传输控制协议（TCP）的安全评估”，http://www.gont.com.ar/ 文件/tn-03-09-security-assessment-TCP.pdf，2009年。
[Gont2009] Gont, F. and P. Srisuresh, "Security implications of Network Address Translators (NATs)", Work in Progress, October 2009.
[Gont2009]Gont，F.和P.Srisuresh，“网络地址转换器（NAT）的安全影响”，正在进行的工作，2009年10月。
[Joncheray1995] Joncheray, L., "A Simple Active Attack Against TCP", Proc. Fifth Usenix UNIX Security Symposium, 1995.
[Joncheray1995]Joncheray，L.，“针对TCP的简单主动攻击”，Proc。第五届Usenix UNIX安全研讨会，1995年。
[Morris1985] Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, NJ, 1985.
[Morris 1985]Morris，R.，“4.2BSD UNIX TCP/IP软件中的弱点”，CSTR 117，美国电话电报公司贝尔实验室，新泽西州默里山，1985年。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0854]Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251]Ylonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954]Siemborski，R.和A.Melnikov，“用于身份验证的SMTP服务扩展”，RFC 49542007年7月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[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月。
[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol (AXFR)", RFC 5936, June 2010.
[RFC5936]Lewis，E.和A.Hoenes，“DNS区域传输协议（AXFR）”，RFC 59362010年6月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 61512011年3月。
[Shimomura1995] Shimomura, T., "Technical details of the attack described by Markoff in NYT", http://www.gont.com.ar/docs/post-shimomura-usenet.txt, Message posted in USENET's comp.security.misc newsgroup, Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>, 1995.
[Shimomura1995]Shimomura，T.，“Markoff在纽约时报中描述的攻击技术细节”，http://www.gont.com.ar/docs/post-shimomura-usenet.txt，在USENET的comp.security.misc新闻组中发布的消息，消息ID:<3g5gkl$5j1@ariel.sdsc.edu>, 1995.
[Silbersack2005] Silbersack, M., "Improving TCP/IP security through randomization without sacrificing interoperability", EuroBSDCon 2005 Conference.
[Silbersack 2005]Silbersack，M.，“通过随机化改进TCP/IP安全性，而不牺牲互操作性”，EuroBSDCon 2005年会议。
[USCERT2001] US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple TCP/IP implementations may use statistically predictable initial sequence numbers", http://www.kb.cert.org/vuls/id/498440, 2001.
[USCERT2001]US-CERT，“US-CERT漏洞注释VU#498440：多个TCP/IP实现可能使用统计上可预测的初始序列号”，http://www.kb.cert.org/vuls/id/498440, 2001.
[Wright1994] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley, 1994.
[Wright1994]Wright，G.和W.Stevens，“TCP/IP图解，第2卷：实现”，Addison-Wesley，1994年。
[Zalewski2001] Zalewski, M., "Strange Attractors and TCP/IP Sequence Number Analysis", http://lcamtuf.coredump.cx/oldtcp/tcpseq.html, 2001.
[Zalewski2001]Zalewski，M.，“奇怪吸引子和TCP/IP序列号分析”，http://lcamtuf.coredump.cx/oldtcp/tcpseq.html, 2001.
[Zalewski2002] Zalewski, M., "Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later", http://lcamtuf.coredump.cx/newtcp/, 2002.
[Zalewski2002]Zalewski，M.，“奇怪吸引子和TCP/IP序列号分析——一年后”，http://lcamtuf.coredump.cx/newtcp/, 2002.
This section discusses the trust-relationship exploitation attack that originally motivated the publication of RFC 1948 [RFC1948]. It should be noted that while RFC 1948 focused its discussion of address-based trust-relationship exploitation attacks on Telnet [RFC0854] and the various UNIX "r" commands, both Telnet and the various "r" commands have since been largely replaced by secure counterparts (such as SSH [RFC4251]) for the purpose of remote login and remote command execution. Nevertheless, address-based trust relationships are still employed nowadays in some scenarios. For example, some SMTP [RFC5321] deployments still authenticate their users by means of their IP addresses, even when more appropriate authentication mechanisms are available [RFC4954]. Another example is the authentication of DNS secondary servers [RFC1034] by means of their IP addresses for allowing DNS zone transfers [RFC5936], or any other access control mechanism based on IP addresses.
本节讨论最初促使RFC 1948[RFC1948]出版的信任关系攻击。应该注意的是，虽然RFC 1948重点讨论了对Telnet[RFC0854]和各种UNIX“r”命令的基于地址的信任关系攻击，但Telnet和各种“r”命令在很大程度上已被安全的对等命令（如SSH[RFC4251]）所取代用于远程登录和远程命令执行。尽管如此，基于地址的信任关系仍然在一些场景中使用。例如，某些SMTP[RFC5321]部署仍然通过其IP地址对其用户进行身份验证，即使有更合适的身份验证机制可用[RFC4954]。另一个例子是通过允许DNS区域传输的IP地址[RFC5936]或基于IP地址的任何其他访问控制机制对DNS辅助服务器[RFC1034]进行身份验证。
In 1985, Morris [Morris1985] described a form of attack based on guessing what sequence numbers TCP [RFC0793] will use for new connections. Briefly, the attacker gags a host trusted by the target, impersonates the IP address of the trusted host when talking to the target, and completes the three-way handshake based on its guess at the next ISN to be used. An ordinary connection to the target is used to gather sequence number state information. This entire sequence, coupled with address-based authentication, allows the attacker to execute commands on the target host.
1985年，Morris[Morris1985]描述了一种基于猜测TCP[RFC0793]将用于新连接的序列号的攻击形式。简单地说，攻击者堵住目标信任的主机，在与目标通话时模拟受信任主机的IP地址，并根据其对下一个要使用的ISN的猜测完成三方握手。与目标的普通连接用于收集序列号状态信息。整个序列再加上基于地址的身份验证，使攻击者能够在目标主机上执行命令。
Clearly, the proper solution for these attacks is cryptographic authentication [RFC4301] [RFC4120] [RFC4251].
显然，这些攻击的正确解决方案是加密身份验证[RFC4301][RFC4120][RFC4251]。
The following subsection provides technical details for the trust-relationship exploitation attack described by Morris [Morris1985].
以下小节提供了Morris[Morris1985]描述的信任关系利用攻击的技术细节。
In order to understand the particular case of sequence number guessing, one must look at the three-way handshake used in the TCP open sequence [RFC0793]. Suppose client machine A wants to talk to rsh server B. It sends the following message:
为了理解序列号猜测的特殊情况，必须了解TCP开放序列[RFC0793]中使用的三向握手。假设客户机A想要与rsh服务器B对话。它发送以下消息：
A->B: SYN, ISNa
A->B:SYN，ISNa
That is, it sends a packet with the SYN ("synchronize sequence number") bit set and an initial sequence number ISNa.
也就是说，它发送一个带有SYN（“同步序列号”）位集和初始序列号ISNa的数据包。
B replies with
B答复如下：
B->A: SYN, ISNb, ACK(ISNa)
B->A: SYN, ISNb, ACK(ISNa)
In addition to sending its own ISN, it acknowledges A's. Note that the actual numeric value ISNa must appear in the message.
除了发送自己的ISN外，它还承认A。请注意，消息中必须显示实际数值ISNa。
A concludes the handshake by sending
A通过发送结束握手
A->B: ACK(ISNb)
A->B: ACK(ISNb)
RFC 793 [RFC0793] specifies that the 32-bit counter be incremented by 1 in the low-order position about every 4 microseconds. Instead, Berkeley-derived kernels traditionally incremented it by a constant every second, and by another constant for each new connection. Thus, if you opened a connection to a machine, you knew to a very high degree of confidence what sequence number it would use for its next connection. And therein lied the vulnerability.
RFC 793[RFC0793]指定32位计数器在低位大约每4微秒递增1。相反，伯克利衍生的内核传统上每秒递增一个常数，每次新连接递增一个常数。因此，如果您打开了一个与机器的连接，您就非常有信心地知道它下一个连接将使用什么序列号。这就是弱点所在。
The attacker X first opens a real connection to its target B -- say, to the mail port or the TCP echo port. This gives ISNb. It then impersonates A and sends
攻击者X首先打开到其目标B的真实连接——例如，到邮件端口或TCP回显端口。这给了ISNb。然后，它模拟一个
Ax->B: SYN, ISNx
Ax->B:SYN，ISNx
where "Ax" denotes a packet sent by X pretending to be A.
其中“Ax”表示X假装为a发送的数据包。
B's response to X's original SYN (so to speak)
B对X原始SYN的响应（可以这么说）
B->A: SYN, ISNb', ACK(ISNx)
B->A: SYN, ISNb', ACK(ISNx)
goes to the legitimate A, about which more anon. X never sees that message but can still send
转到合法的A，更多anon.X从未看到该消息，但仍然可以发送该消息
Ax->B: ACK(ISNb')
Ax->B: ACK(ISNb')
using the predicted value for ISNb'. If the guess is right -- and usually it will be, if the sequence numbers are weak -- B's rsh server thinks it has a legitimate connection with A, when in fact X is sending the packets. X can't see the output from this session, but it can execute commands as more or less any user -- and in that case, the game is over and X has won.
使用ISNb'的预测值。如果猜测是正确的——通常情况下，如果序列号很弱——B的rsh服务器认为它与a有合法连接，而实际上X正在发送数据包。X看不到此会话的输出，但它可以或多或少地以任何用户的身份执行命令——在这种情况下，游戏结束了，X赢了。
There is a minor difficulty here. If A sees B's message, it will realize that B is acknowledging something it never sent, and will send a RST packet in response to tear down the connection. However, an attacker could send the TCP segments containing the commands to be
这里有一个小困难。如果A看到B的消息，它将意识到B正在确认它从未发送过的内容，并将发送RST数据包以响应中断连接。但是，攻击者可以发送包含要执行的命令的TCP段
executed back-to-back with the segments required to establish the TCP connection, and thus by the time the connection is reset, the attacker has already won.
与建立TCP连接所需的段背靠背执行，因此，当连接重置时，攻击者已经赢了。
In the past, attackers exploited a common TCP implementation bug to prevent the connection from being reset (see subsection "A Common TCP Bug" in [RFC1948]). However, all TCP implementations that used to implement this bug have been fixed for a long time.
过去，攻击者利用一个常见的TCP实现错误来防止连接被重置（请参阅[RFC1948]中的“常见TCP错误”小节）。但是，所有用于实现此错误的TCP实现都已经修复了很长一段时间。
o This document is Standards Track (rather than Informational).
o 本文档是标准跟踪（而非信息性）。
o Formal requirements [RFC2119] are specified.
o 规定了正式要求[RFC2119]。
o The discussion of address-based trust-relationship attacks has been updated and moved to an appendix.
o 关于基于地址的信任关系攻击的讨论已更新并移至附录中。
o The subsection entitled "A Common TCP Bug" (describing a common bug in the BSD TCP implementation) has been removed.
o 标题为“常见TCP错误”（描述BSD TCP实现中的常见错误）的小节已被删除。
Authors' Addresses
作者地址
Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont SI6 Networks/UTN-FRH Evaristo Carriego 2644 Haedo，布宜诺斯艾利斯省1706阿根廷
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
Steven M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US
Steven M.Bellovin哥伦比亚大学阿姆斯特丹大道1214号MC 0401美国纽约州纽约市10027
Phone: +1 212 939 7149
EMail: bellovin@acm.org
Phone: +1 212 939 7149
EMail: bellovin@acm.org