[要約] この文書は、IETFプロトコルで使用されるさまざまな種類の「一時的な数値識別子」のセキュリティとプライバシーへの影響を分析し、相互運用性要件とその要件を満たさない場合の関連する障害の深刻度に基づいてそれらを分類しようとします。その後、各識別子カテゴリーの相互運用性要件を満たすために使用できる可能性のあるアルゴリズムに関するアドバイスを提供し、負のセキュリティとプライバシーへの影響を最小限に抑えながら、プロトコル設計者やプロトコル実装者にガイダンスを提供します。最後に、実際の実装で使用されているいくつかのアルゴリズムを説明し、一時的な数値識別子を生成するために使用されるセキュリティとプライバシーの特性を分析します。この文書は、IRTFのPrivacy Enhancements and Assessments Research Group（PEARG）の製品です。
Internet Research Task Force (IRTF) F. Gont
Request for Comments: 9415 SI6 Networks
Category: Informational I. Arce
ISSN: 2070-1721 Quarkslab
July 2023
This document performs an analysis of the security and privacy implications of different types of "transient numeric identifiers" used in IETF protocols and tries to categorize them based on their interoperability requirements and their associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier category while minimizing the negative security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers and analyzes their security and privacy properties. 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/rfc9415.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9415で取得できます。
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
5. Protocol Failure Severity
6. Categorizing Transient Numeric Identifiers
7. Common Algorithms for Transient Numeric Identifier Generation
7.1. Category #1: Uniqueness (Soft Failure)
7.2. Category #2: Uniqueness (Hard Failure)
7.3. Category #3: Uniqueness, Stable within Context (Soft
Failure)
7.4. Category #4: Uniqueness, Monotonically Increasing within
Context (Hard Failure)
8. Common Vulnerabilities Associated with Transient Numeric
Identifiers
8.1. Network Activity Correlation
8.2. Information Leakage
8.3. Fingerprinting
8.4. Exploitation of the Semantics of Transient Numeric
Identifiers
8.5. Exploitation of Collisions of Transient Numeric Identifiers
8.6. Exploitation of Predictable Transient Numeric Identifiers
for Injection Attacks
8.7. Cryptanalysis
9. Vulnerability Assessment of Transient Numeric Identifiers
9.1. Category #1: Uniqueness (Soft Failure)
9.2. Category #2: Uniqueness (Hard Failure)
9.3. Category #3: Uniqueness, Stable within Context (Soft
Failure)
9.4. Category #4: Uniqueness, Monotonically Increasing within
Context (Hard Failure)
10. IANA Considerations
11. Security Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Algorithms and Techniques with Known Issues
A.1. Predictable Linear Identifiers Algorithm
A.2. Random-Increments Algorithm
A.3. Reusing Identifiers Across Different Contexts
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.
ネットワーキングプロトコルは、IPv4およびIPv6識別値[RFC0791] [RFC8200]、IPv6インターフェイス識別子（IID）[RFC4291]、輸送中間ムラーポート[RFC6056]、TCP初期など、さまざまなプロトコルオブジェクトのさまざまな過渡数値識別子を採用しています。シーケンス番号（ISNS）[RFC9293]、NTP参照ID（REFIDS）[RFC5905]、およびDNS IDS [RFC1035]。これらの識別子には通常、特定の要件（特定の期間中の単一性など）があり、そのような要件が満たされない場合、否定的な相互運用性の意味と関連する障害の重大度をもたらさないように満たさなければなりません。
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 [RFC9414].
30年以上にわたり、IETFプロトコルの多数の実装がさまざまな攻撃の対象となり、サービス拒否（DOS）またはデータインジェクションから、広範な監視に利用できる情報漏れに至るまでの影響があります[RFC7258]。これらの問題の根本的な原因は、多くの場合、このようなプロトコルにおける一時的な数値識別子の選択が不十分であり、通常は不十分または誤解を招く仕様の結果です。一般に、特定の一時的な数値識別子の相互運用性要件を満たすことができるアルゴリズムを識別することは些細なことですが、前述のプロトコルのセキュリティおよび/またはプライバシー特性に悪影響を与えることなくそうすることは、エラーが発生しやすいという経験的証拠が存在します[RFC9414]。
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.
最近の履歴は、新しいプロトコルが標準化されているか、新しいプロトコルの実装が生成された場合、関連する一過性の数値識別子のセキュリティとプライバシーのプロパティが見落とされる傾向があり、そのような識別子を生成するための不適切なアルゴリズムは、実装者によって提案されるか、実装者によって選択されていることを示しています。。その結果、この分野でのアドバイスが保証されます。
We note that the use of cryptographic techniques may readily mitigate some of the issues arising from predictable transient numeric identifiers. For example, cryptographic authentication can readily mitigate data injection attacks even in the presence of predictable transient numeric identifiers (such as "sequence numbers"). However, use of flawed algorithms (such as global counters) for generating transient numeric identifiers could still result in information leakages even when cryptographic techniques are employed.
暗号化技術の使用は、予測可能な過渡数値識別子から生じる問題のいくつかを容易に軽減する可能性があることに注意してください。たとえば、暗号化認証は、予測可能な一時的な数値識別子（「シーケンス番号」など）が存在する場合でも、データインジェクション攻撃を容易に軽減できます。ただし、一時的な数値識別子を生成するための欠陥のあるアルゴリズム（グローバルカウンターなど）の使用は、暗号化手法が採用されている場合でも、情報漏れをもたらす可能性があります。
This document contains a non-exhaustive survey of transient numeric identifiers employed in various IETF protocols and aims to categorize such identifiers based on their interoperability requirements and the associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each category while minimizing negative security and privacy implications. Finally, it analyzes several algorithms that have been employed in real implementations to meet such requirements and analyzes their security and privacy properties.
このドキュメントには、さまざまなIETFプロトコルで採用されている過渡数値識別子の非網羅的な調査が含まれており、そのような要件が満たされていない場合の相互運用性要件と関連する障害の重大度に基づいて、そのような識別子を分類することを目的としています。その後、否定的なセキュリティとプライバシーへの影響を最小限に抑えながら、各カテゴリの相互運用性要件を満たすために採用できる可能性のあるアルゴリズムに関するアドバイスを提供します。最後に、このような要件を満たすために実際の実装で採用されているいくつかのアルゴリズムを分析し、セキュリティとプライバシーのプロパティを分析します。
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 (see, e.g., [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]を参照）。さまざまな一時的な数値識別子には、プロトコルでの特定の使用に応じて、追加の要件またはプロパティがある場合があることに注意してください。上記の識別プロパティを満たすプロトコル仕様のデータオブジェクトを参照するための一般的な用語として、「過渡数値識別子」（または単に「数値識別子」または「識別子」）を一般的な用語として使用します。
Failure Severity:
失敗の重大度：
The interoperability consequences of a failure to comply with the interoperability requirements of a given identifier. Severity considers the worst potential consequence of a failure, determined by the system damage and/or time lost to repair the failure. In this document, we define two types of failure severity: "soft failure" and "hard failure".
特定の識別子の相互運用性要件に準拠しなかったことの相互運用性の結果。重大度は、障害の修復のために失われたシステムの損傷および/または時間によって決定される、失敗の最悪の潜在的な結果を考慮します。このドキュメントでは、2種類の障害の重大度を定義します。「ソフト障害」と「困難な障害」です。
Soft Failure:
ソフト障害：
A recoverable condition in which a protocol does not operate in the prescribed manner but normal operation can be resumed automatically in a short period of time. For example, a simple packet-loss event that is subsequently recovered with a packet retransmission can be considered a soft failure.
プロトコルが規定の方法で動作しないが、通常の操作は短期間で自動的に再開できる回復可能な条件。たとえば、パケットの再送信でその後回復される単純なパケットロスイベントは、ソフト障害と見なすことができます。
Hard Failure:
困難な失敗：
A non-recoverable condition in which a protocol does not operate in the prescribed manner or it operates with excessive degradation of service. For example, an established TCP connection that is aborted due to an error condition constitutes, from the point of view of the transport protocol, a hard failure, since it enters a state from which normal operation cannot be resumed.
プロトコルが規定された方法で動作しないか、サービスの過度の劣化で動作することのない非回復不可能な条件。たとえば、輸送プロトコルの観点からは、通常の操作が再開できない状態に入るため、輸送プロトコルの観点からは、エラー条件のために中止される確立されたTCP接続が構成されます。
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初期シーケンス数ランダム化を実装していません。
Section 2 defines the concept of "failure severity", along with two types of failure severities that we employ throughout this document: soft and hard.
セクション2では、このドキュメント全体で採用する2種類の障害の重大度、ソフトアンドハードとともに、「故障の重大度」の概念を定義しています。
Our analysis of the severity of a failure is performed from the point of view of the protocol in question. However, the corresponding severity on the upper protocol (or application) might not be the same as that of the protocol in question. For example, a TCP connection that is aborted might or might not result in a hard failure of the upper application, i.e., if the upper application can establish a new TCP connection without any impact on the application, a hard failure at the TCP protocol may have no severity at the application layer. On the other hand, if a hard failure of a TCP connection results in excessive degradation of service at the application layer, it will also result in a hard failure at the application.
障害の重症度の分析は、問題のプロトコルの観点から実行されます。ただし、上部プロトコル（またはアプリケーション）の対応する重大度は、問題のプロトコルの重大度と同じではない場合があります。たとえば、中止されたTCP接続は、アプリケーションの上部の困難な障害につながる可能性があるか、そうでない可能性があります。つまり、アプリケーションがアプリケーションに影響を与えることなく新しいTCP接続を確立できる場合、TCPプロトコルの困難な障害はアプリケーションレイヤーに重大度はありません。一方、TCP接続の困難な障害により、アプリケーション層でのサービスの過度の劣化が生じると、アプリケーションでも困難な障害が発生します。
This section includes a non-exhaustive survey of transient numeric identifiers, which are representative of all the possible combinations of interoperability requirements and failure severities found in popular protocols of different layers. Additionally, it proposes a number of categories that can accommodate these identifiers based on their interoperability requirements and their associated failure severity (soft or hard).
このセクションには、異なる層の一般的なプロトコルで見られる相互運用性要件と障害の重大度のすべての可能な組み合わせを代表する一時的な数値識別子の非網羅的な調査が含まれています。さらに、相互運用性要件と関連する障害の重大度（ソフトまたはハード）に基づいて、これらの識別子に対応できる多くのカテゴリを提案します。
NOTE: All other transient numeric identifiers that were analyzed as part of this effort could be accommodated into one of the existing categories from Table 1.
注：この取り組みの一部として分析された他のすべての過渡数値識別子は、表1の既存のカテゴリの1つに対応できます。
+===============+===============================+==================+
| Identifier | Interoperability Requirements | Failure Severity |
+===============+===============================+==================+
| IPv6 ID | Uniqueness (for IPv6 address | Soft/Hard (1) |
| | pair) | |
+---------------+-------------------------------+------------------+
| IPv6 IID | Uniqueness (and stable within | Soft (3) |
| | IPv6 prefix) (2) | |
+---------------+-------------------------------+------------------+
| TCP ISN | Monotonically increasing (4) | Hard (4) |
+---------------+-------------------------------+------------------+
| TCP initial | Monotonically increasing (5) | Hard (5) |
| timestamp | | |
+---------------+-------------------------------+------------------+
| TCP ephemeral | Uniqueness (for connection | Hard |
| port | ID) | |
+---------------+-------------------------------+------------------+
| IPv6 Flow | Uniqueness | None (6) |
| Label | | |
+---------------+-------------------------------+------------------+
| DNS ID | Uniqueness | None (7) |
+---------------+-------------------------------+------------------+
Table 1: Survey of Transient Numeric Identifiers
表1：一時的な数値識別子の調査
NOTE:
注記：
(1) While a single collision of IPv6 Identification (ID) values would simply lead to a single packet drop (and hence, a "soft" failure), repeated collisions at high data rates might result in self-propagating collisions of IPv6 IDs, thus possibly leading to a hard failure [RFC4963].
(1) IPv6識別（ID）値の単一の衝突は、単に単一のパケットドロップ（したがって、「ソフト」障害）につながるだけですが、高いデータレートでの衝突を繰り返すと、IPv6 IDの自己伝播衝突が発生する可能性があり、したがって、おそらくリードする可能性があります。困難な障害[RFC4963]。
(2) While the interoperability requirements are simply that the Interface Identifier results in a unique IPv6 address, for operational reasons, it is typically desirable that the resulting IPv6 address (and hence, the corresponding Interface Identifier) be stable within each network [RFC7217] [RFC8064].
(2) 相互運用性の要件は、単にインターフェイス識別子が一意のIPv6アドレスをもたらすということですが、運用上の理由から、結果のIPv6アドレス（したがって、対応するインターフェイス識別子）が各ネットワーク内で安定することが通常望ましい[RFC7217] [RFC8064]。
(3) While IPv6 Interface Identifiers must result in unique IPv6 addresses, IPv6 Duplicate Address Detection (DAD) [RFC4862] allows for the detection of duplicate addresses, and hence, such Interface Identifier collisions can be recovered.
(3) IPv6インターフェイス識別子は一意のIPv6アドレスをもたらす必要がありますが、IPv6の重複アドレス検出（DAD）[RFC4862]により、複製アドレスの検出が可能になるため、そのようなインターフェイス識別子衝突を回復できます。
(4) In theory, there are no interoperability requirements for TCP Initial Sequence Numbers (ISNs), since the TIME-WAIT state and TCP's "quiet time" concept take care of old segments from previous incarnations of a connection. However, a widespread optimization allows for a new incarnation of a previous connection to be created if the ISN of the incoming SYN is larger than the last sequence number seen in that direction for the previous incarnation of the connection. Thus, monotonically increasing TCP ISNs allow for such optimization to work as expected [RFC6528] and can help avoid connection-establishment failures.
(4) 理論的には、TCPの初期シーケンス数（ISNS）の相互運用性要件はありません。これは、時間とTCPの「静かな時間」の概念が、以前の接続の化身から古いセグメントを処理するためです。ただし、広範囲にわたる最適化により、入ってくるSynのISNが接続の前の化身でその方向に見られる最後のシーケンス数よりも大きい場合、以前の接続の新しい化身が作成されます。したがって、単調に増加するTCP ISNにより、このような最適化が期待どおりに動作し[RFC6528]、接続確立の障害を回避するのに役立ちます。
(5) Strictly speaking, there are no interoperability requirements for the *initial* TCP timestamp employed by a TCP instance (i.e., the TS Value (TSval) in a segment with the SYN bit set). However, some TCP implementations allow a new incarnation of a previous connection to be created if the TSval of the incoming SYN is larger than the last TSval seen in that direction for the previous incarnation of the connection (please see [RFC6191]). Thus, monotonically increasing TCP initial timestamps (across connections to the same endpoint) allow for such optimization to work as expected [RFC6191] and can help avoid connection-establishment failures.
(5) 厳密に言えば、TCPインスタンス（つまり、SYNビットセットのセグメントにTS値（TSVAL））で採用されている *初期 * TCPタイムスタンプの相互運用性要件はありません。ただし、一部のTCP実装により、入ってくるSynのTsvalが、接続の以前の化身についてその方向に見られる最後のTsvalよりも大きい場合、以前の接続の新しい化身を作成できます（[RFC6191]を参照）。したがって、単調に増加するTCP初期タイムスタンプ（同じエンドポイントへの接続全体）により、このような最適化が期待どおりに動作し[RFC6191]、接続確立の障害を回避するのに役立ちます。
(6) The IPv6 Flow Label [RFC6437], along with the IPv6 Source Address and the IPv6 Destination Address, is typically employed for load sharing [RFC7098]. Reuse of a Flow Label value for the same set {Source Address, Destination Address} would typically cause both flows to be multiplexed onto the same link. However, as long as this does not occur deterministically, it will not result in any negative implications.
(6) IPv6フローラベル[RFC6437]は、IPv6ソースアドレスとIPv6宛先アドレスとともに、通常、負荷共有に使用されます[RFC7098]。同じセット{ソースアドレス、宛先アドレス}のフローラベル値の再利用により、通常、両方のフローが同じリンクに多重化されます。ただし、これが決定論的に発生しない限り、否定的な意味をもたらすことはありません。
(7) DNS IDs are employed, together with the IP Source Address, the IP Destination Address, the transport-protocol Source Port, and the transport-protocol Destination Port, to match DNS requests and responses. However, since an implementation knows which DNS requests were sent for that set of {IP Source Address, IP Destination Address, transport-protocol Source Port, transport-protocol Destination Port, DNS ID}, a collision of DNS IDs would result, if anything, in a small performance penalty (the response would nevertheless be discarded when it is found that it does not answer the query sent in the corresponding DNS query).
(7) DNS IDは、IPソースアドレス、IP宛先アドレス、Transport-Protocolソースポート、およびDNSリクエストと応答を一致させるために、Transport-Protocol Destinationポートとともに採用されています。ただし、実装が{IPソースアドレス、IP宛先アドレス、Transport-Protocol Source Port、Transport-Protocol Destination Port、DNS ID}のセットに対してどのDNS要求が送信されたかを知っているため、DNS IDの衝突が生じます。、小さなパフォーマンスペナルティで（それにもかかわらず、対応するDNSクエリで送信されたクエリに応答しないことがわかった場合、応答は破棄されます）。
Based on the survey above, we can categorize identifiers as follows:
上記の調査に基づいて、識別子を次のように分類できます。
+=======+======================================+====================+
| Cat # | Category | Sample Numeric |
| | | IDs |
+=======+======================================+====================+
| 1 | Uniqueness (soft failure) | IPv6 Flow L., DNS |
| | | ID |
+-------+--------------------------------------+--------------------+
| 2 | Uniqueness (hard failure) | IPv6 ID, TCP |
| | | ephemeral port |
+-------+--------------------------------------+--------------------+
| 3 | Uniqueness, stable within context | IPv6 IID |
| | (soft failure) | |
+-------+--------------------------------------+--------------------+
| 4 | Uniqueness, monotonically increasing | TCP ISN, TCP |
| | within context (hard failure) | initial timestamp |
+-------+--------------------------------------+--------------------+
Table 2: Identifier Categories
表2：識別子カテゴリ
We note that Category #4 could be considered a generalized case of Category #3, in which a monotonically increasing element is added to a stable (within context) element, such that the resulting identifiers are monotonically increasing within a specified context. That is, the same algorithm could be employed for both #3 and #4, given appropriate parameters.
カテゴリ＃4は、カテゴリ＃3の一般化されたケースと見なされる可能性があることに注意してください。このケースでは、単調に増加する要素が安定した（コンテキスト内）要素に追加され、結果の識別子が指定されたコンテキスト内で単調に増加しています。つまり、適切なパラメーターを考慮して、＃3と＃4の両方に同じアルゴリズムを使用できます。
The following subsections describe some sample algorithms that can be employed for generating transient numeric identifiers for each of the categories above while mitigating the vulnerabilities analyzed in Section 8 of this document.
次のサブセクションでは、このドキュメントのセクション8で分析された脆弱性を緩和しながら、上記の各カテゴリの過渡数値識別子を生成するために使用できるサンプルアルゴリズムについて説明します。
All of the variables employed in the algorithms of the following subsections are of "unsigned integer" type, except for the "retry" variable, which is of (signed) "integer" type.
次のサブセクションのアルゴリズムで採用されているすべての変数は、（署名された）「整数」タイプである「retry」変数を除き、「署名されていない整数」タイプのものです。
The requirement of uniqueness with a soft failure severity can be complied with a Pseudorandom Number Generator (PRNG).
ソフト障害の重症度を備えた一意性の要件は、擬似ランダム数ジェネレーター（PRNG）で遵守することができます。
NOTE: Please see [RFC4086] regarding randomness requirements for security.
注：セキュリティのランダム性要件については、[RFC4086]を参照してください。
While most systems provide access to a PRNG, many of such PRNG implementations are not cryptographically secure and therefore might be statistically biased or subject to adversarial influence. For example, ISO C [C11] rand(3) implementations are not cryptographically secure.
ほとんどのシステムはPRNGへのアクセスを提供しますが、このようなPRNG実装の多くは暗号化されていないため、統計的に偏っているか、敵対的な影響を受けられる可能性があります。たとえば、ISO C [C11] RAND（3）の実装は暗号化的に安全ではありません。
NOTE: Section 7.1 ("Uniform Deviates") of [Press1992] discusses the underlying issues affecting ISO C [C11] rand(3) implementations.
注：[Press1992]のセクション7.1（ "均一な逸脱"）は、ISO C [C11] RAND（3）の実装に影響する根本的な問題について説明しています。
On the other hand, a number of systems provide an interface to a Cryptographically Secure PRNG (CSPRNG) [RFC4086] [RFC8937], which guarantees high entropy, unpredictability, and good statistical distribution of the random values generated. For example, GNU/ Linux's CSPRNG implementation is available via the getentropy(3) interface [GETENTROPY], while OpenBSD's CSPRNG implementation is available via the arc4random(3) and arc4random_uniform(3) interfaces [ARC4RANDOM]. Where available, these CSPRNGs should be preferred over, e.g., POSIX [POSIX] random(3) or ISO C [C11] rand(3) implementations.
一方、多くのシステムは、発生したランダム値の高いエントロピー、予測不能、および良好な統計分布を保証する、暗号化されたPRNG（CSPRNG）[RFC4086] [RFC8937] [RFC4086] [RFC8937]へのインターフェイスを提供します。たとえば、GNU/ LinuxのCSPRNG実装は、GetEntropy（3）インターフェイス[GetEntropy]を介して利用できますが、OpenBSDのCSPRNG実装はArc4random（3）およびArc4random_uniform（3）インターフェイス[Arc4random]を介して利用可能です。利用可能な場合、これらのcsprngは、例えば、posix [posix]ランダム（3）またはISO C [C11] rand（3）の実装よりも優先される必要があります。
In scenarios where a CSPRNG is not readily available to select transient numeric identifiers of Category #1, a security and privacy assessment of employing a regular PRNG should be performed, supporting the implementation decision.
CSPRNGがカテゴリ＃1の一時的な数値識別子を選択できるシナリオでは、通常のPRNGを採用するセキュリティとプライバシー評価を実行し、実装決定をサポートする必要があります。
NOTE: [Aumasson2018], [Press1992], and [Knuth1983] discuss theoretical and practical aspects of pseudorandom number generation and provide guidance on how to evaluate PRNGs.
注：[Aumasson2018]、[Press1992]、および[Knuth1983]は、擬似ランダム数生成の理論的および実用的な側面について議論し、PRNGを評価する方法に関するガイダンスを提供します。
We note that, since the premise is that collisions of transient numeric identifiers of this category only lead to soft failures, in many cases, the algorithm might not need to check the suitability of a selected identifier (i.e., the suitable_id() function, described below, could always return "true").
前提は、このカテゴリの一時的な数値識別子の衝突がソフト障害につながるだけであるため、多くの場合、アルゴリズムは選択した識別子の適合性を確認する必要がないかもしれないことに注意してください（つまり、適切な_ID（）関数は、説明されています。以下では、常に「真」を返すことができます）。
In scenarios where, e.g., simultaneous use of a given numeric identifier is undesirable and an implementation detects such condition, the implementation may opt to select the next available identifier in the same sequence or select another random number. Section 7.1.1 is an implementation of the former strategy, while Section 7.1.2 is an implementation of the latter. Typically, the algorithm in Section 7.1.2 results in a more uniform distribution of the generated transient numeric identifiers. However, for transient numeric identifiers where an implementation typically keeps local state about unsuitable/used identifiers, the algorithm in Section 7.1.2 may require many more iterations than the algorithm in Section 7.1.1 to generate a suitable transient numeric identifier. This will usually be affected by the current usage ratio of transient numeric identifiers (i.e., the number of numeric identifiers considered suitable / total number of numeric identifiers) and other parameters. Therefore, in such cases, many implementations tend to prefer the algorithm in Section 7.1.1 over the algorithm in Section 7.1.2.
たとえば、特定の数値識別子の同時使用が望ましくなく、実装がそのような条件を検出するシナリオでは、実装が同じシーケンスで次の使用可能な識別子を選択するか、別の乱数を選択することを選択する場合があります。セクション7.1.1は以前の戦略の実装であり、セクション7.1.2は後者の実装です。通常、セクション7.1.2のアルゴリズムは、生成された過渡数値識別子のより均一な分布をもたらします。ただし、実装が通常不適切/使用識別子に関するローカル状態を維持する過渡数値識別子の場合、セクション7.1.2のアルゴリズムは、セクション7.1.1のアルゴリズムよりも多くの反復を必要とする場合があります。これは通常、過渡数値識別子の現在の使用率（つまり、適切な /数値識別子の総数と見なされる数値識別子の数）およびその他のパラメーターの影響を受けます。したがって、そのような場合、多くの実装は、セクション7.1.2のアルゴリズムよりもセクション7.1.1のアルゴリズムを好む傾向があります。
/* Transient Numeric ID selection function */
id_range = max_id - min_id + 1;
next_id = min_id + (random() % id_range);
retry = id_range;
do {
if (suitable_id(next_id)) {
return next_id;
}
if (next_id == max_id) {
next_id = min_id;
} else {
next_id++;
}
retry--;
} while (retry > 0);
return ERROR;
NOTE:
注記：
random() is a PRNG that returns a pseudorandom unsigned integer number of appropriate size. Beware that "adapting" the length of the output of random() with a modulo operator (e.g., C language's "%") may change the distribution of the PRNG. To preserve a uniform distribution, the rejection sampling technique [Romailler2020] can be used.
RANDAM（）は、適切なサイズの擬似ランダム整数整数数を返すPRNGです。random（）の出力の長さをModulo演算子（C Languageの「％」など）に「適応」すると、PRNGの分布が変更される可能性があることに注意してください。均一な分布を保持するために、拒絶サンプリング手法[Romailler2020]を使用できます。
suitable_id() is a function that checks, if possible and desirable, whether a candidate numeric identifier is suitable (e.g., whether it is in use or has been recently employed). Depending on how/where the numeric identifier is used, it may or may not be possible (or even desirable) to check whether the numeric identifier is suitable.
surable_id（）は、候補数値識別子が適切かどうか（例えば、使用中であるか、最近採用されているか）かどうかを、可能であれば望ましいチェックと望ましい関数です。数値識別子の使用方法/場所に応じて、数値識別子が適切かどうかを確認することができる（または望ましい）可能性がある場合とそうでない場合があります。
All the variables (in this algorithm and all the others algorithms discussed in this document) are unsigned integers.
すべての変数（このアルゴリズムおよびこのドキュメントで説明されている他のすべてのアルゴリズム）は、署名されていない整数です。
When an identifier is found to be unsuitable, this algorithm selects the next available numeric identifier in sequence. Thus, even when this algorithm selects numeric identifiers randomly, it is biased towards the first available numeric identifier after a sequence of unavailable numeric identifiers. For example, if this algorithm is employed for transport-protocol ephemeral port randomization [RFC6056] and the local list of unsuitable port numbers (e.g., registered port numbers that should not be used for ephemeral ports) is significant, an attacker may actually have a significantly better chance of guessing an ephemeral port number.
識別子が不適切であることがわかった場合、このアルゴリズムは順番に次に利用可能な数値識別子を選択します。したがって、このアルゴリズムが数値識別子をランダムに選択した場合でも、利用できない数値識別子のシーケンスの後、最初に利用可能な数値識別子にバイアスされます。たとえば、このアルゴリズムがトランスポートプロトコールの短命ポートランダム化[RFC6056]および不適切なポート番号のローカルリスト（たとえば、一時的なポートには使用すべきではない登録ポート番号など）に使用されている場合、攻撃者は実際に重要です。一時的なポート番号を推測する可能性が大幅に向上します。
Assuming the randomness requirements for the PRNG are met (see [RFC4086]), this algorithm does not suffer from any of the issues discussed in Section 8.
PRNGのランダム性要件が満たされていると仮定すると（[RFC4086]を参照）、このアルゴリズムはセクション8で説明されている問題のいずれにも悩まされません。
The following pseudocode illustrates another algorithm for selecting a random transient numeric identifier where, in the event a selected identifier is found to be unsuitable (e.g., already in use), another identifier is randomly selected:
次の擬似コードは、選択された識別子が不適切であることが判明した場合（すでに使用中）、別の識別子がランダムに選択されている場合、ランダムな一時的な数値識別子を選択するための別のアルゴリズムを示しています。
/* Transient Numeric ID selection function */
id_range = max_id - min_id + 1;
retry = id_range;
do {
next_id = min_id + (random() % id_range);
if (suitable_id(next_id)) {
return next_id;
}
retry--;
} while (retry > 0);
return ERROR;
NOTE:
注記：
random() is a PRNG that returns a pseudorandom unsigned integer number of appropriate size. Beware that "adapting" the length of the output of random() with a modulo operator (e.g., C language's "%") may change the distribution of the PRNG. To preserve a uniform distribution, the rejection sampling technique [Romailler2020] can be used.
RANDAM（）は、適切なサイズの擬似ランダム整数整数数を返すPRNGです。random（）の出力の長さをModulo演算子（C Languageの「％」など）に「適応」すると、PRNGの分布が変更される可能性があることに注意してください。均一な分布を保持するために、拒絶サンプリング手法[Romailler2020]を使用できます。
suitable_id() is a function that checks, if possible and desirable, whether a candidate numeric identifier is suitable (e.g., if it is not already in use). Depending on how/where the numeric identifier is used, it may or may not be possible (or even desirable) to check whether the numeric identifier is in use (or whether it has been recently employed).
satable_id（）は、候補数値識別子が適切かどうかを、可能であれば望ましい場合にチェックする関数です（たとえば、まだ使用されていない場合）。数値識別子の使用方法/場所に応じて、数値識別子が使用されているかどうか（または最近採用されているかどうか）を確認することが可能である場合とそうでない場合があります（または望ましい）。
When an identifier is found to be unsuitable, this algorithm selects another random numeric identifier. Thus, this algorithm might be unable to select a transient numeric identifier (i.e., return "ERROR"), even if there are suitable identifiers available, in cases where a large number of identifiers are found to be unsuitable (e.g., "in use").
識別子が不適切であることがわかった場合、このアルゴリズムは別のランダム数値識別子を選択します。したがって、このアルゴリズムは、適切な識別子が利用可能であっても、多数の識別子が不適切であることが判明した場合（例：「使用中」」と認められている場合に利用可能な適切な識別子がある場合でも、過渡数値識別子（つまり、「エラー」を返す）を選択できない場合があります。）。
Assuming the randomness requirements for the PRNG are met (see [RFC4086]), this algorithm does not suffer from any of the issues discussed in Section 8.
PRNGのランダム性要件が満たされていると仮定すると（[RFC4086]を参照）、このアルゴリズムはセクション8で説明されている問題のいずれにも悩まされません。
One of the most trivial approaches for generating a unique transient numeric identifier (with a hard failure severity) is to reduce the identifier reuse frequency by generating the numeric identifiers with a monotonically increasing function (e.g., linear). As a result, any of the algorithms described in Section 7.4 ("Category #4: Uniqueness, Monotonically Increasing within Context (Hard Failure)") can be readily employed for complying with the requirements of this transient numeric identifier category.
一意の一時的な数値識別子（硬質障害の重大度を持つ）を生成するための最も些細なアプローチの1つは、単調に増加する機能（例えば、線形）で数値識別子を生成することにより、識別子の再利用周波数を減らすことです。その結果、セクション7.4（ "カテゴリ＃4：一意性、コンテキスト内で単調に増加する（困難な障害）内で単独で増加する"）で説明したアルゴリズムは、この一時的な数値識別子カテゴリの要件に準拠するために容易に採用できます。
In cases where suitability (e.g., uniqueness) of the selected identifiers can be definitely assessed by the local system, any of the algorithms described in Section 7.1 ("Category #1: Uniqueness (Soft Failure)") can be readily employed for complying with the requirements of this numeric identifier category.
選択された識別子の適合性（例えば、単一性）をローカルシステムによって間違いなく評価できる場合、セクション7.1（「カテゴリ＃1：ユニークネス（ソフト障害）」）で説明したアルゴリズムを容易に採用することができます。この数値識別子カテゴリの要件。
NOTE: In the case of, e.g., TCP ephemeral ports or TCP ISNs, a transient numeric identifier that might seem suitable from the perspective of the local system might actually be unsuitable from the perspective of the remote system (e.g., because there is state associated with the selected identifier at the remote system). Therefore, in such cases, it is not possible to employ the algorithms from Section 7.1 ("Category #1: Uniqueness (Soft Failure)").
注：たとえば、TCP Ephemeral PortsまたはTCP ISNの場合、ローカルシステムの観点から適していると思われる一時的な数値識別子は、リモートシステムの観点からは実際には不適切ではない可能性があります（例えば、状態に関連する状態が関連するため、リモートシステムで選択された識別子を使用）。したがって、そのような場合、セクション7.1（「カテゴリ＃1：一意性（ソフト障害）」）からアルゴリズムを使用することはできません。
The goal of the following algorithm is to produce identifiers that are stable for a given context (identified by "CONTEXT") but that change when the aforementioned context changes.
次のアルゴリズムの目標は、特定のコンテキスト（「コンテキスト」で識別される）で安定した識別子を生成することですが、前述のコンテキストが変更されると変更されます。
In order to avoid storing the transient numeric identifiers computed for each CONTEXT in memory, the following algorithm employs a calculated technique (as opposed to keeping state in memory) to generate a stable transient numeric identifier for each given context.
メモリ内の各コンテキストに対して計算された過渡数値識別子を保存することを避けるために、次のアルゴリズムは（メモリ内に状態を維持するのではなく）計算された手法を採用して、指定された各コンテキストの安定した過渡数値識別子を生成します。
/* Transient Numeric ID selection function */
id_range = max_id - min_id + 1;
retry = 0;
do {
offset = F(CONTEXT, retry, secret_key);
next_id = min_id + (offset % id_range);
if (suitable_id(next_id)) {
return next_id;
}
retry++;
} while (retry <= MAX_RETRIES);
return ERROR;
NOTE:
注記：
CONTEXT is the concatenation of all the elements that define a given context.
コンテキストは、特定のコンテキストを定義するすべての要素の連結です。
F() is a pseudorandom function (PRF). It must not be computable from the outside (without knowledge of the secret key). F() must also be difficult to reverse, such that it resists attempts to obtain the secret key, even when given samples of the output of F() and knowledge or control of the other input parameters. F() should produce an output of at least as many bits as required for the transient numeric identifier. SipHash-2-4 (128-bit key, 64-bit output) [SipHash] and BLAKE3 (256-bit key, arbitrary-length output) [BLAKE3] are two possible options for F(). Alternatively, F() could be implemented with a keyed hash message authentication code (HMAC) [RFC2104]. HMAC-SHA-256 [FIPS-SHS] would be one possible option for such implementation alternative. Note: Use of HMAC-MD5 [RFC1321] or HMAC-SHA1 [FIPS-SHS] are not recommended for F() [RFC6151] [RFC6194]. The result of F() is no more secure than the secret key, and therefore, "secret_key" must be unknown to the attacker and must be of a reasonable length. "secret_key" must remain stable for a given CONTEXT, since otherwise, the numeric identifiers generated by this algorithm would not have the desired stability properties (i.e., stable for a given CONTEXT). In most cases, "secret_key" should be selected with a PRNG (see [RFC4086] for recommendations on choosing secrets) at an appropriate time and stored in stable or volatile storage (as necessary) for future use.
f（）は擬似ランダム関数（PRF）です。外部から計算可能であってはなりません（秘密の鍵の知識なし）。f（）も逆になるのが難しい必要があります。そのため、f（）の出力のサンプルと他の入力パラメーターの知識または制御のサンプルが与えられた場合でも、秘密の鍵を取得しようとします。f（）は、過渡数値識別子に必要な数のビットの出力を生成する必要があります。Siphash-2-4（128ビットキー、64ビット出力）[Siphash]およびBlake3（256ビットキー、任意の長さの出力）[Blake3]は、F（）の2つの可能なオプションです。あるいは、F（）は、キー付きハッシュメッセージ認証コード（HMAC）[RFC2104]で実装できます。HMAC-SHA-256 [FIPS-shs]は、このような実装の代替案の1つの可能なオプションです。注：HMAC-MD5 [RFC1321]またはHMAC-SHA1 [FIPS-SHS]の使用は、F（）[RFC6151] [RFC6194]には推奨されません。F（）の結果はシークレットキーほど安全ではないため、「Secret_Key」は攻撃者には知られていない必要があり、妥当な長さでなければなりません。「secret_key」は、特定のコンテキストでは安定したままでなければなりません。そうしないと、このアルゴリズムによって生成された数値識別子には、望ましい安定性特性がありません（つまり、特定のコンテキストでは安定します）。ほとんどの場合、適切な時間に「Secret_key」をPRNG（秘密の選択に関する推奨事項については[RFC4086]を参照）で選択し、将来の使用のために（必要に応じて）安定または揮発性の保管に保存する必要があります。
suitable_id() checks whether a candidate numeric identifier has suitable uniqueness properties.
satable_id（）候補数値識別子に適切な一意性プロパティがあるかどうかをチェックします。
In this algorithm, the function F() provides a stateless and stable per-CONTEXT offset, where CONTEXT is the concatenation of all the elements that define the given context.
このアルゴリズムでは、関数f（）は、文脈が指定されたコンテキストを定義するすべての要素の連結であるというステートレスで安定したコンテキストごとのオフセットを提供します。
For example, if this algorithm is expected to produce IPv6 IIDs that are unique per network interface and Stateless Address Autoconfiguration (SLAAC) prefix, CONTEXT should be the concatenation of, e.g., the network interface index and the SLAAC autoconfiguration prefix (please see [RFC7217] for an implementation of this algorithm for generation of stable IPv6 addresses).
たとえば、このアルゴリズムがネットワークインターフェイスごとに一意のIPv6 IIDを生成すると予想される場合、ステートレスアドレスAutoconfiguration（SLAAC）プレフィックスは、たとえば、ネットワークインターフェイスインデックスとSLAACオートコンチュレーションのプレフィックスの連結である必要があります（[RFC72177を参照してください。]安定したIPv6アドレスの生成のためのこのアルゴリズムの実装。
The result of F() is stored in the variable "offset", which may take any value within the storage type range, since we are restricting the resulting identifier to be in the range [min_id, max_id] in a similar way as in the algorithm described in Section 7.1.1.
f（）の結果は変数「オフセット」に保存されます。これは、結果の識別子を範囲[min_id、max_id]に制限しているため、ストレージタイプの範囲内で任意の値をとることがあります。セクション7.1.1で説明されているアルゴリズム。
As noted above, suitable_id() checks whether a candidate numeric identifier has suitable uniqueness properties. Collisions (i.e., an identifier that is not unique) are recovered by incrementing the "retry" variable and recomputing F(), up to a maximum of MAX_RETRIES times. However, recovering from collisions will usually result in identifiers that fail to remain constant for the specified context. This is normally acceptable when the probability of collisions is small, as in the case of, e.g., IPv6 IIDs resulting from SLAAC [RFC7217] [RFC8981].
上記のように、surtable_id（）は、候補数値識別子に適切な一意性特性があるかどうかをチェックします。衝突（つまり、一意ではない識別子）は、「再試行」変数を増やし、最大MAX_RETRIES時間までにf（）を再計算することにより回収されます。ただし、衝突から回復すると、通常、指定されたコンテキストで一定のままにならない識別子が生じます。これは通常、SLAAC [RFC7217] [RFC8981]に起因するIPv6 IIDなどの場合のように、衝突の確率が小さい場合に許容されます。
For obvious reasons, the transient numeric identifiers generated with this algorithm allow for network activity correlation and fingerprinting within "CONTEXT". However, this is essentially a design goal of this category of transient numeric identifiers.
明らかな理由から、このアルゴリズムで生成された過渡数値識別子は、「コンテキスト」内でネットワークアクティビティの相関とフィンガープリントを可能にします。ただし、これは本質的に、このカテゴリの過渡数値識別子の設計目標です。
One possible way of selecting unique monotonically increasing identifiers (per context) is to employ a per-context counter. Such an algorithm could be described as follows:
一意の単調に増加する識別子（コンテキストごと）を選択する1つの可能な方法は、コンテキストごとのカウンターを使用することです。このようなアルゴリズムは、次のように説明できます。
/* Transient Numeric ID selection function */
id_range = max_id - min_id + 1;
retry = id_range;
id_inc = increment() % id_range;
if( (next_id = lookup_counter(CONTEXT)) == ERROR){
next_id = min_id + random() % id_range;
}
do {
if ( (max_id - next_id) >= id_inc){
next_id = next_id + id_inc;
}
else {
next_id = min_id + id_inc - (max_id - next_id);
}
if (suitable_id(next_id)){
store_counter(CONTEXT, next_id);
return next_id;
}
retry = retry - id_inc;
} while (retry > 0);
return ERROR;
NOTE:
注記：
CONTEXT is the concatenation of all the elements that define a given context.
コンテキストは、特定のコンテキストを定義するすべての要素の連結です。
increment() returns a small integer that is employed to increment the current counter value to obtain the next transient numeric identifier. This value must be larger than or equal to 1, and much smaller than the number of possible values for the numeric identifiers (i.e., "id_range"). Most implementations of this algorithm employ a constant increment of 1. Using a value other than 1 can help mitigate some information leakages (please see below) at the expense of a possible increase in the numeric identifier reuse frequency. The code above makes sure that the increment employed in the algorithm (id_inc) is always smaller than the number of possible values for the numeric identifiers (i.e., "max_id - min_d + 1"). However, as noted above, this value must also be much smaller than the number of possible values for the numeric identifiers.
increment（）は、次の過渡数値識別子を取得するために現在のカウンター値を増分するために使用される小整数を返します。この値は1以上、数値識別子の可能な値の数よりもはるかに小さい必要があります（つまり、「ID_RANGE」）。このアルゴリズムのほとんどの実装では、1以外の値を使用すると、数値識別子の再利用頻度が増加する可能性があるため、情報の漏れ（以下を参照）を軽減することができます。上記のコードは、アルゴリズム（ID_INC）で採用されている増分が、数値識別子の可能な値の数よりも常に小さいことを確認します（つまり、 "max_id -min_d 1"）。ただし、上記のように、この値は、数値識別子の可能な値の数よりもはるかに少ない必要があります。
lookup_counter() is a function that returns the current counter for a given context or an error condition if that counter does not exist.
lookup_counter（）は、そのカウンターが存在しない場合、特定のコンテキストまたはエラー条件に対して現在のカウンターを返す関数です。
random() is a PRNG that returns a pseudorandom unsigned integer number of appropriate size. Beware that "adapting" the length of the output of random() with a modulo operator (e.g., C language's "%") may change the distribution of the PRNG. To preserve a uniform distribution, the rejection sampling technique [Romailler2020] can be used.
RANDAM（）は、適切なサイズの擬似ランダム整数整数数を返すPRNGです。random（）の出力の長さをModulo演算子（C Languageの「％」など）に「適応」すると、PRNGの分布が変更される可能性があることに注意してください。均一な分布を保持するために、拒絶サンプリング手法[Romailler2020]を使用できます。
store_counter() is a function that saves a counter value for a given context.
store_counter（）は、特定のコンテキストのカウンター値を保存する関数です。
suitable_id() checks whether a candidate numeric identifier has suitable uniqueness properties.
satable_id（）候補数値識別子に適切な一意性プロパティがあるかどうかをチェックします。
Essentially, whenever a new identifier is to be selected, the algorithm checks whether a counter for the corresponding context exists. If it does, the value of such counter is incremented to obtain the new transient numeric identifier, and the counter is updated. If no counter exists for such context, a new counter is created and initialized to a random value and used as the selected transient numeric identifier. This algorithm produces a per-context counter, which results in one monotonically increasing function for each context. Since each counter is initialized to a random value, the resulting values are unpredictable by an off-path attacker.
基本的に、新しい識別子を選択する場合はいつでも、アルゴリズムは、対応するコンテキストのカウンターが存在するかどうかをチェックします。もしそうなら、そのようなカウンターの値は、新しい過渡数値識別子を取得するために増分され、カウンターが更新されます。そのようなコンテキストにカウンターが存在しない場合、新しいカウンターが作成され、ランダム値に初期化され、選択された過渡数値識別子として使用されます。このアルゴリズムは、コンテキストごとのカウンターを生成し、各コンテキストで単調に増加する機能を1つ増やします。各カウンターはランダム値に初期化されるため、結果の値はオフパス攻撃者が予測不可能です。
The choice of id_inc has implications on both the security and privacy properties of the resulting identifiers and also on the corresponding interoperability properties. On one hand, minimizing the increments generally minimizes the identifier reuse frequency, albeit at increased predictability. On the other hand, if the increments are randomized, predictability of the resulting identifiers is reduced, and the information leakage produced by global constant increments is mitigated. However, using larger increments than necessary can result in higher numeric identifier reuse frequency.
ID_INCの選択には、結果の識別子のセキュリティプロパティとプライバシープロパティの両方、および対応する相互運用性プロパティにも影響があります。一方では、増分を最小化すると、予測可能性が向上しているにもかかわらず、識別子の再利用頻度を最小限に抑えます。一方、増分がランダム化されている場合、結果の識別子の予測可能性が低下し、グローバルな一定の増分によって生成される情報漏れが軽減されます。ただし、必要以上に増分を使用すると、数値識別子の再利用頻度が高くなる可能性があります。
This algorithm has the following drawbacks:
このアルゴリズムには、次の欠点があります。
* It requires an implementation to store each per-context counter in memory. If, as a result of resource management, the counter for a given context must be removed, the last transient numeric identifier value used for that context will be lost. Thus, if an identifier subsequently needs to be generated for the same context, the corresponding counter will need to be recreated and reinitialized to a random value, thus possibly leading to reuse/ collision of numeric identifiers.
* 各コンテキストごとのカウンターをメモリに保存するための実装が必要です。リソース管理の結果として、特定のコンテキストのカウンターを削除する必要がある場合、そのコンテキストで使用される最後の過渡数値識別子値が失われます。したがって、その後、識別子を同じコンテキストで生成する必要がある場合、対応するカウンターを再現してランダムな値に再発射する必要があり、したがって、数値識別子の再利用/衝突につながる可能性があります。
* Keeping one counter for each possible "context" may in some cases be considered too onerous in terms of memory requirements.
* 可能な「コンテキスト」ごとに1つのカウンターを維持することは、場合によっては、メモリ要件の点であまりにも面倒であると見なされる場合があります。
Otherwise, the identifiers produced by this algorithm do not suffer from the other issues discussed in Section 8.
それ以外の場合、このアルゴリズムによって生成された識別子は、セクション8で説明されている他の問題に悩まされません。
The goal of this algorithm is to produce monotonically increasing transient numeric identifiers (for each given context) with a randomized initial value. For example, if the identifiers being generated must be monotonically increasing for each {Source Address, Destination Address} set, then each possible combination of {Source Address, Destination Address} should have a separate monotonically increasing sequence that starts at a different random value.
このアルゴリズムの目標は、ランダム化された初期値で単調に増加する一時的な数値識別子（指定されたコンテキストごと）を生成することです。たとえば、生成される識別子が各{ソースアドレス、宛先アドレス}セットごとに単調に増加する必要がある場合、{ソースアドレス、宛先アドレス}の各組み合わせが、異なるランダム値で始まる個別の単調に増加するシーケンスを持つ必要があります。
Instead of maintaining a per-context counter (as in the algorithm from Section 7.4.1), the following algorithm employs a calculated technique to maintain a random offset for each possible context.
コンテキストごとのカウンターを維持する代わりに（セクション7.4.1のアルゴリズムのように）、次のアルゴリズムは計算された手法を採用して、可能なコンテキストごとにランダムオフセットを維持します。
/* Initialization code */
counter = 0;
/* Transient Numeric ID selection function */
id_range = max_id - min_id + 1;
id_inc = increment() % id_range;
offset = F(CONTEXT, secret_key);
retry = id_range;
do {
next_id = min_id + (offset + counter) % id_range;
counter = counter + id_inc;
if (suitable_id(next_id)) {
return next_id;
}
retry = retry - id_inc;
} while (retry > 0);
return ERROR;
NOTE:
注記：
CONTEXT is the concatenation of all the elements that define a given context. For example, if this algorithm is expected to produce identifiers that are monotonically increasing for each set {Source Address, Destination Address}, CONTEXT should be the concatenation of Source Address and Destination Address.
コンテキストは、特定のコンテキストを定義するすべての要素の連結です。たとえば、このアルゴリズムが各セット{ソースアドレス、宛先アドレス}に対して単調に増加する識別子を生成すると予想される場合、コンテキストはソースアドレスと宛先アドレスの連結である必要があります。
increment() has the same properties and requirements as those specified for increment() in Section 7.4.1.
Increment（）には、セクション7.4.1でIncrement（）に指定されたプロパティと同じプロパティと要件があります。
F() is a PRF, with the same properties as those specified for F() in Section 7.3.
F（）はPRFであり、セクション7.3でF（）に指定されているプロパティと同じプロパティがあります。
suitable_id() checks whether a candidate numeric identifier has suitable uniqueness properties.
satable_id（）候補数値識別子に適切な一意性プロパティがあるかどうかをチェックします。
In the algorithm above, the function F() provides a stateless, stable, and unpredictable offset for each given context (as identified by "CONTEXT"). Both the "offset" and "counter" variables may take any value within the storage type range since we are restricting the resulting identifier to be in the range [min_id, max_id] in a similar way as in the algorithm described in Section 7.1.1. This allows us to simply increment the "counter" variable and rely on the unsigned integer to wrap around.
上記のアルゴリズムでは、関数f（）は、指定された各コンテキスト（「コンテキスト」で識別される）に対して、ステートレス、安定、および予測不可能なオフセットを提供します。「オフセット」と「カウンター」変数の両方は、セクション7.1.1で説明されているアルゴリズムのように、結果の識別子を同様の方法で範囲内に制限するため、ストレージタイプの範囲内で任意の値を取ることができます。。これにより、「カウンター」変数を単純に増やし、署名していない整数に依存してラップします。
The result of F() is no more secure than the secret key, and therefore, "secret_key" must be unknown to the attacker and must be of a reasonable length. "secret_key" must remain stable for a given CONTEXT, since otherwise, the numeric identifiers generated by this algorithm would not have the desired properties (i.e., monotonically increasing for a given CONTEXT). In most cases, "secret_key" should be selected with a PRNG (see [RFC4086] for recommendations on choosing secrets) at an appropriate time and stored in stable or volatile storage (as necessary) for future use.
F（）の結果はシークレットキーほど安全ではないため、「Secret_Key」は攻撃者には知られていない必要があり、妥当な長さでなければなりません。「secret_key」は、特定のコンテキストでは安定したままでなければなりません。そうしないと、このアルゴリズムによって生成される数値識別子には目的のプロパティがありません（つまり、特定のコンテキストで単調に増加する）。ほとんどの場合、適切な時間に「Secret_key」をPRNG（秘密の選択に関する推奨事項については[RFC4086]を参照）で選択し、将来の使用のために（必要に応じて）安定または揮発性の保管に保存する必要があります。
It should be noted that, since this algorithm uses a global counter ("counter") for selecting identifiers (i.e., all counters share the same increment space), this algorithm results in an information leakage (as described in Section 8.2). For example, if this algorithm was used for selecting TCP ephemeral ports and an attacker could force a client to periodically establish a new TCP connection to an attacker-controlled system (or through an attacker-observable routing path), the attacker could subtract consecutive Source Port values to obtain the number of outgoing TCP connections established globally by the victim host within that time period (up to wrap-around issues and five-tuple collisions, of course). This information leakage could be partially mitigated by employing small random values for the increments (i.e., increment() function), instead of having increment() return the constant "1".
このアルゴリズムは、識別子を選択するためにグローバルカウンター（「カウンター」）を使用するため（つまり、すべてのカウンターが同じ増分空間を共有する）、このアルゴリズムは情報漏れになります（セクション8.2で説明されています）。たとえば、このアルゴリズムがTCP Ephemeral Portsを選択するために使用され、攻撃者がクライアントに攻撃者制御システムへの新しいTCP接続を定期的に確立するように強制する場合（または攻撃者に夢中なルーティングパスを介して）、攻撃者は連続したソースを差し引くことができます。ポート値は、その期間内に被害者のホストによってグローバルに確立された発信TCP接続の数を取得します（もちろん、ラップアラウンドの問題と5タプルの衝突まで）。この情報の漏れは、increment（）をincrement（）に定数「1」を返すのではなく、増分（つまり、増分（）関数）に対して小さなランダム値を使用することで部分的に軽減できます。
We nevertheless note that an improved mitigation of this information leakage could be more successfully achieved by employing the algorithm from Section 7.4.3, instead.
それにもかかわらず、この情報漏れの改善された緩和は、代わりにセクション7.4.3からアルゴリズムを採用することにより、より正常に達成できることに注意してください。
A trade-off between maintaining a single global "counter" variable and maintaining 2**N "counter" variables (where N is the width of the result of F()) could be achieved as follows. The system would keep an array of TABLE_LENGTH values, which would provide a separation of the increment space into multiple buckets. This improvement could be incorporated into the algorithm from Section 7.4.2 as follows:
単一のグローバルな「カウンター」変数を維持し、2 ** n「カウンター」変数を維持することとのトレードオフ（nはf（）の結果の幅）を次のように達成できます。システムは、一連のtable_length値を保持し、増分空間を複数のバケツに分離します。この改善は、次のようにセクション7.4.2からアルゴリズムに組み込むことができます。
/* Initialization code */
for(i = 0; i < TABLE_LENGTH; i++) {
table[i] = random();
}
/* Transient Numeric ID selection function */
id_range = max_id - min_id + 1;
id_inc = increment() % id_range;
offset = F(CONTEXT, secret_key1);
index = G(CONTEXT, secret_key2) % TABLE_LENGTH;
retry = id_range;
do {
next_id = min_id + (offset + table[index]) % id_range;
table[index] = table[index] + id_inc;
if (suitable_id(next_id)) {
return next_id;
}
retry = retry - id_inc;
} while (retry > 0);
return ERROR;
NOTE:
注記：
increment() has the same properties and requirements as those specified for increment() in Section 7.4.1.
Increment（）には、セクション7.4.1でIncrement（）に指定されたプロパティと同じプロパティと要件があります。
Both F() and G() are PRFs, with the same properties as those required for F() in Section 7.3. The results of F() and G() are no more secure than their respective secret keys ("secret_key1" and "secret_key2", respectively), and therefore, both secret keys must be unknown to the attacker and must be of a reasonable length. Both secret keys must remain stable for the given CONTEXT, since otherwise, the transient numeric identifiers generated by this algorithm would not have the desired properties (i.e., monotonically increasing for a given CONTEXT). In most cases, both secret keys should be selected with a PRNG (see [RFC4086] for recommendations on choosing secrets) at an appropriate time and stored in stable or volatile storage (as necessary) for future use.
f（）とg（）の両方はPRFであり、セクション7.3のf（）に必要なプロパティと同じプロパティがあります。f（）とg（）の結果は、それぞれのシークレットキー（それぞれ "Secret_key1"と "Secret_key2"）よりも安全ではないため、両方の秘密のキーは攻撃者には不明であり、妥当な長さでなければなりません。どちらの秘密のキーも、指定されたコンテキストでは安定したままでなければなりません。そうしないと、このアルゴリズムによって生成された過渡数値識別子には目的のプロパティがありません（つまり、特定のコンテキストでは単調に増加します）。ほとんどの場合、両方の秘密のキーは、適切な時期にPRNG（秘密の選択に関する推奨事項については[RFC4086]を参照）で選択し、将来の使用のために（必要に応じて）安定または揮発性の保管に保存する必要があります。
"table[]" could be initialized with random values, as indicated by the initialization code in the pseudocode above.
「表[]」は、上記の擬似コードの初期化コードで示されるように、ランダム値で初期化できます。
The "table[]" array assures that successive transient numeric identifiers for a given context will be monotonically increasing. Since the increment space is separated into TABLE_LENGTH different spaces, the identifier reuse frequency will be (probabilistically) lower than that of the algorithm in Section 7.4.2. That is, the generation of an identifier for one given context will not necessarily result in increments in the identifier sequence of other contexts. It is interesting to note that the size of "table[]" does not limit the number of different identifier sequences but rather separates the *increment space* into TABLE_LENGTH different spaces. The selected transient numeric identifier sequence will be obtained by adding the corresponding entry from "table[]" to the value in the "offset" variable, which selects the actual identifier sequence space (as in the algorithm from Section 7.4.2).
「テーブル[]」アレイは、特定のコンテキストの連続した過渡数値識別子が単調に増加することを保証します。増分空間はtable_lengthの異なる空間に分離されるため、識別子の再利用頻度は、セクション7.4.2のアルゴリズムの識別頻度よりも（確率的に）低くなります。つまり、1つの指定されたコンテキストの識別子の生成は、必ずしも他のコンテキストの識別子シーケンスの増加をもたらすわけではありません。「テーブル[]」のサイズは、異なる識別子シーケンスの数を制限するのではなく、 *増分空間 *をテーブル_Lengthの異なるスペースに分離することに注意してください。選択された過渡数値識別子シーケンスは、「テーブル[]」から「オフセット」変数の値に対応するエントリを追加することで取得されます。これは、実際の識別子シーケンス空間を選択します（セクション7.4.2のアルゴリズムのように）。
An attacker can perform traffic analysis for any "increment space" (i.e., context) into which the attacker has "visibility" -- namely, the attacker can force a system to generate identifiers for G(CONTEXT, secret_key2), where the result of G() identifies the target "increment space". However, the attacker's ability to perform traffic analysis is very reduced when compared to the simple PRF-based identifiers (described in Section 7.4.2) and the predictable linear identifiers (described in Appendix A.1). Additionally, an implementation can further limit the attacker's ability to perform traffic analysis by further separating the increment space (that is, using a larger value for TABLE_LENGTH) and/or by randomizing the increments (i.e., increment() returning a small random number as opposed to the constant "1").
攻撃者は、攻撃者が「可視性」を持っている「インクリメントスペース」（つまり、コンテキスト）のトラフィック分析を実行できます。つまり、攻撃者はシステムにG（Context、Secret_Key2）の識別子を生成するように強制できます。g（）ターゲット「増分スペース」を識別します。ただし、トラフィック分析を実行する攻撃者の能力は、単純なPRFベースの識別子（セクション7.4.2で説明）および予測可能な線形識別子（付録A.1で説明）と比較すると非常に削減されます。さらに、実装は、増分空間をさらに分離することでトラフィック分析を実行する攻撃者の能力をさらに制限することができます（つまり、table_lengthに大きな値を使用）、および/または増分をランダム化することで（つまり、Increment（）、少量の乱数を返すようにします。定数「1」に反対）。
Otherwise, this algorithm does not suffer from the issues discussed in Section 8.
それ以外の場合、このアルゴリズムはセクション8で説明した問題に悩まされません。
An identifier that is predictable within a given context allows for network activity correlation within that context.
特定のコンテキスト内で予測可能な識別子は、そのコンテキスト内でネットワークアクティビティの相関を可能にします。
For example, a stable IPv6 Interface Identifier allows for network activity to be correlated within the context in which the Interface Identifier is stable [RFC7721]. A stable per-network IPv6 Interface Identifier (as in [RFC7217]) allows for network activity correlation within a network, whereas a constant IPv6 Interface Identifier (which remains constant across networks) allows not only network activity correlation within the same network but also across networks ("host-tracking").
たとえば、安定したIPv6インターフェイス識別子により、インターフェイス識別子が安定しているコンテキスト内でネットワークアクティビティを相関させることができます[RFC7721]。安定したネットワークごとのIPv6インターフェイス識別子（[RFC7217]のように）はネットワーク内のネットワークアクティビティ相関を可能にしますが、一定のIPv6インターフェイス識別子（ネットワーク全体で一定のままです）は、同じネットワーク内でのネットワークアクティビティ相関を可能にしますが、ネットワーク（「ホストトラッキング」）。
Similarly, an implementation that generates TCP ISNs with a global counter could allow for fingerprinting and network activity correlation across networks, since an attacker could passively infer the identity of the victim based on the TCP ISNs employed for subsequent communication instances. Similarly, an implementation that generates predictable IPv6 Identification values could be subject to fingerprinting attacks (see, e.g., [Bellovin2002]).
同様に、攻撃者は後続の通信インスタンスに使用されたTCP ISNに基づいて被害者の身元を受動的に推測できるため、グローバルカウンターを使用してTCP ISNを生成する実装により、ネットワーク全体でネットワーク全体でネットワークアクティビティの相関が可能になります。同様に、予測可能なIPv6識別値を生成する実装には、フィンガープリント攻撃の対象となる可能性があります（[Bellovin2002]を参照）。
Transient numeric identifiers that result in specific patterns can produce an information leakage to other communicating entities. For example, it is common to generate transient numeric identifiers with an algorithm such as:
特定のパターンをもたらす一時的な数値識別子は、他の通信エンティティへの情報漏れを生成する可能性があります。たとえば、次のようなアルゴリズムで一時的な数値識別子を生成することが一般的です。
ID = offset(CONTEXT) + mono(CONTEXT);
This generic expression generates identifiers by adding a monotonically increasing function (e.g., linear) to a randomized offset. offset() is constant within a given context, whereas mono() produces a monotonically increasing sequence for the given context. Identifiers generated with this expression will generally be predictable within CONTEXT.
この汎用式は、単調に増加する関数（リニア）をランダム化オフセットに追加することにより、識別子を生成します。Offset（）は特定のコンテキスト内で一定ですが、Mono（）は特定のコンテキストの単調に増加するシーケンスを生成します。この式で生成された識別子は、一般にコンテキスト内で予測可能です。
The predictability of mono(), irrespective of the predictability of offset(), can leak information that may be of use to attackers. For example, a node that selects transport-protocol ephemeral port numbers, as in:
offset（）の予測可能性に関係なく、mono（）の予測可能性は、攻撃者に使用される可能性のある情報をリークできます。たとえば、次のように、トランスポートプロトコルのはかないポート番号を選択するノード。
ephemeral_port = offset(IP_Dst_Addr) + mono()
that is, with a per-destination offset but a global mono() function (e.g., a global counter), will leak information about the total number of outgoing connections that have been issued by the vulnerable implementation.
つまり、設定ごとのオフセットがありますが、グローバルモノ（）関数（グローバルカウンターなど）は、脆弱な実装によって発行された発信接続の総数に関する情報を漏らします。
Similarly, a node that generates IPv6 Identification values as in:
同様に、次のようにIPv6識別値を生成するノード。
ID = offset(IP_Src_Addr, IP_Dst_Addr) + mono()
will leak out information about the total number of fragmented packets that have been transmitted by the vulnerable implementation. The vulnerabilities described in [Sanfilippo1998a], [Sanfilippo1998b], and [Sanfilippo1999] are all associated with the use of a global mono() function (i.e., with a global and constant "CONTEXT") -- particularly when it is a linear function (constant increments of 1).
脆弱な実装によって送信された断片化されたパケットの総数に関する情報が漏れます。[sanfilippo1998a]、[sanfilippo1998b]、および[sanfilippo1999]に記載されている脆弱性はすべて、グローバルモノ（）関数（すなわち、グローバルおよび一定の「コンテキスト」を使用）の使用に関連しています。（1の一定の増分）。
Predicting transient numeric identifiers can be of help for other types of attacks. For example, predictable TCP ISNs can open the door to trivial connection-reset and data injection attacks (see Section 8.6).
一時的な数値識別子を予測することは、他のタイプの攻撃に役立ちます。たとえば、予測可能なTCP ISNは、些細な接続レスセットおよびデータインジェクション攻撃への扉を開くことができます（セクション8.6を参照）。
Fingerprinting is the capability of an attacker to identify or reidentify a visiting user, user agent, or device via configuration settings or other observable characteristics. Observable protocol objects and characteristics can be employed to identify/reidentify various entities. These entities can range from the underlying hardware or operating system (OS) (vendor, type, and version) to the user. [EFF] illustrates web-browser-based fingerprinting, but similar techniques can be applied at other layers and protocols, whether alternatively or in conjunction with it.
フィンガープリントとは、攻撃者が訪問者、ユーザーエージェント、またはデバイスを構成設定またはその他の観察可能な特性を介して識別または再識別する機能です。観察可能なプロトコルオブジェクトと特性を使用して、さまざまなエンティティを識別/再識別できます。これらのエンティティは、基礎となるハードウェアまたはオペレーティングシステム（OS）（ベンダー、タイプ、およびバージョン）からユーザーまでの範囲です。[EFF]は、Webブラウザーベースのフィンガープリントを示していますが、同様の手法を他のレイヤーやプロトコルに、またはそれと併せて適用できます。
Transient numeric identifiers are one of the observable protocol components that could be leveraged for fingerprinting purposes. That is, an attacker could sample transient numeric identifiers to infer the algorithm (and its associated parameters, if any) for generating such identifiers, possibly revealing the underlying OS vendor, type, and version. This information could possibly be further leveraged in conjunction with other fingerprinting techniques and sources.
一時的な数値識別子は、指紋の目的で活用できる観察可能なプロトコルコンポーネントの1つです。つまり、攻撃者は一時的な数値識別子をサンプリングして、そのような識別子を生成するためにアルゴリズム（およびそれに関連するパラメーター（存在する場合）を推測し、基礎となるOSベンダー、タイプ、およびバージョンを明らかにする可能性があります。この情報は、他のフィンガープリント技術やソースと組み合わせてさらに活用される可能性があります。
Evasion of protocol-stack fingerprinting can prove to be a very difficult task, i.e., most systems make use of a wide variety of protocols, each of which have a large number of parameters that can be set to arbitrary values or generated with a variety of algorithms with multiple parameters.
プロトコルスタックのフィンガープリントの回避は非常に困難なタスクであることが証明できます。つまり、ほとんどのシステムはさまざまなプロトコルを利用しています。複数のパラメーターを持つアルゴリズム。
NOTE: General protocol-based fingerprinting is discussed in [RFC6973], along with guidelines to mitigate the associated vulnerability. [Fyodor1998] and [Fyodor2006] are classic references on OS detection via TCP/IP stack fingerprinting. Network Mapper [nmap] is probably the most popular tool for remote OS identification via active TCP/IP stack fingerprinting. p0f [Zalewski2012], on the other hand, is a tool for performing remote OS detection via passive TCP/IP stack fingerprinting. Finally, [TBIT] is a TCP fingerprinting tool that aims at characterizing the behavior of a remote TCP peer based on active probes, which has been widely used in the research community.
注：一般的なプロトコルベースのフィンガープリントについては、[RFC6973]で説明されており、関連する脆弱性を軽減するためのガイドラインです。[fyodor1998]および[fyodor2006]は、TCP/IPスタックフィンガープリンティングを介したOS検出に関する古典的な参照です。ネットワークマッパー[NMAP]は、おそらくアクティブなTCP/IPスタックフィンガープリントを介したリモートOS識別のための最も人気のあるツールです。一方、P0F [Zalewski2012]は、パッシブTCP/IPスタックフィンガープリントを介してリモートOS検出を実行するためのツールです。最後に、[TBIT]は、研究コミュニティで広く使用されているアクティブプローブに基づいて、リモートTCPピアの動作を特徴付けることを目的とするTCPフィンガープリントツールです。
Algorithms that, from the perspective of an observer (e.g., the legitimate communicating peer), result in specific values or patterns will allow for at least some level of fingerprinting. For example, the algorithm from Section 7.3 will typically allow fingerprinting within the context where the resulting identifiers are stable. Similarly, the algorithms from Section 7.4 will result in monotonically increasing sequences within a given context, thus allowing for at least some level of fingerprinting (when the other communicating entity can correlate different sampled identifiers as belonging to the same monotonically increasing sequence).
オブザーバーの観点から（たとえば、合法的なコミュニケーションピア）、特定の値またはパターンをもたらすアルゴリズムは、少なくともある程度のフィンガープリントを可能にします。たとえば、セクション7.3のアルゴリズムは、通常、結果の識別子が安定しているコンテキスト内でフィンガープリントを許可します。同様に、セクション7.4のアルゴリズムは、特定のコンテキスト内で単調に増加するシーケンスをもたらし、したがって、少なくともある程度のフィンガープリントを可能にします（他の通信エンティティが同じ単調に増加するシーケンスに属するものとして異なるサンプリングされた識別子を相関させることができる場合）。
Thus, where possible, algorithms from Section 7.1 should be preferred over algorithms that result in specific values or patterns.
したがって、可能であれば、特定の値またはパターンをもたらすアルゴリズムよりも、セクション7.1のアルゴリズムを優先する必要があります。
Identifiers that are not semantically opaque tend to be more predictable than semantically opaque identifiers. For example, a Media Access Control (MAC) address contains an Organizationally Unique Identifier (OUI), which may identify the vendor that manufactured the corresponding network interface card. This can be leveraged by an attacker trying to "guess" MAC addresses, who has some knowledge about the possible Network Interface Card (NIC) vendor.
意味的に不透明ではない識別子は、意味的に不透明な識別子よりも予測可能である傾向があります。たとえば、メディアアクセスコントロール（MAC）アドレスには、対応するネットワークインターフェイスカードを製造したベンダーを識別する組織的に一意の識別子（OUI）が含まれています。これは、Macアドレスを「推測」しようとする攻撃者が活用できます。
[RFC7707] discusses a number of techniques to reduce the search space when performing IPv6 address-scanning attacks by leveraging the semantics of IPv6 IIDs.
[RFC7707]は、IPv6 IIDのセマンティクスを活用することにより、IPv6アドレススカニング攻撃を実行するときに検索スペースを減らすための多くの手法について説明します。
In many cases, the collision of transient network identifiers can have a hard failure severity (or result in a hard failure severity if an attacker can cause multiple collisions deterministically, one after another). For example, predictable IP Identification values open the door to Denial of Service (DoS) attacks (see, e.g., [RFC5722].).
多くの場合、一時的なネットワーク識別子の衝突は、攻撃者が複数の衝突を決定的に次々と引き起こす可能性がある場合、困難な障害の重大度を持つ可能性があります（または、困難な障害の重症度をもたらす可能性があります）。たとえば、予測可能なIP識別値は、サービス拒否（DOS）攻撃の扉を開きます（例えば[RFC5722]を参照）。
Some protocols rely on "sequence numbers" for the validation of incoming packets. For example, TCP employs sequence numbers for reassembling TCP segments, while IPv4 and IPv6 employ Identification values for reassembling IPv4 and IPv6 fragments (respectively). Lacking built-in cryptographic mechanisms for validating packets, these protocols are therefore vulnerable to on-path data (see, e.g., [Joncheray1995]) and/or control-information (see, e.g., [RFC4953] and [RFC5927]) injection attacks. The extent to which these protocols may resist off-path (i.e., "blind") injection attacks depends on whether the associated "sequence numbers" are predictable and the effort required to successfully predict a valid "sequence number" (see, e.g., [RFC4953] and [RFC5927]).
一部のプロトコルは、着信パケットの検証のために「シーケンス番号」に依存しています。たとえば、TCPはTCPセグメントを再構築するためにシーケンス番号を採用し、IPv4とIPv6はIPv4およびIPv6フラグメントを再組み立てするために識別値を使用します（それぞれ）。したがって、これらのプロトコルは、パケットを検証するための内蔵の暗号化メカニズムを欠いているため、オンパスデータ（たとえば[Joncheray1995]を参照）および/または制御情報（例えば[RFC4953]および[RFC5927]を参照）に対して脆弱です。。これらのプロトコルがオフパス（つまり、「ブラインド」）噴射攻撃に抵抗する可能性のある程度は、関連する「シーケンス番号」が予測可能かどうかによって異なり、有効な「シーケンス番号」を正常に予測するために必要な努力に依存します（例えば、[参照]RFC4953]および[RFC5927]）。
We note that the use of unpredictable "sequence numbers" is a completely ineffective mitigation for on-path injection attacks and also a mostly ineffective mitigation for off-path (i.e., "blind") injection attacks. However, many legacy protocols (such as TCP) do not incorporate cryptographic mitigations as part of the core protocol but rather as optional features (see, e.g., [RFC5925]), if available at all. Additionally, ad hoc use of cryptographic mitigations might not be sufficient to relieve a protocol implementation of generating appropriate transient numeric identifiers. For example, use of the Transport Layer Security (TLS) protocol [RFC8446] with TCP will protect the application protocol but will not help to mitigate, e.g., TCP-based connection-reset attacks (see, e.g., [RFC4953]). Similarly, use of SEcure Neighbor Discovery (SEND) [RFC3971] will still imply reliance on the successful reassembly of IPv6 fragments in those cases where SEND packets do not fit into the link Maximum Transmission Unit (MTU) (see [RFC6980]).
予測不可能な「シーケンス番号」の使用は、パス上の注入攻撃のための完全に効果のない緩和であり、また、オフパス（すなわち、「ブラインド」）注射攻撃に対するほとんど効果のない緩和であることに注意してください。ただし、多くのレガシープロトコル（TCPなど）には、コアプロトコルの一部として暗号化緩和を組み込むのではなく、オプションの機能として組み込まれています（[RFC5925]を参照）。さらに、適切な一時的な数値識別子を生成するプロトコルの実装を緩和するには、暗号化緩和のアドホック使用では十分ではないかもしれません。たとえば、TCPを使用してトランスポートレイヤーセキュリティ（TLS）プロトコル[RFC8446]を使用すると、アプリケーションプロトコルが保護されますが、たとえばTCPベースの接続リセット攻撃を緩和するのに役立ちません（[RFC4953]を参照）。同様に、セキュアネイバーディスカバリー（送信）[RFC3971]の使用は、送信パケットがリンク最大透過ユニット（MTU）に収まらない場合のIPv6フラグメントの成功した再組み立てに依存することを意味します（[RFC6980を参照]）。
A number of algorithms discussed in this document (such as those described in Sections 7.4.2 and 7.4.3) rely on PRFs. Implementations that employ weak PRFs or keys of inappropriate size can be subject to cryptanalysis, where an attacker can obtain the secret key employed for the PRF, predict numeric identifiers, etc.
このドキュメントで説明されている多くのアルゴリズム（セクション7.4.2および7.4.3で説明されているなど）は、PRFSに依存しています。不適切なサイズの弱いPRFまたはキーを使用する実装は、攻撃者がPRFに使用される秘密キーを取得したり、数値識別子を予測するなどで暗号化の対象となります。
Furthermore, an implementation that overloads the semantics of the secret key can result in more trivial cryptanalysis, possibly resulting in the leakage of the value employed for the secret key.
さらに、シークレットキーのセマンティクスを過負荷にする実装は、より些細な暗号化をもたらす可能性があり、おそらくシークレットキーに採用された値の漏れをもたらす可能性があります。
NOTE: [IPID-DEV] describes two vulnerable transient numeric identifier generators that employ cryptographically weak hash functions. Additionally, one of such implementations employs 32 bits of a kernel address as the secret key for a hash function, and therefore, successful cryptanalysis leaks the aforementioned kernel address, allowing for Kernel Address Space Layout Randomization (KASLR) [KASLR] bypass.
注：[IPID-DEV]は、暗号化的に弱いハッシュ関数を使用する2つの脆弱な一時的な数値識別子ジェネレーターを説明しています。さらに、このような実装の1つは、ハッシュ関数の秘密キーとして32ビットのカーネルアドレスを採用しているため、成功した暗号化は前述のカーネルアドレスを漏らし、カーネルアドレススペースレイアウトランダム化（KASLR）[KASLR]バイパスを可能にします。
The following subsections analyze possible vulnerabilities associated with the algorithms described in Section 7.
以下のサブセクションは、セクション7で説明されているアルゴリズムに関連する可能性のある脆弱性を分析します。
Possible vulnerabilities associated with the algorithms from Section 7.1 include the following:
セクション7.1のアルゴリズムに関連する可能性のある脆弱性には、以下が含まれます。
* use of flawed PRNGs (please see, e.g., [Zalewski2001], [Zalewski2002], [Klein2007], and [CVEs])
* 欠陥のあるPRNGの使用（例えば、[Zalewski2001]、[Zalewski2002]、[klein2007]、および[cves]を参照））
* inadvertently affecting the distribution of an otherwise suitable PRNG (please see, e.g., [Romailler2020])
* そうでなければ適切なPRNGの分布に誤って影響を与えます（例えば[romailler2020]を参照））
Where available, CSPRNGs should be preferred over regular PRNGs, such as, e.g., POSIX random(3) implementations. In scenarios where a CSPRNG is not readily available, a security and privacy assessment of employing a regular PRNG should be performed, supporting the implementation decision.
利用可能な場合は、POSIXランダム（3）の実装など、通常のPRNGよりもCSPRNGを優先する必要があります。CSPRNGが容易に利用できないシナリオでは、通常のPRNGを採用するセキュリティとプライバシーの評価を実行し、実装決定をサポートする必要があります。
NOTE: Please see [RFC4086] regarding randomness requirements for security. [Aumasson2018], [Press1992], and [Knuth1983] discuss theoretical and practical aspects of random number generation and provide guidance on how to evaluate PRNGs.
注：セキュリティのランダム性要件については、[RFC4086]を参照してください。[Aumasson2018]、[Press1992]、および[Knuth1983]は、乱数生成の理論的および実用的な側面について議論し、PRNGを評価する方法に関するガイダンスを提供します。
When employing a PRNG, many implementations "adapt" the length of its output with a modulo operator (e.g., C language's "%"), possibly changing the distribution of the output of the PRNG.
PRNGを採用する場合、多くの実装は、Moduloオペレーター（C Languageの「％」など）で出力の長さを「適応」し、PRNGの出力の分布を変更する可能性があります。
For example, consider an implementation that employs the following code:
たとえば、次のコードを使用する実装を検討してください。
id = random() % 50000;
This example implementation means to obtain a transient numeric identifier in the range 0-49999. If random() produces, e.g., a pseudorandom number of 16 bits (with uniform distribution), the selected transient numeric identifier will have a nonuniform distribution with the numbers in the range 0-15535 having double frequency than the numbers in the range 15536-49999.
この例の実装は、範囲0-49999で過渡数値識別子を取得することを意味します。ランダム（）が16ビットの擬似ランダム数（均一な分布）を生成する場合、選択された過渡数値識別子は、範囲の範囲15536の数よりも2倍の周波数を持つ範囲0-15535の数値を持つ不均一な分布を持ちます。49999。
NOTE: For example, in our sample code, both an output of 10 and output of 50010 from the random() function will result in an "id" value of 10.
注：たとえば、サンプルコードでは、ランダム（）関数からの10の出力と50010の出力の両方が10の「ID」値になります。
This effect is reduced if the PRNG produces an output that is much longer than the length implied by the modulo operation. We note that to preserve a uniform distribution, the rejection sampling technique [Romailler2020] can be used.
この効果は、PRNGがModulo操作によって暗示される長さよりもはるかに長い出力を生成すると減少します。均一な分布を保持するために、拒絶サンプリング手法[Romailler2020]を使用できることに注意してください。
Use of algorithms other than PRNGs for generating identifiers of this category is discouraged.
このカテゴリの識別子を生成するためのPRNG以外のアルゴリズムの使用は落胆します。
As noted in Section 7.2, this category can employ the same algorithms as Category #4, since a monotonically increasing sequence tends to minimize the transient numeric identifier reuse frequency. Therefore, the vulnerability analysis in Section 9.4 also applies to this category.
セクション7.2で述べたように、このカテゴリは、単調に増加するシーケンスが過渡数値識別子再利用周波数を最小限に抑える傾向があるため、カテゴリ＃4と同じアルゴリズムを使用できます。したがって、セクション9.4の脆弱性分析もこのカテゴリに適用されます。
Additionally, as noted in Section 7.2, some transient numeric identifiers of this category might be able to use the algorithms from Section 7.1, in which case the same considerations as in Section 9.1 would apply.
さらに、セクション7.2で述べたように、このカテゴリの一時的な数値識別子は、セクション7.1のアルゴリズムを使用できる場合があります。この場合、セクション9.1と同じ考慮事項が適用されます。
Possible vulnerabilities associated with the algorithms from Section 7.3 are the following:
セクション7.3のアルゴリズムに関連する可能性のある脆弱性は次のとおりです。
* Use of weak PRFs or inappropriate secret keys (whether inappropriate selection or inappropriate size) could allow for cryptanalysis, which could eventually be exploited by an attacker to predict future transient numeric identifiers.
* 弱いPRFまたは不適切な秘密キー（不適切な選択または不適切なサイズであろうと）の使用により、攻撃者が最終的に搾取して将来の一時的な数値識別子を予測することができます。
* Since the algorithm generates a unique and stable identifier within a specified context, it may allow for network activity correlation and fingerprinting within the specified context.
* アルゴリズムは、指定されたコンテキスト内で一意で安定した識別子を生成するため、指定されたコンテキスト内でネットワークアクティビティの相関とフィンガープリントを可能にする場合があります。
The algorithm described in Section 7.4.1 for generating identifiers of Category #4 will result in an identifiable pattern (i.e., a monotonically increasing sequence) for the transient numeric identifiers generated for each CONTEXT, and thus will allow for fingerprinting and network activity correlation within each CONTEXT.
カテゴリ＃4の識別子を生成するためのセクション7.4.1で説明されているアルゴリズムは、各コンテキストで生成された過渡数値識別子の識別可能なパターン（つまり、単調に増加するシーケンス）になり、したがって、したがって、したがって、したがって、したがって、フィンガープリントとネットワークアクティビティの相関が可能になります。各コンテキスト。
On the other hand, a simple way to generalize and analyze the algorithms described in Sections 7.4.2 and 7.4.3 for generating identifiers of Category #4 is as follows:
一方、カテゴリ＃4の識別子を生成するためにセクション7.4.2および7.4.3で説明したアルゴリズムを一般化および分析する簡単な方法は次のとおりです。
/* Transient Numeric ID selection function */
id_range = max_id - min_id + 1;
retry = id_range;
id_inc = increment() % id_range;
do {
update_mono(CONTEXT, id_inc);
next_id = min_id + (offset(CONTEXT) + \
mono(CONTEXT)) % id_range;
if (suitable_id(next_id)) {
return next_id;
}
retry = retry - id_inc;
} while (retry > 0);
return ERROR;
NOTE:
注記：
increment() returns a small integer that is employed to generate a monotonically increasing function. Most implementations employ a constant value for "increment()" (usually 1). The value returned by increment() must be much smaller than the value computed for "id_range".
Increment（）は、単調に増加する機能を生成するために使用される小整数を返します。ほとんどの実装は、「increment（）」（通常1）の一定の値を採用しています。increment（）によって返される値は、「id_range」に対して計算された値よりもはるかに小さい必要があります。
update_mono(CONTEXT, id_inc) increments the counter corresponding to CONTEXT by "id_inc".
update_mono（context、id_inc）は、「id_inc」によってコンテキストに対応するカウンターを増分します。
mono(CONTEXT) reads the counter corresponding to CONTEXT.
モノ（コンテキスト）は、コンテキストに対応するカウンターを読み取ります。
Essentially, an identifier (next_id) is generated by adding a monotonically increasing function (mono()) to an offset value, which is unknown to the attacker and stable for given context (CONTEXT).
基本的に、識別子（next_id）は、単調に増加する関数（mono（））をオフセット値に追加することによって生成されます。
The following aspects of the algorithm should be considered:
アルゴリズムの次の側面を考慮する必要があります。
* For the most part, it is the offset() function that results in identifiers that are unpredictable by an off-patch attacker. While the resulting sequence is known to be monotonically increasing, the use of a randomized offset value makes the resulting values unknown to the attacker.
* ほとんどの場合、それはオフセット（）関数であり、オフパッチの攻撃者が予測不可能な識別子になります。結果のシーケンスは単調に増加することが知られていますが、ランダム化されたオフセット値を使用すると、結果の値が攻撃者に不明になります。
* The most straightforward "stateless" implementation of offset() is with a PRF that takes the values that identify the context and a secret key (not shown in the figure above) as arguments.
* Offset（）の最も単純な「ステートレス」実装は、コンテキストと秘密の鍵（上の図には示されていない）を引数として識別する値を取るPRFを使用します。
* One possible implementation of mono() would be to have mono() internally employ a single counter (as in the algorithm from Section 7.4.2) or map the increments for different contexts into a number of counters/buckets, such that the number of counters that need to be maintained in memory is reduced (as in the "Double-PRF Algorithm" from Section 7.4.3).
* モノ（）の可能な実装の1つは、モノ（）を単一のカウンター（セクション7.4.2のアルゴリズムのように）を内部的に使用するか、さまざまなコンテキストの増分を多数のカウンター/バケツにマッピングすることです。メモリ内で維持する必要があるカウンターは減少します（セクション7.4.3の「Double-PRFアルゴリズム」のように）。
* In all cases, a monotonically increasing function is implemented by incrementing the previous value of a counter by increment() units. In the most trivial case, increment() could return the constant "1". But increment() could also be implemented to return small random integers such that the increments are unpredictable (see Appendix A.2 of this document). This represents a trade-off between the unpredictability of the resulting transient numeric identifiers and the transient numeric identifier reuse frequency.
* すべての場合において、単調に増加する関数は、Increment（）ユニットごとにカウンターの以前の値を増分することにより実装されます。最も些細な場合、increment（）は定数「1」を返すことができます。ただし、Increment（）を実装して、小さなランダム整数を返して、増分が予測不可能になるようにすることもできます（このドキュメントの付録A.2を参照）。これは、結果の過渡数値識別子の予測不可能性と過渡数値識別子の再利用周波数のトレードオフを表します。
Considering the generic algorithm illustrated above, we can identify the following possible vulnerabilities:
上記の一般的なアルゴリズムを考慮すると、次の脆弱性を特定できます。
* Since the algorithms for this category are similar to those of Section 9.3, with the addition of a monotonically increasing function, all the issues discussed in Section 9.3 ("Category #3: Uniqueness, Stable within Context (Soft Failure)") also apply to this case.
* このカテゴリのアルゴリズムはセクション9.3のアルゴリズムと類似しているため、単調に増加する機能が追加されているため、セクション9.3で説明されているすべての問題（「カテゴリ＃3：一意性、コンテキスト内の安定」）も適用されます。この場合。
* mono() can be correlated to the number of identifiers generated for a given context (CONTEXT). Thus, if mono() spans more than the necessary context, the "increments" could be leaked to other parties, thus disclosing information about the number of identifiers that have been generated by the algorithm for all contexts. This information disclosure becomes more evident when an implementation employs a constant increment of 1. For example, an implementation where mono() is actually a single global counter will unnecessarily leak information about the number of identifiers that have been generated by the algorithm (globally, for all contexts). [Fyodor2003] describes one example of how such information leakages can be exploited. We note that limiting the span of the increment space will require a larger number of counters to be stored in memory (i.e., a larger value for the TABLE_LENGTH parameter of the algorithm in Section 7.4.3).
* モノ（）は、特定のコンテキスト（コンテキスト）に対して生成された識別子の数と相関することができます。したがって、mono（）が必要なコンテキストよりも多く及ぶ場合、「増分」を他の関係者に漏らせる可能性があるため、すべてのコンテキストでアルゴリズムによって生成された識別子の数に関する情報を開示します。この情報開示は、実装が1の一定の増分を使用するとより明確になります。たとえば、Mono（）が実際に単一のグローバルカウンターである実装が、アルゴリズムによって生成された識別子の数に関する不必要に漏れている情報（グローバルに、すべてのコンテキストに対して）。[Fyodor2003]は、そのような情報漏れがどのように活用されるかの一例を説明しています。増分空間のスパンを制限するには、メモリにより多くのカウンターを保存する必要があることに注意してください（つまり、セクション7.4.3のアルゴリズムのtable_lengthパラメーターの値が大きくなります）。
* Transient numeric identifiers generated with the algorithms described in Sections 7.4.2 and 7.4.3 will normally allow for fingerprinting within CONTEXT since, for such context, the resulting identifiers will have an identifiable pattern (i.e., a monotonically increasing sequence).
* セクション7.4.2および7.4.3で説明されているアルゴリズムで生成された一時的な数値識別子は、通常、コンテキスト内でフィンガープリントを可能にします。なぜなら、そのようなコンテキストでは、結果の識別子に識別可能なパターン（つまり、単調に増加するシーケンス）があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This entire document is about the security and privacy implications of transient numeric identifiers. [RFC9416] recommends that protocol specifications specify the interoperability requirements of their transient numeric identifiers, perform a vulnerability assessment of their transient numeric identifiers, and recommend an algorithm for generating each of their transient numeric identifiers. This document analyzes possible algorithms (and their implications) that could be employed to comply with the interoperability requirements of the most common categories of transient numeric identifiers while minimizing the associated negative security and privacy implications.
このドキュメント全体は、一時的な数値識別子のセキュリティとプライバシーへの影響に関するものです。[RFC9416]は、プロトコル仕様が一時的な数値識別子の相互運用性要件を指定し、過渡数値識別子の脆弱性評価を実行し、各過渡数値識別子を生成するためのアルゴリズムを推奨することを推奨しています。このドキュメントは、関連する負のセキュリティとプライバシーへの影響を最小限に抑えながら、一時的な数値識別子の最も一般的なカテゴリの相互運用性要件に準拠するために使用できる可能性のあるアルゴリズム（およびその意味）を分析します。
[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>.
[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>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[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>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[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>.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, DOI 10.17487/RFC5722, December 2009,
<https://www.rfc-editor.org/info/rfc5722>.
[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>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[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>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP
Timestamps", BCP 159, RFC 6191, DOI 10.17487/RFC6191,
April 2011, <https://www.rfc-editor.org/info/rfc6191>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[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>.
[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>.
[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>.
[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>.
[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>.
[ARC4RANDOM]
OpenBSD, "arc4random(3)", Library Functions Manual,
September 2019, <https://man.openbsd.org/arc4random>.
[Aumasson2018]
Aumasson, J-P., "Serious Cryptography: A Practical
Introduction to Modern Encryption", No Starch Press, Inc.,
ISBN-10 1-59327-826-8, November 2017.
[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, ISBN 1-58113-603-X/02/0011,
November 2002,
<https://www.cs.columbia.edu/~smb/papers/fnat.pdf>.
[BLAKE3] "BLAKE3: one function, fast everywhere", September 2022,
<https://blake3.io/>.
[C11] ISO/IEC, "Information technology - Programming languages -
C", ISO/IEC 9899:2018, June 2018.
[CPNI-TCP] Centre for the Protection of National Infrastructure
(CPNI), "Security Assessment of the Transmission Control
Protocol (TCP)", CPNI Technical Note 3/2009, February
2009, <https://www.si6networks.com/files/publications/tn-
03-09-security-assessment-TCP.pdf>.
[CVEs] NVD, "Vulnerability Advisories for PRNGs",
<https://www.gont.com.ar/miscellanea/prng-cves/>.
[EFF] EFF, "Cover your tracks: See how trackers view your
browser", <https://coveryourtracks.eff.org/>.
[FIPS-SHS] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
[Fyodor1998]
Fyodor, "Remote OS detection via TCP/IP Stack
FingerPrinting", Phrack Magazine, Volume 8, Issue 54,
December 1998,
<http://www.phrack.org/archives/issues/54/9.txt>.
[Fyodor2003]
Fyodor, "Idle Scanning and related IPID games", 2003,
<https://nmap.org/presentations/CanSecWest03/CD_Content/
idlescan_paper/idlescan.html>.
[Fyodor2006]
Lyon, G., "Chapter 8. Remote OS Detection", January 2009,
<https://nmap.org/book/osdetect.html>.
[GETENTROPY]
Linux, "getentropy(3)", Linux Programmer's Manual, March
2021,
<https://man7.org/linux/man-pages/man3/getentropy.3.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>.
[Joncheray1995]
Joncheray, L., "Simple Active Attack Against TCP",
Proceedings of the Fifth USENIX UNIX Security Symposium,
June 1995, <https://www.usenix.org/legacy/publications/lib
rary/proceedings/security95/full_papers/joncheray.pdf>.
[KASLR] PaX Team, "Address Space Layout Randomization",
<https://pax.grsecurity.net/docs/aslr.txt>.
[Klein2007]
Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability", November 2007,
<https://dl.packetstormsecurity.net/papers/attack/OpenBSD_
DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln
erability.pdf>.
[Knuth1983]
Knuth, D., "The Art of Computer Programming", Volume 2
(Seminumerical Algorithms), 2nd Ed., Reading,
Massachusetts, Addison-Wesley Publishing Company, January
1981.
[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>.
[nmap] nmap, "Nmap: Free Security Scanner For Network Exploration
and Audit", 2020, <https://nmap.org/>.
[POSIX] IEEE, "IEEE Standard for Information Technology --
Portable Operating System Interface (POSIX(TM)) Base
Specifications, Issue 7", IEEE Std 1003.1-2017,
DOI 10.1109/IEEESTD.2018.8277153, January 2018,
<https://doi.org/10.1109/IEEESTD.2018.8277153>.
[Press1992]
Press, W., Teukolsky, S., Vetterling, W., and B. Flannery,
"Numerical Recipes in C: The Art of Scientific Computing",
2nd Ed., Cambridge University Press, ISBN 0-521-43108-5,
December 1992.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, DOI 10.17487/RFC4953, July 2007,
<https://www.rfc-editor.org/info/rfc4953>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963,
DOI 10.17487/RFC4963, July 2007,
<https://www.rfc-editor.org/info/rfc4963>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
DOI 10.17487/RFC5927, July 2010,
<https://www.rfc-editor.org/info/rfc5927>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>.
[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>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation
with IPv6 Neighbor Discovery", RFC 6980,
DOI 10.17487/RFC6980, August 2013,
<https://www.rfc-editor.org/info/rfc6980>.
[RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6
Flow Label for Load Balancing in Server Farms", RFC 7098,
DOI 10.17487/RFC7098, January 2014,
<https://www.rfc-editor.org/info/rfc7098>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security
Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
<https://www.rfc-editor.org/info/rfc8937>.
[RFC9414] Gont, F. and I. Arce, "Unfortunate History of Transient
Numeric Identifiers", RFC 9414, DOI 10.17487/RFC9414, July
2023, <https://www.rfc-editor.org/info/rfc9414>.
[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>.
[Romailler2020]
Romailler, Y., "The Definitive Guide to "Modulo Bias and
How to Avoid It"!", Kudelski Security Research, July 2020,
<https://research.kudelskisecurity.com/2020/07/28/the-
definitive-guide-to-modulo-bias-and-how-to-avoid-it/>.
[Sanfilippo1998a]
Sanfilippo, S., "about the ip header id", message to the
Bugtraq mailing list, 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,
<https://www.silby.com/eurobsdcon05/
eurobsdcon_silbersack.pdf>.
[SipHash] "SipHash: a fast short-input PRF", February 2023,
<https://github.com/veorq/SipHash>.
[TBIT] TBIT, "TBIT, the TCP Behavior Inference Tool", 2001,
<https://www.icir.org/tbit/>.
[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>.
[Zalewski2001]
Zalewski, M., "Strange Attractors and TCP/IP Sequence
Number Analysis", April 2001,
<https://lcamtuf.coredump.cx/oldtcp/tcpseq.html>.
[Zalewski2002]
Zalewski, M., "Strange Attractors and TCP/IP Sequence
Number Analysis - One Year Later (2002)",
<https://lcamtuf.coredump.cx/newtcp/>.
[Zalewski2012]
Zalewski, M., "p0f v3 (3.09b)",
<https://lcamtuf.coredump.cx/p0f.shtml>.
The following subsections discuss algorithms and techniques with known negative security and privacy implications.
次のサブセクションでは、既知の否定的なセキュリティとプライバシーへの影響を伴うアルゴリズムと手法について説明します。
NOTE: As discussed in Section 1, the use of cryptographic techniques might allow for the safe use of some of these algorithms and techniques. However, this should be evaluated on a case-by-case basis.
注：セクション1で説明したように、暗号化技術の使用により、これらのアルゴリズムと手法の一部を安全に使用できる場合があります。ただし、これはケースバイケースで評価する必要があります。
One of the most trivial ways to achieve uniqueness with a low identifier reuse frequency is to produce a linear sequence. This type of algorithm has been employed in the past to generate identifiers of Categories #1, #2, and #4 (please see Section 6 for an analysis of these categories).
識別子の再利用頻度が低いために一意性を達成する最も些細な方法の1つは、線形シーケンスを生成することです。このタイプのアルゴリズムは、カテゴリ＃1、＃2、および＃4の識別子を生成するために過去に採用されてきました（これらのカテゴリの分析については、セクション6を参照してください）。
For example, the following algorithm has been employed (see, e.g., [Morris1985], [Shimomura1995], [Silbersack2005], and [CPNI-TCP]) in a number of operating systems for selecting IP IDs, TCP ephemeral port numbers, etc.:
たとえば、次のアルゴリズムが採用されています（たとえば、[Morris1985]、[Shimomura1995]、[Silbersack2005]、および[CPNI-TCP]）は、IP ID、TCP Ephemeral Port Numbersなどを選択するための多くのオペレーティングシステムで採用しています。。：
/* Initialization code */
next_id = min_id;
id_inc= 1;
/* Transient Numeric ID selection function */
id_range = max_id - min_id + 1;
retry = id_range;
do {
if (next_id == max_id) {
next_id = min_id;
}
else {
next_id = next_id + id_inc;
}
if (suitable_id(next_id)) {
return next_id;
}
retry--;
} while (retry > 0);
return ERROR;
NOTE:
注記：
suitable_id() checks whether a candidate numeric identifier is suitable (e.g., whether it is unique or not).
satable_id（）候補数値識別子が適切かどうかをチェックします（例：それが一意かどうか）。
For obvious reasons, this algorithm results in predictable sequences. Since a global counter is used to generate the transient numeric identifiers ("next_id" in the example above), an entity that learns one numeric identifier can infer past numeric identifiers and predict future values to be generated by the same algorithm. Since the value employed for the increments is known (such as "1" in this case), an attacker can sample two values and learn the number of identifiers that were generated in between the two sampled values. Furthermore, if the counter is initialized, to some known value (e.g., when the system is bootstrapped), the algorithm will leak additional information, such as the number of transmitted fragmented datagrams in the case of an IP ID generator [Sanfilippo1998a] or the system uptime in the case of TCP timestamps [TCPT-uptime].
明らかな理由で、このアルゴリズムは予測可能なシーケンスになります。グローバルカウンターを使用して過渡数値識別子（上記の例で「next_id」）を生成するために使用されるため、1つの数値識別子を学習するエンティティは、過去の数値識別子を推測し、同じアルゴリズムによって生成される将来の値を予測できます。増分に使用される値（この場合は「1」など）が既知であるため、攻撃者は2つの値をサンプリングし、2つのサンプリングされた値の間に生成された識別子の数を学習できます。さらに、カウンターが初期化されている場合、ある程度の既知の値（たとえば、システムがブートストラップされている場合）に、アルゴリズムは、IP IDジェネレーター[sanfilippo1998a]または送信された断片化されたデータグラムの数などの追加情報をリークします。TCPタイムスタンプの場合のシステムアップタイム[TCPT-uptime]。
This algorithm offers a middle ground between the algorithms that generate randomized transient numeric identifiers (such as those described in Sections 7.1.1 and 7.1.2) and those that generate identifiers with a predictable monotonically increasing function (see Appendix A.1).
このアルゴリズムは、ランダム化された一過性数値識別子（セクション7.1.1および7.1.2で説明されているものなど）と、予測可能な単調に増加する機能を持つ識別子を生成するアルゴリズムとの間の中間基盤を提供します（付録A.1を参照）。
/* Initialization code */
next_id = random(); /* Initialization value */
id_rinc = 500; /* Determines the trade-off */
/* Transient Numeric ID selection function */
id_range = max_id - min_id + 1;
retry = id_range;
do {
/* Random increment */
id_inc = (random() % id_rinc) + 1;
if ( (max_id - next_id) >= id_inc){
next_id = next_id + id_inc;
}
else {
next_id = min_id + id_inc - (max_id - next_id);
}
if (suitable_id(next_id)) {
return next_id;
}
retry = retry - id_inc;
} while (retry > 0);
return ERROR;
NOTE:
注記：
random() is a PRNG that returns a pseudorandom unsigned integer number of appropriate size. Beware that "adapting" the length of the output of random() with a modulo operator (e.g., C language's "%") may change the distribution of the PRNG. To preserve a uniform distribution, the rejection sampling technique [Romailler2020] can be used.
RANDAM（）は、適切なサイズの擬似ランダム整数整数数を返すPRNGです。random（）の出力の長さをModulo演算子（C Languageの「％」など）に「適応」すると、PRNGの分布が変更される可能性があることに注意してください。均一な分布を保持するために、拒絶サンプリング手法[Romailler2020]を使用できます。
suitable_id() is a function that checks whether a candidate identifier is suitable (e.g., whether it is unique or not).
satable_id（）は、候補識別子が適切かどうかをチェックする関数です（例：それが一意かどうか）。
This algorithm aims at producing a global monotonically increasing sequence of transient numeric identifiers while avoiding the use of fixed increments, which would lead to trivially predictable sequences. The value "id_rinc" allows for direct control of the trade-off between unpredictability and identifier reuse frequency. The smaller the value of "id_rinc", the more similar this algorithm is to a predicable, global linear identifier generation algorithm (as the one in Appendix A.1). The larger the value of "id_rinc", the more similar this algorithm is to the algorithm described in Section 7.1.1 of this document.
このアルゴリズムは、固定増分の使用を回避しながら、一時的な数値識別子のグローバルな単調に増加するシーケンスを生成することを目的としています。値「ID_RINC」により、予測不可能性と識別子の再利用頻度との間のトレードオフを直接制御できます。「ID_RINC」の値が小さいほど、このアルゴリズムはより類似しています。「ID_RINC」の値が大きいほど、このドキュメントのセクション7.1.1で説明されているアルゴリズムにこのアルゴリズムが類似しています。
When the identifiers wrap, there is a risk of collisions of transient numeric identifiers (i.e., identifier reuse). Therefore, "id_rinc" should be selected according to the following criteria:
識別子がラップすると、一時的な数値識別子（つまり、識別子の再利用）の衝突のリスクがあります。したがって、「ID_RINC」は、次の基準に従って選択する必要があります。
* It should maximize the wrapping time of the identifier space.
* 識別子スペースのラッピング時間を最大化する必要があります。
* It should minimize identifier reuse frequency.
* 識別子の再利用頻度を最小限に抑える必要があります。
* It should maximize unpredictability.
* 予測不可能性を最大化する必要があります。
Clearly, these are competing goals, and the decision of which value of "id_rinc" to use is a trade-off. Therefore, the value of "id_rinc" is at times a configurable parameter so that system administrators can make the trade-off for themselves. We note that the alternative algorithms discussed throughout this document offer better interoperability, security, and privacy properties than this algorithm, and hence, implementation of this algorithm is discouraged.
明らかに、これらは競合する目標であり、使用する「ID_RINC」の価値の決定はトレードオフです。したがって、「ID_RINC」の値は、システム管理者が自分自身のトレードオフを作成できるように、時には構成可能なパラメーターです。このドキュメント全体で説明した代替アルゴリズムは、このアルゴリズムよりも優れた相互運用性、セキュリティ、プライバシープロパティを提供するため、このアルゴリズムの実装が推奨されることに注意してください。
Employing the same identifier across contexts in which stability is not required (i.e., overloading the semantics of transient numeric identifiers) usually has negative security and privacy implications.
安定性が不要なコンテキスト間で同じ識別子を使用すると（つまり、一時的な数値識別子のセマンティクスを過負荷にする）、通常、セキュリティとプライバシーの意味合いが否定的になります。
For example, in order to generate transient numeric identifiers of Category #2 or #3, an implementation or specification might be tempted to employ a source for the numeric identifiers that is known to provide unique values but that may also be predictable or leak information related to the entity generating the identifier. This technique has been employed in the past for, e.g., generating IPv6 IIDs by reusing the MAC address of the underlying network interface card. However, as noted in [RFC7721] and [RFC7707], embedding link-layer addresses in IPv6 IIDs not only results in predictable values but also leaks information about the manufacturer of the underlying network interface card, allows for network activity correlation, and makes address-based scanning attacks feasible.
たとえば、カテゴリ＃2または＃3の一時的な数値識別子を生成するために、実装または仕様は、一意の値を提供することが知られているが、予測可能またはリーク情報に関連する数値識別子のソースを使用するように誘惑される場合があります。識別子を生成するエンティティに。この手法は、基礎となるネットワークインターフェイスカードのMACアドレスを再利用することにより、たとえばIPv6 IIDを生成するために、過去に採用されてきました。ただし、[RFC7721]および[RFC7707]に記載されているように、IPv6 IIDにリンク層アドレスを埋め込むと、予測可能な値をもたらすだけでなく、基礎となるネットワークインターフェイスカードのメーカーに関する情報が漏れ、ネットワークアクティビティの相関を可能にし、アドレスを作成できます。 - ベースのスキャン攻撃は実行可能です。
The authors would like to thank (in alphabetical order) Bernard Aboba, Jean-Philippe Aumasson, Steven Bellovin, Luis León Cárdenas Graide, Spencer Dawkins, Theo de Raadt, Guillermo Gont, Joseph Lorenzo Hall, Gre Norcie, Colin Perkins, Vincent Roca, Shivan Sahib, Rich Salz, Martin Thomson, and Michael Tüxen for providing valuable comments on earlier draft versions of this document.
著者は（アルファベット順）バーナード・アボバ、ジャン・フィリップ・オマッソン、スティーブン・ベロビン、ルイス・レオン・カルデナス・グレイデ、テオ・デ・ラード、ギレルモ・ゴント、ジョセフ・ローレンツォ・ホールShivan Sahib、Rich Salz、Martin Thomson、MichaelTüxenは、このドキュメントの以前のドラフトバージョンに関する貴重なコメントを提供してくれたことです。
The authors would like to thank Shivan Sahib and Christopher Wood for their guidance during the publication process of this document.
著者は、この文書の公開プロセス中のガイダンスについて、シヴァン・サヒブとクリストファー・ウッドに感謝したいと思います。
The authors would like to thank Jean-Philippe Aumasson and Mathew D. Green (John Hopkins University) for kindly answering a number of questions.
著者は、Jean-Philippe AumassonとMathew D. Green（John Hopkins University）に、多くの質問に答えてくれたことに感謝します。
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