[要約] この文書は、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のPrivacy Enhancements and Assessments Research Group（PEARG）の成果物です。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは Internet Standards Track の仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet 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）のPrivacy Enhancements and Assessments Research Groupのコンセンサスを表しています。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.
このドキュメントの現在のステータス、正誤表、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9415 で入手できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (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初期シーケンス番号（ISN）[RFC9293]、NTP参照ID（REFID）[RFC5905]、DNS ID [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初期シーケンス番号（ISN）（たとえば、[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 ID（例えば[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:
ソフト障害（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:
ハード障害（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初期シーケンス番号（ISN）に関連する脆弱性を分析する場合、攻撃者は他の2つのホスト間のTCP接続に対応するネットワークトラフィックをキャプチャできないと想定します。ただし、攻撃者はこれらのホストのいずれかと通信（例：いずれかと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インターフェイス識別子から構成される一連のターゲットアドレスをプローブ（探索）することで、ホスト追跡を実行する可能性があります。あるいは、被害者ホストがある場所から別の場所に移動し、攻撃者が運用するサーバーと通信することで構成済みのアドレスを公開する場合、攻撃者はホスト追跡を実行する可能性があります。これらのシナリオはいずれも、攻撃者が攻撃者に明示的に向けられていないトラフィックを観測する必要はないことに注意してください。
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].
注：アクティブなOPENリクエストにおける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初期シーケンス番号（ISN）の相互運用性要件はありません。これは、TIME-WAIT状態とTCPの「quiet time」の概念が、以前の接続インカーネーションからの古いセグメントを処理するためです。ただし、広く普及している最適化により、着信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インスタンスによって採用される *初期* TCPタイムスタンプ（つまり、SYNビットがセットされたセグメント内のTS Value (TSval)）に対する相互運用性要件はありません。ただし、一部の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宛先アドレス、トランスポートプロトコル送信元ポート、およびトランスポートプロトコル宛先ポートとともに、DNS要求と応答を照合するために使用されます。ただし、実装はそのセット{IP送信元アドレス, IP宛先アドレス, トランスポートプロトコル送信元ポート, トランスポートプロトコル宛先ポート, 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（"Uniform Deviates"）は、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]へのインターフェイスを提供します。たとえば、GNU/LinuxのCSPRNG実装はgetentropy(3)インターフェイス[GETENTROPY]を介して利用可能であり、OpenBSDのCSPRNG実装はarc4random(3)およびarc4random_uniform(3)インターフェイス[ARC4RANDOM]を介して利用可能です。利用可能な場合、これらのCSPRNGは、例えばPOSIX [POSIX] random(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.
カテゴリ＃1の一時的な数値識別子を選択するためにCSPRNGが容易に利用できないシナリオでは、通常の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").
このカテゴリの一時的な数値識別子の衝突はソフト障害につながるだけであるという前提があるため、多くの場合、アルゴリズムは選択した識別子の適合性をチェックする必要がないかもしれないことに注意してください（つまり、以下で説明するsuitable_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.
random() は、適切なサイズの擬似乱数の符号なし整数を返すPRNGです。剰余演算子（C言語の「%」など）を使用してrandom()の出力の長さを「適合」させると、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.
suitable_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.
random() は、適切なサイズの擬似乱数の符号なし整数を返すPRNGです。剰余演算子（C言語の「%」など）を使用してrandom()の出力の長さを「適合」させると、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エフェメラルポートや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.
suitable_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() は、ステートレスで安定したコンテキストごとのオフセットを提供します。ここで、CONTEXTは、指定されたコンテキストを定義するすべての要素の連結です。
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).
たとえば、このアルゴリズムがネットワークインターフェイスおよびステートレスアドレス自動構成（SLAAC）プレフィックスごとに一意のIPv6 IIDを生成すると予想される場合、CONTEXTは、たとえば、ネットワークインターフェイスインデックスとSLAAC自動構成プレフィックスの連結である必要があります（安定したIPv6アドレスの生成のためのこのアルゴリズムの実装については[RFC7217]を参照してください）。
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() の結果は変数「offset」に保存されます。セクション7.1.1で説明されているアルゴリズムと同様の方法で、結果の識別子を範囲[min_id, max_id]に制限しているため、この変数はストレージタイプの範囲内で任意の値をとることができます。
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の定数増分を採用しています。1以外の値を使用すると、数値識別子の再利用頻度が増加する可能性があるという犠牲を払って、一部の情報漏洩（以下を参照）を軽減するのに役立ちます。上記のコードは、アルゴリズムで採用されている増分（id_inc）が、数値識別子の可能な値の数（つまり、「max_id - min_id + 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.
random() は、適切なサイズの擬似乱数の符号なし整数を返すPRNGです。剰余演算子（C言語の「%」など）を使用してrandom()の出力の長さを「適合」させると、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.
suitable_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.
suitable_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() は、指定された各コンテキスト（「CONTEXT」で識別される）に対して、ステートレス、安定、および予測不可能なオフセットを提供します。「オフセット」と「カウンター」変数の両方は、セクション7.1.1で説明されているアルゴリズムと同様の方法で結果の識別子を範囲[min_id, max_id]内に制限しているため、ストレージタイプの範囲内で任意の値を取ることができます。これにより、「カウンター」変数を単純に増やし、符号なし整数のラップアラウンドに依存することができます。
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".
このアルゴリズムは、識別子を選択するためにグローバルカウンター（「counter」）を使用するため（つまり、すべてのカウンターが同じ増分空間を共有する）、このアルゴリズムは情報漏洩をもたらすことに注意する必要があります（セクション8.2で説明）。たとえば、このアルゴリズムがTCPエフェメラルポートを選択するために使用され、攻撃者がクライアントに攻撃者制御システムへの新しいTCP接続を定期的に確立するように強制できる場合（または攻撃者が観測可能なルーティングパスを介して）、攻撃者は連続した送信元ポート値を差し引くことで、その期間内に被害者のホストによってグローバルに確立された発信TCP接続の総数を取得できます（もちろん、ラップアラウンドの問題や5タプルの衝突は除きます）。この情報漏洩は、increment() に定数「1」を返すのではなく、増分（つまり、increment() 関数）に対して小さなランダム値を使用することで部分的に軽減できます。
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:
単一のグローバルな「counter」変数を維持することと、2**N個の「counter」変数を維持すること（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.
「table[]」は、上記の擬似コードの初期化コードで示されるように、ランダム値で初期化できます。
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[]」配列は、特定のコンテキストの連続した一時的な数値識別子が単調増加することを保証します。増分空間はTABLE_LENGTH個の異なる空間に分離されるため、識別子の再利用頻度は、セクション7.4.2のアルゴリズムのそれよりも（確率的に）低くなります。つまり、1つの指定されたコンテキストの識別子の生成は、必ずしも他のコンテキストの識別子シーケンスの増加をもたらすわけではありません。「table[]」のサイズは、異なる識別子シーケンスの数を制限するのではなく、むしろ *増分空間* をTABLE_LENGTH個の異なる空間に分離することに注意してください。選択された一時的な数値識別子シーケンスは、「table[]」からの対応するエントリを「offset」変数の値に追加することで取得されます。これは、実際の識別子シーケンス空間を選択します（セクション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() は特定のコンテキストに対して単調増加シーケンスを生成します。この式で生成された識別子は、一般にCONTEXT内で予測可能です。
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.
つまり、宛先ごとのオフセットがあるが、グローバルなmono()関数（例：グローバルカウンター）を使用する場合、脆弱な実装によって発行された発信接続の総数に関する情報が漏洩します。
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]に記載されている脆弱性はすべて、グローバルなmono()関数（すなわち、グローバルかつ一定の「CONTEXT」）の使用に関連しています。特に、それが線形関数（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検出に関する古典的な参考文献です。Network Mapper [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）アドレスには、対応するネットワークインターフェイスカードを製造したベンダーを識別するOrganizationally Unique Identifier（OUI）が含まれています。これは、可能なネットワークインターフェイスカード（NIC）ベンダーについてある程度の知識を持っている、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]を参照）。同様に、Secure Neighbor Discovery (SEND) [RFC3971]を使用しても、SENDパケットがリンク最大転送ユニット（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で説明されているものなど）は、PRFに依存しています。弱い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 random(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を採用する場合、多くの実装は、剰余演算子（C言語の「%」など）で出力の長さを「適合」させますが、これにより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の一時的な数値識別子を取得することを意図しています。random() が、例えば16ビットの擬似乱数（一様分布）を生成する場合、選択された一時的な数値識別子は不均一な分布となり、範囲0-15535の数値は、範囲15536-49999の数値の2倍の頻度で出現します。
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.
注：たとえば、サンプルコードでは、random() 関数からの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で説明されているアルゴリズムは、各コンテキスト（CONTEXT）に対して生成された一時的な数値識別子に識別可能なパターン（つまり、単調増加シーケンス）をもたらし、したがって、各コンテキスト内でのフィンガープリンティングとネットワークアクティビティの相関を可能にします。
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) は、CONTEXTに対応するカウンターを「id_inc」だけ増加させます。
mono(CONTEXT) reads the counter corresponding to CONTEXT.
mono(CONTEXT) は、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()）をオフセット値に追加することによって生成されます。このオフセット値は攻撃者には不明であり、特定のコンテキスト（CONTEXT）に対して安定しています。
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.
* ほとんどの場合、オフパス攻撃者が予測不可能な識別子をもたらすのは offset()関数です。結果のシーケンスは単調増加することが知られていますが、ランダム化されたオフセット値を使用すると、結果の値が攻撃者に不明になります。
* 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).
* mono() の可能な実装の1つは、mono() を単一のカウンター（セクション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() は、特定のコンテキスト（CONTEXT）に対して生成された識別子の数と相関することができます。したがって、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で説明されているアルゴリズムで生成された一時的な数値識別子は、通常、CONTEXT内でのフィンガープリンティングを可能にします。なぜなら、そのようなコンテキストでは、結果の識別子に識別可能なパターン（つまり、単調増加シーケンス）があるためです。
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.
random() は、適切なサイズの擬似乱数の符号なし整数を返すPRNGです。剰余演算子（C言語の「%」など）を使用してrandom()の出力の長さを「適合」させると、PRNGの分布が変わる可能性があることに注意してください。一様分布を維持するために、棄却サンプリング手法[Romailler2020]を使用できます。
suitable_id() is a function that checks whether a candidate identifier is suitable (e.g., whether it is unique or not).
suitable_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」の値が小さいほど、このアルゴリズムは予測可能なグローバル線形識別子生成アルゴリズム（付録A.1のものなど）に類似します。「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.
著者は、このドキュメントの以前のドラフトバージョンに関する貴重なコメントを提供してくれた（アルファベット順に）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、および Michael Tü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