[要約] RFC 7739は、予測可能なフラグメント識別値のセキュリティ上の影響について説明しています。その目的は、予測可能なフラグメント識別値が攻撃者による攻撃やセキュリティ侵害のリスクを増加させる可能性があることを識別し、対策を提案することです。
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宛先アドレスとともに、同じ元のデータグラムに対応するフラグメントを識別する「識別」フィールドが含まれているため、受信側ホストでそれらを一緒に再構成できます。 Identificationフィールドを設定するための唯一の要件は、対応する値が、同じ送信元アドレスと宛先アドレスで最近送信された他のフラグメント化されたデータグラムに使用される値と異なる必要があることです。一部の実装では、単純なグローバルカウンターを使用して識別フィールドを設定するため、識別可能な識別値が得られます。このドキュメントでは、予測可能な識別値のセキュリティへの影響を分析し、前述のセキュリティへの影響が軽減されるように、フラグメントヘッダーの識別フィールドを設定するための実装ガイダンスを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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宛先アドレスとともに、同じ元のデータグラムに対応するフラグメントを識別する「識別」フィールドが含まれているため、受信側ホストでそれらを一緒に再構成できます。 Identificationフィールドを設定するための唯一の要件は、その値が、同じ送信元アドレスと宛先アドレスで最近送信された他のフラグメント化されたデータグラムに使用される値とは異なる必要があることです。
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には、ID値を生成するために一般的な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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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 perform Denial-of-Service (DoS) attacks, or
oミドルボックスの背後にあるシステムの数を数える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.
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ケースの主な違いの1つは、IPv4では識別フィールドが固定IPv4ヘッダーの一部であるため（通常はすべてのパケットに設定されます）、IPv6では識別フィールドが存在するパケットにのみ存在することですフラグメントヘッダーを運ぶ。その結果、識別フィールドの悪用が成功するかどうかは、2つの異なる要因に依存します。
o vulnerable Identification generators, and
o 脆弱なIDジェネレーター、および
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 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.
攻撃者が前述の攻撃を成功させるシナリオは、特定の攻撃タイプによって異なります。たとえば、2つのホスト間の通信でDoS攻撃を実行するには、攻撃者は前述の2つのノードで使用されているIPv6アドレスを知っている必要があります。このような知識は、攻撃のターゲットが2つの特定のBGPピア、2つの特定のSMTPサーバー、または1つの特定のプライマリDNSサーバーとそのセカンダリDNSサーバー間の通信である場合はすぐに利用できますが、目的が簡単ではない場合があります。任意のIPv6ホスト間のすべての通信に対するDoS攻撃（たとえば、目標は、任意の/不明なホストを持つ1つの特定のノードが関与するすべての通信に対して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]は、1280バイト未満の最大転送ユニット（MTU）を通知するICMPv6パケットが大きすぎる（PTB）エラーメッセージを受信した場合、受信ホストはパスのMTUを減らす必要がないと述べています。対応する宛先アドレス。ただし、その宛先に送信される後続のすべてのパケットにフラグメントヘッダーを含める必要があります。これにより、いわゆるIPv6「アトミックフラグメント」[RFC6946]の使用がトリガーされます。フラグメントオフセットが0で、「M」（「その他のフラグメント」）ビットがクリアされたIPv6フラグメント。 [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.
したがって、攻撃者は通常、攻撃対象のホストに、1280バイト未満のMTUをアドバタイズする偽造ICMPv6 Packet Too Big（PTB）エラーメッセージを送信することにより、送信パケットを「断片化」させることができます。
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 著者が知っているすべての実装は、宛先ごとにPath-MTU情報を記録します。したがって、攻撃者は、ICMPv6 PTBメッセージのペイロードに埋め込まれたIPv6パケットの送信元アドレスに送信されたパケットに対してフラグメンテーションを有効にすることのみを被害者に引き起こすことができます。ただし、[RFC1981]のセクション5.2は、実装がそのノードに送信されるすべてのパケットに使用される単一のシステム全体のパスMTU（PMTU）値を維持できることを示していることに注意してください。明らかに、そのような実装は、Path MTU Discovery（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 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.
o被害者ノードがRFC 5927 [RFC5927]で説明されているICMP攻撃の対策のいくつかを実装している場合、攻撃者が被害者ノードに発信パケットのフラグメンテーションを採用させるのは困難な場合があります。ただし、現在の多くの実装では、これらの検証チェックを実施できません。たとえば、Linux 2.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攻撃を実行するために予測可能な識別値を利用できる1つの可能な方法は次のとおりです。ホストAがホストBと通信していて、攻撃者がそのような通信にDoS攻撃を実行したいとします。攻撃者は、おそらくホストAで現在使用されている識別値を学習します。おそらく、断片化された応答を引き出すパケット（たとえば、大きなペイロードを持つICPMv6エコー要求）を送信することによってです。次に、攻撃者は偽造されたICMPv6 PTBエラーメッセージをホストAに送信します（埋め込みIPv6パケットのIPv6ソースアドレスをホストAのIPv6アドレスに設定し、埋め込みIPv6パケットの宛先アドレスをホストAのIPv6アドレスに設定します）ホストB）。ホストAからホストBに送信される後続のパケットにはフラグメントヘッダーが含まれます。最後に、攻撃者はIPv6送信元アドレスがホストAのアドレスに設定された偽造IPv6フラグメントをホストBに送信し、ホストAからホストBに送信される正当なトラフィックに使用される識別値との衝突を引き起こす識別値を送信します。ホストBがID値の衝突を引き起こすフラグメントを破棄する場合（そのようなフラグメントが重複し、ホストが[RFC5722]を実装するなど）、攻撃者は、異なるID値を持つ複数の偽造フラグメントを送信することにより、IDスペースを単純に破棄することができます。ホスト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.
[RFC6946]は、少なくともPath-MTU Discoveryメカニズムを使用するTCP接続の場合に、この特定の攻撃ベクトルを排除するこれらのパケットの処理の改善について説明しています。
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-to-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では、IPv4アドレススペースをIPv6にマッピングするネットワーク固有のプレフィックス（NSP）を使用することをオペレーターに推奨しています。したがって、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.
このドキュメントで説明されているセキュリティの問題が回避されるように、IDフィールドを設定するために使用できるいくつかのアルゴリズムがあります。このセクションでは、そのうちの3つを示します。
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 このアルゴリズムは（単一のシステム全体のカウンターではなく）宛先ごとのカウンターを使用するため、IDの再利用頻度は通常、グローバルカウンター（複数の宛先にトラフィックを送信する場合）が達成する頻度よりも低くなります。
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 これには優れたパフォーマンスプロパティがあります（宛先キャッシュ内の対応するエントリが作成および初期化されると、後続の各ID値は単にカウンターの増分を伴います）。
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が使用している識別値をホストCに漏洩する可能性があります。ホストBにパケットを送信します。付録Aでは、このような漏洩の1つの可能なシナリオについて詳しく説明しています。
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()
識別= 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よりも（処理要件および/または実装の複雑さの点で）高価になる場合と同じです。
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は予測可能であることが判明していることに注意してください[Klein2007]。セキュリティのランダム性要件については、[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)]
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.
送信元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).
secret1：攻撃者にとって未知の秘密データ。この値は、システムのブートストラップシーケンス中に疑似ランダム値に初期化できます。少なくともネットワーク内、または対応する宛先システムのフラグメント再構成バッファーに以前に送信されたフラグメントが存在する可能性がある場合、少なくとも一定である必要があります。
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.
counter []：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 "Destination Prefix"（そのようなパケットの宛先アドレスの最初の8バイトであると想定できます）。注：攻撃者が同じサブネットの複数のアドレスを使用して「インクリメント」スペースを検索する能力が低下するように、（宛先アドレスではなく）「宛先プレフィックス」が使用されます。
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).
secret2：攻撃者にとって未知の秘密データ。この値は、システムのブートストラップシーケンス中に疑似ランダム値に初期化できます。少なくともネットワーク内、または対応する宛先システムのフラグメント再構成バッファーに以前に送信されたフラグメントが存在する可能性がある場合、少なくとも一定である必要があります。
NOTE: counter[G(src IP, Dst Pref, secret2)] should be incremented by one each time an Identification value is selected.
注：counter [G（src IP、Dst Pref、secret2）]は、ID値が選択されるたびに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.
F()の出力は、（Src IP、Dst IP）ペアごとに一定になります。同様に、G()の出力は、（Src IP、Dst Pref）ペアごとに一定になります。したがって、結果の識別値は、ランダムオフセットと線形関数（counter []によって提供される）の結果となり、したがって、各（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()は、結果として得られる識別値の予測不能性（オフパス攻撃者による）を本質的に提供しますが、counter []は、識別再利用頻度が最小限に抑えられながら、断片化されたパケットごとに識別値が異なるような線形関数を提供します。
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 このアルゴリズムは複数のシステム全体のカウンター（単一のシステム全体のカウンターではなく）を使用するため、識別再利用頻度は通常、グローバルカウンターによって達成される頻度よりも低くなります（トラフィックを複数の宛先に送信する場合）。再利用の頻度が低くなる程度は、counter []の要素の数、および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()の結果は、counter []の計算されたインデックス/引数とともに（送信する必要があるパケットごとに再計算する必要がないように）宛先キャッシュに格納できます。
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が使用している識別値をホストCに漏洩する可能性があります。パケットをホストBに送信します）。付録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、「Path MTU Discovery for IP version 6」、RFC 1981、DOI 10.17487 / RFC1981、1996年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.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<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、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年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。、「Handling of Overlapping IPv6 Fragments」、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、「Recommendations for Transport-Protocol Port Randomization」、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 6145、DOI 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。、「Processing of IPv6 "Atomic" Fragments」、RFC 6946、DOI 10.17487 / RFC6946、May 2013、<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。、「TCPに対するICMP攻撃」、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、「Generation of IPv6 Atomic Fragments考慮される有害」、Work in Progress、draft-ietf-6man-deprecate-atomfrag-generation-05、2016年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。、「NATされたホストをカウントするための手法」、IMW'02、2002年11月6〜8日、フランス、マルセイユ、DOI 10.1145 / 637201.637243、2002。
[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 Idle Scan」、「Nmap Network Scanning」の第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-03、2013年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 _and_Multiple_OS_Predictable_IP_ID_Vulnerability.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。、「Subject：more about 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エコー応答パケットの1つのパケットのみを示していますが、これらの各パケットは通常、対応するフラグメント化されていないデータグラムがホストBが接続するネットワークのMTUよりも大きくなるように、2つのフラグメントを含みます。およびホストCが接続されています。さらに、次のシナリオでは、ホストBにトラフィックを送信するときにホストAがフラグメントヘッダーを使用すると想定しています（通常、いわゆる「IPv6アトミックフラグメント」[RFC6946]）。この動作は、MTUを小さくアドバタイズする偽造ICMPv6 PTBメッセージによってトリガーされる可能性があります1280バイトよりも大きい（被害者が依然としてアトミックフラグメントを生成すると想定[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では、攻撃者は偽造TCP SYNセグメントをホストAに送信します。行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 --->
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 -->
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.
明らかに、2番目のICMPv6エコー応答パケット（ "Echo Repl＃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.
このセクションには、一部の一般的なオペレーティングシステムで採用されているID選択アルゴリズムの調査が含まれています。
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) |
+------------------------------+------------------------------------+
| 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：さまざまなOSで使用されるフラグメント識別アルゴリズム
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.
著者は、付録Aで説明されている攻撃シナリオを提案してくれたIvan Arceに感謝します。
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.
著者は、イヴァンアルセ、スティーブンベンスリー、ロンボニカ、タソスチャトチマオグル、ギジェルモゴン、ブライアンハーバーマン、ボブヒンデン、シェンジャン、タトゥヤジンメイ、メリケケオ、ウィルリュー、ファンアントニオマトス、サイモンペロー、ホスニーラフィエ、メラルに感謝しますShirazipour、Mark Smith、Dave Thaler、およびKlaas Wierengaは、このドキュメントの以前のドラフトバージョンに貴重なコメントを提供してくれました。
This document is based on work performed by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI).
このドキュメントは、英国国家インフラ保護センター（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ブエノスアイレス州ハエド1706アルゼンチン
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com