[要約] RFC 9414は、IETFプロトコルで使用される「一時的な数値識別子」の仕様と実装のタイムラインを分析し、その結果としてプロトコルのセキュリティとプライバシーにどのような影響があるかを提供しています。この文書は、IRTGのPrivacy Enhancements and Assessments Research Group (PEARG)の成果です。
Internet Research Task Force (IRTF) F. Gont
Request for Comments: 9414 SI6 Networks
Category: Informational I. Arce
ISSN: 2070-1721 Quarkslab
July 2023
This document analyzes the timeline of the specification and implementation of different types of "transient numeric identifiers" used in IETF protocols and how the security and privacy properties of such protocols have been affected as a result of it. It provides empirical evidence that advice in this area is warranted. This document is a product of the Privacy Enhancements and Assessments Research Group (PEARG) in the IRTF.
このドキュメントは、IETFプロトコルで使用されるさまざまなタイプの「過渡数値識別子」の仕様と実装のタイムラインと、その結果としてそのようなプロトコルのセキュリティとプライバシーのプロパティがどのように影響を受けたかを分析します。この分野のアドバイスが保証されているという経験的証拠を提供します。このドキュメントは、IRTFのプライバシー強化と評価研究グループ（PEARG）の製品です。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Privacy Enhancements and Assessments Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）のプライバシー強化と評価研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9414.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9414で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Terminology
3. Threat Model
4. Issues with the Specification of Transient Numeric Identifiers
4.1. IPv4/IPv6 Identification
4.2. TCP Initial Sequence Numbers (ISNs)
4.3. IPv6 Interface Identifiers (IIDs)
4.4. NTP Reference IDs (REFIDs)
4.5. Transport-Protocol Ephemeral Port Numbers
4.6. DNS ID
5. Conclusions
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
Networking protocols employ a variety of transient numeric identifiers for different protocol objects, such as IPv4 and IPv6 Identification values [RFC0791] [RFC8200], IPv6 Interface Identifiers (IIDs) [RFC4291], transport-protocol ephemeral port numbers [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC9293], NTP Reference IDs (REFIDs) [RFC5905], and DNS IDs [RFC1035]. These identifiers typically have specific requirements (e.g., uniqueness during a specified period of time) that must be satisfied such that they do not result in negative interoperability implications and an associated failure severity when such requirements are not met [RFC9415].
ネットワーキングプロトコルは、IPv4およびIPv6識別値[RFC0791] [RFC8200]、IPv6インターフェイス識別子（IID）[RFC4291]、輸送中間ムラーポート[RFC6056]、TCP初期など、さまざまなプロトコルオブジェクトのさまざまな過渡数値識別子を採用しています。シーケンス番号（ISNS）[RFC9293]、NTP参照ID（REFIDS）[RFC5905]、およびDNS IDS [RFC1035]。これらの識別子には通常、特定の要件（例えば、指定された期間中の一意性）があり、そのような要件が満たされない場合、否定的な相互運用性の意味と関連する障害の重大度をもたらさないように満たす必要があります[RFC9415]。
NOTE: Some documents refer to the DNS ID as the DNS "Query ID" or "TxID".
注：一部のドキュメントでは、DNS IDをDNS「クエリID」または「TXID」と呼びます。
For more than 30 years, a large number of implementations of IETF protocols have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection to information leakages that could be exploited for pervasive monitoring [RFC7258]. The root cause of these issues has been, in many cases, the poor selection of transient numeric identifiers in such protocols, usually as a result of insufficient or misleading specifications. While it is generally trivial to identify an algorithm that can satisfy the interoperability requirements of a given transient numeric identifier, empirical evidence exists that doing so without negatively affecting the security and/or privacy properties of the aforementioned protocols is prone to error.
30年以上にわたり、IETFプロトコルの多数の実装がさまざまな攻撃の対象となり、サービス拒否（DOS）またはデータインジェクションから、広範な監視に利用できる情報漏れに至るまでの影響があります[RFC7258]。これらの問題の根本的な原因は、多くの場合、このようなプロトコルにおける一時的な数値識別子の選択が不十分であり、通常は不十分または誤解を招く仕様の結果です。一般に、特定の一時的な数値識別子の相互運用性要件を満たすことができるアルゴリズムを識別することは些細なことですが、前述のプロトコルのセキュリティおよび/またはプライバシー特性に悪影響を与えることなくそうすることは、エラーが発生しやすいという経験的証拠が存在します。
For example, implementations have been subject to security and/or privacy issues resulting from:
たとえば、実装は、次の結果として生じるセキュリティおよび/またはプライバシーの問題の対象となっています。
* predictable IPv4 or IPv6 Identification values (e.g., see [Sanfilippo1998a], [RFC6274], and [RFC7739]),
* 予測可能なIPv4またはIPv6識別値（たとえば、[sanfilippo1998a]、[rfc6274]、および[rfc7739]を参照）、
* predictable IPv6 IIDs (e.g., see [RFC7217], [RFC7707], and [RFC7721]),
* 予測可能なIPv6 IID（例：[RFC7217]、[RFC7707]、および[RFC7721]を参照）、
* predictable transport-protocol ephemeral port numbers (e.g., see [RFC6056] and [Silbersack2005]),
* 予測可能なトランスポートプロトコールの一時的なポート番号（例：[RFC6056]および[SilberSack2005]を参照）、
* predictable TCP Initial Sequence Numbers (ISNs) (e.g., see [Morris1985], [Bellovin1989], and [RFC6528]),
* 予測可能なTCP初期シーケンス番号（ISNS）（たとえば、[Morris1985]、[Bellovin1989]、および[RFC6528]を参照）、
* predictable initial timestamps in TCP timestamps options (e.g., see [TCPT-uptime] and [RFC7323]), and
* TCPタイムスタンプのオプションの予測可能な初期タイムスタンプ（例：[TCPT-uptime]および[RFC7323]を参照）、および
* predictable DNS IDs (see, e.g., [Schuba1993] and [Klein2007]).
* 予測可能なDNS IDS（例えば[Schuba1993]および[Klein2007]を参照）。
Recent history indicates that, when new protocols are standardized or new protocol implementations are produced, the security and privacy properties of the associated transient numeric identifiers tend to be overlooked, and inappropriate algorithms to generate such identifiers are either suggested in the specifications or selected by implementers. As a result, advice in this area is warranted.
最近の履歴は、新しいプロトコルが標準化されているか、新しいプロトコルの実装が生成された場合、関連する一過性の数値識別子のセキュリティとプライバシーのプロパティが見落とされる傾向があり、そのような識別子を生成するための不適切なアルゴリズムは、実装者によって提案されるか、実装者によって選択されていることを示しています。。その結果、この分野でのアドバイスが保証されます。
This document contains a non-exhaustive timeline of the specification and vulnerability disclosures related to some sample transient numeric identifiers, including other work that has led to advances in this area. This analysis indicates that:
このドキュメントには、この分野の進歩につながった他の作業を含む、いくつかのサンプルの一時的な数値識別子に関連する仕様と脆弱性開示の非網羅的なタイムラインが含まれています。この分析は、次のことを示しています。
* vulnerabilities associated with the inappropriate generation of transient numeric identifiers have affected protocol implementations for an extremely long period of time,
* 一時的な数値識別子の不適切な生成に関連する脆弱性は、非常に長い間プロトコルの実装に影響を与えています。
* such vulnerabilities, even when addressed for a given protocol version, were later reintroduced in new versions or new implementations of the same protocol, and
* このような脆弱性は、特定のプロトコルバージョンに対処された場合でも、後に同じプロトコルの新しいバージョンまたは新しい実装で再導入され、
* standardization efforts that discuss and provide advice in this area can have a positive effect on IETF specifications and their corresponding implementations.
* この分野でアドバイスを議論し提供する標準化の取り組みは、IETF仕様とそれらに対応する実装にプラスの効果をもたらす可能性があります。
While it is generally possible to identify an algorithm that can satisfy the interoperability requirements for a given transient numeric identifier, this document provides empirical evidence that doing so without negatively affecting the security and/or privacy properties of the corresponding protocols is nontrivial. Other related documents ([RFC9415] and [RFC9416]) provide guidance in this area, as motivated by the present document.
一般に、特定の一時的な数値識別子の相互運用性要件を満たすことができるアルゴリズムを識別することは可能ですが、このドキュメントは、対応するプロトコルのセキュリティおよび/またはプライバシープロパティに悪影響を与えることなくそうすることは非重要であるという経験的証拠を提供します。その他の関連文書（[RFC9415]および[RFC9416]）は、現在の文書で動機付けられているように、この分野でのガイダンスを提供します。
This document represents the consensus of the Privacy Enhancements and Assessments Research Group (PEARG).
このドキュメントは、プライバシー強化と評価研究グループ（PEARG）のコンセンサスを表しています。
Transient Numeric Identifier:
一時的な数値識別子：
A data object in a protocol specification that can be used to definitely distinguish a protocol object (a datagram, network interface, transport-protocol endpoint, session, etc.) from all other objects of the same type, in a given context. Transient numeric identifiers are usually defined as a series of bits and represented using integer values. These identifiers are typically dynamically selected, as opposed to statically assigned numeric identifiers (e.g., see [IANA-PROT]). We note that different transient numeric identifiers may have additional requirements or properties depending on their specific use in a protocol. We use the term "transient numeric identifier" (or simply "numeric identifier" or "identifier" as short forms) as a generic term to refer to any data object in a protocol specification that satisfies the identification property stated above.
プロトコル仕様のデータオブジェクトは、特定のコンテキストで、同じタイプの他のすべてのオブジェクトからプロトコルオブジェクト（データグラム、ネットワークインターフェイス、トランスポートプロトコルエンドポイント、セッションなど）を明確に区別するために使用できます。通常、一時的な数値識別子は一連のビットとして定義され、整数値を使用して表されます。これらの識別子は通常、静的に割り当てられた数値識別子とは対照的に動的に選択されます（例：[IANA-Prot]を参照）。さまざまな一時的な数値識別子には、プロトコルでの特定の使用に応じて、追加の要件またはプロパティがある場合があることに注意してください。上記の識別プロパティを満たすプロトコル仕様のデータオブジェクトを参照するための一般的な用語として、「過渡数値識別子」（または単に「数値識別子」または「識別子」）を一般的な用語として使用します。
The terms "constant IID", "stable IID", and "temporary IID" are to be interpreted as defined in [RFC7721].
「定数IID」、「安定IID」、および「一時的なIID」という用語は、[RFC7721]で定義されていると解釈されます。
Throughout this document, we do not consider on-path attacks. That is, we assume the attacker does not have physical or logical access to the system(s) being attacked and that the attacker can only observe traffic explicitly directed to the attacker. Similarly, an attacker cannot observe traffic transferred between the sender and the receiver(s) of a target protocol but may be able to interact with any of these entities, including by, e.g., sending any traffic to them to sample transient numeric identifiers employed by the target hosts when communicating with the attacker.
このドキュメント全体で、パス上の攻撃を考慮しません。つまり、攻撃者は攻撃されているシステムへの物理的または論理的なアクセスがなく、攻撃者は攻撃者に明示的に向けられたトラフィックのみを観察できると仮定します。同様に、攻撃者は、ターゲットプロトコルの送信者と受信機の間で転送されたトラフィックを観察することはできませんが、たとえば、それらにトラフィックを送信して、採用されている一時的な数値識別子をサンプリングするためにそれらに送信するなど、これらのエンティティのいずれかと対話できる場合があります。ターゲットは、攻撃者と通信するときにホストします。
For example, when analyzing vulnerabilities associated with TCP Initial Sequence Numbers (ISNs), we consider the attacker is unable to capture network traffic corresponding to a TCP connection between two other hosts. However, we consider the attacker is able to communicate with any of these hosts (e.g., establish a TCP connection with any of them) to, e.g., sample the TCP ISNs employed by these hosts when communicating with the attacker.
たとえば、TCP初期シーケンス番号（ISNS）に関連する脆弱性を分析する場合、攻撃者は他の2つのホスト間のTCP接続に対応するネットワークトラフィックをキャプチャできないと考えています。ただし、攻撃者は、攻撃者と通信するときにこれらのホストが採用しているTCP ISNをサンプリングするために、攻撃者がこれらのホストのいずれかと通信することができると考えています。
Similarly, when considering host-tracking attacks based on IPv6 Interface Identifiers, we consider an attacker may learn the IPv6 address employed by a victim host if, e.g., the address becomes exposed as a result of the victim host communicating with an attacker-operated server. Subsequently, an attacker may perform host-tracking by probing a set of target addresses composed by a set of target prefixes and the IPv6 Interface Identifier originally learned by the attacker. Alternatively, an attacker may perform host-tracking if, e.g., the victim host communicates with an attacker-operated server as it moves from one location to another, thereby exposing its configured addresses. We note that none of these scenarios require the attacker observe traffic not explicitly directed to the attacker.
同様に、IPv6インターフェイス識別子に基づいてホスト追跡攻撃を検討する場合、攻撃者が攻撃者ホストが通信した結果として住所が公開される場合、攻撃者は被害者ホストが採用したIPv6アドレスを学習できると考えています。。その後、攻撃者は、ターゲットプレフィックスのセットとIPv6インターフェイス識別子によって構成された一連のターゲットアドレスを攻撃者が元々学習したIPv6インターフェイス識別子を調査することにより、ホストトラッキングを実行できます。あるいは、攻撃者は、たとえば、被害者のホストが、ある場所から別の場所に移動するときに攻撃者が運営するサーバーと通信し、それによって構成されたアドレスを公開する場合、ホストトラッキングを実行することができます。これらのシナリオはどれも、攻撃者が攻撃者に明示的に向けられていないトラフィックを観察する必要はないことに注意してください。
While assessing IETF protocol specifications regarding the use of transient numeric identifiers, we have found that most of the issues discussed in this document arise as a result of one of the following conditions:
過渡数値識別子の使用に関するIETFプロトコル仕様を評価している間、このドキュメントで説明した問題のほとんどは、次の条件の1つの結果として生じることがわかりました。
* protocol specifications that under specify their transient numeric identifiers
* 下で一時的な数値識別子を指定するプロトコル仕様
* protocol specifications that over specify their transient numeric identifiers
* 過渡数値識別子を指定するプロトコル仕様
* protocol implementations that simply fail to comply with the specified requirements
* 指定された要件を単に遵守できないプロトコル実装
A number of IETF protocol specifications under specified their transient numeric identifiers, thus leading to implementations that were vulnerable to numerous off-path attacks. Examples of them are the specification of TCP local ports in [RFC0793] or the specification of the DNS ID in [RFC1035].
指定された一時的な数値識別子を指定した多くのIETFプロトコル仕様により、多数のオフパス攻撃に対して脆弱な実装につながりました。それらの例は、[RFC0793]のTCPローカルポートの仕様または[RFC1035]のDNS IDの仕様です。
NOTE: The TCP local port in an active OPEN request is commonly known as the "ephemeral port" of the corresponding TCP connection [RFC6056].
注：アクティブなオープンリクエストのTCPローカルポートは、対応するTCP接続[RFC6056]の「はかないポート」として一般的に知られています。
On the other hand, there are a number of IETF protocol specifications that over specify some of their associated transient numeric identifiers. For example, [RFC4291] essentially overloads the semantics of IPv6 Interface Identifiers (IIDs) by embedding link-layer addresses in the IPv6 IIDs when the interoperability requirement of uniqueness could be achieved in other ways that do not result in negative security and privacy implications [RFC7721]. Similarly, [RFC2460] suggests the use of a global counter for the generation of Identification values when the interoperability requirement of uniqueness per {IPv6 Source Address, IPv6 Destination Address} could be achieved with other algorithms that do not result in negative security and privacy implications [RFC7739].
一方、関連する一時的な数値識別子の一部を指定するIETFプロトコル仕様が多数あります。たとえば、[RFC4291]は、IPv6 IIDにリンク層アドレスを埋め込むことにより、IPv6インターフェイス識別子（IID）のセマンティクスを本質的に過負荷にします。RFC7721]。同様に、[RFC2460]は、{IPv6ソースアドレス、IPv6宛先アドレス}ごとに一意性の相互運用性の要件が、否定的なセキュリティとプライバシーへの影響をもたらさない他のアルゴリズムで達成できる場合、識別値の生成にグローバルカウンターを使用することを示唆しています。[RFC7739]。
Finally, there are protocol implementations that simply fail to comply with existing protocol specifications. For example, some popular operating systems still fail to implement transport-protocol ephemeral port randomization, as recommended in [RFC6056], or TCP Initial Sequence Number randomization, as recommended in [RFC9293].
最後に、既存のプロトコル仕様に単に準拠していないプロトコルの実装があります。たとえば、一部の一般的なオペレーティングシステムは、[RFC6056]で推奨されるように、[RFC9293]で推奨されるように、TCP初期シーケンス数ランダム化を実装していません。
The following subsections document the timelines for a number of sample transient numeric identifiers that illustrate how the problem discussed in this document has affected protocols from different layers over time. These sample transient numeric identifiers have different interoperability requirements and failure severities (see Section 6 of [RFC9415]), and thus are considered to be representative of the problem being analyzed in this document.
次のサブセクションは、このドキュメントで議論されている問題が時間の経過とともに異なるレイヤーからのプロトコルにどのように影響したかを示す多くのサンプル過渡数値識別子のタイムラインを文書化します。これらのサンプルの一時的な数値識別子は、異なる相互運用性要件と障害の重大度を持ち（[RFC9415]のセクション6を参照）、このドキュメントで分析されている問題を表していると考えられています。
This section presents the timeline of the Identification field employed by IPv4 (in the base header) and IPv6 (in Fragment Headers). The reason for presenting both cases in the same section is to make it evident that, while the Identification value serves the same purpose in both protocols, the work and research done for the IPv4 case did not influence IPv6 specifications or implementations.
このセクションでは、IPv4（ベースヘッダー）とIPv6（フラグメントヘッダー）で採用されている識別フィールドのタイムラインを示します。同じセクションで両方のケースを提示する理由は、識別値が両方のプロトコルで同じ目的を果たしている一方で、IPv4ケースで行われた研究と研究がIPv6仕様または実装に影響を与えないことを明らかにするためです。
The IPv4 Identification is specified in [RFC0791], which specifies the interoperability requirements for the Identification field, i.e., the sender must choose the Identification field to be unique for a given {Source Address, Destination Address, Protocol} for the time the datagram (or any fragment of it) could be alive in the Internet. It suggests that a sending protocol module may keep "a table of Identifiers, one entry for each destination it has communicated with in the last maximum packet lifetime for the [I]nternet", and it also suggests that "since the Identifier field allows 65,536 different values, hosts may be able to simply use unique identifiers independent of destination". The above has been interpreted numerous times as a suggestion to employ per-destination or global counters for the generation of Identification values. While [RFC0791] does not suggest any flawed algorithm for the generation of Identification values, the specification omits a discussion of the security and privacy implications of predictable Identification values. This resulted in many IPv4 implementations generating predictable Identification values by means of a global counter, at least at some point in time.
IPv4の識別は[RFC0791]で指定されており、識別フィールドの相互運用性要件を指定します。つまり、送信者は、データグラム（データグラム）の時間のために特定の{ソースアドレス、宛先アドレス、プロトコル}に対して一意に識別フィールドを選択する必要があります。または、それの断片）がインターネットで生きている可能性があります。送信プロトコルモジュールは、「識別子の表、[i] nternetの最後の最大パケット寿命と通信した各宛先の1つのエントリ」を保持することを示唆しており、「識別子フィールドが65,536を許可するため、さまざまな値、ホストは、宛先とは独立した一意の識別子を単純に使用できる場合があります」。上記は、識別値を生成するために、想定またはグローバルなカウンターを採用するための提案として何度も解釈されています。[RFC0791]は識別値の生成のための欠陥のあるアルゴリズムを示唆していませんが、仕様は予測可能な識別値のセキュリティとプライバシーへの影響についての議論を省略します。これにより、少なくともある時点で、グローバルカウンターによって予測可能な識別値を生成する多くのIPv4実装が生成されました。
The IPv6 Identification was originally specified in [RFC1883]. It serves the same purpose as its IPv4 counterpart, but rather than being part of the base header (as in the IPv4 case), it is part of the Fragment Header (which may or may not be present in an IPv6 packet). Section 4.5 of [RFC1883] states that the Identification must be different than that of any other fragmented packet sent recently (within the maximum likely lifetime of a packet) with the same Source Address and Destination Address. Subsequently, it notes that this requirement can be met by means of a wrap-around 32-bit counter that is incremented each time a packet must be fragmented and that it is an implementation choice whether to use a global or a per-destination counter. Thus, the specification of the IPv6 Identification is similar to that of the IPv4 case, with the only difference that, in the IPv6 case, the suggestions to use simple counters is more explicit. [RFC2460] is the first revision of the core IPv6 specification and maintains the same text for the specification of the IPv6 Identification field. [RFC8200], the second revision of the core IPv6 specification, removes the suggestion from [RFC2460] to use a counter for the generation of IPv6 Identification values and points to [RFC7739] for sample algorithms for their generation.
IPv6の識別は、もともと[RFC1883]で指定されていました。IPv4の対応物と同じ目的を果たしますが、ベースヘッダーの一部（IPv4の場合のように）の一部ではなく、フラグメントヘッダーの一部です（IPv6パケットに存在する場合と存在しない場合があります）。[RFC1883]のセクション4.5は、識別は、同じソースアドレスと宛先アドレスを持つ最近（パケットの最大寿命以内）送信された他の断片化パケットとは異なる必要があると述べています。その後、この要件は、パケットを断片化する必要があるたびにインクリメントされるラップアラウンド32ビットカウンターによって満たすことができ、グローバルまたはデステーションごとのカウンターを使用するかどうかにかかわらず実装選択であることに注意してください。したがって、IPv6識別の仕様はIPv4の場合の仕様と類似しており、IPv6の場合、単純なカウンターを使用する提案がより明確になるという唯一の違いがあります。[RFC2460]は、コアIPv6仕様の最初の改訂であり、IPv6識別フィールドの仕様のために同じテキストを維持します。[RFC8200]は、コアIPv6仕様の2回目の改訂であり、[RFC2460]からの提案を削除して、IPv6識別値の生成にカウンターを使用し、生成のサンプルアルゴリズムの[RFC7739]を指します。
September 1981:
1981年9月：
[RFC0791] specifies the interoperability requirements for the IPv4 Identification but does not perform a vulnerability assessment of this transient numeric identifier.
[RFC0791]は、IPv4識別の相互運用性要件を指定しますが、この一時的な数値識別子の脆弱性評価を実行しません。
December 1995:
1995年12月：
[RFC1883], the first specification of the IPv6 protocol, is published. It suggests that a counter be used to generate the IPv6 Identification values and notes that it is an implementation choice whether to maintain a single counter for the node or multiple counters (e.g., one for each of the node's possible Source Addresses, or one for each active {Source Address, Destination Address} set).
[RFC1883]、IPv6プロトコルの最初の仕様が公開されています。カウンターを使用してIPv6の識別値を生成し、ノードまたは複数のカウンターに単一のカウンターを維持するかどうか（たとえば、ノードの可能なソースアドレスのそれぞれ、またはそれぞれ用の1つを維持するかどうかが実装の選択肢であることを示唆しています。Active {ソースアドレス、宛先アドレス}セット）。
December 1998:
1998年12月：
[Sanfilippo1998a] finds that predictable IPv4 Identification values (as generated by most popular implementations) can be leveraged to count the number of packets sent by a target node. [Sanfilippo1998b] explains how to leverage the same vulnerability to implement a port-scanning technique known as "idle scan". A tool that implements this attack is publicly released.
[sanfilippo1998a]は、予測可能なIPv4識別値（最も一般的な実装によって生成される）を活用して、ターゲットノードによって送信されるパケットの数をカウントできることを発見しました。[sanfilippo1998b]は、同じ脆弱性を活用して「アイドルスキャン」と呼ばれるポートスキャンテクニックを実装する方法を説明しています。この攻撃を実装するツールは公開されています。
December 1998:
1998年12月：
[RFC2460], a revision of the IPv6 specification, is published, obsoleting [RFC1883]. It maintains the same specification of the IPv6 Identification field as its predecessor [RFC1883].
[RFC2460]は、IPv6仕様の改訂版で、廃止された[RFC1883]が公開されています。IPv6識別フィールドと同じ仕様を前身と維持しています[RFC1883]。
December 1998:
1998年12月：
OpenBSD implements randomization of the IPv4 Identification field [OpenBSD-IPv4-ID].
OpenBSDは、IPv4識別フィールドのランダム化[OpenBSD-IPV4-ID]を実装します。
November 1999:
1999年11月：
[Sanfilippo1999] discusses how to leverage predictable IPv4 Identification values to uncover the rules of a number of firewalls.
[SanFilippo1999]は、予測可能なIPv4識別値を活用して、多くのファイアウォールのルールを明らかにする方法について説明します。
September 2002:
2002年9月：
[Fyodor2002] documents the implementation of the "idle scan" technique in the popular Network Mapper (nmap) tool.
[FYODOR2002]は、人気のあるネットワークマッパー（NMAP）ツールで「アイドルスキャン」手法の実装を文書化しています。
November 2002:
2002年11月：
[Bellovin2002] explains how the IPv4 Identification field can be exploited to count the number of systems behind a NAT.
[Bellovin2002]は、IPv4識別フィールドを悪用してNATの背後にあるシステムの数をカウントする方法を説明しています。
October 2003:
2003年10月：
OpenBSD implements randomization of the IPv6 Identification field [OpenBSD-IPv6-ID].
OpenBSDは、IPv6識別フィールドのランダム化を実装します[OpenBSD-IPV6-ID]。
December 2003:
2003年12月：
[Zalewski2003] explains a technique to perform TCP data injection attacks based on predictable IPv4 Identification values, which requires less effort than TCP injection attacks performed with bare TCP packets.
[Zalewski2003]は、予測可能なIPv4識別値に基づいてTCPデータインジェクション攻撃を実行する手法を説明します。
January 2005:
2005年1月：
[Silbersack2005] discusses shortcomings in a number of techniques to mitigate predictable IPv4 Identification values.
[SilberSack2005]は、予測可能なIPv4識別値を緩和するための多くの手法で欠点について説明します。
October 2007:
2007年10月：
[Klein2007] describes a weakness in the pseudorandom number generator (PRNG) in use for the generation of IP Identification values by a number of operating systems.
[Klein2007]は、多くのオペレーティングシステムによるIP識別値の生成に使用されている擬似ランダム数ジェネレーター（PRNG）の弱点を説明しています。
June 2011:
2011年6月：
[Gont2011] describes how to perform idle scan attacks in IPv6.
[Gont2011]は、IPv6でアイドルスキャン攻撃を実行する方法について説明しています。
November 2011:
2011年11月：
Linux mitigates predictable IPv6 Identification values [RedHat2011] [SUSE2011] [Ubuntu2011].
Linuxは、予測可能なIPv6識別値[Redhat2011] [Suse2011] [Ubuntu2011]を軽減します。
December 2011:
2011年12月：
[draft-gont-6man-predictable-fragment-id-00] describes the security implications of predictable IPv6 Identification values and possible mitigations. This document has the intended status of "Standards Track", with the intention to formally update [RFC2460] to introduce security and privacy requirements on the generation of IPv6 Identification values.
[Draft-Gont-6man-Predictable-Fragment-ID-00]は、予測可能なIPv6識別値と緩和の可能性のセキュリティへの意味を説明しています。このドキュメントには、[RFC2460]を正式に更新して、IPv6識別値の生成に関するセキュリティおよびプライバシー要件を導入することを目的とした「標準追跡」の意図されたステータスがあります。
May 2012:
2012年5月：
[Gont2012] notes that some major IPv6 implementations still employ predictable IPv6 Identification values.
[Gont2012]は、一部の主要なIPv6実装では、予測可能なIPv6識別値を依然として採用していることに注意してください。
March 2013:
2013年3月：
The 6man WG adopts [draft-gont-6man-predictable-fragment-id-03] but changes the track to "BCP" (while still formally updating [RFC2460]), posting the resulting document as [draft-ietf-6man-predictable-fragment-id-00].
6man WGは[Draft-Gont-6man-Predictable-Fragment-ID-03]を採用していますが、トラックを「BCP」に変更します（まだ正式に更新しながら[RFC2460]）。-fragment-id-00]。
June 2013:
2013年6月：
A patch to incorporate support for IPv6-based idle scans in nmap is submitted [Morbitzer2013].
NMAPでIPv6ベースのアイドルスキャンのサポートを組み込むパッチが提出されます[Morbitzer2013]。
December 2014:
2014年12月：
The 6man WG changes the intended status of [draft-ietf-6man-predictable-fragment-id-01] to "Informational" and posts it as [draft-ietf-6man-predictable-fragment-id-02]. As a result, it no longer formally updates [RFC2460], and security and privacy requirements on the generation of IPv6 Identification values are eliminated.
6man WGは、[ドラフト-6MAN予測可能なフラグメント-ID-01]の意図したステータスを「情報」に変更し、[ドラフト-IITF-6MAN予測可能なフラグメントID-02]として投稿します。その結果、[RFC2460]を正式に更新しなくなり、IPv6識別値の生成に関するセキュリティとプライバシーの要件が排除されます。
June 2015:
2015年6月：
[draft-ietf-6man-predictable-fragment-id-08] notes that some popular host and router implementations still employ predictable IPv6 Identification values.
[Draft-IITF-6MAN-PREDICTABLE-FRAGMENT-ID-08]は、人気のあるホストとルーターの実装が予測可能なIPv6識別値を依然として採用していることを指摘しています。
February 2016:
2016年2月：
[RFC7739] (based on [draft-ietf-6man-predictable-fragment-id-10]) analyzes the security and privacy implications of predictable IPv6 Identification values and provides guidance for selecting an algorithm to generate such values. However, being published as an "Informational" RFC, it does not formally update [RFC2460] and does not introduce security and privacy requirements on the generation of IPv6 Identification values.
[RFC7739]（[ドラフト-ITF-6MAN-PREDICTABLE-FRAGMENT-ID-10]に基づく）は、予測可能なIPv6識別値のセキュリティとプライバシーへの影響を分析し、そのような値を生成するためのアルゴリズムを選択するためのガイダンスを提供します。ただし、「情報」RFCとして公開されているため、正式に[RFC2460]を更新せず、IPv6識別値の生成に関するセキュリティおよびプライバシー要件を導入しません。
June 2016:
2016年6月：
[draft-ietf-6man-rfc2460bis-05], a draft revision of [RFC2460], removes the suggestion from [RFC2460] to use a counter for the generation of IPv6 Identification values but does not perform a vulnerability assessment of the generation of IPv6 Identification values and does not introduce security and privacy requirements on the generation of IPv6 Identification values.
[rfc2460]のドラフト改訂であるドラフト-iTF-6MAN-RFC2460BIS-05]は、[RFC2460]の提案を削除して、IPv6識別値の生成にカウンターを使用しますが、IPv6の生成の脆弱性評価を実行しません識別値と、IPv6識別値の生成に関するセキュリティおよびプライバシー要件は導入されていません。
July 2017:
2017年7月：
[draft-ietf-6man-rfc2460bis-13] is finally published as [RFC8200], obsoleting [RFC2460] and pointing to [RFC7739] for sample algorithms for the generation of IPv6 Identification values. However, it does not introduce security and privacy requirements on the generation of IPv6 Identification values.
[ドラフト-ITF-6MAN-RFC2460BIS-13]は、IPv6識別値の生成のためのサンプルアルゴリズムについては、[RFC8200]、[RFC2460]、[RFC2460]、[RFC7739]を指すように最終的に公開されます。ただし、IPv6識別値の生成に関するセキュリティとプライバシーの要件は導入されません。
October 2019:
2019年10月：
[IPID-DEV] notes that the IPv6 Identification generators of two popular operating systems are flawed.
[IPID-DEV]は、2つの一般的なオペレーティングシステムのIPv6識別ジェネレーターに欠陥があると指摘しています。
[RFC0793] suggests that the choice of the ISN of a connection is not arbitrary but aims to reduce the chances of a stale segment from being accepted by a new incarnation of a previous connection. [RFC0793] suggests the use of a global 32-bit ISN generator that is incremented by 1 roughly every 4 microseconds. However, as a matter of fact, protection against stale segments from a previous incarnation of the connection is enforced by preventing the creation of a new incarnation of a previous connection before 2*MSL has passed since a segment corresponding to the old incarnation was last seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This is accomplished by the TIME-WAIT state and TCP's "quiet time" concept (see Appendix B of [RFC1323]). Based on the assumption that ISNs are monotonically increasing across connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an incoming SYN segment to perform "heuristics" that enable the creation of a new incarnation of a connection while the previous incarnation is still in the TIME-WAIT state (see p. 945 of [Wright1994]). This avoids an interoperability problem that may arise when a node establishes connections to a specific TCP end-point at a high rate [Silbersack2005].
[RFC0793]は、接続のISNの選択はarbitrary意的ではなく、古いセグメントの可能性を減らすことを目的としていることを示唆しています。[RFC0793]は、約4マイクロ秒ごとに1つずつ増加するグローバル32ビットISNジェネレーターの使用を示唆しています。しかし、実際のところ、接続の以前の化身からの古いセグメントに対する保護は、2*MSLが古い化身に対応するセグメントが最後に見られて以来、以前の接続の新しい化身の作成を防ぐことにより実施されます。（ここで、「MSL」は「最大セグメント寿命」[RFC0793]です）。これは、Time-Wait StateとTCPの「静かな時間」の概念によって達成されます（[RFC1323]の付録Bを参照）。ISNSが接続全体で単調に増加しているという仮定に基づいて、多くのスタック（4.2bsd由来）を使用して、次のシンセグメントのISNを使用して、以前の化身中の接続の新しい化身の作成を可能にする「ヒューリスティック」を実行します。まだ時間の状態です（[wright1994]のp。945を参照）。これにより、ノードが高速で特定のTCPエンドポイントへの接続を確立すると発生する可能性のある相互運用性の問題が回避されます[SilberSack2005]。
The interoperability requirements for TCP ISNs are probably not as clearly spelled out as one would expect. Furthermore, the suggestion of employing a global counter in [RFC0793] negatively affects the security and privacy properties of the protocol.
TCP ISNの相互運用性要件は、おそらく予想されるほど明確に綴られていません。さらに、[RFC0793]でグローバルカウンターを採用するという提案は、プロトコルのセキュリティとプライバシーの特性に悪影響を及ぼします。
September 1981:
1981年9月：
[RFC0793] suggests the use of a global 32-bit ISN generator, whose lower bit is incremented roughly every 4 microseconds. However, such an ISN generator makes it trivial to predict the ISN that a TCP implementation will use for new connections, thus allowing a variety of attacks against TCP.
[RFC0793]は、グローバルな32ビットISNジェネレーターの使用を示唆しています。ただし、そのようなISNジェネレーターは、TCP実装が新しい接続に使用するISNを予測するのを簡単にし、TCPに対するさまざまな攻撃を可能にします。
February 1985:
1985年2月：
[Morris1985] is the first to describe how to exploit predictable TCP ISNs for forging TCP connections that could then be leveraged for trust relationship exploitation.
[Morris1985]は、TCP接続を偽造するために予測可能なTCP ISNを活用する方法を説明した最初のものです。
April 1989:
1989年4月：
[Bellovin1989] discusses the security considerations for predictable ISNs (along with a range of other protocol-based vulnerabilities).
[Bellovin1989]は、予測可能なISNのセキュリティに関する考慮事項について説明します（他のさまざまなプロトコルベースの脆弱性とともに）。
January 1995:
1995年1月：
[Shimomura1995] reports a real-world exploitation of the vulnerability described in [Morris1985] ten years before (in 1985).
[Shimomura1995]は、[Morris1985]に記載されている10年前（1985年）に記載されている脆弱性の実際の搾取を報告しています。
May 1996:
1996年5月：
[RFC1948] is the first IETF effort, authored by Steven Bellovin, to address predictable TCP ISNs. However, [RFC1948] does not formally update [RFC0793]. Note: The same concept specified in this document for TCP ISNs was later proposed for TCP ephemeral ports [RFC6056], TCP Timestamps, and eventually even IPv6 Interface Identifiers [RFC7217].
[RFC1948]は、予測可能なTCP ISNに対処するSteven Bellovinが作成した最初のIETFの取り組みです。ただし、[RFC1948]は正式に[RFC0793]を更新しません。注：TCP ISNのこのドキュメントで指定されたのと同じ概念は、TCP Ephemeral Ports [RFC6056]、TCPタイムスタンプ、および最終的にはIPv6インターフェイス識別子[RFC7217]で後に提案されました。
July 1996:
1996年7月：
OpenBSD implements TCP ISN randomization based on random increments (please see Appendix A.2 of [RFC9415]) [OpenBSD-TCP-ISN-I].
OpenBSDは、ランダム増分に基づいてTCP ISNランダム化を実装しています（[RFC9415]の付録A.2を参照）[OpenBSD-TCP-ISN-I]。
December 2000:
2000年12月：
OpenBSD implements TCP ISN randomization using simple randomization (please see Section 7.1 of [RFC9415]) [OpenBSD-TCP-ISN-R].
OpenBSDは、単純なランダム化を使用してTCP ISNランダム化を実装します（[RFC9415]のセクション7.1を参照）[OpenBSD-TCP-ISN-R]。
March 2001:
2001年3月：
[Zalewski2001] provides a detailed analysis of statistical weaknesses in some TCP ISN generators and includes a survey of the algorithms in use by popular TCP implementations. Vulnerability advisories [USCERT2001] were released regarding statistical weaknesses in some TCP ISN generators, affecting popular TCP implementations. Other vulnerability advisories on the same vulnerability, such as [CERT2001], were published later on.
[Zalewski2001]は、一部のTCP ISNジェネレーターの統計的弱点の詳細な分析を提供し、一般的なTCP実装で使用されているアルゴリズムの調査を含みます。脆弱性勧告[USCERT2001]は、一部のTCP ISNジェネレーターの統計的弱点に関してリリースされ、一般的なTCP実装に影響を与えました。[CERT2001]など、同じ脆弱性に関するその他の脆弱性アドバイザリは、後で公開されました。
March 2002:
2002年3月：
[Zalewski2002] updates and complements [Zalewski2001]. It concludes that "while some vendors [...] reacted promptly and tested their solutions properly, many still either ignored the issue and never evaluated their implementations, or implemented a flawed solution that apparently was not tested using a known approach" [Zalewski2002].
[Zalewski2002]更新および補完[Zalewski2001]。「一部のベンダー[...]は迅速に反応し、ソリューションを適切にテストしましたが、多くはまだ問題を無視し、実装を評価することはありませんでした。。
June 2007:
2007年6月：
OpenBSD implements TCP ISN randomization based on the algorithm specified in [RFC1948] (currently obsoleted and replaced by [RFC6528]) for the TCP endpoint that performs the active open while keeping the simple randomization scheme for the endpoint performing the passive open [OpenBSD-TCP-ISN-H]. This provides monotonically increasing ISNs for the "client side" (allowing the BSD heuristics to work as expected) while avoiding any patterns in the ISN generation for the "server side".
OpenBSDは、[RFC1948]で指定されているアルゴリズム（現在廃止され、[RFC6528]に置き換えられている）に基づいてTCP ISNランダム化を実装します。-isn-h]。これにより、「クライアント側」のISN（BSDヒューリスティックが予想どおりに機能するように）のISNを単調に増加させ、「サーバー側」のISN世代のパターンを避けます。
February 2012:
2012年2月：
[RFC6528], published 27 years after Morris's original work [Morris1985], formally updates [RFC0793] to mitigate predictable TCP ISNs.
[RFC6528]、Morrisの元の作品[Morris1985]の27年後に発行された、予測可能なTCP ISNを緩和するために[RFC0793]を正式に更新します。
August 2014:
2014年8月：
The algorithm specified in [RFC6528] becomes the recommended ("SHOULD") algorithm for TCP ISN generation in [draft-eddy-rfc793bis-04], an early revision of the core TCP specification [RFC9293].
[RFC6528]で指定されたアルゴリズムは、[Draft-Eddy-RFC793BIS-04]のTCP ISN生成の推奨される（ "sefs"）アルゴリズムになります。これは、コアTCP仕様[RFC9293]の初期改訂です。
August 2022:
2022年8月：
[RFC9293], a revision of the core TCP specification, is published, adopting the algorithm specified in [RFC6528] as the recommended ("SHOULD") algorithm for TCP ISN generation.
[RFC9293]は、Core TCP仕様の改訂版であり、[RFC6528]で指定されたアルゴリズムをTCP ISN世代の推奨（「SOFE」）アルゴリズムとして採用しています。
IPv6 Interface Identifiers can be generated as a result of different mechanisms, including Stateless Address Autoconfiguration (SLAAC) [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section focuses on Interface Identifiers resulting from SLAAC.
IPv6インターフェイス識別子は、ステートレスアドレスAutoConfiguration（SLAAC）[RFC4862]、DHCPV6 [RFC8415]、および手動構成など、さまざまなメカニズムの結果として生成できます。このセクションでは、SLAACに起因するインターフェイス識別子に焦点を当てています。
The Interface Identifier of stable IPv6 addresses resulting from SLAAC originally resulted in the underlying link-layer address being embedded in the IID. At the time, employing the underlying link-layer address for the IID was seen as a convenient way to obtain a unique address. However, recent awareness about the security and privacy properties of this approach [RFC7707] [RFC7721] has led to the replacement of this flawed scheme with an alternative one [RFC7217] [RFC8064] that does not negatively affect the security and privacy properties of the protocol.
SLAACに起因する安定したIPv6アドレスのインターフェイス識別子は、元々IIDに埋め込まれている基礎となるリンク層アドレスが埋め込まれていました。当時、IIDの基礎となるリンク層アドレスを採用することは、一意のアドレスを取得する便利な方法と見なされていました。ただし、このアプローチのセキュリティとプライバシーの特性に関する最近の認識[RFC7707] [RFC7721]は、この欠陥スキームを代替のものに置き換えることにつながりました[RFC7217] [RFC8064]。プロトコル。
January 1997:
1997年1月：
[RFC2073] specifies the syntax of IPv6 global addresses (referred to as "An IPv6 Provider-Based Unicast Address Format" at the time), which is consistent with the IPv6 addressing architecture specified in [RFC1884]. Hosts are recommended to "generate addresses using link-specific addresses as Interface ID such as 48 bit IEEE-802 MAC addresses".
[RFC2073]は、[RFC1884]で指定されたIPv6アドレス指定アーキテクチャと一致するIPv6グローバルアドレス（当時の「IPv6プロバイダーベースのユニキャストアドレス形式」と呼ばれる）の構文を指定します。ホストは、「48ビットIEEE-802 MACアドレスなどのインターフェイスIDとしてリンク固有のアドレスを使用してアドレスを生成することをお勧めします。
July 1998:
1998年7月：
[RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address Format" (obsoleting [RFC2073]), changing the size of the IID to 64 bits, and specifies that IIDs must be constructed in IEEE 64-bit Extended Unique Identifier (EUI-64) format. How such identifiers are constructed is specified in the corresponding "IPv6 over <link>" specifications, such as "IPv6 over Ethernet".
[RFC2374]は、「IIDのサイズを64ビットに変更し、IIDを64ビット拡張ユニークな識別子（EUI-64）でIIDを構築する必要があることを指定し、「IPv6集約可能なグローバルユニキャストアドレス形式」（廃止[RFC2073]）を指定します。フォーマット。そのような識別子の構築方法は、「イーサネット上のIPv6」などの対応する「IPv6 over <link>」仕様で指定されています。
January 2001:
2001年1月：
[RFC3041] recognizes the problem of IPv6 network activity correlation and specifies IPv6 temporary addresses. Temporary addresses are to be used along with stable addresses.
[RFC3041]は、IPv6ネットワークアクティビティの相関の問題を認識し、IPv6の一時アドレスを指定します。一時的なアドレスは、安定したアドレスとともに使用されます。
August 2003:
2003年8月：
[RFC3587] obsoletes [RFC2374], making the Top-Level Aggregator (TLA) / Next-Level Aggregator (NLA) structure historic, though the syntax and recommendations for the stable IIDs remain unchanged.
[RFC3587]廃止[RFC2374]、トップレベルのアグリゲーター（TLA） /次レベルのアグリゲーター（NLA）構造歴史的なものになりましたが、安定したIIDの構文と推奨事項は変更されていません。
February 2006:
2006年2月：
[RFC4291] is published as the latest "IP Version 6 Addressing Architecture", requiring the IIDs of "all unicast addresses, except those that start with the binary value 000" to employ the Modified EUI-64 format. The details of constructing such interface identifiers are defined in the corresponding "IPv6 over <link>" specifications.
[RFC4291]は、最新の「IPバージョン6アドレス指定アーキテクチャ」として公開されており、修正されたEUI-64形式を使用するためにバイナリ値000 000から始まるものを除くすべてのユニキャストアドレスのIIDが必要です。このようなインターフェイス識別子の構築の詳細は、対応する「IPv6 Over <link>」仕様で定義されています。
March 2008:
2008年3月：
[RFC5157] provides hints regarding how patterns in IPv6 addresses could be leveraged for the purpose of address scanning.
[RFC5157]は、IPv6アドレスのパターンをアドレススキャンの目的で活用する方法に関するヒントを提供します。
December 2011:
2011年12月：
[draft-gont-6man-stable-privacy-addresses-00] notes that the original scheme for generating stable addresses allows for IPv6 address scanning and for active host tracking (even when IPv6 temporary addresses are employed). It also specifies an alternative algorithm meant to replace IIDs based on Modified EUI-64 format identifiers.
[Draft-Gont-6man-Stable-Privacy-Addresses-00]は、安定したアドレスを生成するための元のスキームにより、IPv6アドレスのスキャンとアクティブなホスト追跡が可能になります（IPv6の一時アドレスが採用されている場合でも）。また、変更されたEUI-64形式識別子に基づいてIIDを置き換えることを目的とした代替アルゴリズムも指定します。
November 2012:
2012年11月：
The 6man WG adopts [draft-gont-6man-stable-privacy-addresses-01] as a working group item (as [draft-ietf-6man-stable-privacy-addresses-00]). However, the document no longer formally updates [RFC4291]; therefore, the specified algorithm no longer formally replaces the Modified EUI-64 format identifiers.
6man WGは、[ドラフトゴント-6man-stable-privacy-addresses-01]をワーキンググループ項目として採用しています（[ドラフト-ITF-6MAN-STABLE-PRIVACY-ADDRESSES-00]）。ただし、ドキュメントは正式に[RFC4291]を更新しなくなりました。したがって、指定されたアルゴリズムは、変更されたEUI-64形式識別子を正式に置き換えなくなりました。
February 2013:
2013年2月：
An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages IPv6 address patterns is released [Gont2013].
IPv6アドレスパターンを活用するアドレススキャンツール（[IPv6-Toolkit]のScan6）がリリースされます[Gont2013]。
July 2013:
2013年7月：
[draft-cooper-6man-ipv6-address-generation-privacy-00] elaborates on the security and privacy properties of all known algorithms for generating IPv6 IIDs.
[Draft-Cooper-6man-IPV6-Address-Generation-Privacy-00]は、IPv6 IIDを生成するためのすべての既知のアルゴリズムのセキュリティとプライバシーのプロパティについて詳しく説明します。
January 2014:
2014年1月：
The 6man WG posts [draft-ietf-6man-default-iids-00] ("Recommendation on Stable IPv6 Interface Identifiers"), recommending [draft-ietf-6man-stable-privacy-addresses-17] for the generation of stable addresses.
6man WGは、安定したアドレスの生成のために[ドラフト-IITF-6MAN-6MAN-stable-Privacy-Addresses-17]を推奨することを推奨する[ドラフト-ITEF-6MAN-DEFAULT-IIDS-00]（「安定したIPv6インターフェイス識別子に関する推奨」）を投稿します。。
April 2014:
2014年4月：
[RFC7217] (formerly [draft-ietf-6man-stable-privacy-addresses-17]) is published, specifying "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" as an alternative to (but *not* replacement of) Modified EUI-64 format IIDs.
[RFC7217]（以前は[ドラフト-ITF-6MAN-STABLE-PRIVACY-ADDRESSES-17]）が公開され、「IPv6 StatelessアドレスAutoconfiguration（SLAAC）を使用して意味的に不透明なインターフェイス識別子を生成する方法」を指定します（しかし *が修正されたEUI-64形式のIIDの交換ではありません。
March 2016:
2016年3月：
[RFC7707] (formerly [draft-gont-opsec-ipv6-host-scanning-02] and later [draft-ietf-opsec-ipv6-host-scanning-08]), about "Network Reconnaissance in IPv6 Networks", is published.
[RFC7707]（以前は[Draft-Gont-Opsec-IPV6-Host-Scanning-02]および後に[Draft-Itef-Opsec-IPV6-Host-Scanning-08]）、「IPv6ネットワークのネットワーク偵察」について、公開されています。。
March 2016:
2016年3月：
[RFC7721] (formerly [draft-cooper-6man-ipv6-address-generation-privacy-00] and later [draft-ietf-6man-ipv6-address-generation-privacy-08]), about "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", is published.
[RFC7721]（以前は[ドラフトクーパー-6MAN-IPV6-ADDRESS-GENERATION-PRIVACY-00]および[Draft-IITF-6MAN-IPV6-ADDRESS-GENERATION-PRIVACY-08]））、「セキュリティとプライバシーの考慮事項の考慮事項IPv6アドレス生成メカニズム」が公開されています。
May 2016:
2016年5月：
[draft-gont-6man-non-stable-iids-00] is posted, with the goal of specifying requirements for non-stable addresses and updating [RFC4941] such that use of only temporary addresses is allowed.
[ドラフト-Gont-6man-non-stable-iids-00]が投稿され、安定しないアドレスの要件を指定し、[RFC4941]を更新することを目的として、一時的なアドレスのみの使用が許可されます。
May 2016:
2016年5月：
[draft-gont-6man-address-usage-recommendations-00] is posted, providing an analysis of how different aspects on an address (from stability to usage mode) affect their corresponding security and privacy properties and meaning to eventually provide advice in this area.
[Draft-Gont-6man-Address-Usage-Cremendations-00]が投稿され、アドレス（安定性から使用モードまで）のさまざまな側面が、対応するセキュリティとプライバシーの特性に影響し、最終的にこれにアドバイスを提供する方法を分析するエリア。
February 2017:
2017年2月：
[draft-ietf-6man-default-iids-16], produced by the 6man WG, is published as [RFC8064] ("Recommendation on Stable IPv6 Interface Identifiers"), with requirements for stable addresses and a recommendation to employ [RFC7217] for the generation of stable addresses. It formally updates a large number of RFCs.
[6MAN WGによって生成されたドラフト-ITEF-6MAN-DEFAULT-IIDS-16]は[RFC8064]（「安定したIPv6インターフェイス識別子に関する推奨事項」）として公開され、安定したアドレスの要件と[RFC7217]を採用する推奨安定したアドレスの生成用。多数のRFCを正式に更新します。
March 2018:
2018年3月：
[draft-fgont-6man-rfc4941bis-00] is posted (as suggested by the 6man WG) to address flaws in [RFC4941] by revising it (as an alternative to the [draft-gont-6man-non-stable-iids-00] effort, posted in March 2016).
[ドラフト-Fgont-6man-RFC4941Bis-00]は、[RFC4941]の欠陥に対処するために（6man WGが示唆しているように）投稿します（[ドラフト-gont-6man-non-stable-iids--に代わるものとして）00] 2016年3月に投稿）。
July 2018:
2018年7月：
[draft-fgont-6man-rfc4941bis-00] is adopted (as [draft-ietf-6man-rfc4941bis-00]) as a WG item of the 6man WG.
[ドラフト-Fgont-6MAN-RFC4941BIS-00]は、6MAN WGのWGアイテムとして（[Draft-ITF-6MAN-RFC4941BIS-00]として採用されています。
December 2020:
2020年12月：
[draft-ietf-6man-rfc4941bis-12] is approved by the IESG for publication as an RFC.
[Draft-IITF-6MAN-RFC4941BIS-12]は、IESGによってRFCとして公開されて承認されています。
February 2021:
2021年2月：
[draft-ietf-6man-rfc4941bis-12] is finally published as [RFC8981].
[Draft-ITEF-6MAN-RFC4941BIS-12]は最終的に[RFC8981]として公開されました。
The NTP [RFC5905] Reference ID is a 32-bit code identifying the particular server or reference clock. Above stratum 1 (secondary servers and clients), this value can be employed to avoid degree-one timing loops, that is, scenarios where two NTP peers are (mutually) the time source of each other. If using the IPv4 address family, the identifier is the four-octet IPv4 address. If using the IPv6 address family, it is the first four octets of the MD5 hash of the IPv6 address.
NTP [RFC5905]参照IDは、特定のサーバーまたは参照クロックを識別する32ビットコードです。Stratum 1（セカンダリサーバーとクライアント）の上で、この値は、学位1タイミングループ、つまり2つのNTPピアが（相互に）互いの時間源であるシナリオを回避するために使用できます。IPv4アドレスファミリを使用する場合、識別子は4オクタートIPv4アドレスです。IPv6アドレスファミリを使用する場合、IPv6アドレスのMD5ハッシュの最初の4オクテットです。
June 2010:
2010年6月：
[RFC5905] ("Network Time Protocol Version 4: Protocol and Algorithms Specification") is published. It specifies that, for NTP peers with stratum higher than 1, the REFID embeds the IPv4 address of the time source or the first four octets of the MD5 hash of the IPv6 address of the time source.
[RFC5905]（「ネットワークタイムプロトコルバージョン4：プロトコルとアルゴリズムの仕様」）が公開されています。1を超えるStratumのNTPピアの場合、RefidはTime SourceのIPv4アドレスまたはTime SourceのIPv6アドレスのMD5ハッシュの最初の4オクテットを埋め込むことを指定します。
July 2016:
2016年7月：
[draft-stenn-ntp-not-you-refid-00] is posted, describing the information leakage produced via the NTP REFID. It proposes that NTP returns a special REFID when a packet employs an IP Source Address that is not believed to be a current NTP peer but otherwise generates and returns the common REFID. It is subsequently adopted by the NTP WG as [draft-ietf-ntp-refid-updates-00].
[Draft-stenn-ntp-not-you-refid-00]が投稿されており、NTP refidを介して生成された情報漏れを説明しています。パケットが現在のNTPピアとは思われないが、それ以外の場合は一般的なrefidを生成および返す場合、パケットがIPソースアドレスを採用した場合、NTPは特別なrefidを返すことを提案します。その後、NTP WGによって[draft-itf-ntp-refid-updates-00]として採用されます。
April 2019:
2019年4月：
[Gont-NTP] notes that the proposed fix specified in [draft-ietf-ntp-refid-updates-00] is, at the very least, sub-optimal. As a result of a lack of WG support, the [draft-ietf-ntp-refid-updates-00] effort is eventually abandoned.
[gont-ntp]は、[draft-itf-ntp-refid-updates-00]で指定された提案された修正は、少なくとも最適であることに注意してください。WGサポートが不足しているため、[ドラフト-ITF-NTP-Refid-Updates-00]の努力は最終的に放棄されます。
Most (if not all) transport protocols employ "port numbers" to demultiplex packets to the corresponding transport-protocol instances. "Ephemeral ports" refer to the local ports employed in active OPEN requests, that is, typically the local port numbers employed on the side initiating the communication.
ほとんどの（すべてではないにしても）輸送プロトコルは、「ポート番号」を使用して、対応するトランスポートプロトコルインスタンスへのパケットをDemultiplexで使用しています。「はかない港」は、アクティブなオープンリクエストで採用されているローカルポート、つまり、通常、通信を開始する側で採用されているローカルポート番号を指します。
August 1980:
1980年8月：
[RFC0768] notes that the UDP source port is optional and identifies the port of the sending process. It does not specify interoperability requirements for source port selection, nor does it suggest possible ways to select port numbers. Most popular implementations end up selecting source ports from a system-wide global counter.
[RFC0768]は、UDPソースポートがオプションであることを指摘し、送信プロセスのポートを識別します。ソースポート選択の相互運用性要件を指定しておらず、ポート番号を選択する方法を示唆していません。最も一般的な実装は、システム全体のグローバルカウンターからソースポートを選択することになります。
September 1981:
1981年9月：
[RFC0793] (the TCP specification) essentially describes the use of port numbers and specifies that port numbers should result in a unique socket pair {local address, local port, remote address, remote port}. How ephemeral ports are selected and the port range from which they are selected are left unspecified.
[RFC0793]（TCP仕様）は、本質的にポート番号の使用を説明し、ポート番号が一意のソケットペア（ローカルアドレス、ローカルポート、リモートアドレス、リモートポート}になることを指定します。一時的なポートが選択され、選択されたポートの範囲は不特定のままになります。
July 1996:
1996年7月：
OpenBSD implements ephemeral port randomization [OpenBSD-PR].
OpenBSDは、一時的なポートランダム化[OpenBSD-PR]を実装します。
July 2008:
2008年7月：
The CERT Coordination Center publishes details of what became known as the "Kaminsky Attack" [VU-800113] [Kaminsky2008] on the DNS. The attack exploits the lack of ephemeral port randomization and DNS ID randomization in many major DNS implementations to perform cache poisoning in an effective and practical manner.
CERT Coordination Centerは、DNSで「Kaminsky Attack」[VU-800113] [Kaminsky2008]として知られるようになったものの詳細を公開しています。この攻撃は、多くの主要なDNS実装における一時的なポートランダム化とDNS IDランダム化の欠如を活用して、効果的かつ実用的な方法でキャッシュ中毒を実行します。
January 2009:
2009年1月：
[RFC5452] mandates the use of port randomization for DNS resolvers and mandates that implementations must randomize ports from the range of available ports (53 or 1024 and above) that is as large as possible and practicable. It does not recommend possible algorithms for port randomization, although the document specifically targets DNS resolvers, for which a simple port randomization suffices (e.g., Algorithm 1 of [RFC6056]). This document led to the implementation of port randomization in the DNS resolvers themselves, rather than in the underlying transport protocols.
[RFC5452]は、DNSリゾルバーのポートランダム化の使用を義務付け、可能な限り大きく実行可能な利用可能なポート（53または1024以降）の範囲からポートをランダム化する必要があることを義務付けています。ドキュメントはDNSリゾルバーをターゲットにしているが、単純なポートランダム化で十分であるため、ポートランダム化のために可能なアルゴリズムを推奨することはありません（たとえば、[RFC6056]のアルゴリズム1）。このドキュメントは、基礎となる輸送プロトコルではなく、DNSリゾルバー自体にポートランダム化が実装されました。
January 2011:
2011年1月：
[RFC6056] notes that many TCP and UDP implementations result in predictable ephemeral port numbers and also notes that many implementations select port numbers from a small portion of the whole port number space. It recommends the implementation and use of ephemeral port randomization, proposes a number of possible algorithms for port randomization, and also recommends to randomize port numbers over the range 1024-65535.
[RFC6056]は、多くのTCPおよびUDPの実装により予測可能な一時的なポート番号が生じることを指摘し、多くの実装がポート番号スペース全体のごく一部からポート番号を選択することも指摘しています。一時的なポートランダム化の実装と使用を推奨し、ポートランダム化のために多くの可能なアルゴリズムを提案し、範囲1024-65535でポート番号をランダム化することも推奨します。
March 2016:
2016年3月：
[NIST-NTP] reports a non-normal distribution of the ephemeral port numbers employed by the NTP clients of an Internet Time Service.
[NIST-NTP]は、インターネットタイムサービスのNTPクライアントが採用している短命ポート番号の非正規分布を報告しています。
April 2019:
2019年4月：
[draft-gont-ntp-port-randomization-00] notes that some NTP implementations employ the NTP service port (123) as the local port for nonsymmetric modes and aims to update the NTP specification to recommend port randomization in such cases, which is in line with [RFC6056]. The proposal experiences some pushback in the relevant working group (NTP WG) [NTP-PORTR] but is finally adopted as a working group item as [draft-ietf-ntp-port-randomization-00].
[Draft-Gont-NTP-Port-Randomization-00]は、一部のNTP実装は、NTPサービスポート（123）を非対称モードのローカルポートとして採用していることを指摘しており、NTP仕様を更新して、そのような場合のポートランダム化を推奨することを目指しています。[RFC6056]に沿って。この提案は、関連するワーキンググループ（NTP WG）[NTP-PORTR]でいくつかのプッシュバックを経験しますが、最終的にワーキンググループ項目として[Draft-ITP-NTP-Port-Randomization-00]として採用されます。
August 2021:
2021年8月：
[draft-ietf-ntp-port-randomization-08] is finally published as [RFC9109].
[Draft-ITEF-NTP-Port-Randomization-08]は、最終的に[RFC9109]として公開されました。
The DNS ID [RFC1035] can be employed to match DNS replies to outstanding DNS queries.
DNS ID [RFC1035]を使用して、DNS応答を未解決のDNSクエリに一致させることができます。
NOTE: Some documents refer to the DNS ID as the DNS "Query ID" or "TxID".
注：一部のドキュメントでは、DNS IDをDNS「クエリID」または「TXID」と呼びます。
November 1987:
1987年11月：
[RFC1035] specifies that the DNS ID is a 16-bit identifier assigned by the program that generates any kind of query and that this identifier is copied in the corresponding reply and can be used by the requester to match up replies to outstanding queries. It does not specify the interoperability requirements for this numeric identifier, nor does it suggest an algorithm for generating it.
[RFC1035]は、DNS IDがあらゆる種類のクエリを生成するプログラムによって割り当てられた16ビット識別子であり、この識別子が対応する返信にコピーされ、リクエスターがリクエスターが傑出したクエリに合わせるために使用できることを指定します。この数値識別子の相互運用性要件を指定しておらず、それを生成するためのアルゴリズムを示唆していません。
August 1993:
1993年8月：
[Schuba1993] describes DNS cache poisoning attacks that require the attacker to guess the DNS ID.
[Schuba1993]は、攻撃者がDNS IDを推測する必要があるDNSキャッシュ中毒攻撃について説明しています。
June 1995:
1995年6月：
[Vixie1995] suggests that both the UDP source port and the DNS ID of query packets should be randomized, although that might not provide enough entropy to prevent an attacker from guessing these values.
[Vixie1995]は、UDPソースポートとクエリパケットのDNS IDの両方をランダム化する必要があることを示唆していますが、攻撃者がこれらの値を推測するのを防ぐのに十分なエントロピーを提供しない可能性があります。
April 1997:
1997年4月：
[Arce1997] finds that implementations employ predictable UDP source ports and predictable DNS IDs and argues that both should be randomized.
[ARCE1997]は、実装が予測可能なUDPソースポートと予測可能なDNS IDを使用していることを発見し、両方をランダム化する必要があると主張しています。
November 2002:
2002年11月：
[Sacramento2002] finds that, by spoofing multiple requests for the same domain name from different IP addresses, an attacker may guess the DNS ID employed for a victim with a high probability of success, thus allowing for DNS cache poisoning attacks.
[Sacramento2002]は、異なるIPアドレスから同じドメイン名の複数のリクエストをスプーフィングすることにより、攻撃者が成功の可能性が高い被害者に採用されているDNS IDを推測し、DNSキャッシュ中毒攻撃を可能にすることができることを発見しました。
March 2007:
2007年3月：
[Klein2007c] finds that the Microsoft Windows DNS server generates predictable DNS ID values.
[klein2007c]は、Microsoft Windows DNSサーバーが予測可能なDNS ID値を生成することを発見しました。
July 2007:
2007年7月：
[Klein2007b] finds that a popular DNS server software (BIND 9) that randomizes the DNS ID is still subject to DNS cache poisoning attacks by forging a large number of queries and leveraging the birthday paradox.
[Klein2007b]は、DNS IDをランダム化する人気のあるDNSサーバーソフトウェア（Bind 9）が、多数のクエリを鍛造し、誕生日パラドックスを活用することにより、DNSキャッシュ中毒攻撃の対象となることを発見しました。
October 2007:
2007年10月：
[Klein2007] finds that OpenBSD's DNS software (based on the BIND DNS server of the Internet Systems Consortium (ISC)) generates predictable DNS ID values.
[Klein2007]は、OpenBSDのDNSソフトウェア（Internet Systems Consortium（ISC）のBind DNSサーバーに基づく）が予測可能なDNS ID値を生成することを発見しました。
January 2009:
2009年1月：
[RFC5452] is published, requiring resolvers to randomize the DNS ID of queries and to verify that the DNS ID of a reply matches that of the DNS query as part of the DNS reply validation process.
[RFC5452]が公開されており、リゾルバーがクエリのDNS IDをランダム化し、返信のDNS IDがDNS応答検証プロセスの一部としてDNSクエリのIDと一致することを確認する必要があります。
May 2010:
2010年5月：
[Economou2010] finds that the Windows SMTP Service implements its own DNS resolver that results in predictable DNS ID values. Additionally, it fails to validate that the DNS ID of a reply matches that of the DNS query that supposedly elicited it.
[Economou2010]は、Windows SMTPサービスが独自のDNSリゾルバーを実装して、予測可能なDNS ID値を実装することを発見しました。さらに、返信のDNS IDがそれを誘発したと思われるDNSクエリのIDと一致することを検証できません。
For more than 30 years, a large number of implementations of IETF protocols have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection to information leakages that could be exploited for pervasive monitoring [RFC7258]. The root cause of these issues has been, in many cases, the poor selection of transient numeric identifiers in such protocols, usually as a result of insufficient or misleading specifications.
30年以上にわたり、IETFプロトコルの多数の実装がさまざまな攻撃の対象となり、サービス拒否（DOS）またはデータインジェクションから、広範な監視に利用できる情報漏れに至るまでの影響があります[RFC7258]。これらの問題の根本的な原因は、多くの場合、このようなプロトコルにおける一時的な数値識別子の選択が不十分であり、通常は不十分または誤解を招く仕様の結果です。
While it is generally possible to identify an algorithm that can satisfy the interoperability requirements for a given transient numeric identifier, this document provides empirical evidence that doing so without negatively affecting the security and/or privacy properties of the aforementioned protocols is nontrivial. It is thus evident that advice in this area is warranted.
一般に、特定の一時的な数値識別子の相互運用性要件を満たすことができるアルゴリズムを識別することは可能ですが、このドキュメントは、前述のプロトコルのセキュリティおよび/またはプライバシー特性に悪影響を与えることなくそうすることを行うという経験的証拠を提供します。したがって、この分野のアドバイスが保証されていることは明らかです。
[RFC9416] aims at requiring future IETF protocol specifications to contain analysis of the security and privacy properties of any transient numeric identifiers specified by the protocol and to recommend an algorithm for the generation of such transient numeric identifiers. [RFC9415] specifies a number of sample algorithms for generating transient numeric identifiers with specific interoperability requirements and failure severities.
[RFC9416]は、プロトコルによって指定された過渡数値識別子のセキュリティおよびプライバシープロパティの分析を含むように、将来のIETFプロトコル仕様を要求し、そのような一時的な数値識別子の生成のためのアルゴリズムを推奨することを目的としています。[RFC9415]特定の相互運用性要件と障害の重大度を備えた過渡数値識別子を生成するための多くのサンプルアルゴリズムを指定します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document analyzes the timeline of the specification and implementation of the transient numeric identifiers of some sample IETF protocols and how the security and privacy properties of such protocols have been affected as a result of it. It provides concrete evidence that advice in this area is warranted.
このドキュメントでは、いくつかのサンプルIETFプロトコルの過渡数値識別子の仕様と実装のタイムラインと、その結果としてそのようなプロトコルのセキュリティとプライバシープロパティがどのように影響を受けたかを分析します。この分野のアドバイスが保証されているという具体的な証拠を提供します。
[RFC9415] analyzes and categorizes transient numeric identifiers based on their interoperability requirements and their associated failure severities and recommends possible algorithms that can be employed to comply with those requirements without negatively affecting the security and privacy properties of the corresponding protocols.
[RFC9415]は、相互運用性要件と関連する障害の重大度に基づいて過渡数値識別子を分析および分類し、対応するプロトコルのセキュリティとプライバシープロパティに悪影響を与えることなくそれらの要件を順守するために使用できる可能性のあるアルゴリズムを推奨します。
[RFC9416] formally requires IETF protocol specifications to specify the interoperability requirements for their transient numeric identifiers, to do a warranted vulnerability assessment of such transient numeric identifiers, and to recommend possible algorithms for their generation, such that the interoperability requirements are complied with, while any negative security or privacy properties of these transient numeric identifiers are mitigated.
[RFC9416]は、一時的な数値識別子の相互運用性要件を指定し、そのような一時的な数値識別子の保証された脆弱性評価を行うために、IETFプロトコル仕様を正式に必要とします。これらの一時的な数値識別子の負のセキュリティまたはプライバシープロパティは緩和されます。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC0793] Postel, J., "Transmission Control Protocol", RFC 793,
DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
1992, <https://www.rfc-editor.org/info/rfc1323>.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
December 1995, <https://www.rfc-editor.org/info/rfc1883>.
[RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6
Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884,
December 1995, <https://www.rfc-editor.org/info/rfc1884>.
[RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J.
Postel, "An IPv6 Provider-Based Unicast Address Format",
RFC 2073, DOI 10.17487/RFC2073, January 1997,
<https://www.rfc-editor.org/info/rfc2073>.
[RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6
Aggregatable Global Unicast Address Format", RFC 2374,
DOI 10.17487/RFC2374, July 1998,
<https://www.rfc-editor.org/info/rfc2374>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
DOI 10.17487/RFC3041, January 2001,
<https://www.rfc-editor.org/info/rfc3041>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
August 2003, <https://www.rfc-editor.org/info/rfc3587>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452,
DOI 10.17487/RFC5452, January 2009,
<https://www.rfc-editor.org/info/rfc5452>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6056>.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
2012, <https://www.rfc-editor.org/info/rfc6528>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[Arce1997] Arce, I. and E. Kargieman, "BIND Vulnerabilities and
Solutions", April 1997,
<http://www.openbsd.org/advisories/sni_12_resolverid.txt>.
[Bellovin1989]
Bellovin, S., "Security Problems in the TCP/IP Protocol
Suite", Computer Communications Review, vol. 19, no. 2,
pp. 32-48, April 1989,
<https://www.cs.columbia.edu/~smb/papers/ipext.pdf>.
[Bellovin2002]
Bellovin, S., "A Technique for Counting NATted Hosts",
IMW'02, Marseille, France, DOI 10.1145/637201.637243,
November 2002,
<https://www.cs.columbia.edu/~smb/papers/fnat.pdf>.
[CERT2001] CERT/CC, "CERT Advisory CA-2001-09: Statistical Weaknesses
in TCP/IP Initial Sequence Numbers", May 2001,
<https://resources.sei.cmu.edu/asset_files/
WhitePaper/2001_019_001_496192.pdf>.
[draft-cooper-6man-ipv6-address-generation-privacy-00]
Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms",
Work in Progress, Internet-Draft, draft-cooper-6man-ipv6-
address-generation-privacy-00, 15 July 2013,
<https://www.ietf.org/archive/id/draft-cooper-6man-ipv6-
address-generation-privacy-00.txt>.
[draft-eddy-rfc793bis-04]
Eddy, W., Ed., "Transmission Control Protocol
Specification", Work in Progress, Internet-Draft, draft-
eddy-rfc793bis-04, 25 August 2014,
<https://www.ietf.org/archive/id/draft-eddy-rfc793bis-
04.txt>.
[draft-fgont-6man-rfc4941bis-00]
Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Privacy Extensions for Stateless Address
Autoconfiguration in IPv6", Work in Progress, Internet-
Draft, draft-fgont-6man-rfc4941bis-00, 25 March 2018,
<https://www.ietf.org/archive/id/draft-fgont-6man-
rfc4941bis-00.txt>.
[draft-gont-6man-address-usage-recommendations-00]
Gont, F. and W. LIU, "IPv6 Address Usage Recommendations",
Work in Progress, Internet-Draft, draft-gont-6man-address-
usage-recommendations-00, 27 May 2016,
<https://www.ietf.org/archive/id/draft-gont-6man-address-
usage-recommendations-00.txt>.
[draft-gont-6man-non-stable-iids-00]
Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6
Interface Identifiers", Work in Progress, Internet-Draft,
draft-gont-6man-non-stable-iids-00, 23 May 2016,
<https://www.ietf.org/archive/id/draft-gont-6man-non-
stable-iids-00.txt>.
[draft-gont-6man-predictable-fragment-id-00]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-gont-6man-predictable-fragment-id-00, 15 December
2011, <https://www.ietf.org/archive/id/draft-gont-6man-
predictable-fragment-id-00.txt>.
[draft-gont-6man-predictable-fragment-id-03]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-gont-6man-predictable-fragment-id-03, 9 January
2013, <https://www.ietf.org/archive/id/draft-gont-6man-
predictable-fragment-id-03.txt>.
[draft-gont-6man-stable-privacy-addresses-00]
Gont, F., "A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", Work in Progress, Internet-Draft, draft-gont-
6man-stable-privacy-addresses-00, 15 December 2011,
<https://www.ietf.org/archive/id/draft-gont-6man-stable-
privacy-addresses-00.txt>.
[draft-gont-6man-stable-privacy-addresses-01]
Gont, F., "A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", Work in Progress, Internet-Draft, draft-gont-
6man-stable-privacy-addresses-01, 31 March 2012,
<https://www.ietf.org/archive/id/draft-gont-6man-stable-
privacy-addresses-01.txt>.
[draft-gont-ntp-port-randomization-00]
Gont, F. and G. Gont, "Port Randomization in the Network
Time Protocol Version 4", Work in Progress, Internet-
Draft, draft-gont-ntp-port-randomization-00, 16 April
2019, <https://www.ietf.org/archive/id/draft-gont-ntp-
port-randomization-00.txt>.
[draft-gont-opsec-ipv6-host-scanning-02]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", Work in Progress, Internet-Draft, draft-gont-
opsec-ipv6-host-scanning-02, 23 October 2012,
<https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-
host-scanning-02.txt>.
[draft-gont-predictable-numeric-ids-03]
Gont, F. and I. Arce, "Security and Privacy Implications
of Numeric Identifiers Employed in Network Protocols",
Work in Progress, Internet-Draft, draft-gont-predictable-
numeric-ids-03, 11 March 2019,
<https://datatracker.ietf.org/doc/html/draft-gont-
predictable-numeric-ids-03>.
[draft-ietf-6man-default-iids-00]
Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
Work in Progress, Internet-Draft, draft-ietf-6man-default-
iids-00, 24 January 2014,
<https://www.ietf.org/archive/id/draft-ietf-6man-default-
iids-00.txt>.
[draft-ietf-6man-default-iids-16]
Gont, F., Cooper, A., Thaler, D., and W. LIU,
"Recommendation on Stable IPv6 Interface Identifiers",
Work in Progress, Internet-Draft, draft-ietf-6man-default-
iids-16, 28 September 2016,
<https://www.ietf.org/archive/id/draft-ietf-6man-default-
iids-16.txt>.
[draft-ietf-6man-ipv6-address-generation-privacy-08]
Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms",
Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
address-generation-privacy-08, 23 September 2015,
<https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-
address-generation-privacy-08.txt>.
[draft-ietf-6man-predictable-fragment-id-00]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-ietf-6man-predictable-fragment-id-00, 22 March 2013,
<https://www.ietf.org/archive/id/draft-ietf-6man-
predictable-fragment-id-00.txt>.
[draft-ietf-6man-predictable-fragment-id-01]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-ietf-6man-predictable-fragment-id-01, 29 April 2014,
<https://www.ietf.org/archive/id/draft-ietf-6man-
predictable-fragment-id-01.txt>.
[draft-ietf-6man-predictable-fragment-id-02]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-ietf-6man-predictable-fragment-id-02, 19 December
2014, <https://datatracker.ietf.org/doc/html/draft-ietf-
6man-predictable-fragment-id-02>.
[draft-ietf-6man-predictable-fragment-id-08]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-ietf-6man-predictable-fragment-id-08, 9 June 2015,
<https://www.ietf.org/archive/id/draft-ietf-6man-
predictable-fragment-id-08.txt>.
[draft-ietf-6man-predictable-fragment-id-10]
Gont, F., "Security Implications of Predictable Fragment
Identification Values", Work in Progress, Internet-Draft,
draft-ietf-6man-predictable-fragment-id-10, 9 October
2015, <https://www.ietf.org/archive/id/draft-ietf-6man-
predictable-fragment-id-10.txt>.
[draft-ietf-6man-rfc2460bis-05]
Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", Work in Progress, Internet-Draft,
draft-ietf-6man-rfc2460bis-05, 28 June 2016,
<https://www.ietf.org/archive/id/draft-ietf-6man-
rfc2460bis-05.txt>.
[draft-ietf-6man-rfc2460bis-13]
Deering, S. and R. Hinden, "draft-ietf-6man-rfc2460bis-
13", Work in Progress, Internet-Draft, draft-ietf-6man-
rfc2460bis-13, 19 May 2017,
<https://www.ietf.org/archive/id/draft-ietf-6man-
rfc2460bis-13.txt>.
[draft-ietf-6man-rfc4941bis-00]
Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Privacy Extensions for Stateless Address
Autoconfiguration in IPv6", Work in Progress, Internet-
Draft, draft-ietf-6man-rfc4941bis-00, 2 July 2018,
<https://www.ietf.org/archive/id/draft-ietf-6man-
rfc4941bis-00.txt>.
[draft-ietf-6man-rfc4941bis-12]
Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", Work in Progress, Internet-
Draft, draft-ietf-6man-rfc4941bis-12, 2 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-6man-
rfc4941bis-12.txt>.
[draft-ietf-6man-stable-privacy-addresses-00]
Gont, F., "A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", Work in Progress, Internet-Draft, draft-ietf-
6man-stable-privacy-addresses-00, 18 May 2012,
<https://www.ietf.org/archive/id/draft-ietf-6man-stable-
privacy-addresses-00.txt>.
[draft-ietf-6man-stable-privacy-addresses-17]
Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", Work in Progress, Internet-
Draft, draft-ietf-6man-stable-privacy-addresses-17, 27
January 2014, <https://www.ietf.org/archive/id/draft-ietf-
6man-stable-privacy-addresses-17.txt>.
[draft-ietf-ntp-port-randomization-00]
Gont, F., Gont, G., and M. Lichvar, "Port Randomization in
the Network Time Protocol Version 4", Work in Progress,
Internet-Draft, draft-ietf-ntp-port-randomization-00, 22
October 2019, <https://www.ietf.org/archive/id/draft-ietf-
ntp-port-randomization-00.txt>.
[draft-ietf-ntp-port-randomization-08]
Gont, F., Gont, G., and M. Lichvar, "Port Randomization in
the Network Time Protocol Version 4", Work in Progress,
Internet-Draft, draft-ietf-ntp-port-randomization-00, 10
June 2021, <https://www.ietf.org/archive/id/draft-ietf-
ntp-port-randomization-08.txt>.
[draft-ietf-ntp-refid-updates-00]
Stenn, H. and S. Goldberg, "Network Time Protocol REFID
Updates", Work in Progress, Internet-Draft, draft-ietf-
ntp-refid-updates-00, 13 November 2016,
<https://www.ietf.org/archive/id/draft-ietf-ntp-refid-
updates-00.txt>.
[draft-ietf-opsec-ipv6-host-scanning-08]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", Work in Progress, Internet-Draft, draft-ietf-
opsec-ipv6-host-scanning-08, 28 August 2015,
<https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6-
host-scanning-08.txt>.
[draft-stenn-ntp-not-you-refid-00]
Goldberg, S. and H. Stenn, "Network Time Protocol Not You
REFID", Work in Progress, Internet-Draft, draft-stenn-ntp-
not-you-refid-00, 8 July 2016,
<https://www.ietf.org/archive/id/draft-stenn-ntp-not-you-
refid-00.txt>.
[Economou2010]
Economou, N., "Windows SMTP Service DNS query Id
vulnerabilities", Advisory ID Internal CORE-2010-0427, May
2010, <https://www.coresecurity.com/core-labs/advisories/
core-2010-0424-windows-smtp-dns-query-id-bugs>.
[Fyodor2002]
Fyodor, "Idle scanning and related IP ID games", September
2002,
<https://nmap.org/presentations/CanSecWest03/CD_Content/
idlescan_paper/idlescan.html>.
[Gont-NTP] Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates-
05", message to the IETF NTP mailing list, 16 April 2019,
<https://mailarchive.ietf.org/arch/msg/ntp/
NkfTHxUUOdp14Agh3h1IPqfcRRg>.
[Gont2011] Gont, F., "Hacking IPv6 Networks (training course)", Hack
In Paris 2011 Conference, Paris, France, June 2011,
<https://www.si6networks.com/files/presentations/hip2011/
fgont-hip2011-hacking-ipv6-networks.pdf>.
[Gont2012] Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012
Conference, Ottawa, Canada, May 2012,
<https://www.si6networks.com/files/presentations/
bsdcan2012/fgont-bsdcan2012-recent-advances-in-
ipv6-security.pdf>.
[Gont2013] Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit
(help wanted!)", message to the IPv6 Hackers mailing list,
11 February 2013,
<https://lists.si6networks.com/pipermail/
ipv6hackers/2013-February/000947.html>.
[IANA-PROT]
IANA, "Protocol Registries",
<https://www.iana.org/protocols>.
[IPID-DEV] Klein, A. and B. Pinkas, "From IP ID to Device ID and
KASLR Bypass (Extended Version)",
DOI 10.48550/arXiv.1906.10478, October 2019,
<https://arxiv.org/pdf/1906.10478.pdf>.
[IPv6-Toolkit]
SI6 Networks, "IPv6 Toolkit",
<https://www.si6networks.com/tools/ipv6toolkit>.
[Kaminsky2008]
Kaminsky, D., "Black Ops 2008: It's The End Of The Cache
As We Know It", August 2008,
<https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-
Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf>.
[Klein2007]
Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability", October 2007,
<https://dl.packetstormsecurity.net/papers/attack/OpenBSD_
DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln
erability.pdf>.
[Klein2007b]
Klein, A., "BIND 9 DNS Cache Poisoning", March 2007,
<https://citeseerx.ist.psu.edu/doc/10.1.1.86.4474>.
[Klein2007c]
Klein, A., "Windows DNS Server Cache Poisoning", March
2007, <https://dl.packetstormsecurity.net/papers/attack/
Windows_DNS_Cache_Poisoning.pdf>.
[Morbitzer2013]
Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", message to
the nmap-dev mailing list, 3 June 2013,
<https://seclists.org/nmap-dev/2013/q2/394>.
[Morris1985]
Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP
Software", CSTR 117, AT&T Bell Laboratories, Murray Hill,
NJ, February 1985,
<https://pdos.csail.mit.edu/~rtm/papers/117.pdf>.
[NIST-NTP] Sherman, J. and J. Levine, "Usage Analysis of the NIST
Internet Time Service", Journal of Research of the
National Institute of Standards and Technology, Volume
121, March 2016,
<https://tf.nist.gov/general/pdf/2818.pdf>.
[NTP-PORTR]
Gont, F., "[Ntp] New rev of the NTP port randomization I-D
(Fwd: New Version Notification for draft-gont-ntp-port-
randomization-01.txt)", message to the IETF NTP mailing
list, 21 May 2019,
<https://mailarchive.ietf.org/arch/msg/ntp/
xSCu5Vhb3zoWcqEjUMmzP8pOdW4/>.
[OpenBSD-IPv4-ID]
OpenBSD, "Randomization of the IPv4 Identification field",
December 1998,
<https://cvsweb.openbsd.org/src/sys/netinet/
ip_id.c?rev=1.1>.
[OpenBSD-IPv6-ID]
OpenBSD, "Randomization of the IPv6 Identification field",
October 2003,
<https://cvsweb.openbsd.org/src/sys/netinet6/
ip6_id.c?rev=1.1>.
[OpenBSD-PR]
OpenBSD, "Implementation of port randomization", July
1996, <https://cvsweb.openbsd.org/src/sys/netinet/
in_pcb.c?rev=1.6>.
[OpenBSD-TCP-ISN-H]
OpenBSD, "Implementation of RFC1948 for TCP ISN
randomization", June 2007,
<https://cvsweb.openbsd.org/src/sys/netinet/
tcp_subr.c?rev=1.97>.
[OpenBSD-TCP-ISN-I]
OpenBSD, "Implementation of TCP ISN randomization based on
random increments", July 1996,
<https://cvsweb.openbsd.org/src/sys/netinet/
tcp_subr.c?rev=1.6>.
[OpenBSD-TCP-ISN-R]
OpenBSD, "Implementation of TCP ISN randomization based on
simple randomization", December 2000,
<https://cvsweb.openbsd.org/src/sys/netinet/
tcp_subr.c?rev=1.37>.
[RedHat2011]
Red Hat, "RHSA-2011:1465-1 - Security Advisory", November
2011, <https://rhn.redhat.com/errata/RHSA-2011-1465.html>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, DOI 10.17487/RFC1948, May 1996,
<https://www.rfc-editor.org/info/rfc1948>.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, DOI 10.17487/RFC5157, March 2008,
<https://www.rfc-editor.org/info/rfc5157>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol
Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
<https://www.rfc-editor.org/info/rfc6274>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
Version 4: Port Randomization", RFC 9109,
DOI 10.17487/RFC9109, August 2021,
<https://www.rfc-editor.org/info/rfc9109>.
[RFC9415] Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", RFC 9415, DOI 10.17487/RFC9415, July
2023, <https://www.rfc-editor.org/info/rfc9415>.
[RFC9416] Gont, F. and I. Arce, "Security Considerations for
Transient Numeric Identifiers Employed in Network
Protocols", BCP 72, RFC 9416, DOI 10.17487/RFC9416, July
2023, <https://www.rfc-editor.org/info/rfc9416>.
[Sacramento2002]
Sacramento, V., "CAIS-ALERT: Vulnerability in the sending
requests control of BIND", message to the Bugtraq mailing
list, 25 November 2002,
<https://seclists.org/bugtraq/2002/Nov/331>.
[Sanfilippo1998a]
Sanfilippo, S., "about the ip header id", message to the
Bugtraq mailing list, 14 December 1998,
<http://seclists.org/bugtraq/1998/Dec/48>.
[Sanfilippo1998b]
Sanfilippo, S., "new tcp scan method", message to the
Bugtraq mailing list, 18 December 1998,
<https://seclists.org/bugtraq/1998/Dec/79>.
[Sanfilippo1999]
Sanfilippo, S., "more ip id", message to the Bugtraq
mailing list, November 1999,
<https://github.com/antirez/hping/raw/master/docs/MORE-
FUN-WITH-IPID>.
[Schuba1993]
Schuba, C., "Addressing Weakness in the Domain Name System
Protocol", August 1993,
<http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/
schuba-DNS-msthesis.pdf>.
[Shimomura1995]
Shimomura, T., "Technical details of the attack described
by Markoff in NYT", message to the USENET
comp.security.misc newsgroup, 25 January 1995,
<https://www.gont.com.ar/files/post-shimomura-usenet.txt>.
[Silbersack2005]
Silbersack, M., "Improving TCP/IP security through
randomization without sacrificing interoperability",
EuroBSDCon 2005 Conference, January 2005,
<https://citeseerx.ist.psu.edu/viewdoc/
download?doi=10.1.1.91.4542&rep=rep1&type=pdf>.
[SUSE2011] Meissner, M., "[security-announce] SUSE Security
Announcement: Linux kernel security update (SUSE-
SA:2011:046)", message to the openSUSE Security Announce
mailing list, 13 December 2011,
<https://lists.opensuse.org/opensuse-security-
announce/2011-12/msg00011.html>.
[TCPT-uptime]
McDanel, B., "TCP Timestamping - Obtaining System Uptime
Remotely", message to the Bugtraq mailing list, March
2001, <https://seclists.org/bugtraq/2001/Mar/182>.
[Ubuntu2011]
Ubuntu, "USN-1253-1: Linux kernel vulnerabilities",
November 2011,
<https://ubuntu.com/security/notices/USN-1253-1>.
[USCERT2001]
CERT CC, "Multiple TCP/IP implementations may use
statistically predictable initial sequence numbers",
Vulnerability Note VU#498440, March 2001,
<https://www.kb.cert.org/vuls/id/498440>.
[Vixie1995]
Vixie, P., "DNS and BIND Security Issues", 5th Usenix
Security Symposium, June 1995, <https://www.usenix.org/leg
acy/publications/library/proceedings/security95/
full_papers/vixie.pdf>.
[VU-800113]
CERT/CC, "Multiple DNS implementations vulnerable to cache
poisoning", Vulnerability Note VU#800113, July 2008,
<https://www.kb.cert.org/vuls/id/800113>.
[Wright1994]
Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
The Implementation", Addison-Wesley, February 1995.
[Zalewski2001]
Zalewski, M., "Strange Attractors and TCP/IP Sequence
Number Analysis (2001)", March 2001,
<https://lcamtuf.coredump.cx/oldtcp/tcpseq.html>.
[Zalewski2002]
Zalewski, M., "Strange Attractors and TCP/IP Sequence
Number Analysis - One Year Later (2002)", 2002,
<https://lcamtuf.coredump.cx/newtcp/>.
[Zalewski2003]
Zalewski, M., "A new TCP/IP blind data injection
technique?", December 2003,
<https://lcamtuf.coredump.cx/ipfrag.txt>.
The authors would like to thank (in alphabetical order) Bernard Aboba, Dave Crocker, Spencer Dawkins, Theo de Raadt, Sara Dickinson, Guillermo Gont, Christian Huitema, Colin Perkins, Vincent Roca, Kris Shrishak, Joe Touch, Brian Trammell, and Christopher Wood for providing valuable comments on earlier versions of this document.
著者は、（アルファベット順に）バーナード・アボバ、デイブ・クロッカー、スペンサー・ドーキンス、テオ・デ・ラードト、サラ・ディキンソン、ギレルモ・ゴント、クリスチャン・フイテマ、コリン・パーキンス、ヴィンセント・ロカ、クリス・シュリシャク、ジョー・タッチ、ブライアン・トラメル、そしてキリストファーこのドキュメントの以前のバージョンに貴重なコメントを提供するためのWood。
The authors would like to thank (in alphabetical order) Steven Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson for providing valuable comments on [draft-gont-predictable-numeric-ids-03], on which this document is based.
著者は、（アルファベット順に）Steven Bellovin、Joseph Lorenzo Hall、Gre Norcie、Martin Thomsonに感謝したいと思います。
Section 4.2 of this document borrows text from [RFC6528], authored by Fernando Gont and Steven Bellovin.
このドキュメントのセクション4.2は、Fernando GontとSteven Bellovinが執筆した[RFC6528]からテキストを借用しています。
The authors would like to thank Sara Dickinson and Christopher Wood for their guidance during the publication process of this document.
著者は、この文書の公開プロセス中のガイダンスについて、Sara DickinsonとChristopher Woodに感謝したいと思います。
The authors would like to thank Diego Armando Maradona for his magic and inspiration.
著者は、ディエゴ・アルマンド・マラドーナの魔法とインスピレーションに感謝したいと思います。
Fernando Gont
SI6 Networks
Segurola y Habana
4310 7mo piso
Ciudad Autonoma de Buenos Aires
Argentina
Email: fgont@si6networks.com
URI: https://www.si6networks.com
Ivan Arce
Quarkslab
Segurola y Habana
4310 7mo piso
Ciudad Autonoma de Buenos Aires
Argentina
Email: iarce@quarkslab.com
URI: https://www.quarkslab.com