[要約] RFC 9416 は、ネットワークプロトコルで使用される一時的な数値識別子に関するセキュリティ考慮事項をまとめ、RFC 3552 を更新して将来のプロトコルや実装の欠陥を防ぐことを目的としています。セキュリティ上の問題を回避するために、暗号技術を使用している場合でも、慎重な一時的な数値識別子の仕様が必要です。
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 9416 SI6 Networks
BCP: 72 I. Arce
Updates: 3552 Quarkslab
Category: Best Current Practice July 2023
ISSN: 2070-1721
Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks on implementations, ranging from Denial of Service (DoS) or data injection to information leakages that can be exploited by pervasive monitoring. Due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed, since these techniques might not mitigate all the associated issues. This document formally updates RFC 3552, incorporating requirements for transient numeric identifiers, to prevent flaws in future protocols and implementations.
TCP/IPスイートなどのプロトコルの一時的な数値識別子の選択は、歴史的に、サービスの拒否（DOS）またはデータの注入から、広範な監視によって活用される可能性のある情報漏れまで、実装に対する多くの攻撃につながりました。これらの手法は関連するすべての問題を軽減しない可能性があるため、暗号化手法が採用されている場合でも、一時的な数値識別子の仕様におけるデューデリジェンスが必要です。このドキュメントは、RFC 3552を正式に更新し、一時的な数値識別子の要件を組み込み、将来のプロトコルと実装の欠陥を防ぎます。
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPSの詳細については、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/rfc9416.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9416で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. Issues with the Specification of Transient Numeric Identifiers
4. Common Flaws in the Generation of Transient Numeric Identifiers
5. Requirements for Transient Numeric Identifiers
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
Networking protocols employ a variety of transient numeric identifiers for different protocol objects, such as IPv4 and IPv6 Identification values [RFC0791] [RFC8200], IPv6 Interface Identifiers (IIDs) [RFC4291], transport-protocol ephemeral port numbers [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC9293], NTP Reference IDs (REFIDs) [RFC5905], and DNS IDs [RFC1035]. These identifiers typically have specific requirements (e.g., uniqueness during a specified period of time) that must be satisfied such that they do not result in negative interoperability implications, and an associated failure severity when such requirements are not met [RFC9415].
ネットワーキングプロトコルは、IPv4およびIPv6識別値[RFC0791] [RFC8200]、IPv6インターフェイス識別子（IID）[RFC4291]、輸送中間ムラーポート[RFC6056]、TCP初期など、さまざまなプロトコルオブジェクトのさまざまな過渡数値識別子を採用しています。シーケンス番号（ISNS）[RFC9293]、NTP参照ID（REFIDS）[RFC5905]、およびDNS IDS [RFC1035]。これらの識別子には通常、特定の要件（特定の期間中の単一性など）があり、否定的な相互運用性への影響をもたらさないように満たさなければなりません。
NOTE: Some documents refer to the DNS ID as the DNS "Query ID" or "TxID".
注：一部のドキュメントでは、DNS IDをDNS「クエリID」または「TXID」と呼びます。
For more than 30 years, a large number of implementations of IETF protocols have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection to information leakages that could be exploited for pervasive monitoring [RFC7258]. The root cause of these issues has been, in many cases, the poor selection of transient numeric identifiers in such protocols, usually as a result of insufficient or misleading specifications. While it is generally trivial to identify an algorithm that can satisfy the interoperability requirements of a given transient numeric identifier, empirical evidence exists that doing so without negatively affecting the security and/or privacy properties of the aforementioned protocols is prone to error [RFC9414].
30年以上にわたり、IETFプロトコルの多数の実装がさまざまな攻撃の対象となり、サービス拒否（DOS）またはデータインジェクションから、広範な監視に利用できる情報漏れに至るまでの影響があります[RFC7258]。これらの問題の根本的な原因は、多くの場合、このようなプロトコルにおける一時的な数値識別子の選択が不十分であり、通常は不十分または誤解を招く仕様の結果です。一般に、特定の一時的な数値識別子の相互運用性要件を満たすことができるアルゴリズムを識別することは些細なことですが、前述のプロトコルのセキュリティおよび/またはプライバシー特性に悪影響を与えることなくそうすることは、エラーが発生しやすいという経験的証拠が存在します[RFC9414]。
For example, implementations have been subject to security and/or privacy issues resulting from:
たとえば、実装は、次の結果として生じるセキュリティおよび/またはプライバシーの問題の対象となっています。
* predictable IPv4 or IPv6 Identification values (e.g., see [Sanfilippo1998a], [RFC6274], and [RFC7739]),
* 予測可能なIPv4またはIPv6識別値（たとえば、[sanfilippo1998a]、[rfc6274]、および[rfc7739]を参照）、
* predictable IPv6 IIDs (e.g., see [RFC7217], [RFC7707], and [RFC7721]),
* 予測可能なIPv6 IID（例：[RFC7217]、[RFC7707]、および[RFC7721]を参照）、
* predictable transport-protocol ephemeral port numbers (e.g., see [RFC6056] and [Silbersack2005]),
* 予測可能なトランスポートプロトコールの一時的なポート番号（例：[RFC6056]および[SilberSack2005]を参照）、
* predictable TCP Initial Sequence Numbers (ISNs) (e.g., see [Morris1985], [Bellovin1989], and [RFC6528]),
* 予測可能なTCP初期シーケンス番号（ISNS）（たとえば、[Morris1985]、[Bellovin1989]、および[RFC6528]を参照）、
* predictable initial timestamps in TCP timestamps options (e.g., see [TCPT-uptime] and [RFC7323]), and
* TCPタイムスタンプのオプションの予測可能な初期タイムスタンプ（例：[TCPT-uptime]および[RFC7323]を参照）、および
* predictable DNS IDs (see, e.g., [Schuba1993] and [Klein2007]).
* 予測可能なDNS IDS（例えば[Schuba1993]および[Klein2007]を参照）。
Recent history indicates that, when new protocols are standardized or new protocol implementations are produced, the security and privacy properties of the associated transient numeric identifiers tend to be overlooked, and inappropriate algorithms to generate such identifiers are either suggested in the specifications or selected by implementers. As a result, advice in this area is warranted.
最近の履歴は、新しいプロトコルが標準化されているか、新しいプロトコルの実装が生成された場合、関連する一過性の数値識別子のセキュリティとプライバシーのプロパティが見落とされる傾向があり、そのような識別子を生成するための不適切なアルゴリズムは、実装者によって提案されるか、実装者によって選択されていることを示しています。。その結果、この分野でのアドバイスが保証されます。
We note that the use of cryptographic techniques for confidentiality and authentication might not eliminate all the issues associated with predictable transient numeric identifiers. Therefore, due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed.
機密性と認証のために暗号化技術を使用すると、予測可能な過渡数値識別子に関連するすべての問題が排除されない可能性があることに注意してください。したがって、暗号化手法が採用されている場合でも、過渡数値識別子の仕様におけるデューデリジェンスが必要です。
NOTE: 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. These information leakages could in turn be leveraged to perform other devastating attacks (please see [RFC9415] for further details).
注：たとえば、暗号化認証は、予測可能な過渡数値識別子（「シーケンス番号」など）が存在する場合でも、データインジェクション攻撃を容易に軽減できます。ただし、一時的な数値識別子を生成するための欠陥のあるアルゴリズム（グローバルカウンターなど）の使用は、暗号化手法が採用されている場合でも、情報漏れをもたらす可能性があります。これらの情報漏れは、他の壊滅的な攻撃を実行するために活用できます（詳細については[RFC9415]を参照してください）。
Section 3 provides an overview of common flaws in the specification of transient numeric identifiers. Section 4 provides an overview of common flaws in the generation of transient numeric identifiers and their associated security and privacy implications. Finally, Section 5 provides key guidelines for protocol designers.
セクション3では、過渡数値識別子の仕様における一般的な欠陥の概要を説明します。セクション4では、一時的な数値識別子の生成における一般的な欠陥の概要と、それに関連するセキュリティとプライバシーへの影響について説明します。最後に、セクション5では、プロトコル設計者の重要なガイドラインを説明します。
Transient Numeric Identifier:
一時的な数値識別子：
A data object in a protocol specification that can be used to definitely distinguish a protocol object (a datagram, network interface, transport-protocol endpoint, session, etc.) from all other objects of the same type, in a given context. Transient numeric identifiers are usually defined as a series of bits and represented using integer values. These identifiers are typically dynamically selected, as opposed to statically assigned numeric identifiers (e.g., see [IANA-PROT]). We note that different transient numeric identifiers may have additional requirements or properties depending on their specific use in a protocol. We use the term "transient numeric identifier" (or simply "numeric identifier" or "identifier" as short forms) as a generic term to refer to any data object in a protocol specification that satisfies the identification property stated above.
プロトコル仕様のデータオブジェクトは、特定のコンテキストで、同じタイプの他のすべてのオブジェクトからプロトコルオブジェクト（データグラム、ネットワークインターフェイス、トランスポートプロトコルエンドポイント、セッションなど）を明確に区別するために使用できます。通常、一時的な数値識別子は一連のビットとして定義され、整数値を使用して表されます。これらの識別子は通常、静的に割り当てられた数値識別子とは対照的に動的に選択されます（例：[IANA-Prot]を参照）。さまざまな一時的な数値識別子には、プロトコルでの特定の使用に応じて、追加の要件またはプロパティがある場合があることに注意してください。上記の識別プロパティを満たすプロトコル仕様のデータオブジェクトを参照するための一般的な用語として、「過渡数値識別子」（または単に「数値識別子」または「識別子」）を一般的な用語として使用します。
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" and "hard".
特定の識別子の相互運用性要件に準拠しなかったことの相互運用性の結果。重大度は、障害の修復のために失われたシステムの損傷および/または時間によって決定される、失敗の最悪の潜在的な結果を考慮します。このドキュメントでは、「ソフト」と「ハード」という2種類の障害の重大度を定義します。
Soft Failure:
ソフト障害：
A recoverable condition in which a protocol does not operate in the prescribed manner but normal operation can be resumed automatically in a short period of time. For example, a simple packet-loss event that is subsequently recovered with a retransmission can be considered a soft failure.
プロトコルが規定の方法で動作しないが、通常の操作は短期間で自動的に再開できる回復可能な条件。たとえば、その後再送信で回復する単純なパケットロスイベントは、ソフト障害と見なすことができます。
Hard Failure:
困難な失敗：
A non-recoverable condition in which a protocol does not operate in the prescribed manner or it operates with excessive degradation of service. For example, an established TCP connection that is aborted due to an error condition constitutes, from the point of view of the transport protocol, a hard failure, since it enters a state from which normal operation cannot be recovered.
プロトコルが規定された方法で動作しないか、サービスの過度の劣化で動作することのない非回復不可能な条件。たとえば、輸送プロトコルの観点からは、通常の操作が回復できない状態に入るため、輸送プロトコルの観点からは、エラー条件のために中止される確立されたTCP接続が構成されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Recent work on transient numeric identifier usage in protocol specifications and implementations [RFC9414] [RFC9415] revealed that most of the issues discussed in this document arise as a result of one of the following conditions:
プロトコル仕様と実装における一時的な数値識別子使用に関する最近の研究[RFC9414] [RFC9415]は、このドキュメントで説明した問題のほとんどが、次の条件の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
* 指定された要件を単に遵守できないプロトコル実装
Both under specifying and over specifying transient numeric identifiers is hazardous. TCP local ports [RFC0793], as well as DNS IDs [RFC1035], were originally under specified, leading to implementations that resulted in predictable values and thus were vulnerable to numerous off-path attacks. Over specification, as for IPv6 Interface Identifiers (IIDs) [RFC4291] and IPv6 Identification values [RFC2460], left implementations unable to respond to security and privacy issues stemming from the mandated or recommended algorithms -- IPv6 IIDs need not expose privacy-sensitive link-layer addresses, and predictable IPv6 Fragment Header Identification values invite the same off-path attacks that plague TCP.
一時的な数値識別子を指定する下および超過の両方の両方が危険です。TCPローカルポート[RFC0793]、およびDNS IDS [RFC1035]は元々指定されていたため、予測可能な値をもたらす実装につながり、したがって多数のパス攻撃に対して脆弱でした。IPv6インターフェイス識別子（IIDS）[RFC4291]およびIPv6識別値[RFC2460]およびIPv6インターフェイスの識別値[RFC2460]のように、仕様を超えて、義務付けられたまたは推奨アルゴリズムに起因するセキュリティおよびプライバシーの問題に対応できないままの実装 - IPv6 IIDは、プライバシーに敏感なリンクを公開する必要はありません-layerアドレス、および予測可能なIPv6フラグメントヘッダー識別値は、TCPと同じパス攻撃と同じオフパス攻撃を招きます。
Finally, there are protocol implementations that simply fail to comply with existing protocol specifications. That is, appropriate guidance is provided by the protocol specification (whether it be the core specification or an update to it), but an implementation simply fails to follow such guidance. For example, some popular operating systems still fail to implement transport-protocol port randomization, as specified in [RFC6056].
最後に、既存のプロトコル仕様に単に準拠していないプロトコルの実装があります。つまり、プロトコル仕様（コア仕様であろうと更新であろうと）によって適切なガイダンスが提供されますが、実装はそのようなガイダンスに従うことができません。たとえば、[RFC6056]で指定されているように、一部の一般的なオペレーティングシステムは依然として輸送プロトコルポートランダム化の実装に失敗しています。
Clear specification of the interoperability requirements for the transient numeric identifiers will help identify possible algorithms that could be employed to generate them and also make evident if such identifiers are being over specified. A protocol specification will usually also benefit from a vulnerability assessment of the transient numeric identifiers they specify to prevent the corresponding considerations from being overlooked.
過渡数値識別子の相互運用性要件の明確な指定は、それらを生成するために使用できる可能性のあるアルゴリズムを識別し、そのような識別子が過剰に指定されている場合に明らかにするのに役立ちます。プロトコル仕様は通常、対応する考慮事項が見落とされないように指定した過渡数値識別子の脆弱性評価の恩恵も恩恵を受けます。
This section briefly notes common flaws associated with the generation of transient numeric identifiers. Such common flaws include, but are not limited to:
このセクションは、過渡数値識別子の生成に関連する一般的な欠陥を簡単に示します。このような一般的な欠陥には含まれますが、これらに限定されません。
* employing trivial algorithms (e.g., global counters) that result in predictable identifiers,
* 予測可能な識別子をもたらす些細なアルゴリズム（グローバルカウンターなど）を使用する
* employing the same identifier across contexts in which constancy is not required,
* 恒常性が不要なコンテキスト全体で同じ識別子を使用すると、
* reusing identifiers across different protocols or layers of the protocol stack,
* プロトコルスタックのさまざまなプロトコルまたはレイヤーにわたって識別子を再利用する
* initializing counters or timers to constant values when such initialization is not required,
* そのような初期化が不要な場合、カウンターまたはタイマーを一定の値に初期化する、
* employing the same increment space across different contexts, and
* 異なるコンテキストで同じ増分空間を使用し、
* use of flawed Pseudorandom Number Generators (PRNGs).
* 欠陥のある擬似ランダム数ジェネレーター（PRNGS）の使用。
Employing trivial algorithms for generating the identifiers means that any node that is able to sample such identifiers can easily predict future identifiers employed by the victim node.
識別子を生成するために些細なアルゴリズムを使用すると、そのような識別子をサンプリングできるノードは、被害者ノードで採用されている将来の識別子を簡単に予測できることを意味します。
When one identifier is employed across contexts where such constancy is not needed, activity correlation is made possible. For example, employing an identifier that is constant across networks allows for node tracking across networks.
そのような恒常性が必要ないコンテキスト全体で1つの識別子が使用される場合、活動相関が可能になります。たとえば、ネットワーク全体で一定の識別子を使用すると、ネットワーク全体でノード追跡が可能になります。
Reusing identifiers across different layers or protocols ties the security and privacy properties of the protocol reusing the identifier to the security and privacy properties of the original identifier (over which the protocol reusing the identifier may have no control regarding its generation). Besides, when reusing an identifier across protocols from different layers, the goal of isolating the properties of a layer from those of another layer is broken, and the vulnerability assessment may be harder to perform since the combined system, rather than each protocol in isolation, will have to be assessed.
異なるレイヤーまたはプロトコルにわたって識別子を再利用すると、識別子を元の識別子のセキュリティとプライバシープロパティに再利用するプロトコルのセキュリティとプライバシープロパティを結びます（識別子を再利用するプロトコルには、その生成に関して制御できない場合があります）。さらに、異なるレイヤーからのプロトコル間で識別子を再利用する場合、別のレイヤーの特性からレイヤーのプロパティを分離するという目標が壊れており、各プロトコルではなく、組み合わせたシステムではなく、脆弱性評価を実行するのが難しい場合があります。評価する必要があります。
At times, a protocol needs to convey order information (whether it be sequence, timing, etc.). In many cases, there is no reason for the corresponding counter or timer to be initialized to any specific value, e.g., at system bootstrap. Similarly, there may not be a need for the difference between successive counter values to be predictable.
時には、プロトコルは注文情報（シーケンス、タイミングなど）を伝える必要があります。多くの場合、対応するカウンターまたはタイマーが特定の値、たとえばSystem Bootstrapに初期化される理由はありません。同様に、連続したカウンター値の違いが予測可能である必要がない場合があります。
A node that implements a per-context linear function may share the increment space among different contexts (please see the "Simple PRF-Based Algorithm" section in [RFC9415]). Sharing the same increment space allows an attacker that can sample identifiers in other context to, e.g., learn how many identifiers have been generated between two sampled values.
コンテキストごとの線形関数を実装するノードは、異なるコンテキスト間で増分空間を共有する場合があります（[RFC9415]の「単純なPRFベースのアルゴリズム」セクションを参照してください）。同じ増分スペースを共有すると、他のコンテキストで識別子をサンプリングできる攻撃者が、たとえば、2つのサンプリングされた値の間に生成された識別子の数を学習できます。
Finally, some implementations have been found to employ flawed PRNGs (e.g., see [Klein2007]).
最後に、いくつかの実装は、欠陥のあるPRNGを採用することがわかっています（例：[Klein2007]を参照）。
Protocol specifications that employ transient numeric identifiers MUST explicitly specify the interoperability requirements for the aforementioned transient numeric identifiers (e.g., required properties such as uniqueness, along with the failure severity if such requirements are not met).
過渡数値識別子を使用するプロトコル仕様は、前述の過渡数値識別子の相互運用性要件を明示的に指定する必要があります（たとえば、そのような要件が満たされない場合の障害の重大度などの必要なプロパティなど）。
A vulnerability assessment of the aforementioned transient numeric identifiers MUST be performed as part of the specification process. Such vulnerability assessment should cover, at least, spoofing, tampering, repudiation, information disclosure, DoS, and elevation of privilege.
前述の過渡数値識別子の脆弱性評価は、仕様プロセスの一部として実行する必要があります。このような脆弱性評価は、少なくとも、スプーフィング、改ざん、否認、情報の開示、DOS、および特権の高さをカバーする必要があります。
NOTE: Sections 8 and 9 of [RFC9415] provide a general vulnerability assessment of transient numeric identifiers, along with a vulnerability assessment of common algorithms for generating transient numeric identifiers. Please see [Shostack2014] for further guidance on threat modeling.
注：[RFC9415]のセクション8および9は、過渡数値識別子を生成するための共通アルゴリズムの脆弱性評価とともに、一時的な数値識別子の一般的な脆弱性評価を提供します。脅威モデリングに関するさらなるガイダンスについては、[shostack2014]を参照してください。
Protocol specifications SHOULD NOT employ predictable transient numeric identifiers, except when such predictability is the result of their interoperability requirements.
プロトコル仕様は、そのような予測可能性が相互運用性要件の結果である場合を除き、予測可能な過渡数値識別子を採用してはなりません。
Protocol specifications that employ transient numeric identifiers SHOULD recommend an algorithm for generating the aforementioned transient numeric identifiers that mitigates the vulnerabilities identified in the previous step, such as those discussed in [RFC9415].
過渡数値識別子を使用するプロトコル仕様は、[RFC9415]で説明したものなど、前のステップで特定された脆弱性を軽減する前述の過渡数値識別子を生成するためのアルゴリズムを推奨する必要があります。
As discussed in Section 1, use of cryptographic techniques for confidentiality and authentication might not eliminate all the issues associated with predictable transient numeric identifiers. Therefore, the advice from this section MUST still be applied for cases where cryptographic techniques for confidentiality or authentication are employed.
セクション1で説明したように、機密性と認証のための暗号化手法の使用は、予測可能な一時的な数値識別子に関連するすべての問題を排除しない場合があります。したがって、このセクションのアドバイスは、機密性または認証のための暗号化技術が採用されている場合にまだ適用されなければなりません。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This entire document is about the security and privacy implications of transient numeric identifiers and formally updates [RFC3552] such that the security and privacy implications of transient numeric identifiers are addressed when writing the "Security Considerations" section of future RFCs.
このドキュメント全体は、一時的な数値識別子のセキュリティとプライバシーへの影響に関するものであり、将来のRFCSの「セキュリティに関する考慮事項」セクションを記述する際に、一時的な数値識別子のセキュリティとプライバシーの影響が対処されるように、[RFC3552]を正式に更新します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[IANA-PROT]
IANA, "Protocol Registries",
<https://www.iana.org/protocols>.
[Klein2007]
Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability", October 2007,
<https://dl.packetstormsecurity.net/papers/attack/OpenBSD_
DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vuln
erability.pdf>.
[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>.
[PREDICTABLE-NUMERIC-IDS]
Gont, F. and I. Arce, "Security and Privacy Implications
of Numeric Identifiers Employed in Network Protocols",
Work in Progress, Internet-Draft, draft-gont-predictable-
numeric-ids-03, 11 March 2019,
<https://datatracker.ietf.org/doc/html/draft-gont-
predictable-numeric-ids-03>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC9415] Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", RFC 9415, DOI 10.17487/RFC9415, July
2023, <https://www.rfc-editor.org/info/rfc9415>.
[Sanfilippo1998a]
Sanfilippo, S., "about the ip header id", message to the
Bugtraq mailing list, December 1998,
<https://seclists.org/bugtraq/1998/Dec/48>.
[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>.
[Shostack2014]
Shostack, A., "Threat Modeling: Designing for Security",
Wiley, 1st edition, February 2014.
[Silbersack2005]
Silbersack, M., "Improving TCP/IP security through
randomization without sacrificing interoperability",
EuroBSDCon 2005 Conference, January 2005,
<http://www.silby.com/eurobsdcon05/
eurobsdcon_silbersack.pdf>.
[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>.
The authors would like to thank (in alphabetical order) Bernard Aboba, Brian Carpenter, Roman Danyliw, Theo de Raadt, Lars Eggert, Russ Housley, Benjamin Kaduk, Charlie Kaufman, Erik Kline, Alvaro Retana, Joe Touch, Michael Tüxen, Robert Wilton, and Paul Wouters for providing valuable comments on draft versions of this document.
著者は、（アルファベット順の順序で）バーナード・アボバ、ブライアン・カーペンター、ローマン・ダニリウ、テオ・デ・ラード、ラース・エガート、ラス・ヒューズリー、ベンジャミン・カドゥク、チャーリー・カウフマン、エリック・クライン、アルバロ・レタナ、ジョー・タッチ、マイケル・テュクスン、ロバート・ウィルトン、およびこのドキュメントのドラフトバージョンに関する貴重なコメントを提供するためのPaul Wouters。
The authors would like to thank (in alphabetical order) Steven Bellovin, Joseph Lorenzo Hall, and Gre Norcie for providing valuable comments on [PREDICTABLE-NUMERIC-IDS], on which the present document is based.
著者は、（アルファベット順の）スティーブンベロビン、ジョセフロレンツォホール、グレノーチーに感謝したいと思います。
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