Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7739 Huawei Technologies
Category: Informational February 2016
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7739 Huawei Technologies
Category: Informational February 2016
ISSN: 2070-1721
Security Implications of Predictable Fragment Identification Values
可预测片段标识值的安全含义
Abstract
摘要
IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.
IPv6指定片段头，用于碎片和重组机制。片段头包含一个“标识”字段，该字段与数据包的IPv6源地址和IPv6目标地址一起标识对应于相同原始数据报的片段，以便接收主机可以将它们重新组装在一起。设置标识字段的唯一要求是，对应的值必须不同于最近使用相同源地址和目标地址发送的任何其他碎片数据报所采用的值。一些实现使用一个简单的全局计数器来设置标识字段，从而产生可预测的标识值。本文档分析了可预测标识值的安全影响，并提供了设置片段头的标识字段的实现指南，以减轻上述安全影响。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7739.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7739.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Implications of Predictable Fragment Identification
Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Constraints for the Selection of Fragment Identification
Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Algorithms for Selecting Fragment Identification Values . . . 8
5.1. Per-Destination Counter (Initialized to a Random Value) . 8
5.2. Randomized Identification Values . . . . . . . . . . . . 9
5.3. Hash-Based Fragment Identification Selection Algorithm . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Information Leakage Produced by Vulnerable
Implementations . . . . . . . . . . . . . . . . . . 16
Appendix B. Survey of Fragment Identification Selection
Algorithms Employed by Popular IPv6 Implementations 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Implications of Predictable Fragment Identification
Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Constraints for the Selection of Fragment Identification
Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Algorithms for Selecting Fragment Identification Values . . . 8
5.1. Per-Destination Counter (Initialized to a Random Value) . 8
5.2. Randomized Identification Values . . . . . . . . . . . . 9
5.3. Hash-Based Fragment Identification Selection Algorithm . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Information Leakage Produced by Vulnerable
Implementations . . . . . . . . . . . . . . . . . . 16
Appendix B. Survey of Fragment Identification Selection
Algorithms Employed by Popular IPv6 Implementations 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that its value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address.
IPv6指定片段头，用于碎片和重组机制。片段头包含一个“标识”字段，该字段与数据包的IPv6源地址和IPv6目标地址一起标识对应于相同原始数据报的片段，以便接收主机可以将它们重新组装在一起。设置标识字段的唯一要求是其值必须不同于最近使用相同源地址和目标地址发送的任何其他碎片数据报的值。
The most trivial algorithm to avoid reusing Identification values too quickly is to maintain a global counter that is incremented for each fragmented datagram that is transmitted. However, this trivial algorithm leads to predictable Identification values that can be leveraged to perform a variety of attacks.
避免过快重用标识值的最简单的算法是维护一个全局计数器，该计数器对于传输的每个碎片数据报递增。但是，这种简单的算法会产生可预测的标识值，这些值可用于执行各种攻击。
Section 3 of this document analyzes the security implications of predictable Identification values. Section 4 discusses constraints in the possible algorithms for selecting Identification values. Section 5 specifies a number of algorithms that could be used for generating Identification values that mitigate the issues discussed in this document. Finally, Appendix B contains a survey of the algorithms employed by popular IPv6 implementations for generating the Identification values.
本文件第3节分析了可预测标识值的安全含义。第4节讨论了选择识别值的可能算法中的约束。第5节规定了可用于生成识别值的若干算法，以缓解本文件中讨论的问题。最后，附录B包含对流行IPv6实现用于生成标识值的算法的调查。
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]中所述进行解释。
Predictable Identification values result in an information leakage that can be exploited in a number of ways. Among others, they may potentially be exploited to:
可预测的标识值会导致信息泄漏，可通过多种方式加以利用。除其他外，它们可能被用来：
o determine the packet rate at which a given system is transmitting information
o 确定给定系统传输信息的分组速率
o perform stealth port scans to a third party
o 向第三方执行隐形端口扫描
o uncover the rules of a number of firewalls
o 了解许多防火墙的规则
o count the number of systems behind a middle-box
o 计算中间框后面的系统数
o perform Denial-of-Service (DoS) attacks, or
o 执行拒绝服务（DoS）攻击，或
o perform data injection attacks against transport or application protocols
o 对传输或应用程序协议执行数据注入攻击
The security implications introduced by predictable Identification values in IPv6 are very similar to those of predictable Identification values in IPv4.
IPv6中的可预测标识值引入的安全含义与IPv4中的可预测标识值非常相似。
NOTE:
[Sanfilippo1998a] originally pointed out how the IPv4
Identification field could be examined to determine the packet
rate at which a given system is transmitting information. Later,
[Sanfilippo1998b] described how a system with such an
implementation could be used to perform a stealth port scan to a
third (victim) host. [Sanfilippo1999] explained how to exploit
this implementation strategy to uncover the rules of a number of
firewalls. [Bellovin2002] explained how the IPv4 Identification
field could be exploited to count the number of systems behind a
NAT. [Fyodor2004] is an entire paper on most (if not all) the
ways to exploit the information provided by the Identification
field of the IPv4 header (and these results apply in a similar way
to IPv6). [Zalewski2003] originally envisioned the exploitation
of IP fragmentation/reassembly for performing data injection
attacks against upper-layer protocols. [Herzberg2013] explores
the use of IPv4/IPv6 fragmentation and predictable Identification
values for performing DNS cache poisoning attacks in great detail.
[RFC6274] covers the security implications of the IPv4 case in
detail.
NOTE:
[Sanfilippo1998a] originally pointed out how the IPv4
Identification field could be examined to determine the packet
rate at which a given system is transmitting information. Later,
[Sanfilippo1998b] described how a system with such an
implementation could be used to perform a stealth port scan to a
third (victim) host. [Sanfilippo1999] explained how to exploit
this implementation strategy to uncover the rules of a number of
firewalls. [Bellovin2002] explained how the IPv4 Identification
field could be exploited to count the number of systems behind a
NAT. [Fyodor2004] is an entire paper on most (if not all) the
ways to exploit the information provided by the Identification
field of the IPv4 header (and these results apply in a similar way
to IPv6). [Zalewski2003] originally envisioned the exploitation
of IP fragmentation/reassembly for performing data injection
attacks against upper-layer protocols. [Herzberg2013] explores
the use of IPv4/IPv6 fragmentation and predictable Identification
values for performing DNS cache poisoning attacks in great detail.
[RFC6274] covers the security implications of the IPv4 case in
detail.
One key difference between the IPv4 case and the IPv6 case is that, in IPv4, the Identification field is part of the fixed IPv4 header (and thus usually set for all packets), while in IPv6 the Identification field is present only in those packets that carry a Fragment Header. As a result, successful exploitation of the Identification field depends on two different factors:
IPv4情况和IPv6情况之间的一个关键区别是，在IPv4中，标识字段是固定IPv4报头的一部分（因此通常为所有数据包设置），而在IPv6中，标识字段仅存在于携带片段报头的数据包中。因此，识别字段的成功利用取决于两个不同的因素：
o vulnerable Identification generators, and
o 易受攻击的识别生成器，以及
o the ability of an attacker to trigger the use of IPv6 fragmentation for packets sent from/to the victim node
o 攻击者能够触发对从/发送到受害节点的数据包使用IPv6分段
The scenarios in which an attacker may successfully perform the aforementioned attacks depend on the specific attack type. For example, in order to perform a DoS attack on communications between two hosts, an attacker would need to know the IPv6 addresses employed by the aforementioned two nodes. Such knowledge may be readily available if the target of the attack is the communication between
攻击者成功执行上述攻击的场景取决于特定的攻击类型。例如，为了对两台主机之间的通信执行DoS攻击，攻击者需要知道上述两个节点使用的IPv6地址。如果攻击的目标是双方之间的通信，则此类知识可能随时可用
two specific BGP peers, two specific SMTP servers, or one specific primary DNS server and one of its secondary DNS servers, but may not be easily available if the goal is a DoS attack on all communications between arbitrary IPv6 hosts (e.g., the goal is to perform a DoS attack on all communications involving one specific node with arbitrary/unknown hosts). Other attacks, such as performing stealth port scans to a third party or determining the packet rate at which a given system is transmitting information, only require the attacker to know the IPv6 address of a vulnerable implementation.
两个特定的BGP对等点、两个特定的SMTP服务器或一个特定的主DNS服务器及其一个辅助DNS服务器，但如果目标是对任意IPv6主机之间的所有通信进行DoS攻击，则可能无法轻松使用这些服务器（例如，目标是对涉及具有任意/未知主机的特定节点的所有通信执行DoS攻击）。其他攻击，如对第三方执行隐形端口扫描或确定给定系统传输信息的数据包速率，只需要攻击者知道易受攻击实现的IPv6地址。
As noted in Section 1, some implementations have been known to use predictable Identification values. For instance, Appendix B of this document shows that recent versions of a number of popular IPv6 implementations employ predictable values for the Identification field of the Fragment Header.
如第1节所述，一些实现已知使用可预测的标识值。例如，本文档的附录B显示，许多流行IPv6实现的最新版本为片段头的标识字段使用了可预测的值。
Additionally, we note that [RFC2460] states that when an ICMPv6 Packet Too Big (PTB) error message advertising a Maximum Transfer Unit (MTU) smaller than 1280 bytes is received, the receiving host is not required to reduce the Path-MTU for the corresponding Destination Address, but must simply include a Fragment Header in all subsequent packets sent to that destination. This triggers the use of the so-called IPv6 "atomic fragments" [RFC6946]: IPv6 fragments with a Fragment Offset equal to 0, and the "M" ("More fragments") bit clear. [DEPGEN] documents the motivation of deprecating the generation of IPv6 atomic fragments in [RFC2460].
此外，我们注意到[RFC2460]指出，当接收到一条ICMPv6数据包太大（PTB）错误消息，该消息宣传小于1280字节的最大传输单元（MTU），则接收主机无需减少相应目的地址的路径MTU，但必须只在发送到该目的地的所有后续数据包中包含一个片段头。这触发了所谓的IPv6“原子片段”[RFC6946]的使用：片段偏移量等于0的IPv6片段，“M”（“更多片段”）位清除。[DEPGEN]在[RFC2460]中记录了反对生成IPv6原子片段的动机。
Thus, an attacker can usually cause a victim host to "fragment" its outgoing packets by sending it a forged ICMPv6 Packet Too Big (PTB) error message that advertises an MTU smaller than 1280 bytes.
因此，攻击者通常可以通过向受攻击主机发送伪造的ICMPv6数据包过大（PTB）错误消息，播发小于1280字节的MTU，从而使受攻击主机“分割”其传出数据包。
There are a number of aspects that should be considered, though:
尽管如此，仍应考虑以下几个方面：
o All the implementations the author is aware of record the Path-MTU information on a per-destination basis. Thus, an attacker can only cause the victim to enable fragmentation for those packets sent to the Source Address of IPv6 packet embedded in the payload of the ICMPv6 PTB message. However, we note that Section 5.2 of [RFC1981] notes that an implementation could maintain a single system-wide Path MTU (PMTU) value to be used for all packets sent to that node. Clearly, such implementations would exacerbate the problem of any attacks based on Path MTU Discovery (PMTUD) [RFC5927] or IPv6 fragmentation.
o 作者所知道的所有实现都以每个目的地为基础记录路径MTU信息。因此，攻击者只能使受害者对发送到嵌入在ICMPv6 PTB消息有效负载中的IPv6数据包的源地址的那些数据包启用碎片。然而，我们注意到[RFC1981]的第5.2节指出，一个实现可以维护一个系统范围的MTU（PMTU）值，用于发送到该节点的所有数据包。显然，这种实现会加剧基于路径MTU发现（PMTUD）[RFC5927]或IPv6碎片的任何攻击问题。
o If the victim node implements some of the counter-measures for ICMP attacks described in RFC 5927 [RFC5927], it might be difficult for an attacker to cause the victim node to employ fragmentation for its outgoing packets. However, many current
o 如果受害节点实施RFC 5927[RFC5927]中所述的ICMP攻击的一些对策，攻击者可能很难使受害节点对其传出的数据包使用碎片。然而，目前有许多
implementations fail to enforce these validation checks. For example, Linux 2.6.38-8 does not even require received ICMPv6 error messages to correspond to an ongoing communication instance.
实现无法强制执行这些验证检查。例如，Linux2.6.38-8甚至不需要收到ICMPv6错误消息来对应正在进行的通信实例。
o Some implementations (notably Linux) have already been updated according to [DEPGEN] such that ICMPv6 PTB messages do not result in the generation of IPv6 atomic fragments.
o 一些实现（尤其是Linux）已经根据[DEPGEN]进行了更新，这样ICMPv6 PTB消息就不会产生IPv6原子片段。
Implementations that employ predictable Identification values and also fail to enforce validation checks on ICMPv6 error messages become vulnerable to the same type of attacks that can be exploited with IPv4 fragmentation, discussed earlier in this section.
采用可预测标识值且无法对ICMPv6错误消息实施验证检查的实现容易受到与IPv4碎片攻击类型相同的攻击，本节前面将讨论这一点。
One possible way in which predictable Identification values could be leveraged for performing a DoS attack is as follows: Let us assume that Host A is communicating with Host B, and that an attacker wants to perform a DoS attack such communication. The attacker would learn the Identification value currently in use by Host A, possibly by sending any packet that would elicit a fragmented response (e.g., an ICPMv6 echo request with a large payload). The attacker would then send a forged ICMPv6 PTB error message to Host A (with the IPv6 Source Address of the embedded IPv6 packet set to the IPv6 address of Host A, and the Destination Address of the embedded IPv6 packet set to the IPv6 address of a Host B), such that any subsequent packets sent by Host A to Host B include a Fragment Header. Finally, the attacker would send forged IPv6 fragments to Host B, with their IPv6 Source Address set to that of Host A, and Identification values that would result in collisions with the Identification values employed for the legitimate traffic sent by Host A to Host B. If Host B discards fragments that result in collisions of Identification values (e.g., such fragments overlap, and the host implements [RFC5722]), the attacker could simply trash the Identification space by sending multiple forged fragments with different Identification values, such that any subsequent packets from Host A to Host B are discarded at Host B as a result of the malicious fragments sent by the attacker.
利用可预测的标识值执行DoS攻击的一种可能方式如下：假设主机a正在与主机B通信，并且攻击者希望在这种通信中执行DoS攻击。攻击者可能会通过发送任何会引发分段响应的数据包（例如，具有大负载的ICPMv6回显请求）来了解主机A当前使用的标识值。然后，攻击者将向主机a发送伪造的ICMPv6 PTB错误消息（嵌入式IPv6数据包的IPv6源地址设置为主机a的IPv6地址，嵌入式IPv6数据包的目标地址设置为主机B的IPv6地址），以便主机a向主机B发送的任何后续数据包都包含一个片段头。最后，攻击者会将伪造的IPv6片段发送到主机B，并将其IPv6源地址设置为主机A的源地址，以及会导致与主机A发送给主机B的合法通信所使用的标识值冲突的标识值。如果主机B丢弃导致标识值冲突的片段（例如，这些片段重叠，并且主机实现[RFC5722]），攻击者可以通过发送具有不同标识值的多个伪造片段来破坏标识空间，这样，由于攻击者发送的恶意片段，从主机A到主机B的任何后续数据包都会在主机B上被丢弃。
NOTE: For example, Linux 2.6.38-10 is vulnerable to the aforementioned issue.
注意：例如，Linux 2.6.38-10易受上述问题的攻击。
[RFC6946] describes an improved processing of these packets that would eliminate this specific attack vector, at least in the case of TCP connections that employ the Path-MTU Discovery mechanism.
[RCF6946]描述了这些分组的改进处理，至少在TCP连接使用路径MTU发现机制的情况下，该分组将消除该特定攻击向量。
The aforementioned attack scenario is simply included to illustrate the problem of employing predictable Identification values. We note that regardless of the attacker's ability to cause a victim host to
包含上述攻击场景只是为了说明使用可预测标识值的问题。我们注意到，无论攻击者是否有能力使受害主机
employ fragmentation when communicating with third parties, use of predictable Identification values makes communication flows that employ fragmentation vulnerable to any fragmentation-based attacks.
使用碎片与第三方通信时，使用可预测的标识值会使使用碎片的通信流容易受到任何基于碎片的攻击。
The Identification field of the Fragment Header is 32-bits long. However, when translators (e.g. [RFC6145]) are employed, the high-order 16 bits of the Identification field are effectively ignored.
片段头的标识字段长度为32位。然而，当使用翻译器（例如[RFC6145]）时，识别字段的高阶16位被有效地忽略。
NOTE: [RFC6145] notes that, when translating in the IPv6-to-IPv4 direction, "if there is a Fragment Header in the IPv6 packet, the last 16 bits of its value MUST be used for the IPv4 identification value".
注意：[RFC6145]注意，在IPv6到IPv4的方向上进行转换时，“如果IPv6数据包中存在片段头，则其值的最后16位必须用于IPv4标识值”。
Additionally, Section 3.3 of [RFC6052] encourages operators to use a Network-Specific Prefix (NSP) that maps the IPv4 address space into IPv6. Thus, when an NSP is being used, IPv6 addresses representing IPv4 nodes (reached through a stateless translator) are indistinguishable from native IPv6 addresses.
此外，[RFC6052]第3.3节鼓励运营商使用网络特定前缀（NSP），将IPv4地址空间映射到IPv6。因此，当使用NSP时，表示IPv4节点的IPv6地址（通过无状态转换器到达）与本机IPv6地址无法区分。
Thus, when translators are employed, the "effective" length of the Identification field is 16 bits and, as a result, at least during the IPv6/IPv4 transition/co-existence phase, it is probably safer to assume that only the low-order 16 bits of the Identification field are of use to the destination system.
因此，当使用翻译器时，标识字段的“有效”长度为16位，因此，至少在IPv6/IPv4转换/共存阶段，假设只有标识字段的低阶16位用于目的地系统可能更安全。
Regarding the selection of Identification values, the only requirement specified in [RFC2460] is that the Identification value must be different than that of any other fragmented packet sent recently with the same Source Address and Destination Address. Failure to comply with this requirement could lead to the interoperability problems discussed in [RFC4963].
关于标识值的选择，[RFC2460]中规定的唯一要求是标识值必须不同于最近使用相同源地址和目的地址发送的任何其他碎片数据包的标识值。未能遵守此要求可能导致[RFC4963]中讨论的互操作性问题。
From a security standpoint, unpredictable Identification values are desirable. However, this is somewhat at odds with the "reuse" requirements specified in [RFC2460], that specifies that an Identification value must be different than that employed for any other fragmented packet sent recently with the same Source Address and Destination Address.
从安全角度来看，不可预测的标识值是可取的。然而，这与[RFC2460]中规定的“重用”要求有些不一致，该要求规定标识值必须不同于最近使用相同源地址和目标地址发送的任何其他碎片数据包的标识值。
Finally, since Identification values need to be selected for each outgoing datagram that requires fragmentation, the performance impact should be considered when choosing an algorithm for the selection of Identification values.
最后，由于需要为每个需要分段的传出数据报选择标识值，因此在选择标识值选择算法时应考虑性能影响。
There are a number of algorithms that may be used for setting the Identification field such that the security issues discussed in this document are avoided. This section presents three of those.
有许多算法可用于设置标识字段，以避免本文档中讨论的安全问题。本节介绍其中的三个。
The algorithm in Section 5.1 typically leads to a low Identification reuse frequency at the expense of keeping per-destination state; this algorithm only uses a Pseudorandom Number Generator (PNRG) when the host communicates with a new destination. The algorithm in Section 5.2 may result in a higher Identification reuse frequency. It also uses a PRNG for each datagram that needs to be fragmented. Hence, the algorithm in Section 5.1 will likely result in better performance properties. Finally, the algorithm in Section 5.3 achieves a similar Identification reuse frequency to that of the algorithm in Section 5.1 without the need of keeping state, but possibly at the expense of lower per-packet performance.
第5.1节中的算法通常导致较低的标识重用频率，但代价是保持每个目标状态；该算法仅在主机与新目标通信时使用伪随机数生成器（PNRG）。第5.2节中的算法可能会导致更高的识别重用频率。它还为每个需要分段的数据报使用PRNG。因此，第5.1节中的算法可能会产生更好的性能。最后，第5.3节中的算法实现了与第5.1节中的算法相似的识别重用频率，无需保持状态，但可能以较低的每包性能为代价。
NOTE: Since the specific algorithm to be employed for the PRNGs in Section 5.1 and Section 5.2, and the specific algorithms to be employed for the hash functions in Section 5.3 have not been specified, it is impossible to provide a quantitative performance comparison of the algorithms described in this section.
注：由于第5.1节和第5.2节中用于PRNG的特定算法以及第5.3节中用于哈希函数的特定算法尚未指定，因此无法提供本节中所述算法的定量性能比较。
This algorithm consists of the following steps:
该算法包括以下步骤：
1. Whenever a packet must be sent with a Fragment Header, the sending host should look up in the Destination Cache an entry corresponding to the Destination Address of the packet.
1. 每当必须使用片段头发送数据包时，发送主机应在目标缓存中查找与数据包的目标地址相对应的条目。
2. If such an entry exists, it contains the last Identification value used for that Destination Address. Therefore, such a value should be incremented by 1 and used for setting the Identification field of the outgoing packet. Additionally, the updated value should be recorded in the corresponding entry of the Destination Cache [RFC4861].
2. 如果存在这样的条目，则它包含用于该目标地址的最后一个标识值。因此，该值应增加1，并用于设置传出分组的标识字段。此外，更新后的值应记录在目标缓存[RFC4861]的相应条目中。
3. If such an entry does not exist, it should be created, and the Identification value for that destination should be initialized with a random value (e.g., with a Pseudorandom Number Generator), and used for setting the Identification field of the Fragment Header of the outgoing fragmented datagram.
3. 如果这样的条目不存在，则应创建该条目，并且该目的地的标识值应使用随机值初始化（例如，使用伪随机数生成器），并用于设置传出碎片数据报的碎片报头的标识字段。
The advantages of this algorithm are:
该算法的优点是：
o It is simple to implement, with the only complexity residing in the PRNG used to initialize the Identification value contained in each entry of the Destination Cache.
o 实现起来很简单，PRNG中只存在用于初始化目标缓存的每个条目中包含的标识值的复杂性。
o The Identification reuse frequency will typically be lower than that achieved by a global counter (when sending traffic to multiple destinations), since this algorithm uses per-destination counters (rather than a single system-wide counter).
o 标识重用频率通常低于全局计数器（向多个目的地发送流量时）实现的频率，因为该算法使用每个目的地计数器（而不是单个系统范围的计数器）。
o It has good performance properties (once the corresponding entry in the Destination Cache has been created and initialized, each subsequent Identification value simply involves the increment of a counter).
o 它具有良好的性能属性（一旦创建并初始化了目标缓存中的相应条目，每个后续标识值只涉及计数器的增量）。
The possible drawbacks of this algorithm are:
此算法的可能缺点是：
o If, as a result of resource management, an entry of the Destination Cache must be removed, the last Identification value used for that Destination will be lost. Thus, subsequent traffic to that destination would cause that entry to be recreated and reinitialized to random value, thus possibly leading to Identification "collisions".
o 如果由于资源管理，必须删除目标缓存的条目，则用于该目标的最后一个标识值将丢失。因此，到该目的地的后续通信将导致重新创建该条目并将其重新初始化为随机值，从而可能导致标识“冲突”。
o Since the Identification values are predictable by the destination host, a vulnerable host might possibly leak to third parties the Identification values used by other hosts to send traffic to it (i.e., Host B could leak to Host C the Identification values that Host A is using to send packets to Host B). Appendix A describes one possible scenario for such leakage in detail.
o 由于目标主机可以预测标识值，因此易受攻击的主机可能会将其他主机用于向其发送流量的标识值泄漏给第三方（即，主机B可能会将主机a用于向主机B发送数据包的标识值泄漏给主机C）。附录A详细描述了此类泄漏的一种可能情况。
Clearly, use of a Pseudorandom Number Generator for selecting the Identification would be desirable from a security standpoint. With such a scheme, the Identification of each fragmented datagram would be selected as:
显然，从安全角度来看，使用伪随机数生成器来选择标识是可取的。通过这种方案，每个碎片数据报的标识将被选择为：
Identification = random()
标识=随机（）
where "random()" is the PRNG.
其中“random（）”是PRNG。
The specific properties of such scheme would clearly depend on the specific PRNG employed. For example, some PRNGs may result in higher Identification reuse frequencies than others, in the same way that some PRNGs may be more expensive (in terms of processing requirements and/or implementation complexity) than others.
该计划的具体性质显然取决于所采用的特定PRNG。例如，一些prng可能导致比其他prng更高的标识重用频率，这与一些prng可能比其他prng更昂贵（在处理需求和/或实现复杂性方面）的方式相同。
Discussion of the properties of possible PRNGs is considered out of the scope of this document. However, we do note that some PRNGs employed in the past by some implementations have been found to be predictable [Klein2007]. Please see [RFC4086] for randomness requirements for security.
对可能的PRNG特性的讨论不在本文件范围内。然而，我们注意到，一些实现在过去使用的一些PRNG被发现是可预测的[2007]。有关安全性的随机性要求，请参见[RFC4086]。
Another alternative is to implement a hash-based algorithm similar to that specified in [RFC6056] for the selection of transport port numbers. With such a scheme, the Identification value of each fragmented datagram would be selected with the expression:
另一种选择是实现一种基于散列的算法，类似于[RFC6056]中指定的用于选择传输端口号的算法。使用这种方案，每个分段数据报的标识值将使用以下表达式进行选择：
Identification = F(Src IP, Dst IP, secret1) +
counter[G(Src IP, Dst Pref, secret2)]
Identification = F(Src IP, Dst IP, secret1) +
counter[G(Src IP, Dst Pref, secret2)]
where:
哪里：
Identification: Identification value to be used for the fragmented datagram.
标识：用于碎片数据报的标识值。
F(): Hash function.
F（）：散列函数。
Src IP: IPv6 Source Address of the datagram to be fragmented.
Src IP：要分段的数据报的IPv6源地址。
Dst IP: IPv6 Destination Address of the datagram to be fragmented.
Dst IP：要分段的数据报的IPv6目标地址。
secret1: Secret data unknown to the attacker. This value can be initialized to a pseudo-random value during the system bootstrapping sequence. It should remain constant at least while there could be previously sent fragments still in the network or at the fragment reassembly buffer of the corresponding destination system(s).
秘密1：攻击者未知的秘密数据。在系统引导序列期间，可以将该值初始化为伪随机值。至少在网络中或在相应目标系统的片段重组缓冲区中仍然存在以前发送的片段时，它应该保持不变。
counter[]: System-wide array of 32-bit counters (e.g. with 8K elements or more). Each counter should be initialized to a pseudo-random value during the system bootstrapping sequence.
计数器[]：32位计数器的系统范围阵列（例如，具有8K或更多元素）。在系统引导序列期间，每个计数器应初始化为伪随机值。
G(): Hash function. It may or may not be the same hash function as that used for F().
G（）：散列函数。它可能与用于F（）的哈希函数相同，也可能不同。
Dst Pref: IPv6 "Destination Prefix" of the datagram to be fragmented (can be assumed to be the first eight bytes of the Destination Address of such packet). Note: the "Destination Prefix" (rather than Destination Address) is used, such that the ability of an attacker of searching the "increments" space by using multiple addresses of the same subnet is reduced.
Dst Pref：要分段的数据报的IPv6“目的地前缀”（可以假定为该数据包目的地地址的前八个字节）。注意：使用了“目的地前缀”（而不是目的地地址），从而降低了攻击者使用同一子网的多个地址搜索“增量”空间的能力。
secret2: Secret data unknown to the attacker. This value can be initialized to a pseudo-random value during the system bootstrapping sequence. It should remain constant at least while there could be previously sent fragments still in the network or at the fragment reassembly buffer of the corresponding destination system(s).
秘密2：攻击者未知的秘密数据。在系统引导序列期间，可以将该值初始化为伪随机值。至少在网络中或在相应目标系统的片段重组缓冲区中仍然存在以前发送的片段时，它应该保持不变。
NOTE: counter[G(src IP, Dst Pref, secret2)] should be incremented by one each time an Identification value is selected.
注：每次选择标识值时，计数器[G（src IP、Dst Pref、secret2）]应增加1。
The output of F() will be constant for each (Src IP, Dst IP) pair. Similarly, the output of G() will be constant for each (Src IP, Dst Pref) pair. Thus, the resulting Identification value will be the result of a random offset plus a linear function (provided by counter[]), therefore resulting in a monotonically increasing sequence of Identification values for each (src IP, Dst IP) pair.
对于每个（Src IP，Dst IP）对，F（）的输出都是常量。类似地，G（）的输出对于每个（Src IP，Dst Pref）对都是常量。因此，产生的识别值将是随机偏移加上线性函数（由计数器[]提供）的结果，因此导致每个（src IP，Dst IP）对的识别值序列单调递增。
NOTE: F() essentially provides the unpredictability (by off-path attackers) of the resulting Identification values, while counter[] provides a linear function such that the Identification values are different for each fragmented packet while the Identification reuse frequency is minimized.
注意：F（）本质上提供了结果标识值的不可预测性（由非路径攻击者），而计数器[]提供了一个线性函数，使得每个碎片数据包的标识值不同，同时标识重用频率最小化。
The advantages of this algorithm are:
该算法的优点是：
o The Identification reuse frequency will typically be lower than that achieved by a global counter (when sending traffic to multiple destinations), since this algorithm uses multiple system-wide counters (rather than a single system-wide counter). The extent to which the reuse frequency will be lower depends on the number of elements in counter[], and the number of other active flows that result in the same value of G() (and hence cause the same counter to be incremented for each datagram that is fragmented).
o 由于该算法使用多个系统范围内的计数器（而不是单个系统范围内的计数器），因此标识重用频率通常低于全局计数器（向多个目的地发送流量时）实现的频率。重用频率降低的程度取决于计数器[]中元素的数量，以及导致相同G（）值的其他活动流的数量（从而导致每个分段数据报的相同计数器增加）。
o It is possible to implement the algorithm such that good performance is achieved. For example, the result of F() could be stored in the Destination Cache (such that it need not be recomputed for each packet that must be sent) along with the computed index/argument for counter[].
o 可以实现该算法，从而获得良好的性能。例如，F（）的结果可以与计数器[]的计算索引/参数一起存储在目标缓存中（这样就不需要为每个必须发送的数据包重新计算）。
NOTE: If this implementation approach is followed, and an entry of the Destination Cache must be removed as a result of resource management, the last Identification value used for that Destination will *not* be lost. This is an improvement over the algorithm specified in Section 5.1.
注意：如果遵循此实现方法，并且由于资源管理而必须删除目标缓存的条目，则用于该目标的最后一个标识值*不会*丢失。这是对第5.1节中规定的算法的改进。
The possible drawbacks of this algorithm are:
此算法的可能缺点是：
o Since the Identification values are predictable by the destination host, a vulnerable host could possibly leak to third parties the Identification values used by other hosts to send traffic to it (i.e., Host B could leak to Host C the Identification values that Host A is using to send packets to Host B). Appendix A describes a possible scenario in which that information leakage could take place. We note, however, that this algorithm makes the aforementioned attack less reliable for the attacker, since each counter could be possibly shared by multiple traffic flows (i.e., packets destined to other destinations might cause the same counter to be incremented).
o 由于目标主机可以预测标识值，因此易受攻击的主机可能会将其他主机用于向其发送流量的标识值泄漏给第三方（即，主机B可能会将主机a用于向主机B发送数据包的标识值泄漏给主机C）。附录A描述了可能发生信息泄漏的情况。然而，我们注意到，该算法使上述攻击对攻击者的可靠性降低，因为每个计数器可能由多个流量流共享（即，发送到其他目的地的数据包可能导致相同计数器增加）。
This algorithm might be preferable (over the one specified in Section 5.1) in those scenarios in which a node is expected to communicate with a large number of destinations, and thus it is desirable to limit the amount of information to be maintained in memory.
在预期节点与大量目的地通信的场景中，该算法可能更可取（优于第5.1节中规定的算法），因此需要限制内存中要维护的信息量。
NOTE: In such scenarios, if the algorithm specified in Section 5.1 were implemented, entries from the Destination Cache might need to be pruned frequently, thus increasing the risk of Identification "collisions".
注意：在这种情况下，如果实现了第5.1节中指定的算法，则可能需要频繁删除目标缓存中的条目，从而增加识别“冲突”的风险。
This document discusses the security implications of predictable Identification values, and provides implementation guidance such that the aforementioned security implications can be mitigated.
本文档讨论了可预测标识值的安全影响，并提供了实施指南，以减轻上述安全影响。
A number of possible algorithms are described, to provide some implementation alternatives to implementers. We note that the selection of such an algorithm usually implies a number of trade-offs (security, performance, implementation complexity, interoperability properties, etc.).
本文描述了一些可能的算法，以向实现者提供一些实现备选方案。我们注意到，选择这样一种算法通常意味着一些权衡（安全性、性能、实现复杂性、互操作性属性等）。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，DOI 10.17487/RFC19811996年8月<http://www.rfc-editor.org/info/rfc1981>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<http://www.rfc-editor.org/info/rfc4086>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009, <http://www.rfc-editor.org/info/rfc5722>.
[RFC5722]Krishnan，S.，“重叠IPv6片段的处理”，RFC 5722，DOI 10.17487/RFC5722，2009年12月<http://www.rfc-editor.org/info/rfc5722>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052，DOI 10.17487/RFC6052，2010年10月<http://www.rfc-editor.org/info/rfc6052>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.
[RFC6056]Larsen，M.和F.Gont，“运输协议端口随机化建议”，BCP 156，RFC 6056，DOI 10.17487/RFC6056，2011年1月<http://www.rfc-editor.org/info/rfc6056>.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 6145DOI 10.17487/RFC6145，2011年4月<http://www.rfc-editor.org/info/rfc6145>.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 6946, DOI 10.17487/RFC6946, May 2013, <http://www.rfc-editor.org/info/rfc6946>.
[RFC6946]Gont，F.，“IPv6原子片段的处理”，RFC 6946，DOI 10.17487/RFC6946，2013年5月<http://www.rfc-editor.org/info/rfc6946>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, July 2007, <http://www.rfc-editor.org/info/rfc4963>.
[RFC4963]Heffner，J.，Mathis，M.，和B.Chandler，“高数据速率下的IPv4重组错误”，RFC 4963，DOI 10.17487/RFC4963，2007年7月<http://www.rfc-editor.org/info/rfc4963>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, <http://www.rfc-editor.org/info/rfc5927>.
[RFC5927]Gont，F.，“ICMP对TCP的攻击”，RFC 5927，DOI 10.17487/RFC5927，2010年7月<http://www.rfc-editor.org/info/rfc5927>.
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, <http://www.rfc-editor.org/info/rfc6274>.
[RFC6274]Gont，F.，“互联网协议版本4的安全评估”，RFC 6274，DOI 10.17487/RFC6274，2011年7月<http://www.rfc-editor.org/info/rfc6274>.
[DEPGEN] Gont, F., Liu, S., and T. Anderson, "Generation of IPv6 Atomic Fragments Considered Harmful", Work in Progress, draft-ietf-6man-deprecate-atomfrag-generation-05, January 2016.
[DEPGEN]Gont，F.，Liu，S.，和T.Anderson，“被认为有害的IPv6原子碎片的生成”，正在进行的工作，草稿-ietf-6man-deprecate-atomfrag-Generation-052016年1月。
[Bellovin2002] Bellovin, S., "A Technique for Counting NATted Hosts", IMW'02 Nov. 6-8, 2002, Marseille, France, DOI 10.1145/637201.637243, 2002.
[Bellovin2002]Bellovin，S.，“计算NATted宿主的技术”，IMW'02，2002年11月6-8日，法国马赛，DOI 10.1145/637201.6372432002。
[Fyodor2004] Lyon, G., "TCP Idle Scan", from Chapter 5 of "Nmap Network Scanning", 2004, <http://www.insecure.org/nmap/idlescan.html>.
[Fyodor2004]Lyon，G.，“TCP空闲扫描”，摘自“Nmap网络扫描”第5章，2004年<http://www.insecure.org/nmap/idlescan.html>.
[Herzberg2013] Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", Technical Report 13-03, March 2013, <http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf>.
[Herzberg2013]Herzberg，A.和H.Shulman，“碎片被认为是有毒的”，技术报告13-032013年3月<http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf>。
[Klein2007] Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability", 2007, <http://www.trusteer.com/files/OpenBSD_DNS_Cache_Poisoning _and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf>.
[Klein2007]Klein，A.，“OpenBSD DNS缓存中毒和多O/S可预测IP ID漏洞”，2007年<http://www.trusteer.com/files/OpenBSD_DNS_Cache_Poisoning _和多个可预测的IP ID漏洞。pdf>。
[Sanfilippo1998a] Sanfilippo, S., "Subject: about the ip header id", message to Bugtraq mailing list, 14 December 1998, <http://diswww.mit.edu/menelaus.mit.edu/bt/8704>.
[Sanfilippo1998a]Sanfilippo，S.，“主题：关于ip头id”，给Bugtraq邮件列表的消息，1998年12月14日<http://diswww.mit.edu/menelaus.mit.edu/bt/8704>.
[Sanfilippo1998b] Sanfilippo, S., "Subject: new tcp scan method", message to Bugtraq mailing list, 18 December 1998, <http://diswww.mit.edu/menelaus.mit.edu/bt/8736>.
[Sanfilippo1998b]Sanfilippo，S.，“主题：新的tcp扫描方法”，致Bugtraq邮件列表的信息，1998年12月18日<http://diswww.mit.edu/menelaus.mit.edu/bt/8736>.
[Sanfilippo1999] Sanfilippo, S., "Subject: more about IP ID", message to Bugtraq mailing list, 20 November 1999, <http://diswww.mit.edu/menelaus.mit.edu/bt/12686>.
[Sanfilippo1999]Sanfilippo，S.，“主题：关于IP ID的更多信息”，致Bugtraq邮件列表的信息，1999年11月20日<http://diswww.mit.edu/menelaus.mit.edu/bt/12686>.
[SI6-IPv6] SI6 Networks, "SI6 Networks' IPv6 Toolkit", <http://www.si6networks.com/tools/ipv6toolkit>.
[SI6-IPv6]SI6网络，“SI6网络的IPv6工具包”<http://www.si6networks.com/tools/ipv6toolkit>.
[Zalewski2003] Zalewski, M., "Subject: A new TCP/IP blind data injection technique?", message to Bugtraq mailing list, 11 December 2003, <http://lcamtuf.coredump.cx/ipfrag.txt>.
[Zalewski2003]Zalewski，M.，“主题：一种新的TCP/IP盲数据注入技术？”，发给Bugtraq邮件列表的消息，2003年12月11日<http://lcamtuf.coredump.cx/ipfrag.txt>.
Section 3 provides a number of references describing a number of ways in which a vulnerable implementation may reveal the Identification values to be used in subsequent packets, thus opening the door to a number of attacks. In all of those scenarios, a vulnerable implementation leaks/reveals its own Identification number.
第3节提供了大量参考文献，描述了易受攻击的实现可能会以多种方式暴露将在后续数据包中使用的标识值，从而为许多攻击打开大门。在所有这些场景中，易受攻击的实现都会泄漏/暴露自己的标识号。
This section presents a different attack scenario, in which a vulnerable implementation leaks/reveals the Identification number of a non-vulnerable implementation. That is, a vulnerable implementation (Host A) leaks the current Identification value in use by a third-party host (Host B) to send fragmented datagrams from Host B to Host A.
本节介绍一种不同的攻击场景，其中易受攻击的实现泄漏/显示非易受攻击实现的标识号。也就是说，易受攻击的实现（主机a）泄漏第三方主机（主机B）正在使用的当前标识值，以将碎片数据报从主机B发送到主机a。
NOTE: For the most part, this section is included to illustrate how a vulnerable implementation might be leveraged to leak out the Identification value of an otherwise non-vulnerable implementation.
注意：在大多数情况下，本节旨在说明如何利用易受攻击的实现泄漏非易受攻击实现的标识值。
The following scenarios assume:
以下场景假设：
Host A: An IPv6 host that implements the algorithm specified in Section 5.1, implements [RFC5722], but does not implement [RFC6946].
主机A：实现第5.1节中指定算法的IPv6主机，实现[RFC5722]，但不实现[RFC6946]。
Host B: Victim node. Selects the Identification values from a global counter.
主机B：受害者节点。从全局计数器中选择标识值。
Host C: Attacker. Can forge the IPv6 Source Address of his packets at will.
主机C：攻击者。可以随意伪造其数据包的IPv6源地址。
In the following scenarios, large ICMPv6 Echo Request packets are employed to "sample" the Identification value of a host. We note that while the figures show only one packet for the ICMPv6 Echo Request and the ICMPv6 Echo Reply packets, each of those packets will typically comprise two fragments, such that the corresponding unfragmented datagram is larger than the MTU of the networks to which Host B and Host C are attached. Additionally, the following scenarios assume that Host A employs a Fragment Header when sending traffic to Host B (typically the so-called "IPv6 atomic fragments" [RFC6946]): this behavior may be triggered by forged ICMPv6 PTB messages that advertise an MTU smaller than 1280 bytes (assuming the victim still generates atomic fragments [DEPGEN]).
在以下场景中，使用大型ICMPv6回显请求包“采样”主机的标识值。我们注意到，尽管图中仅显示了ICMPv6回显请求和ICMPv6回显回复数据包的一个数据包，但这些数据包中的每个数据包通常将包含两个片段，使得相应的未分段数据报大于主机B和主机C连接到的网络的MTU。此外，以下场景假设主机A在向主机B发送流量时使用片段头（通常是所谓的“IPv6原子片段”[RFC6946]）：此行为可能由发布小于1280字节MTU的伪造ICMPv6 PTB消息触发（假设受害者仍生成原子片段[DEPGEN]）。
In lines #1-#2 (and lines #7-#8), the attacker samples the current Identification value at Host B. In line #3, the attacker sends a forged TCP SYN segment to Host A. In line 4, the attacker sends a forged TCP segment to Host B as an incomplete IPv6 fragmented datagram (e.g., a single fragment with Fragment Offset=0, More fragments=1). If corresponding TCP port is closed, and the attacker fails when trying to produce a collision of Identification values (see line #4), the following packet exchange might take place:
在第1至第2行（以及第7至第8行）中，攻击者对主机B上的当前标识值进行采样。在第3行中，攻击者向主机a发送伪造的TCP SYN段。在第4行中，攻击者将伪造的TCP段作为不完整的IPv6碎片数据报发送给主机B（例如，碎片偏移量为0的单个碎片，更多碎片=1）。如果相应的TCP端口关闭，并且攻击者在尝试产生标识值冲突时失败（请参见第4行），则可能发生以下数据包交换：
A B C
A、B、C
#1 <------ Echo Req #1 -----------
#2 --- Echo Repl #1, FID=5000 --->
#3 <------------------- SYN #1, src= B -----------------------
#4 <--- SYN/ACK, FID=42 src=A ----
#5 ---- SYN/ACK, FID=9000 --->
#6 <----- RST, FID= 5001 -----
#7 <-------- Echo Req #2 ---------
#8 --- Echo Repl #2, FID=5002 --->
#1 <------ Echo Req #1 -----------
#2 --- Echo Repl #1, FID=5000 --->
#3 <------------------- SYN #1, src= B -----------------------
#4 <--- SYN/ACK, FID=42 src=A ----
#5 ---- SYN/ACK, FID=9000 --->
#6 <----- RST, FID= 5001 -----
#7 <-------- Echo Req #2 ---------
#8 --- Echo Repl #2, FID=5002 --->
The RST segment in line #6 is elicited by the SYN/ACK segment from line #5 (illegitimately elicited by the SYN segment from line #3). The packet from line #4, sent as an incomplete IPv6 datagram, eventually times out.
第6行的RST段由第5行的SYN/ACK段引出（第3行的SYN段非法引出）。第4行的数据包作为不完整的IPv6数据报发送，最终超时。
On the other hand, if the attacker succeeds to produce a collision of Identification values, the following packet exchange could take place:
另一方面，如果攻击者成功产生标识值冲突，则可能发生以下数据包交换：
A B C
A、B、C
#1 <------- Echo Req #1 ----------
#2 --- Echo Repl #1, FID=5000 --->
#3 <------------------- SYN #1, src= B -----------------------
#4 <-- SYN/ACK, FID=9000 src=A ---
#5 ---- SYN/ACK, FID=9000 --->
... (RFC5722) ...
#6 <------- Echo Req #2 ----------
#7 ---- Echo Repl #2, FID=5001 -->
#1 <------- Echo Req #1 ----------
#2 --- Echo Repl #1, FID=5000 --->
#3 <------------------- SYN #1, src= B -----------------------
#4 <-- SYN/ACK, FID=9000 src=A ---
#5 ---- SYN/ACK, FID=9000 --->
... (RFC5722) ...
#6 <------- Echo Req #2 ----------
#7 ---- Echo Repl #2, FID=5001 -->
Clearly, the Identification value sampled from the second ICMPv6 Echo Reply packet ("Echo Repl #2") implicitly indicates whether the Identification value in the forged SYN/ACK (see line #4 in both figures) was the current Identification value in use by Host A.
显然，从第二个ICMPv6回显回复包（“回显回复2”）中采样的标识值隐含地指示伪造SYN/ACK中的标识值（参见两个图中的第4行）是否是主机A正在使用的当前标识值。
As a result, the attacker could employ this technique to learn the current Identification value used by host A to send packets to host B, even when Host A itself has a non-vulnerable implementation.
因此，攻击者可以利用此技术了解主机a向主机B发送数据包时使用的当前标识值，即使主机a本身具有非易受攻击的实现。
Appendix B. Survey of Fragment Identification Selection Algorithms Employed by Popular IPv6 Implementations
附录B.流行IPv6实现中使用的片段识别选择算法调查
This section includes a survey of the Identification selection algorithms employed by some popular operating systems.
本节包括对一些流行操作系统使用的标识选择算法的概述。
NOTE: The survey was produced with the SI6 Networks' IPv6 toolkit [SI6-IPv6].
注：调查是使用SI6 Networks的IPv6工具包[SI6-IPv6]进行的。
+------------------------------+------------------------------------+
| Operating System | Algorithm |
+------------------------------+------------------------------------+
| Cisco IOS 15.3 | Predictable (Global Counter, |
| | Init=0, Incr=1) |
+------------------------------+------------------------------------+
| FreeBSD 9.0 | Unpredictable (Random) |
+------------------------------+------------------------------------+
| Linux 3.0.0-15 | Predictable (Global Counter, |
| | Init=0, Incr=1) |
+------------------------------+------------------------------------+
| Linux-current | Unpredictable (Per-dest Counter, |
| | Init=random, Incr=1) |
+------------------------------+------------------------------------+
| NetBSD 5.1 | Unpredictable (Random) |
+------------------------------+------------------------------------+
| OpenBSD-current | Unpredictable (Random, SKIP32) |
+------------------------------+------------------------------------+
| Solaris 10 | Predictable (Per-dst Counter, |
| | Init=0, Incr=1) |
+------------------------------+------------------------------------+
| Windows XP SP2 | Predictable (Global Counter, |
| | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows XP Professional | Predictable (Global Counter, |
| 32bit, SP3 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows Vista (Build 6000) | Predictable (Global Counter, |
| | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows Vista Business | Predictable (Global Counter, |
| 64bit, SP1 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows 7 Home Premium | Predictable (Global Counter, |
| | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows Server 2003 R2 | Predictable (Global Counter, |
| Standard 64bit, SP2 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Operating System | Algorithm |
+------------------------------+------------------------------------+
| Cisco IOS 15.3 | Predictable (Global Counter, |
| | Init=0, Incr=1) |
+------------------------------+------------------------------------+
| FreeBSD 9.0 | Unpredictable (Random) |
+------------------------------+------------------------------------+
| Linux 3.0.0-15 | Predictable (Global Counter, |
| | Init=0, Incr=1) |
+------------------------------+------------------------------------+
| Linux-current | Unpredictable (Per-dest Counter, |
| | Init=random, Incr=1) |
+------------------------------+------------------------------------+
| NetBSD 5.1 | Unpredictable (Random) |
+------------------------------+------------------------------------+
| OpenBSD-current | Unpredictable (Random, SKIP32) |
+------------------------------+------------------------------------+
| Solaris 10 | Predictable (Per-dst Counter, |
| | Init=0, Incr=1) |
+------------------------------+------------------------------------+
| Windows XP SP2 | Predictable (Global Counter, |
| | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows XP Professional | Predictable (Global Counter, |
| 32bit, SP3 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows Vista (Build 6000) | Predictable (Global Counter, |
| | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows Vista Business | Predictable (Global Counter, |
| 64bit, SP1 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows 7 Home Premium | Predictable (Global Counter, |
| | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows Server 2003 R2 | Predictable (Global Counter, |
| Standard 64bit, SP2 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows Server 2008 Standard | Predictable (Global Counter, |
| 32bit, SP1 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows Server 2008 R2 | Predictable (Global Counter, |
| Standard 64bit, SP1 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows Server 2012 Standard | Predictable (Global Counter, |
| 64bit | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows 7 Home Premium | Predictable (Global Counter, |
| 32bit, SP1 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows 7 Ultimate 32bit, | Predictable (Global Counter, |
| SP1 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows 8 Enterprise 32 bit | Unpredictable (Alg. from Section |
| | 5.3) |
+------------------------------+------------------------------------+
+------------------------------+------------------------------------+
| Windows Server 2008 Standard | Predictable (Global Counter, |
| 32bit, SP1 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows Server 2008 R2 | Predictable (Global Counter, |
| Standard 64bit, SP1 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows Server 2012 Standard | Predictable (Global Counter, |
| 64bit | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows 7 Home Premium | Predictable (Global Counter, |
| 32bit, SP1 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows 7 Ultimate 32bit, | Predictable (Global Counter, |
| SP1 | Init=0, Incr=2) |
+------------------------------+------------------------------------+
| Windows 8 Enterprise 32 bit | Unpredictable (Alg. from Section |
| | 5.3) |
+------------------------------+------------------------------------+
Table 1: Fragment Identification algorithms employed by different OSs
表1：不同操作系统使用的片段识别算法
NOTE: In the text above, "predictable" should be taken as "easily guessable by an off-path attacker, by sending a few probe packets".
注意：在上面的文本中，“可预测”应被视为“通过发送几个探测数据包，可被非路径攻击者轻易猜到”。
Acknowledgements
致谢
The author would like to thank Ivan Arce for proposing the attack scenario described in Appendix A.
作者要感谢Ivan Arce提出附录A中描述的攻击场景。
The author would like to thank Ivan Arce, Stephen Bensley, Ron Bonica, Tassos Chatzithomaoglou, Guillermo Gont, Brian Haberman, Bob Hinden, Sheng Jiang, Tatuya Jinmei, Merike Kaeo, Will Liu, Juan Antonio Matos, Simon Perreault, Hosnieh Rafiee, Meral Shirazipour, Mark Smith, Dave Thaler, and Klaas Wierenga, for providing valuable comments on earlier draft versions of this document.
作者要感谢伊万·阿尔奇、斯蒂芬·本斯利、罗恩·博尼卡、塔索斯·查兹托马戈卢、吉列尔莫·冈特、布赖恩·哈伯曼、鲍勃·欣登、盛江、塔图亚·金梅、梅里克·卡奥、威尔·刘、胡安·安东尼奥·马托斯、西蒙·佩雷尔特、霍斯尼·拉菲、梅拉尔·西拉齐普尔、马克·史密斯、戴夫·泰勒和克拉斯·韦伦加，为本文件的早期草案提供有价值的意见。
This document is based on work performed by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI).
本文件基于Fernando Gont代表英国国家基础设施保护中心（CPNI）开展的工作。
The author would like to thank Buffy for her love and support.
作者要感谢巴菲的爱和支持。
Author's Address
作者地址
Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont Huawei Technologies 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