diff --git a/data/9000/rfc9858-trans.json b/data/9000/rfc9858-trans.json new file mode 100644 index 000000000..509abe23d --- /dev/null +++ b/data/9000/rfc9858-trans.json @@ -0,0 +1,870 @@ +{ + "title": { + "text": "RFC 9858 - Additional Parameter Sets for HSS/LMS Hash-Based Signatures", + "ja": "RFC 9858 - HSS/LMS ハッシュベース署名の追加パラメーター セット" + }, + "number": 9858, + "created_at": "2025-10-15 23:24:14.029721+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Research Task Force (IRTF) S. Fluhrer\nRequest for Comments: 9858 Cisco Systems\nCategory: Informational Q. Dang\nISSN: 2070-1721 NIST\n October 2025", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Additional Parameter Sets for HSS/LMS Hash-Based Signatures", + "section_title": true, + "ja": "HSS/LMS ハッシュベース署名の追加パラメーター セット" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document extends HSS/LMS (RFC 8554) by defining parameter sets that use alternative hash functions. These include hash functions that result in signatures with significantly smaller sizes than the signatures that use the RFC 8554 parameter sets and should have sufficient security.", + "ja": "このドキュメントは、代替ハッシュ関数を使用するパラメータ セットを定義することにより、HSS/LMS (RFC 8554) を拡張します。これらには、RFC 8554 パラメーター セットを使用する署名よりも大幅に小さいサイズの署名が生成され、十分なセキュリティが必要なハッシュ関数が含まれます。" + }, + { + "indent": 3, + "text": "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 Crypto Forum 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.", + "ja": "この文書は Internet Research Task Force (IRTF) の成果物です。IRTF は、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開には適していない可能性があります。この RFC は、インターネット研究タスクフォース (IRTF) の暗号フォーラム研究グループの合意を表しています。IRSG によって公開が承認された文書は、どのレベルのインターネット標準の候補でもありません。RFC 7841 のセクション 2 を参照してください。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This document is not an Internet Standards Track specification; it is published for informational purposes.", + "ja": "この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。" + }, + { + "indent": 3, + "text": "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 Crypto Forum 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.", + "ja": "この文書は Internet Research Task Force (IRTF) の成果物です。IRTF は、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開には適していない可能性があります。この RFC は、インターネット研究タスクフォース (IRTF) の暗号フォーラム研究グループの合意を表しています。IRSG によって公開が承認された文書は、どのレベルのインターネット標準の候補でもありません。RFC 7841 のセクション 2 を参照してください。" + }, + { + "indent": 3, + "text": "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/rfc9858.", + "ja": "この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9858 で入手できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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.", + "ja": "この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n2. Additional Hash Function Definitions\n 2.1. 192-Bit Hash Function Based on SHA-256\n 2.2. 256-Bit Hash Function Based on SHAKE256\n 2.3. 192-Bit Hash Function Based on SHAKE256\n3. Additional LM-OTS Parameter Sets\n4. Additional LMS Parameter Sets\n5. Usage for These Additional Hash Functions within HSS\n6. Parameter Set Selection\n7. Comparisons of 192-Bit and 256-Bit Parameter Sets\n8. Security Considerations\n 8.1. Note on the Version of SHAKE\n9. IANA Considerations\n10. References\n 10.1. Normative References\n 10.2. Informative References\nAppendix A. Test Cases\n A.1. Test Case 1 - SHA-256/192\n A.2. Test Vector for SHAKE256/192\n A.3. Test Vector for SHA-256/256\n A.4. Test Vector for SHA-256/192, W=4\nAcknowledgements\nAuthors' Addresses", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "Stateful hash-based signatures have small private and public keys, are efficient to compute, and are believed to have excellent security. One disadvantage is that the signatures they produce tend to be somewhat large (possibly 1-4 kilobytes). This document defines a set of parameter sets for the HSS/LMS stateful hash-based signature method [RFC8554] that reduce the size of the signature significantly or rely on a hash function other than SHA-256 (to increase cryptodiversity).", + "ja": "ステートフル ハッシュ ベースの署名には小さな秘密キーと公開キーがあり、計算が効率的で、セキュリティが優れていると考えられています。欠点の 1 つは、生成される署名がやや大きくなる傾向があることです (おそらく 1 ～ 4 キロバイト)。この文書は、署名のサイズを大幅に削減するか、(暗号多様性を高めるために) SHA-256 以外のハッシュ関数に依存する、HSS/LMS ステートフル ハッシュベースの署名方法 [RFC8554] の一連のパラメーター セットを定義します。" + }, + { + "indent": 3, + "text": "This document represents the consensus of the Crypto Forum Research Group (CFRG) in the IRTF. It is not an IETF product and is not a standard.", + "ja": "この文書は、IRTF の暗号フォーラム研究グループ (CFRG) の総意を表しています。これは IETF 製品ではなく、標準でもありません。" + }, + { + "indent": 3, + "text": "According to official definitions and common usage, a Leighton-Micali Signature (LMS) is a stateful hash-based signature scheme that is based on a single-level Merkle tree. The Hierarchical Signature System (HSS) is a way of binding several LMS signatures together in a hierarchical manner to increase the number of signatures available. Strictly speaking, all the signatures discussed in this document are HSS signatures (even if the HSS signature consists of a single LMS signature). However, it is common to refer to these signatures as \"LMS signatures\". This document uses the term \"HSS/LMS\" to cover both the pedantic and the common meanings.", + "ja": "公式の定義と一般的な使用法によれば、Leighton-Micali Signature (LMS) は、単一レベルのマークル ツリーに基づくステートフル ハッシュ ベースの署名スキームです。階層署名システム (HSS) は、複数の LMS 署名を階層的にバインドして、利用可能な署名の数を増やす方法です。厳密に言えば、このドキュメントで説明するすべての署名は HSS 署名です (HSS 署名が単一の LMS 署名で構成されている場合でも)。ただし、これらの署名を「LMS 署名」と呼ぶのが一般的です。このドキュメントでは、衒学的な意味と一般的な意味の両方をカバーするために「HSS/LMS」という用語を使用します。" + }, + { + "indent": 3, + "text": "This document is intended to be compatible with the NIST document [NIST_SP_800-208].", + "ja": "この文書は、NIST 文書 [NIST_SP_800-208] と互換性を持つことを目的としています。" + }, + { + "indent": 0, + "text": "2. Additional Hash Function Definitions", + "section_title": true, + "ja": "2. 追加のハッシュ関数定義" + }, + { + "indent": 3, + "text": "This section defines three hash functions that are used with the parameter sets defined in Sections 3 and 4. These hash functions are used where SHA-256 is used in the original parameter sets from [RFC8554]. The hash function used is specified by the parameter set that is selected.", + "ja": "このセクションでは、セクション 3 と 4 で定義されたパラメータ セットで使用される 3 つのハッシュ関数を定義します。これらのハッシュ関数は、[RFC8554] の元のパラメータ セットで SHA-256 が使用される場合に使用されます。使用されるハッシュ関数は、選択されたパラメータ セットによって指定されます。" + }, + { + "indent": 0, + "text": "2.1. 192-Bit Hash Function Based on SHA-256", + "section_title": true, + "ja": "2.1. SHA-256 に基づく 192 ビット ハッシュ関数" + }, + { + "indent": 3, + "text": "This document defines a SHA-2-based hash function with a 192-bit output. As such, we define SHA-256/192 as a truncated version of SHA-256 [FIPS180]. That is, it is the result of performing a SHA-256 operation to a message and then omitting the final 64 bits of the output. This procedure for truncating the hash output to 192 bits is described in Section 7 of [FIPS180].", + "ja": "このドキュメントでは、192 ビット出力の SHA-2 ベースのハッシュ関数を定義します。そのため、SHA-256/192 を SHA-256 [FIPS180] の短縮バージョンとして定義します。つまり、メッセージに対して SHA-256 操作を実行し、出力の最後の 64 ビットを省略した結果です。ハッシュ出力を 192 ビットに切り詰めるこの手順は、[FIPS180] のセクション 7 で説明されています。" + }, + { + "indent": 3, + "text": "The following test vector illustrates this:", + "ja": "次のテスト ベクトルはこれを示しています。" + }, + { + "indent": 5, + "text": "SHA-256(\"abc\") = ba7816bf 8f01cfea 414140de 5dae2223\n b00361a3 96177a9c b410ff61 f20015ad\nSHA-256/192(\"abc\") = ba7816bf 8f01cfea 414140de 5dae2223\n b00361a3 96177a9c", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "We use the same initial hash value (initialization vector) as the untruncated SHA-256, rather than defining a distinct one, so that we can use a standard SHA-256 hash implementation without modification. In addition, the fact that anyone gets partial knowledge of the SHA-256 hash of a message by examining the SHA-256/192 hash of the same message is not a concern for this application. Each message that is hashed is randomized. Any message being signed includes the C randomizer (a value that is selected by the signer and is included in the hash), which varies per message. Therefore, signing the same message by SHA-256 and by SHA-256/192 will not result in the same value being hashed, and so the latter hash value is not a prefix of the former one. In addition, all hashes include the I identifier, which is included as a part of the signature process in [RFC8554]. This I identifier is selected randomly for each private key (and hence two keys will have different I values with high probability), and so two intermediate hashes computed as a part of signing with two HSS private keys (one with a SHA-256 parameter set and one with a SHA-256/192 parameter set) will also be distinct with high probability.", + "ja": "標準の SHA-256 ハッシュ実装を変更せずに使用できるように、別個のハッシュ値を定義するのではなく、切り捨てられていない SHA-256 と同じ初期ハッシュ値 (初期化ベクトル) を使用します。さらに、同じメッセージの SHA-256/192 ハッシュを調べることで、メッセージの SHA-256 ハッシュの部分的な知識が誰でも得られるという事実は、このアプリケーションでは問題になりません。ハッシュ化される各メッセージはランダム化されます。署名されるメッセージには C ランダマイザー (署名者によって選択され、ハッシュに含まれる値) が含まれており、これはメッセージごとに異なります。したがって、SHA-256 と SHA-256/192 で同じメッセージに署名しても、同じ値がハッシュされることはなく、後者のハッシュ値は前者のハッシュ値のプレフィックスではありません。さらに、すべてのハッシュには I 識別子が含まれており、これは [RFC8554] の署名プロセスの一部として含まれています。この I 識別子は秘密キーごとにランダムに選択されます (したがって、2 つのキーは高い確率で異なる I 値を持つことになります)。そのため、2 つの HSS 秘密キー (SHA-256 パラメーター セットを持つ 1 つと SHA-256/192 パラメーター セットを持つ 1 つ) を使用した署名の一部として計算される 2 つの中間ハッシュも、高い確率で区別されます。" + }, + { + "indent": 0, + "text": "2.2. 256-Bit Hash Function Based on SHAKE256", + "section_title": true, + "ja": "2.2. SHAKE256に基づく256ビットハッシュ関数" + }, + { + "indent": 3, + "text": "This document defines a SHAKE-based hash function with a 256-bit output. As such, we define SHAKE256/256 to be the first 256 bits of the SHAKE256 extendable-output function (XOF). That is, it is the result of performing a SHAKE-256 operation to a message and then using the first 256 bits of output. See [FIPS202] for more detail.", + "ja": "このドキュメントでは、256 ビット出力の SHAKE ベースのハッシュ関数を定義します。そのため、SHAKE256/256 を SHAKE256 拡張可能出力関数 (XOF) の最初の 256 ビットとして定義します。つまり、メッセージに対して SHAKE-256 操作を実行し、出力の最初の 256 ビットを使用した結果です。詳細については、[FIPS202] を参照してください。" + }, + { + "indent": 0, + "text": "2.3. 192-Bit Hash Function Based on SHAKE256", + "section_title": true, + "ja": "2.3. SHAKE256に基づく192ビットハッシュ関数" + }, + { + "indent": 3, + "text": "This document defines a SHAKE-based hash function with a 192-bit output. As such, we define SHAKE256/192 to be the first 192 bits of the SHAKE256 XOF. That is, it is the result of performing a SHAKE-256 operation to a message and then using the first 192 bits of output. See [FIPS202] for more detail.", + "ja": "This document defines a SHAKE-based hash function with a 192-bit output.そのため、SHAKE256/192 を SHAKE256 XOF の最初の 192 ビットとして定義します。つまり、これはメッセージに対して SHAKE-256 操作を実行し、出力の最初の 192 ビットを使用した結果です。詳細については、[FIPS202] を参照してください。" + }, + { + "indent": 0, + "text": "3. Additional LM-OTS Parameter Sets", + "section_title": true, + "ja": "3. 追加のLM-OTSパラメータセット" + }, + { + "indent": 3, + "text": "The table below defines the Leighton-Micali One-Time Signature (LM-OTS) parameters that use the hashes defined in Section 2:", + "ja": "以下の表は、セクション 2 で定義されたハッシュを使用する Leighton-Micali ワンタイム署名 (LM-OTS) パラメーターを定義しています。" + }, + { + "indent": 1, + "text": " +=====================+==============+==+=+=====+====+============+\n | Parameter Set Name | H | n|w| p | ls | id |\n +=====================+==============+==+=+=====+====+============+\n | LMOTS_SHA256_N24_W1 | SHA-256/192 |24|1| 200 | 8 | 0x00000005 |\n +---------------------+--------------+--+-+-----+----+------------+\n | LMOTS_SHA256_N24_W2 | SHA-256/192 |24|2| 101 | 6 | 0x00000006 |\n +---------------------+--------------+--+-+-----+----+------------+\n | LMOTS_SHA256_N24_W4 | SHA-256/192 |24|4| 51 | 4 | 0x00000007 |\n +---------------------+--------------+--+-+-----+----+------------+\n | LMOTS_SHA256_N24_W8 | SHA-256/192 |24|8| 26 | 0 | 0x00000008 |\n +---------------------+--------------+--+-+-----+----+------------+\n | LMOTS_SHAKE_N32_W1 | SHAKE256/256 |32|1| 265 | 7 | 0x00000009 |\n +---------------------+--------------+--+-+-----+----+------------+\n | LMOTS_SHAKE_N32_W2 | SHAKE256/256 |32|2| 133 | 6 | 0x0000000A |\n +---------------------+--------------+--+-+-----+----+------------+\n | LMOTS_SHAKE_N32_W4 | SHAKE256/256 |32|4| 67 | 4 | 0x0000000B |\n +---------------------+--------------+--+-+-----+----+------------+\n | LMOTS_SHAKE_N32_W8 | SHAKE256/256 |32|8| 34 | 0 | 0x0000000C |\n +---------------------+--------------+--+-+-----+----+------------+\n | LMOTS_SHAKE_N24_W1 | SHAKE256/192 |24|1| 200 | 8 | 0x0000000D |\n +---------------------+--------------+--+-+-----+----+------------+\n | LMOTS_SHAKE_N24_W2 | SHAKE256/192 |24|2| 101 | 6 | 0x0000000E |\n +---------------------+--------------+--+-+-----+----+------------+\n | LMOTS_SHAKE_N24_W4 | SHAKE256/192 |24|4| 51 | 4 | 0x0000000F |\n +---------------------+--------------+--+-+-----+----+------------+\n | LMOTS_SHAKE_N24_W8 | SHAKE256/192 |24|8| 26 | 0 | 0x00000010 |\n +---------------------+--------------+--+-+-----+----+------------+\n\n Table 1", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Parameter Set Name:", + "ja": "パラメータセット名:" + }, + { + "indent": 12, + "text": "The human-readable name of the parameter set.", + "ja": "人間が判読できるパラメータ セットの名前。" + }, + { + "indent": 3, + "text": "H: ", + "ja": "ひ:" + }, + { + "indent": 12, + "text": "The second-preimage-resistant cryptographic hash function used within this parameter set.", + "ja": "このパラメータ セット内で使用される 2 番目のプリイメージ耐性のある暗号化ハッシュ関数。" + }, + { + "indent": 3, + "text": "n: ", + "ja": "n:" + }, + { + "indent": 12, + "text": "The number of bytes of the output of the hash function.", + "ja": "ハッシュ関数の出力のバイト数。" + }, + { + "indent": 3, + "text": "w: ", + "ja": "w:" + }, + { + "indent": 12, + "text": "The width (in bits) of the Winternitz coefficients; that is, the number of bits from the hash or checksum that is used with a single Winternitz chain. It is a member of the set { 1, 2, 4, 8 }.", + "ja": "Winternitz 係数の幅 (ビット単位)。つまり、単一の Winternitz チェーンで使用されるハッシュまたはチェックサムのビット数です。これは集合 { 1, 2, 4, 8 } のメンバーです。" + }, + { + "indent": 3, + "text": "p: ", + "ja": "p:" + }, + { + "indent": 12, + "text": "The number of n-byte string elements that make up the LM-OTS signature.", + "ja": "LM-OTS 署名を構成する n バイトの文字列要素の数。" + }, + { + "indent": 3, + "text": "ls:", + "ja": "ls:" + }, + { + "indent": 12, + "text": "The number of left-shift bits used in the checksum function Cksm (used by algorithm 2 of [RFC8554]).", + "ja": "チェックサム関数 Cksm ([RFC8554] のアルゴリズム 2 で使用) で使用される左シフト ビットの数。" + }, + { + "indent": 3, + "text": "id:", + "ja": "id:" + }, + { + "indent": 12, + "text": "The IANA-defined identifier used to denote this specific parameter set, which appears in both public keys and signatures.", + "ja": "この特定のパラメータ セットを示すために使用される IANA 定義の識別子。公開鍵と署名の両方に表示されます。" + }, + { + "indent": 3, + "text": "These values are additions to the entries in Table 1 of [RFC8554].", + "ja": "これらの値は、[RFC8554] の表 1 のエントリに追加されたものです。" + }, + { + "indent": 3, + "text": "The SHA256_N24, SHAKE_N32, and SHAKE_N24 in the parameter set names denote the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions defined in Section 2.", + "ja": "パラメータ セット名の SHA256_N24、SHAKE_N32、および SHAKE_N24 は、セクション 2 で定義された SHA-256/192、SHAKE256/256、および SHAKE256/192 ハッシュ関数を示します。" + }, + { + "indent": 3, + "text": "Remember that the C message randomizer (which is included in the signature) has the same size (n bytes) as the hash output, and so it shrinks from 32 bytes to 24 bytes for the parameter sets that use either SHA-256/192 or SHAKE256/192.", + "ja": "C メッセージ ランダマイザー (署名に含まれる) のサイズはハッシュ出力と同じ (n バイト) であるため、SHA-256/192 または SHAKE256/192 を使用するパラメーター セットでは 32 バイトから 24 バイトに縮小されることに注意してください。" + }, + { + "indent": 0, + "text": "4. Additional LMS Parameter Sets", + "section_title": true, + "ja": "4. 追加の LMS パラメータ セット" + }, + { + "indent": 3, + "text": "The table below defines several many-time signature parameters called Leighton-Micali Signature (LMS) parameters, using the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions:", + "ja": "以下の表は、SHA-256/192、SHAKE256/256、および SHAKE256/192 ハッシュ関数を使用して、Leighton-Micali Signature (LMS) パラメーターと呼ばれる複数の複数回署名パラメーターを定義しています。" + }, + { + "indent": 4, + "text": " +====================+==============+====+====+============+\n | Parameter Set Name | H | m | h | id |\n +====================+==============+====+====+============+\n | LMS_SHA256_M24_H5 | SHA-256/192 | 24 | 5 | 0x0000000A |\n +--------------------+--------------+----+----+------------+\n | LMS_SHA256_M24_H10 | SHA-256/192 | 24 | 10 | 0x0000000B |\n +--------------------+--------------+----+----+------------+\n | LMS_SHA256_M24_H15 | SHA-256/192 | 24 | 15 | 0x0000000C |\n +--------------------+--------------+----+----+------------+\n | LMS_SHA256_M24_H20 | SHA-256/192 | 24 | 20 | 0x0000000D |\n +--------------------+--------------+----+----+------------+\n | LMS_SHA256_M24_H25 | SHA-256/192 | 24 | 25 | 0x0000000E |\n +--------------------+--------------+----+----+------------+\n | LMS_SHAKE_M32_H5 | SHAKE256/256 | 32 | 5 | 0x0000000F |\n +--------------------+--------------+----+----+------------+\n | LMS_SHAKE_M32_H10 | SHAKE256/256 | 32 | 10 | 0x00000010 |\n +--------------------+--------------+----+----+------------+\n | LMS_SHAKE_M32_H15 | SHAKE256/256 | 32 | 15 | 0x00000011 |\n +--------------------+--------------+----+----+------------+\n | LMS_SHAKE_M32_H20 | SHAKE256/256 | 32 | 20 | 0x00000012 |\n +--------------------+--------------+----+----+------------+\n | LMS_SHAKE_M32_H25 | SHAKE256/256 | 32 | 25 | 0x00000013 |\n +--------------------+--------------+----+----+------------+\n | LMS_SHAKE_M24_H5 | SHAKE256/192 | 24 | 5 | 0x00000014 |\n +--------------------+--------------+----+----+------------+\n | LMS_SHAKE_M24_H10 | SHAKE256/192 | 24 | 10 | 0x00000015 |\n +--------------------+--------------+----+----+------------+\n | LMS_SHAKE_M24_H15 | SHAKE256/192 | 24 | 15 | 0x00000016 |\n +--------------------+--------------+----+----+------------+\n | LMS_SHAKE_M24_H20 | SHAKE256/192 | 24 | 20 | 0x00000017 |\n +--------------------+--------------+----+----+------------+\n | LMS_SHAKE_M24_H25 | SHAKE256/192 | 24 | 25 | 0x00000018 |\n +--------------------+--------------+----+----+------------+\n\n Table 2", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Parameter Set Name:", + "ja": "パラメータセット名:" + }, + { + "indent": 12, + "text": "The human-readable name of the parameter set.", + "ja": "人間が判読できるパラメータ セットの名前。" + }, + { + "indent": 3, + "text": "H: ", + "ja": "ひ:" + }, + { + "indent": 12, + "text": "The second-preimage-resistant cryptographic hash function used within this parameter set.", + "ja": "このパラメータ セット内で使用される 2 番目のプリイメージ耐性のある暗号化ハッシュ関数。" + }, + { + "indent": 3, + "text": "m: ", + "ja": "メートル:" + }, + { + "indent": 12, + "text": "The size in bytes of the hash function output.", + "ja": "ハッシュ関数出力のバイト単位のサイズ。" + }, + { + "indent": 3, + "text": "h: ", + "ja": "h:" + }, + { + "indent": 12, + "text": "The height of the Merkle tree.", + "ja": "マークル ツリーの高さ。" + }, + { + "indent": 3, + "text": "id:", + "ja": "id:" + }, + { + "indent": 12, + "text": "The IANA-defined identifier used to denote this specific parameter set, which appears in both public keys and signatures.", + "ja": "この特定のパラメータ セットを示すために使用される IANA 定義の識別子。公開鍵と署名の両方に表示されます。" + }, + { + "indent": 3, + "text": "These values are additions to the entries in Table 2 of [RFC8554].", + "ja": "これらの値は、[RFC8554] の表 2 のエントリに追加されたものです。" + }, + { + "indent": 3, + "text": "The SHA256_M24, SHAKE_M32, and SHAKE_M24 in the parameter set names denote the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions defined in Section 2.", + "ja": "パラメータ セット名の SHA256_M24、SHAKE_M32、および SHAKE_M24 は、セクション 2 で定義された SHA-256/192、SHAKE256/256、および SHAKE256/192 ハッシュ関数を示します。" + }, + { + "indent": 0, + "text": "5. Usage for These Additional Hash Functions within HSS", + "section_title": true, + "ja": "5. HSS 内でのこれらの追加ハッシュ関数の使用法" + }, + { + "indent": 3, + "text": "To use the additional hash functions within HSS, one would use the appropriate LM-OTS id from Table 1 and the appropriate LMS id from Table 2 and use that additional hash function when computing the hashes for key generation, signature generation, and signature verification.", + "ja": "HSS 内で追加のハッシュ関数を使用するには、表 1 の適切な LM-OTS ID と表 2 の適切な LMS ID を使用し、キーの生成、署名の生成、および署名の検証のハッシュを計算するときにその追加のハッシュ関数を使用します。" + }, + { + "indent": 3, + "text": "Note that the size of the I Merkle tree identifier remains 16 bytes, independent of what hash function is used.", + "ja": "I マークル ツリー識別子のサイズは、使用されるハッシュ関数に関係なく、16 バイトのままであることに注意してください。" + }, + { + "indent": 0, + "text": "6. Parameter Set Selection", + "section_title": true, + "ja": "6. パラメータセットの選択" + }, + { + "indent": 3, + "text": "This document, along with [RFC8554], defines four hash functions for use within HSS/LMS: SHA-256, SHA-256/192, SHAKE256/256, and SHAKE256/192. The main reason one would select a hash with a 192-bit output (either SHA-256/192 or SHAKE256/192) would be to reduce the signature size; this comes at the cost of reducing the security margin. However, the security should be sufficient for most uses.", + "ja": "この文書は、[RFC8554] とともに、HSS/LMS 内で使用する 4 つのハッシュ関数、SHA-256、SHA-256/192、SHAKE256/256、および SHAKE256/192 を定義します。192 ビット出力のハッシュ (SHA-256/192 または SHAKE256/192) を選択する主な理由は、署名のサイズを減らすためです。これには、セキュリティマージンが減少するという代償が伴います。ただし、セキュリティはほとんどの用途には十分です。" + }, + { + "indent": 3, + "text": "In contrast, there is no security or signature size difference between the SHA-256-based parameter sets (SHA-256 or SHA-256/192) versus the SHAKE-based parameter sets (SHAKE256/256 or SHAKE256/192). The reason for selecting between the two would be based on practical considerations, for example, if the implementation happens to have an existing SHA-256 (or SHAKE) implementation or if one of the two happens to give better hashing performance on the platform.", + "ja": "対照的に、SHA-256 ベースのパラメータ セット (SHA-256 または SHA-256/192) と SHAKE ベースのパラメータ セット (SHAKE256/256 または SHAKE256/192) の間には、セキュリティや署名サイズの違いはありません。2 つのどちらかを選択する理由は、実装にたまたま既存の SHA-256 (または SHAKE) 実装があるかどうか、または 2 つのうちの 1 つがたまたまプラットフォーム上でより優れたハッシュ パフォーマンスを提供するかどうかなど、実際的な考慮事項に基づいています。" + }, + { + "indent": 0, + "text": "7. Comparisons of 192-Bit and 256-Bit Parameter Sets", + "section_title": true, + "ja": "7. 192 ビットと 256 ビットのパラメータ セットの比較" + }, + { + "indent": 3, + "text": "Switching to a 192-bit hash affects the signature size, the computation time, and the security strength. It significantly reduces the signature size and somewhat reduces the computation time, at the cost of security strength. See Section 8 for a discussion of the security strength.", + "ja": "192 ビット ハッシュに切り替えると、署名のサイズ、計算時間、セキュリティ強度に影響します。これにより、セキュリティ強度は犠牲になりますが、署名のサイズが大幅に縮小され、計算時間が若干短縮されます。セキュリティ強度の説明については、セクション 8 を参照してください。" + }, + { + "indent": 3, + "text": "The impact on signature size and computation time is based on two effects:", + "ja": "署名のサイズと計算時間への影響は、次の 2 つの影響に基づいています。" + }, + { + "indent": 8, + "text": "1. Each hash that appears in the signature is shorter.", + "ja": "1. 署名に含まれる各ハッシュは短くなります。" + }, + { + "indent": 8, + "text": "2. We need fewer Winternitz chains (because LM-OTS signs a shorter value).", + "ja": "2. 必要な Winternitz チェーンの数は少なくなります (LM-OTS がより短い値に署名するため)。" + }, + { + "indent": 3, + "text": "For signature length, both effects are relevant. The first is relevant because the signature consists of a series of hashes and each hash is shorter. The second is relevant because when we need fewer Winternitz chains, we need fewer hashes in each LM-OTS signature.", + "ja": "署名の長さについては、両方の効果が関係します。署名は一連のハッシュで構成され、各ハッシュは短いため、最初のものが重要です。2 つ目は、必要な Winternitz チェーンが少なくなると、各 LM-OTS 署名に必要なハッシュが少なくなるため、関連性があります。" + }, + { + "indent": 3, + "text": "For computation time (for both signature generation and verification), effect 1 is irrelevant (we still need to perform essentially the same hash computation), but effect 2 still applies. For example, with W=8, SHA-256 requires 34 Winternitz chains per LM-OTS signature, but SHA-256/192 requires only 26. Since the vast majority of time (for both signature generation and verification) is spent computing these Winternitz chains, this reduction in the number of chains gives us some performance improvement.", + "ja": "計算時間 (署名の生成と検証の両方) に関しては、効果 1 は無関係です (本質的に同じハッシュ計算を実行する必要があります)、効果 2 は依然として適用されます。たとえば、W=8 の場合、SHA-256 では LM-OTS 署名ごとに 34 個の Winternitz チェーンが必要ですが、SHA-256/192 では 26 個しか必要ありません。大部分の時間 (署名の生成と検証の両方) がこれらの Winternitz チェーンの計算に費やされるため、このチェーン数の削減によりパフォーマンスがある程度向上します。" + }, + { + "indent": 3, + "text": "The table below gives the space used by both the 256-bit and 192-bit parameter sets for a range of commonly used Winternitz parameters and tree heights:", + "ja": "以下の表は、一般的に使用される Winternitz パラメーターと木の高さの範囲について、256 ビットと 192 ビットの両方のパラメーター セットで使用されるスペースを示しています。" + }, + { + "indent": 7, + "text": " +=========+============+==============+==============+\n | ParmSet | Winternitz | 256-bit hash | 192-bit hash |\n +=========+============+==============+==============+\n | 15 | 4 | 2672 | 1624 |\n +---------+------------+--------------+--------------+\n | 15 | 8 | 1616 | 1024 |\n +---------+------------+--------------+--------------+\n | 20 | 4 | 2832 | 1744 |\n +---------+------------+--------------+--------------+\n | 20 | 8 | 1776 | 1144 |\n +---------+------------+--------------+--------------+\n | 15/10 | 4 | 5236 | 3172 |\n +---------+------------+--------------+--------------+\n | 15/10 | 8 | 3124 | 1972 |\n +---------+------------+--------------+--------------+\n | 15/15 | 4 | 5396 | 3292 |\n +---------+------------+--------------+--------------+\n | 15/15 | 8 | 3284 | 2092 |\n +---------+------------+--------------+--------------+\n | 20/10 | 4 | 5396 | 3292 |\n +---------+------------+--------------+--------------+\n | 20/10 | 8 | 3284 | 2092 |\n +---------+------------+--------------+--------------+\n | 20/15 | 4 | 5556 | 3412 |\n +---------+------------+--------------+--------------+\n | 20/15 | 8 | 3444 | 2212 |\n +---------+------------+--------------+--------------+\n\n Table 3", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "ParmSet:", + "ja": "パラメータセット:" + }, + { + "indent": 12, + "text": "The height of the Merkle tree(s), which is the parameter \"h\" from Table 2. Parameter sets listed as a single integer have L=1 and consist of a single Merkle tree of that height; parameter sets with L=2 are listed as x/y, with x being the height of the top-level Merkle tree and y being the bottom level.", + "ja": "マークル ツリーの高さ。表 2 のパラメータ「h」です。単一の整数としてリストされているパラメータ セットは L=1 を持ち、その高さの単一のマークル ツリーで構成されます。L=2 のパラメータ セットは x/y としてリストされます。x は最上位のマークル ツリーの高さ、y は最下位レベルです。" + }, + { + "indent": 3, + "text": "Winternitz:", + "ja": "ウィンターニッツ:" + }, + { + "indent": 12, + "text": "The Winternitz parameter used, which is the parameter \"w\" from Table 1. For the tests that use multiple trees, this applies to all of them.", + "ja": "使用される Winternitz パラメーター。これは、表 1 のパラメーター「w」です。複数のツリーを使用するテストの場合、これはすべてのツリーに適用されます。" + }, + { + "indent": 3, + "text": "256-bit hash:", + "ja": "256ビットハッシュ:" + }, + { + "indent": 12, + "text": "The size in bytes of a signature, assuming that a 256-bit hash is used in the signature (either SHA-256 or SHAKE256/256).", + "ja": "256 ビット ハッシュが署名 (SHA-256 または SHAKE256/256) で使用されると仮定した場合の、署名のバイト単位のサイズ。" + }, + { + "indent": 3, + "text": "192-bit hash:", + "ja": "192ビットハッシュ:" + }, + { + "indent": 12, + "text": "The size in bytes of a signature, assuming that a 192-bit hash is used in the signature (either SHA-256/192 or SHAKE256/192).", + "ja": "192 ビット ハッシュが署名 (SHA-256/192 または SHAKE256/192) で使用されると仮定した場合の、署名のバイト単位のサイズ。" + }, + { + "indent": 3, + "text": "An examination of the signature sizes shows that the 192-bit parameters consistently give a 35-40% reduction in the size of the signature in comparison with the 256-bit parameters.", + "ja": "署名のサイズを調べると、192 ビットのパラメータでは、256 ビットのパラメータと比較して署名のサイズが一貫して 35 ～ 40% 削減されることがわかります。" + }, + { + "indent": 3, + "text": "For SHA-256/192, there is a smaller (circa 20%) reduction in the amount of computation required for a signature operation with a 192-bit hash, because fewer Winternitz chains would need to be computed. The SHAKE256/192 signatures may have either a faster or slower computation, depending on the implementation speed of SHAKE versus SHA-256 hashes.", + "ja": "SHA-256/192 の場合、計算する必要のある Winternitz チェーンの数が少なくなるため、192 ビット ハッシュでの署名操作に必要な計算量はより小さく (約 20%) 削減されます。SHAKE256/192 署名は、SHAKE ハッシュと SHA-256 ハッシュの実装速度に応じて、計算が高速になる場合もあれば、低速になる場合もあります。" + }, + { + "indent": 3, + "text": "The SHAKE256/256-based parameter sets give no space advantage (or disadvantage) over the existing SHA-256-based parameter sets; any performance delta would depend solely on the implementation and whether they can generate SHAKE hashes faster than SHA-256 ones.", + "ja": "SHAKE256/256 ベースのパラメータ セットには、既存の SHA-256 ベースのパラメータ セットに比べてスペース上の利点 (または欠点) がありません。パフォーマンスの差は、実装と、SHA-256 ハッシュよりも高速に SHAKE ハッシュを生成できるかどうかのみに依存します。" + }, + { + "indent": 0, + "text": "8. Security Considerations", + "section_title": true, + "ja": "8. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "The strength of a signature that uses the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions is based on the difficulty in finding preimages or second preimages to those hash functions. As shown in [Katz16], if we assume that the hash function can be modeled as a random oracle, then the security of the system is at least 8N-1 bits (where N is the size of the hash output in bytes); this gives us a security level of 255 bits for SHAKE256/256 and 191 bits for SHA-256/192 and SHAKE256/192). That is, the strength of SHA-256/192 and SHAKE256/192 can be expected to be equivalent to the strength of AES-192, while the strength of SHAKE256/256 is equivalent to the strength of AES-256. If AES-192 and AES-256 are quantum-resistant, then we expect SHA-256/192, SHAKE256/192, and SHAKE256/256 to also be.", + "ja": "SHA-256/192、SHAKE256/256、および SHAKE256/192 ハッシュ関数を使用する署名の強度は、それらのハッシュ関数に対するプリイメージまたは 2 番目のプリイメージを見つける難しさに基づいています。[Katz16] に示されているように、ハッシュ関数がランダム オラクルとしてモデル化できると仮定すると、システムのセキュリティは少なくとも 8N-1 ビットになります (N はバイト単位のハッシュ出力のサイズです)。これにより、SHAKE256/256 のセキュリティ レベルは 255 ビット、SHA-256/192 および SHAKE256/192 のセキュリティ レベルは 191 ビットになります)。つまり、SHA-256/192 および SHAKE256/192 の強度は AES-192 の強度と同等であることが期待でき、一方、SHAKE256/256 の強度は AES-256 の強度と同等であると考えられます。AES-192 と AES-256 が量子耐性がある場合、SHA-256/192、SHAKE256/192、および SHAKE256/256 も量子耐性があると予想されます。" + }, + { + "indent": 3, + "text": "If we look at this in a different way, we see that the case of SHAKE256/256 is essentially the same as the existing SHA-256-based signatures; the difficultly of finding preimages and second preimages is essentially the same, and so they have (barring unexpected cryptographical advances) essentially the same level of security.", + "ja": "これを別の見方で見ると、SHAKE256/256 の場合は既存の SHA-256 ベースの署名と本質的に同じであることがわかります。プリイメージと 2 番目のプリイメージを見つけることの難しさは本質的に同じであるため、(予期しない暗号化の進歩がない限り) 本質的に同じレベルのセキュリティを備えています。" + }, + { + "indent": 3, + "text": "The case of SHA-256/192 and SHAKE256/192 requires closer analysis.", + "ja": "SHA-256/192 および SHAKE256/192 の場合は、より詳細な分析が必要です。" + }, + { + "indent": 3, + "text": "For a classical (non-quantum) computer, there is no known attack better than performing hashes of a large number of distinct preimages. Therefore, a successful attack has a high probability of requiring nearly 2^192 hash computations (for either SHA-256/192 or SHAKE256/192). These can be taken as the expected work effort and would appear to be completely infeasible in practice.", + "ja": "古典的な (非量子) コンピューターの場合、多数の個別のプリイメージのハッシュを実行することより優れた攻撃は知られていません。したがって、攻撃が成功すると、ほぼ 2^192 のハッシュ計算 (SHA-256/192 または SHAKE256/192 の場合) が必要になる可能性が高くなります。これらは予想される作業量とみなされる可能性があり、実際には完全に実行不可能であるように見えます。" + }, + { + "indent": 3, + "text": "In theory, an attacker with a quantum computer could use Grover's algorithm [Grover96] to reduce the expected complexity to circa 2^96 hash computations (for N=24). On the other hand, implementing Grover's algorithm with this number of hash computations would require performing circa 2^96 hash computations in succession, which will take more time than is likely to be acceptable to any attacker. To speed this up, the attacker would need to run a number of instances of Grover's algorithm in parallel. This would necessarily increase the total work effort required, and to an extent, that makes it likely infeasible. This is because if we limit the time taken by Grover's algorithm to 2^t steps (for t <= 96), then to attack a hash preimage problem of 192 bits, it requires a total of 2^(192-t) hash computations, rather than the 2^(192/2) hash computations it would require if we did not limit the time taken. In other words, the hash preimage can be found in 2^t steps by using 2^(192-2t) quantum computers (for t <= 96), with one of the quantum computers finding the preimage. For example, if the adversary is willing to wait for 2^64 times the time taken by a hash computation (which is over 50 years if a quantum computer can compute a hash in 0.1 nanoseconds), this implies that a total of 2^(192-64) = 2^128 hash computations will need to be performed, on 2^64 (18 quintillion) separate quantum computers, each of which computes 2^64 hash evaluations.", + "ja": "理論的には、量子コンピューターを使用する攻撃者は、グローバーのアルゴリズム [Grover96] を使用して、予想される複雑さを約 2^96 ハッシュ計算 (N=24 の場合) に減らすことができます。一方、この数のハッシュ計算でグローバーのアルゴリズムを実装するには、約 2^96 のハッシュ計算を連続して実行する必要があり、攻撃者が許容できる以上に時間がかかります。これを高速化するには、攻撃者はグローバーのアルゴリズムの多数のインスタンスを並行して実行する必要があります。これにより必然的に必要な総作業量が増加するため、ある程度は実行不可能になる可能性があります。これは、Grover のアルゴリズムにかかる時間を 2^t ステップ (t <= 96) に制限すると、192 ビットのハッシュ プリイメージ問題を攻撃するには、かかる時間を制限しなかった場合に必要となる 2^(192/2) 回のハッシュ計算ではなく、合計 2^(192-t) 回のハッシュ計算が必要になるためです。言い換えれば、ハッシュ プリイメージは 2^(192-2t) 量子コンピューター (t <= 96) を使用して 2^t ステップで見つけることができ、量子コンピューターの 1 つがプリイメージを見つけます。たとえば、攻撃者がハッシュ計算にかかる時間の 2^64 倍待つことをいとわない場合 (量子コンピューターが 0.1 ナノ秒でハッシュを計算できる場合、これは 50 年以上に相当します)、これは、2^64 (18 京) 個の個別の量子に対して、合計 2^(192-64) = 2^128 回のハッシュ計算を実行する必要があることを意味します。コンピューター。それぞれが 2^64 ハッシュを計算します\n\n評価。" + }, + { + "indent": 3, + "text": "Hence, we expect that HSS/LMS based on these hash functions is secure against both classical and quantum computers, even though, in both cases, the expected work effort is less (for the N=24 case) than against either SHA-256 or SHAKE256/256.", + "ja": "したがって、これらのハッシュ関数に基づく HSS/LMS は、古典コンピューターと量子コンピューターの両方に対して安全であると予想されます。ただし、どちらの場合でも、予想される作業量は (N=24 の場合) SHA-256 または SHAKE256/256 よりも少なくなります。" + }, + { + "indent": 3, + "text": "SHA-256 is subject to a length extension attack. In this attack, if the attacker is given the hash value of an unknown message (and the message length), then the attacker can compute the hash of the message appended with certain strings (even though the attacker does not know the contents of the initial part of the modified message). This would appear to be irrelevant to HSS for two reasons:", + "ja": "SHA-256 は長さ拡張攻撃の対象となります。この攻撃では、攻撃者に未知のメッセージのハッシュ値 (およびメッセージの長さ) が与えられた場合、攻撃者は、(攻撃者が変更されたメッセージの最初の部分の内容を知らなくても) 特定の文字列が追加されたメッセージのハッシュを計算できます。これは、次の 2 つの理由から HSS とは無関係であるように見えます。" + }, + { + "indent": 6, + "text": "* For the initial message hash, the hash is entirely on public data. Hence, this attack is irrelevant, because the attacker could compute the hash of the message with appended data anyways.", + "ja": "* 最初のメッセージ ハッシュの場合、ハッシュは完全に公開データに基づいています。したがって、攻撃者はいずれにしてもデータが追加されたメッセージのハッシュを計算できるため、この攻撃は無関係です。" + }, + { + "indent": 6, + "text": "* The rest of the hashes within HSS are fixed length. Hence, there is no opportunity to perform length extension attacks.", + "ja": "* HSS 内の残りのハッシュは固定長です。したがって、長さ拡張攻撃を実行する機会はありません。" + }, + { + "indent": 3, + "text": "In addition, to perform a length extension attack on SHA-256/192, the attacker has to guess the 64 omitted bits (because the attack requires all 256 bits of the hash value); hence, that is even less of a concern than it is for the standard SHA-256.", + "ja": "さらに、SHA-256/192 に対して長さ拡張攻撃を実行するには、攻撃者は省略された 64 ビットを推測する必要があります (攻撃にはハッシュ値の 256 ビットすべてが必要であるため)。したがって、標準の SHA-256 よりもそれほど心配はありません。" + }, + { + "indent": 3, + "text": "There is one corner case for which the security strength is reduced: if we need to assume that the signer will never deliberately generate a signature that is valid for two different messages. HSS uses randomized hashing when signing a message. That is, when a message is being presented to be signed, the signer generates a random value C and includes that in what is prepended to the message. Because the attacker cannot predict this value, it is infeasible for anyone other than the signer to find a generic collision. That is, practically speaking, a signature that is valid for two colliding messages is feasible only if the signer signed both messages. For this to happen, a signer (that is, the one with the private key and who picks the random C value) would have to break the collision resistance of the hash function to generate those two colliding messages. Note that this does not apply to someone who submits the messages for signing; only the signer could perform this. This would result in a signature that would be valid for two different selected messages. This is a nonstandard assumption for signature schemes and is usually not a concern, as we assume that the signer is trusted to generate signatures for any message. However, if the application needs to assume that it is infeasible for the signer to generate such a signature, then the security strength assumptions are reduced (128 bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192).", + "ja": "セキュリティ強度が低下する特殊なケースが 1 つあります。それは、署名者が 2 つの異なるメッセージに対して有効な署名を意図的に生成しないと仮定する必要がある場合です。HSS は、メッセージに署名するときにランダム化されたハッシュを使用します。つまり、メッセージが署名のために提示されるときに、署名者はランダムな値 C を生成し、それをメッセージの先頭に追加するものに含めます。攻撃者はこの値を予測できないため、署名者以外の者が一般的な衝突を見つけることは不可能です。つまり、実際には、衝突する 2 つのメッセージに対して有効な署名は、署名者が両方のメッセージに署名した場合にのみ実現可能です。これを実現するには、署名者 (つまり、秘密鍵を持ち、ランダムな C 値を選択する署名者) がハッシュ関数の衝突耐性を破って、これら 2 つの衝突するメッセージを生成する必要があります。これは、署名のためにメッセージを送信する人には適用されないことに注意してください。これを実行できるのは署名者だけです。これにより、選択された 2 つの異なるメッセージに対して有効な署名が得られます。これは署名スキームの非標準的な仮定であり、署名者があらゆるメッセージの署名を生成することが信頼されていると仮定しているため、通常は問題になりません。ただし、署名者がそのような署名を生成することは実行不可能であるとアプリケーションが仮定する必要がある場合、セキュリティ強度の仮定は減らされます (SHAKE256/256 の場合は 128 ビット、SHA-256/192 および SHAKE256/192 の場合は 96 ビット)。" + }, + { + "indent": 3, + "text": "Some cryptographers have raised the possibility of a multi-target attack (where the attacker has signatures from a large number of public keys and succeeds if they can generate a forgery against any one of those public keys). While no such method of attack has been proposed, the possibility cannot be excluded; if there are a large number of public keys, it might be prudent to consider the possibility of some security loss with N=24. If there are 2^K public keys, this security loss cannot be more than K bits of security.", + "ja": "一部の暗号学者は、マルチターゲット攻撃（攻撃者が多数の公開鍵からの署名を持っており、それらの公開鍵のいずれかに対する偽造を生成できれば成功する）の可能性を提起しています。そのような攻撃方法は提案されていませんが、可能性は排除できません。多数の公開キーがある場合、N=24 でセキュリティがある程度失われる可能性を考慮することが賢明かもしれません。2^K 個の公開キーがある場合、このセキュリティ損失は K ビットのセキュリティを超えることはできません。" + }, + { + "indent": 0, + "text": "8.1. Note on the Version of SHAKE", + "section_title": true, + "ja": "8.1. SHAKEのバージョンについてのご注意" + }, + { + "indent": 3, + "text": "[FIPS202] defines both SHAKE128 and SHAKE256. This specification selects SHAKE256, even though it is less efficient for large messages. The reason is that SHAKE128 has a low upper bound on the difficulty of finding preimages (due to the invertibility of its internal permutation), which would limit the strength of HSS/LMS (whose strength is based on the difficulty of finding preimages). Hence, we specify the use of SHAKE256, which has a considerably stronger preimage resistance.", + "ja": "[FIPS202] は SHAKE128 と SHAKE256 の両方を定義しています。この仕様では、大きなメッセージの場合は効率が低くなりますが、SHAKE256 が選択されます。その理由は、SHAKE128 には (内部順列の可逆性により) プリイメージを見つける難易度の上限が低く、HSS/LMS の強度 (その強度はプリイメージを見つける難易度に基づいています) が制限されるためです。したがって、プリイメージ耐性がかなり強い SHAKE256 の使用を指定します。" + }, + { + "indent": 0, + "text": "9. IANA Considerations", + "section_title": true, + "ja": "9. IANAの考慮事項" + }, + { + "indent": 3, + "text": "IANA has assigned the code points for the parameter sets in Section 3 in the \"LM-OTS Signatures\" registry and the parameter sets in Section 4 in the \"Leighton-Micali Signatures (LMS)\" registry. These assignments are included in [NIST_SP_800-208], but the IANA registrations only reference this document.", + "ja": "IANA は、「LM-OTS Signatures」レジストリのセクション 3 のパラメータ セットと、「Leighton-Micali Signatures (LMS)」レジストリのセクション 4 のパラメータ セットのコード ポイントを割り当てました。これらの割り当ては [NIST_SP_800-208] に含まれていますが、IANA 登録はこの文書のみを参照しています。" + }, + { + "indent": 0, + "text": "10. References", + "section_title": true, + "ja": "10. 参考文献" + }, + { + "indent": 0, + "text": "10.1. Normative References", + "section_title": true, + "ja": "10.1. 引用文献" + }, + { + "indent": 3, + "text": "[FIPS180] NIST, \"Secure Hash Standard\", NIST FIPS 180-4,\n DOI 10.6028/NIST.FIPS.180-4, August 2015,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[FIPS202] NIST, \"SHA-3 Standard: Permutation-Based Hash and\n Extendable-Output Functions\", NIST FIPS 202,\n DOI 10.6028/NIST.FIPS.202, August 2015,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, \"Leighton-Micali\n Hash-Based Signatures\", RFC 8554, DOI 10.17487/RFC8554,\n April 2019, .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "10.2. Informative References", + "section_title": true, + "ja": "10.2. 参考引用" + }, + { + "indent": 3, + "text": "[Grover96] Grover, L., \"A fast quantum mechanical algorithm for\n database search\", Proceedings of the twenty-eighth annual\n ACM symposium on Theory of Computing (STOC '96), pp.\n 212-219, DOI 10.1145/237814.237866, July 1996,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[Katz16] Katz, J., \"Analysis of a Proposed Hash-Based Signature\n Standard\", Security Standardisation Research (SSR 2016),\n Lecture Notes in Computer Science, vol. 10074, pp.\n 261-273, DOI 10.1007/978-3-319-49100-4_12, 2016,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[NIST_SP_800-208]\n Cooper, D., Apon, D., Dang, Q., Davidson, M., Dworkin, M.,\n and C. Miller, \"Recommendation for Stateful Hash-Based\n Signature Schemes\", National Institute of Standards and\n Technology, NIST SP 800-208, DOI 10.6028/NIST.SP.800-208,\n October 2020, .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Appendix A. Test Cases", + "section_title": true, + "ja": "付録A. テストケース" + }, + { + "indent": 3, + "text": "This appendix provides four test cases that can be used to verify or debug an implementation. This data is formatted with the name of the elements on the left and the value of the elements on the right, in hexadecimal. The concatenation of all of the values within a public key or signature produces that public key or signature, and values that do not fit within a single line are listed across successive lines.", + "ja": "この付録では、実装の検証またはデバッグに使用できる 4 つのテスト ケースを提供します。このデータは、左側に要素の名前、右側に要素の値を 16 進数で表示してフォーマットされています。公開キーまたは署名内のすべての値を連結すると、その公開キーまたは署名が生成され、1 行に収まらない値は連続した行にリストされます。" + }, + { + "indent": 0, + "text": "A.1. Test Case 1 - SHA-256/192", + "section_title": true, + "ja": "A.1. テストケース 1 - SHA-256/192" + }, + { + "indent": 3, + "text": "--------------------------------------------\n(note: procedure in Appendix A of [RFC8554] is used)\nSEED 000102030405060708090a0b0c0d0e0f\n 1011121314151617\nI 202122232425262728292a2b2c2d2e2f\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 19, + "text": "Figure 1: Private Key for SHA-256/192", + "ja": "図 1: SHA-256/192 の秘密キー" + }, + { + "indent": 3, + "text": "--------------------------------------------\nHSS public key\nlevels 00000001\n--------------------------------------------\nLMS type 0000000a # LMS_SHA256_M24_H5\nLM-OTS type 00000008 # LMOTS_SHA256_N24_W8\nI 202122232425262728292a2b2c2d2e2f\nK 2c571450aed99cfb4f4ac285da148827\n 96618314508b12d2\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 20, + "text": "Figure 2: Public Key for SHA-256/192", + "ja": "図 2: SHA-256/192 の公開キー" + }, + { + "indent": 3, + "text": "--------------------------------------------\nMessage 54657374206d65737361676520666f72 |Test message for|\n 205348413235362d3139320a | SHA-256/192.|\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 21, + "text": "Figure 3: Message for SHA-256/192", + "ja": "図 3: SHA-256/192 のメッセージ" + }, + { + "indent": 3, + "text": "--------------------------------------------\nHSS signature\nNspk 00000000\nsig[0]:\n--------------------------------------------\nLMS signature\nq 00000005\n--------------------------------------------\nLM-OTS signature\nLM-OTS type 00000008 # LMOTS_SHA256_N24_W8\nC 0b5040a18c1b5cabcbc85b047402ec62\n 94a30dd8da8fc3da\ny[0] e13b9f0875f09361dc77fcc4481ea463\n c073716249719193\ny[1] 614b835b4694c059f12d3aedd34f3db9\n 3f3580fb88743b8b\ny[2] 3d0648c0537b7a50e433d7ea9d6672ff\n fc5f42770feab4f9\ny[3] 8eb3f3b23fd2061e4d0b38f832860ae7\n 6673ad1a1a52a900\ny[4] 5dcf1bfb56fe16ff723627612f9a48f7\n 90f3c47a67f870b8\ny[5] 1e919d99919c8db48168838cece0abfb\n 683da48b9209868b\ny[6] e8ec10c63d8bf80d36498dfc205dc45d\n 0dd870572d6d8f1d\ny[7] 90177cf5137b8bbf7bcb67a46f86f26c\n fa5a44cbcaa4e18d\ny[8] a099a98b0b3f96d5ac8ac375d8da2a7c\n 248004ba11d7ac77\ny[9] 5b9218359cddab4cf8ccc6d54cb7e1b3\n 5a36ddc9265c0870\ny[10] 63d2fc6742a7177876476a324b03295b\n fed99f2eaf1f3897\ny[11] 0583c1b2b616aad0f31cd7a4b1bb0a51\n e477e94a01bbb4d6\ny[12] f8866e2528a159df3d6ce244d2b6518d\n 1f0212285a3c2d4a\ny[13] 927054a1e1620b5b02aab0c8c10ed48a\n e518ea73cba81fcf\ny[14] ff88bff461dac51e7ab4ca75f47a6259\n d24820b9995792d1\ny[15] 39f61ae2a8186ae4e3c9bfe0af2cc717\n f424f41aa67f03fa\ny[16] edb0665115f2067a46843a4cbbd297d5\n e83bc1aafc18d1d0\ny[17] 3b3d894e8595a6526073f02ab0f08b99\n fd9eb208b59ff631\ny[18] 7e5545e6f9ad5f9c183abd043d5acd6e\n b2dd4da3f02dbc31\ny[19] 67b468720a4b8b92ddfe7960998bb7a0\n ecf2a26a37598299\ny[20] 413f7b2aecd39a30cec527b4d9710c44\n 73639022451f50d0\ny[21] 1c0457125da0fa4429c07dad859c846c\n bbd93ab5b91b01bc\ny[22] 770b089cfede6f651e86dd7c15989c8b\n 5321dea9ca608c71\ny[23] fd862323072b827cee7a7e28e4e2b999\n 647233c3456944bb\ny[24] 7aef9187c96b3f5b79fb98bc76c3574d\n d06f0e95685e5b3a\ny[25] ef3a54c4155fe3ad817749629c30adbe\n 897c4f4454c86c49\n--------------------------------------------\nLMS type 0000000a # LMS_SHA256_M24_H5\npath[0] e9ca10eaa811b22ae07fb195e3590a33\n 4ea64209942fbae3\npath[1] 38d19f152182c807d3c40b189d3fcbea\n 942f44682439b191\npath[2] 332d33ae0b761a2a8f984b56b2ac2fd4\n ab08223a69ed1f77\npath[3] 19c7aa7e9eee96504b0e60c6bb5c942d\n 695f0493eb25f80a\npath[4] 5871cffd131d0e04ffe5065bc7875e82\n d34b40b69dd9f3c1", + "raw": true, + "ja": "" + }, + { + "indent": 20, + "text": "Figure 4: Signature for SHA-256/192", + "ja": "図 4: SHA-256/192 の署名" + }, + { + "indent": 0, + "text": "A.2. Test Vector for SHAKE256/192", + "section_title": true, + "ja": "A.2. SHAKE256/192のテストベクター" + }, + { + "indent": 3, + "text": "--------------------------------------------\n(note: procedure in Appendix A of [RFC8554] is used)\nSEED 303132333435363738393a3b3c3d3e3f\n 4041424344454647\nI 505152535455565758595a5b5c5d5e5f\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 19, + "text": "Figure 5: Private Key for SHAKE256/192", + "ja": "図 5: SHAKE256/192 の秘密鍵" + }, + { + "indent": 3, + "text": "---------------------------------------------\nHSS public key\nlevels 00000001\n--------------------------------------------\nLMS type 00000014 # LMS_SHAKE_N24_H5\nLM-OTS type 00000010 # LMOTS_SHAKE_N24_W8\nI 505152535455565758595a5b5c5d5e5f\nK db54a4509901051c01e26d9990e55034\n 7986da87924ff0b1\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 19, + "text": "Figure 6: Public Key for SHAKE256/192", + "ja": "図 6: SHAKE256/192 の公開鍵" + }, + { + "indent": 3, + "text": "--------------------------------------------\nMessage 54657374206d65737361676520666f72 |Test message for|\n 205348414b453235362d3139320a | SHAKE256/192.|\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 21, + "text": "Figure 7: Message for SHAKE256/192", + "ja": "図 7: SHAKE256/192 のメッセージ" + }, + { + "indent": 3, + "text": "--------------------------------------------\nHSS signature\nNspk 00000000\nsig[0]:\n--------------------------------------------\nLMS signature\nq 00000006\n--------------------------------------------\nLM-OTS signature\nLM-OTS type 00000010 # LMOTS_SHAKE_N24_W8\nC 84219da9ce9fffb16edb94527c6d1056\n 5587db28062deac4\ny[0] 208e62fc4fbe9d85deb3c6bd2c01640a\n ccb387d8a6093d68\ny[1] 511234a6a1a50108091c034cb1777e02\n b5df466149a66969\ny[2] a498e4200c0a0c1bf5d100cdb97d2dd4\n 0efd3cada278acc5\ny[3] a570071a043956112c6deebd1eb3a7b5\n 6f5f6791515a7b5f\ny[4] fddb0ec2d9094bfbc889ea15c3c7b9be\n a953efb75ed648f5\ny[5] 35b9acab66a2e9631e426e4e99b733ca\n a6c55963929b77fe\ny[6] c54a7e703d8162e736875cb6a455d4a9\n 015c7a6d8fd5fe75\ny[7] e402b47036dc3770f4a1dd0a559cb478\n c7fb1726005321be\ny[8] 9d1ac2de94d731ee4ca79cff454c811f\n 46d11980909f047b\ny[9] 2005e84b6e15378446b1ca691efe491e\n a98acc9d3c0f785c\ny[10] aba5e2eb3c306811c240ba2280292382\n 7d582639304a1e97\ny[11] 83ba5bc9d69d999a7db8f749770c3c04\n a152856dc726d806\ny[12] 7921465b61b3f847b13b2635a45379e5\n adc6ff58a99b00e6\ny[13] 0ac767f7f30175f9f7a140257e218be3\n 07954b1250c9b419\ny[14] 02c4fa7c90d8a592945c66e86a76defc\n b84500b55598a199\ny[15] 0faaa10077c74c94895731585c8f900d\n e1a1c675bd8b0c18\ny[16] 0ebe2b5eb3ef8019ece3e1ea7223eb79\n 06a2042b6262b4aa\ny[17] 25c4b8a05f205c8befeef11ceff12825\n 08d71bc2a8cfa0a9\ny[18] 9f73f3e3a74bb4b3c0d8ca2abd0e1c2c\n 17dafe18b4ee2298\ny[19] e87bcfb1305b3c069e6d385569a4067e\n d547486dd1a50d6f\ny[20] 4a58aab96e2fa883a9a39e1bd45541ee\n e94efc32faa9a94b\ny[21] e66dc8538b2dab05aee5efa6b3b2efb3\n fd020fe789477a93\ny[22] afff9a3e636dbba864a5bffa3e28d13d\n 49bb597d94865bde\ny[23] 88c4627f206ab2b465084d6b780666e9\n 52f8710efd748bd0\ny[24] f1ae8f1035087f5028f14affcc5fffe3\n 32121ae4f87ac5f1\ny[25] eac9062608c7d87708f1723f38b23237\n a4edf4b49a5cd3d7\n--------------------------------------------\nLMS type 00000014 # LMS_SHAKE_N24_H5\npath[0] dd4bdc8f928fb526f6fb7cdb944a7eba\n a7fb05d995b5721a\npath[1] 27096a5007d82f79d063acd434a04e97\n f61552f7f81a9317\npath[2] b4ec7c87a5ed10c881928fc6ebce6dfc\n e9daae9cc9dba690\npath[3] 7ca9a9dd5f9f573704d5e6cf22a43b04\n e64c1ffc7e1c442e\npath[4] cb495ba265f465c56291a902e62a461f\n 6dfda232457fad14", + "raw": true, + "ja": "" + }, + { + "indent": 20, + "text": "Figure 8: Signature for SHAKE256/192", + "ja": "図 8: SHAKE256/192 の署名" + }, + { + "indent": 0, + "text": "A.3. Test Vector for SHA-256/256", + "section_title": true, + "ja": "A.3. SHA-256/256 のテスト ベクトル" + }, + { + "indent": 3, + "text": "--------------------------------------------\n(note: procedure in Appendix A of [RFC8554] is used)\nSEED 606162636465666768696a6b6c6d6e6f\n 707172737475767778797a7b7c7d7e7f\nI 808182838485868788898a8b8c8d8e8f\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 19, + "text": "Figure 9: Private Key for SHAKE256/256", + "ja": "図 9: SHAKE256/256 の秘密鍵" + }, + { + "indent": 3, + "text": "--------------------------------------------\nHSS public key\nlevels 00000001\n--------------------------------------------\nLMS type 0000000f # LMS_SHAKE_N32_H5\nLM-OTS type 0000000c # LMOTS_SHAKE_N32_W8\nI 808182838485868788898a8b8c8d8e8f\nK 9bb7faee411cae806c16a466c3191a8b\n 65d0ac31932bbf0c2d07c7a4a36379fe\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 19, + "text": "Figure 10: Public Key for SHAKE256/256", + "ja": "図 10: SHAKE256/256 の公開鍵" + }, + { + "indent": 3, + "text": "--------------------------------------------\nMessage 54657374206d657361676520666f7220 |Test message for|\n 5348414b453235362d3235360a |SHAKE256/256.|\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 20, + "text": "Figure 11: Message for SHAKE256/256", + "ja": "図 11: SHAKE256/256 のメッセージ" + }, + { + "indent": 3, + "text": "--------------------------------------------\nHSS signature\nNspk 00000000\nsig[0]:\n--------------------------------------------\nLMS signature\nq 00000007\n--------------------------------------------\nLM-OTS signature\nLM-OTS type 0000000c # LMOTS_SHAKE_N32_W8\nC b82709f0f00e83759190996233d1ee4f\n 4ec50534473c02ffa145e8ca2874e32b\ny[0] 16b228118c62b96c9c77678b33183730\n debaade8fe607f05c6697bc971519a34\ny[1] 1d69c00129680b67e75b3bd7d8aa5c8b\n 71f02669d177a2a0eea896dcd1660f16\ny[2] 864b302ff321f9c4b8354408d0676050\n 4f768ebd4e545a9b0ac058c575078e6c\ny[3] 1403160fb45450d61a9c8c81f6bd69bd\n fa26a16e12a265baf79e9e233eb71af6\ny[4] 34ecc66dc88e10c6e0142942d4843f70\n a0242727bc5a2aabf7b0ec12a99090d8\ny[5] caeef21303f8ac58b9f200371dc9e41a\n b956e1a3efed9d4bbb38975b46c28d5f\ny[6] 5b3ed19d847bd0a737177263cbc1a226\n 2d40e80815ee149b6cce2714384c9b7f\ny[7] ceb3bbcbd25228dda8306536376f8793\n ecadd6020265dab9075f64c773ef97d0\ny[8] 7352919995b74404cc69a6f3b469445c\n 9286a6b2c9f6dc839be76618f053de76\ny[9] 3da3571ef70f805c9cc54b8e501a98b9\n 8c70785eeb61737eced78b0e380ded4f\ny[10] 769a9d422786def59700eef3278017ba\n bbe5f9063b468ae0dd61d94f9f99d5cc\ny[11] 36fbec4178d2bda3ad31e1644a2bcce2\n 08d72d50a7637851aa908b94dc437612\ny[12] 0d5beab0fb805e1945c41834dd6085e6\n db1a3aa78fcb59f62bde68236a10618c\ny[13] ff123abe64dae8dabb2e84ca705309c2\n ab986d4f8326ba0642272cb3904eb96f\ny[14] 6f5e3bb8813997881b6a33cac0714e4b\n 5e7a882ad87e141931f97d612b84e903\ny[15] e773139ae377f5ba19ac86198d485fca\n 97742568f6ff758120a89bf19059b8a6\ny[16] bfe2d86b12778164436ab2659ba86676\n 7fcc435584125fb7924201ee67b535da\ny[17] f72c5cb31f5a0b1d926324c26e67d4c3\n 836e301aa09bae8fb3f91f1622b1818c\ny[18] cf440f52ca9b5b9b99aba8a6754aae2b\n 967c4954fa85298ad9b1e74f27a46127\ny[19] c36131c8991f0cc2ba57a15d35c91cf8\n bc48e8e20d625af4e85d8f9402ec44af\ny[20] bd4792b924b839332a64788a7701a300\n 94b9ec4b9f4b648f168bf457fbb3c959\ny[21] 4fa87920b645e42aa2fecc9e21e000ca\n 7d3ff914e15c40a8bc533129a7fd3952\ny[22] 9376430f355aaf96a0a13d13f2419141\n b3cc25843e8c90d0e551a355dd90ad77\ny[23] 0ea7255214ce11238605de2f000d2001\n 04d0c3a3e35ae64ea10a3eff37ac7e95\ny[24] 49217cdf52f307172e2f6c7a2a4543e1\n 4314036525b1ad53eeaddf0e24b1f369\ny[25] 14ed22483f2889f61e62b6fb78f5645b\n dbb02c9e5bf97db7a0004e87c2a55399\ny[26] b61958786c97bd52fa199c27f6bb4d68\n c4907933562755bfec5d4fb52f06c289\ny[27] d6e852cf6bc773ffd4c07ee2d6cc55f5\n 7edcfbc8e8692a49ad47a121fe3c1b16\ny[28] cab1cc285faf6793ffad7a8c341a49c5\n d2dce7069e464cb90a00b2903648b23c\ny[29] 81a68e21d748a7e7b1df8a593f3894b2\n 477e8316947ca725d141135202a9442e\ny[30] 1db33bbd390d2c04401c39b253b78ce2\n 97b0e14755e46ec08a146d279c67af70\ny[31] de256890804d83d6ec5ca3286f1fca9c\n 72abf6ef868e7f6eb0fddda1b040ecec\ny[32] 9bbc69e2fd8618e9db3bdb0af13dda06\n c6617e95afa522d6a2552de15324d991\ny[33] 19f55e9af11ae3d5614b564c642dbfec\n 6c644198ce80d2433ac8ee738f9d825e\n--------------------------------------------\nLMS type 0000000f # LMS_SHAKE_N32_H5\npath[0] 71d585a35c3a908379f4072d070311db\n 5d65b242b714bc5a756ba5e228abfa0d\npath[1] 1329978a05d5e815cf4d74c1e547ec4a\n a3ca956ae927df8b29fb9fab3917a7a4\npath[2] ae61ba57e5342e9db12caf6f6dbc5253\n de5268d4b0c4ce4ebe6852f012b162fc\npath[3] 1c12b9ffc3bcb1d3ac8589777655e22c\n d9b99ff1e4346fd0efeaa1da044692e7\npath[4] ad6bfc337db69849e54411df8920c228\n a2b7762c11e4b1c49efb74486d3931ea", + "raw": true, + "ja": "" + }, + { + "indent": 19, + "text": "Figure 12: Signature for SHAKE256/256", + "ja": "図 12: SHAKE256/256 の署名" + }, + { + "indent": 0, + "text": "A.4. Test Vector for SHA-256/192, W=4", + "section_title": true, + "ja": "A.4. SHA-256/192 のテスト ベクトル、W=4" + }, + { + "indent": 3, + "text": "--------------------------------------------\n(note: procedure in Appendix A of [RFC8554] is used)\nSEED 202122232425262728292a2b2c2d2e2f\n 3031323334353637\nI 404142434445464748494a4b4c4d4e4f\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 15, + "text": "Figure 13: Private Key for SHA256/192 with W=4", + "ja": "図 13: W=4 の SHA256/192 の秘密鍵" + }, + { + "indent": 3, + "text": "--------------------------------------------\nHSS public key\nlevels 00000001\n--------------------------------------------\nLMS type 0000000d # LMS_SHA256_M24_H20\nLM-OTS type 00000007 # LMOTS_SHA256_N24_W4\nI 404142434445464748494a4b4c4d4e4f\nK 9c08a50d170406869892802ee4142fcd\n eac990f110c2460c\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 15, + "text": "Figure 14: Public Key for SHA256/192 with W=4", + "ja": "図 14: W=4 の SHA256/192 の公開鍵" + }, + { + "indent": 3, + "text": "--------------------------------------------\nMessage 54657374206d65737361676520666f72 |Test message for|\n 205348413235362f31393220773d34 | SHA256/192 w=4|\n--------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 17, + "text": "Figure 15: Message for SHA256/192 with W=4", + "ja": "図 15: W=4 の SHA256/192 のメッセージ" + }, + { + "indent": 3, + "text": "--------------------------------------------\nHSS signature\nNspk 00000000\nsig[0]:\n--------------------------------------------\nLMS signature\nq 00000064\n--------------------------------------------\nLM-OTS signature\nLM-OTS type 00000007 # LMOTS_SHA256_N24_W4\nC 853fa6e1a65fef076acd2485505b93be\n 9aeb2641e3d3805c\ny[0] 1887f26f4bcdb6ac0337b76fa5d66038\n 34287e010b20516f\ny[1] 7c336df2134c0a981f1ec2bb7baee516\n e91e67d3bd16c8d9\ny[2] 45a7f2be4fd84a604ae3743efc609ee0\n e69572e9c6d4a682\ny[3] 50e877b75d3cae63e9d5c15a32bb3cd1\n 7045f6b3e195284f\ny[4] dd1ee3cfbe18f1cbd06ef3e7af34b184\n 4d42dac453115a45\ny[5] 07ed525cec120d054b403c61a7e5034f\n ac4be6ef5412d194\ny[6] d4b6bbc0ae6cd3fe9993d583ee06f403\n 0bc832efec24d1f7\ny[7] 13f5088731b91a98491fa3adf1b322bc\n e26df24c8415e3a4\ny[8] 6bdfe07a6fd48e6d951515758cd64349\n 91098bf6949249fc\ny[9] a338ec235871dd564998d07d9b1b1b8d\n 644e657fee8039da\ny[10] 8fe195d129faddb12d543b86b0ab8cf6\n f26c121783f3b828\ny[11] d03f793b42909272f688e4ef6d46e82b\n dd1a02b1ff86c3b7\ny[12] 9920b2e6f19faf75c623242f1f2c549f\n 84fb2f4c3ffead31\ny[13] 20d97baea507467bb2da79f132bbe15b\n 596fdfcb70983107\ny[14] ebca2597de9d55bd83bcae5c28a85259\n dadb354859986e60\ny[15] c8afa0b10bd08a8f9ed9b1ede3377075\n fe0ae36349f7d2ed\ny[16] 7bfc9ece0d4cd6972059329419feaf3b\n 9a1045b6cfa4ae89\ny[17] b1cea8950aea4af870d1a3a3909ebc5a\n 3013d6deb927abc0\ny[18] f95093e83cb36a9c1d6f13add19268ac\n 7a0371f8335b0952\ny[19] a57fdb0141d55d937dd6ebb08fee8a5c\n f426ac97d54ee7aa\ny[20] 17e6c57be5e62a52a6b1b986730d3a3a\n ad8a7d327ddf883e\ny[21] 6bc7b636eb2a5c4f2a635ae5bada5418\n d43dfedb69c0a020\ny[22] 9334fac89d420d6ad5a2e1df95d26a1b\n feb99a5e8455061b\ny[23] fdf2d6e8394caf8a4be699b8afa38e52\n 4d4053330af478f8\ny[24] 5bf33d3ca3a35bc96987282bd513a8f6\n a52db9ba36aa9088\ny[25] 2b3bf573fa275449d8d49eb30bed2bb1\n 7a0ecc7d8a20807f\ny[26] 2ea3dd37acd46c713cc2ac9d01a20a30\n d6832eef86a1e26d\ny[27] 1cad7761bf4130a6565572766026509d\n eeddaf46b605452b\ny[28] 218a4e137a7ce063b546a35c52510f0e\n a2cac879192ec443\ny[29] e43b37c5ffa23da7a7fc254324a3de70\n 5c771794f10ea356\ny[30] e5a747e5146fd804a47719803c185b38\n 0e34b8dcc8269c2b\ny[31] 073d86b2307cf90c6c3ef9271f2d53df\n 2579f0c4cfb632db\ny[32] 37a9025965f70b4616673228e98644be\n 6576417b7a97f104\ny[33] 350259e7f697408cdf8cf81a3e774162\n 6ccdb87ad8531264\ny[34] cb5ceb7c8c097cec505091a3ee3a826c\n 54f78169abc2e7d0\ny[35] a318dac10250ba940e51e79a3f572fb3\n 2bf442be6fd81267\ny[36] 946e6387f9a8c705d945c653f2684655\n e3fa6b9ee311d8a0\ny[37] 91bef9898292fa272fb8761f066c23d8\n 7aa10d67871cc541\ny[38] 9c843b796855c51ad1272e9264acd203\n 5a82b12c2ddbc85a\ny[39] dfcd7c22366a36495349391dbf000106\n 4b8f6b28365445d7\ny[40] 33e48f1b058a6cb3e71bbb8df3e90406\n 299894f4ca682943\ny[41] ceeba410b33b07716ffc18d6eab75f2d\n 6372f1133605fa3c\ny[42] 3ed66f2d8f7c5abe59e87d4500965e34\n 7523d73cb356c144\ny[43] 827aaa22b1c72a15293c7400e02aaefc\n f36f68a8246900e6\ny[44] e6228e7ad19d1450c23434f1e45043dc\n 2b6db57f20d8f5b3\ny[45] 44d4162aa651333287cd8bf8fac41c78\n d61fe2929209bfe2\ny[46] dc5a2f80205c043b22e540a29f0ea0a5\n ff529e55bf1dfe42\ny[47] 96fc4bb4ac2e875322ab115db479fe97\n 9d64f78409af4ec3\ny[48] ad3b758fff83af1b9c48e90ca39366f4\n 26c2fb921df55c72\ny[49] 786a9217723945a1ac1a66af7def4f8b\n 367001732cce0e5b\ny[50] ac91ac9d603807f8bab105b46d315d4c\n b88feb1c8686884b\n--------------------------------------------\nLMS type 0000000d # LMS_SHA256_M24_H20\npath[0] 13d1a8ef00c5811c15c4d774fdcf7515\n 5315aff53ebdff8f\npath[1] b6a54f12c165963dd5690cc9842b0e21\n 90afc5443497584c\npath[2] 832155599d00aced84bb3b59170396f7\n db4fa84aa8577f76\npath[3] cf9367d6e99d3d5be3555d7156b004f2\n 002f505681b1ad22\npath[4] 9b9b46a666672aa8ee662c3a0456a9ad\n da7a44fbaca46789\npath[5] 577dcd36dc5cdff34b864d0a32492a0a\n cbcaa6c011748f20\npath[6] 5b91ab2ab84f2333fb3e3b9acaecdac3\n 8b58aa5f32e718e2\npath[7] 25631ed6674cccb8c119acbd4992ab31\n 30a6e912deec5983\npath[8] 5ab52fbc549430f8b403e4a2a51cc7f4\n 6fc143d365763aa1\npath[9] 708fd25bcd657a790e54718d97090624\n 2a3b8a97dff18e91\npath[10] a44c4ba818a8dd2d242251265b023b82\n 6077eb740f6682e6\npath[11] c4ada2b85a67988d406132c2ad899099\n e44cfe610c3a5af7\npath[12] 0b406224411a59597e5dda0f31cd16c9\n 14b67e96141661f0\npath[13] 074f43eb02273481bc324ded26c64f23\n 88559d8c8bd0ef8b\npath[14] 34ca4afebfac2a689b4246c264241488\n dcf922350dc44f7b\npath[15] c09d57dc1126291b2318810e0f44801c\n 071e572fd032c780\npath[16] f44c9503a4c03c37417dc96422ba0849\n c37956f9fd5d33ea\npath[17] 4fcab84276effec652ca77d7d47ac93c\n 633d99e0a236f03d\npath[18] 5587d1990ffaef737fced1f5cdd8f373\n 844e9f316aad41a0\npath[19] b12302639f83a2d74c9fe30d305a942b\n c0c30352a5e44dfb", + "raw": true, + "ja": "" + }, + { + "indent": 16, + "text": "Figure 16: Signature for SHA256/192 with W=4", + "ja": "図 16: W=4 の SHA256/192 の署名" + }, + { + "indent": 0, + "text": "Acknowledgements", + "section_title": true, + "ja": "謝辞" + }, + { + "indent": 3, + "text": "We would like to thank Carsten Bormann, Russ Housley, Andrey Jivsov, Mallory Knodel, Virendra Kumar, Thomas Pornin, and Stanislav Smyshlyaev for their insightful and helpful reviews.", + "ja": "洞察力に富んだ有益なレビューをくださった Carsten Bormann、Russ Housley、Andrey Jivsov、Mallory Knodel、Virendra Kumar、Thomas Portin、Stanislav Smyshlyaev に感謝します。" + }, + { + "indent": 0, + "text": "Authors' Addresses", + "section_title": true, + "ja": "著者の住所" + }, + { + "indent": 3, + "text": "Scott Fluhrer\nCisco Systems\n170 West Tasman Drive\nSan Jose, CA\nUnited States of America\nEmail: sfluhrer@cisco.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Quynh Dang\nNIST\n100 Bureau Drive\nGaithersburg, MD\nUnited States of America\nEmail: quynh.dang@nist.gov", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9861-trans.json b/data/9000/rfc9861-trans.json new file mode 100644 index 000000000..2e8161f3a --- /dev/null +++ b/data/9000/rfc9861-trans.json @@ -0,0 +1,1017 @@ +{ + "title": { + "text": "RFC 9861 - KangarooTwelve and TurboSHAKE", + "ja": "RFC 9861 - KangarooTwelve と TurboSHAKE" + }, + "number": 9861, + "created_at": "2025-10-13 23:24:10.752954+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Research Task Force (IRTF) B. Viguier\nRequest for Comments: 9861 ABN AMRO Bank\nCategory: Informational D. Wong, Ed.\nISSN: 2070-1721 zkSecurity\n G. Van Assche, Ed.\n STMicroelectronics\n Q. Dang, Ed.\n NIST\n J. Daemen, Ed.\n Radboud University\n October 2025", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "KangarooTwelve and TurboSHAKE", + "section_title": true, + "ja": "KangarooTwelve と TurboSHAKE" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document defines four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128, and KT256.", + "ja": "この文書では、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 という名前の、任意の長さの出力を持つハッシュ関数である 4 つの eXtendable-Output Function (XOF) を定義します。" + }, + { + "indent": 3, + "text": "All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way.", + "ja": "4 つの関数はすべて、効率的で安全なハッシュ プリミティブを提供し、最後の 2 つはスケーラブルな方法で実装の並列性を利用できます。" + }, + { + "indent": 3, + "text": "This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in NIST FIPS 202 and is meant to serve as a stable reference and an implementation guide.", + "ja": "この文書は、Crypto Forum Research Group の成果物です。これは、NIST FIPS 202 の順列とスポンジ構造の定義に基づいて構築されており、安定したリファレンスおよび実装ガイドとして機能することを目的としています。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This document is not an Internet Standards Track specification; it is published for informational purposes.", + "ja": "この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。" + }, + { + "indent": 3, + "text": "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 Crypto Forum 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.", + "ja": "この文書は Internet Research Task Force (IRTF) の成果物です。IRTF は、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開には適していない可能性があります。この RFC は、インターネット研究タスクフォース (IRTF) の暗号フォーラム研究グループの合意を表しています。IRSG によって公開が承認された文書は、どのレベルのインターネット標準の候補でもありません。RFC 7841 のセクション 2 を参照してください。" + }, + { + "indent": 3, + "text": "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/rfc9861.", + "ja": "この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9861 で入手できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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.", + "ja": "この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n 1.1. Conventions\n2. TurboSHAKE\n 2.1. Interface\n 2.2. Specifications\n3. KangarooTwelve: Tree Hashing over TurboSHAKE\n 3.1. Interface\n 3.2. Specification of KT128\n 3.3. length_encode( x )\n 3.4. Specification of KT256\n4. Message Authentication Codes\n5. Test Vectors\n6. IANA Considerations\n7. Security Considerations\n8. References\n 8.1. Normative References\n 8.2. Informative References\nAppendix A. Pseudocode\n A.1. Keccak-p[1600,n_r=12]\n A.2. TurboSHAKE128\n A.3. TurboSHAKE256\n A.4. KT128\n A.5. KT256\nAuthors' Addresses", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "This document defines the TurboSHAKE128, TurboSHAKE256 [TURBOSHAKE], KT128, and KT256 [KT] eXtendable-Output Functions (XOFs), i.e., hash function generalizations that can return an output of arbitrary length. Both TurboSHAKE128 and TurboSHAKE256 are based on a Keccak-p permutation specified in [FIPS202] and have a higher speed than the SHA-3 and SHAKE functions.", + "ja": "この文書は、TurboSHAKE128、TurboSHAKE256 [TURBOSHAKE]、KT128、および KT256 [KT] eXtendable-Output Functions (XOF)、つまり、任意の長さの出力を返すことができる一般化されたハッシュ関数を定義します。TurboSHAKE128 と TurboSHAKE256 はどちらも [FIPS202] で指定されている Keccak-p 順列に基づいており、SHA-3 および SHAKE 関数よりも高速です。" + }, + { + "indent": 3, + "text": "TurboSHAKE is a sponge function family that makes use of Keccak-p[n_r=12,b=1600], a round-reduced version of the permutation used in SHA-3. Similarly to the SHAKE's security, it proposes two security strengths: 128 bits for TurboSHAKE128 and 256 bits for TurboSHAKE256. Halving the number of rounds compared to the original SHAKE functions makes TurboSHAKE roughly two times faster.", + "ja": "TurboSHAKE は、SHA-3 で使用される置換の丸め削減バージョンである Keccak-p[n_r=12,b=1600] を利用するスポンジ関数ファミリーです。SHAKE のセキュリティと同様に、TurboSHAKE128 の場合は 128 ビット、TurboSHAKE256 の場合は 256 ビットという 2 つのセキュリティ強度が提案されています。オリジナルの SHAKE 関数と比較してラウンド数が半分になるため、TurboSHAKE は約 2 倍高速になります。" + }, + { + "indent": 3, + "text": "KangarooTwelve applies tree hashing on top of TurboSHAKE and comprises two functions, KT128 and KT256. Note that [KT] only defined KT128 under the name KangarooTwelve. KT256 is defined in this document.", + "ja": "KangarooTwelve は TurboSHAKE にツリー ハッシュを適用し、KT128 と KT256 の 2 つの関数で構成されます。[KT] は KT128 を KangarooTwelve という名前でのみ定義していることに注意してください。KT256 はこの文書で定義されています。" + }, + { + "indent": 3, + "text": "The SHA-3 and SHAKE functions process data in a serial manner and are strongly limited in exploiting available parallelism in modern CPU architectures. Similar to ParallelHash [SP800-185], KangarooTwelve splits the input message into fragments. It then applies TurboSHAKE on each of them separately before applying TurboSHAKE again on the combination of the first fragment and the digests. More precisely, KT128 uses TurboSHAKE128 and KT256 uses TurboSHAKE256. They make use of Sakura coding for ensuring soundness of the tree hashing mode [SAKURA]. The use of TurboSHAKE in KangarooTwelve makes it faster than ParallelHash.", + "ja": "SHA-3 関数と SHAKE 関数はデータをシリアル方式で処理するため、最新の CPU アーキテクチャで利用可能な並列処理の活用には大きな制限があります。ParallelHash [SP800-185] と同様に、KangarooTwelve は入力メッセージをフラグメントに分割します。次に、それぞれに個別に TurboSHAKE を適用してから、最初のフラグメントとダイジェストの組み合わせに再度 TurboSHAKE を適用します。より正確には、KT128 は TurboSHAKE128 を使用し、KT256 は TurboSHAKE256 を使用します。ツリー ハッシュ モード [SAKURA] の健全性を確保するために、Sakura コーディングを利用します。KangarooTwelve で TurboSHAKE を使用すると、ParallelHash よりも高速になります。" + }, + { + "indent": 3, + "text": "The security of TurboSHAKE128, TurboSHAKE256, KT128, and KT256 builds on the public scrutiny that Keccak has received since its publication [KECCAK_CRYPTANALYSIS] [TURBOSHAKE].", + "ja": "TurboSHAKE128、TurboSHAKE256、KT128、および KT256 のセキュリティは、[KECCAK_CRYPTANALYSIS] [TURBOSHAKE] の公開以来 Keccak が受けてきた一般の監視に基づいています。" + }, + { + "indent": 3, + "text": "With respect to functions defined in [FIPS202] and [SP800-185], TurboSHAKE128, TurboSHAKE256, KT128, and KT256 feature the following advantages:", + "ja": "[FIPS202] および [SP800-185] で定義されている関数に関して、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 には次の利点があります。" + }, + { + "indent": 6, + "text": "* Unlike SHA3-224, SHA3-256, SHA3-384, and SHA3-512, the TurboSHAKE and KangarooTwelve functions have an extendable output.", + "ja": "* SHA3-224、SHA3-256、SHA3-384、SHA3-512 とは異なり、TurboSHAKE 関数と KangarooTwelve 関数には拡張可能な出力があります。" + }, + { + "indent": 6, + "text": "* Unlike any functions in [FIPS202], and similar to functions in [SP800-185], KT128 and KT256 allow the use of a customization string.", + "ja": "* [FIPS202] の他の関数とは異なり、[SP800-185] の関数と同様に、KT128 および KT256 ではカスタマイズ文字列の使用が許可されています。" + }, + { + "indent": 6, + "text": "* Unlike any functions in [FIPS202] and [SP800-185] except for ParallelHash, KT128 and KT256 exploit available parallelism.", + "ja": "* ParallelHash を除く [FIPS202] および [SP800-185] の関数とは異なり、KT128 および KT256 は利用可能な並列処理を利用します。" + }, + { + "indent": 6, + "text": "* Unlike ParallelHash, KT128 and KT256 do not have overhead when processing short messages.", + "ja": "* ParallelHash とは異なり、KT128 と KT256 にはショート メッセージを処理する際のオーバーヘッドがありません。" + }, + { + "indent": 6, + "text": "* The permutation in the TurboSHAKE functions has half the number of rounds compared to the one in the SHA-3 and SHAKE functions, making them faster than any function defined in [FIPS202]. The KangarooTwelve functions immediately benefit from the same speedup, improving over [FIPS202] and [SP800-185].", + "ja": "* TurboSHAKE 関数の順列は、SHA-3 および SHAKE 関数の順列に比べてラウンド数が半分であるため、[FIPS202] で定義されているどの関数よりも高速になります。KangarooTwelve 関数は同じ高速化の恩恵をすぐに受けられ、[FIPS202] および [SP800-185] よりも改善されています。" + }, + { + "indent": 3, + "text": "With respect to SHA-256, SHA-512, and other functions defined in [FIPS180], TurboSHAKE128, TurboSHAKE256, KT128, and KT256 feature the following advantages:", + "ja": "SHA-256、SHA-512、および [FIPS180] で定義されているその他の関数に関して、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 には次の利点があります。" + }, + { + "indent": 6, + "text": "* Unlike any functions in [FIPS180], the TurboSHAKE and KangarooTwelve functions have an extendable output.", + "ja": "* [FIPS180] の他の関数とは異なり、TurboSHAKE 関数と KangarooTwelve 関数には拡張可能な出力があります。" + }, + { + "indent": 6, + "text": "* The TurboSHAKE functions produce output at the same rate as they process input, whereas SHA-256 and SHA-512, when used in a mask generation function (MGF) construction, produce output half as fast as they process input.", + "ja": "* TurboSHAKE 関数は入力の処理と同じ速度で出力を生成しますが、SHA-256 および SHA-512 をマスク生成関数 (MGF) の構築で使用すると、入力の処理の半分の速度で出力を生成します。" + }, + { + "indent": 6, + "text": "* Unlike the SHA-256 and SHA-512 functions, TurboSHAKE128, TurboSHAKE256, KT128, and KT256 do not suffer from the length extension weakness.", + "ja": "* SHA-256 および SHA-512 関数とは異なり、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 には長さ拡張の弱点がありません。" + }, + { + "indent": 6, + "text": "* Unlike any functions in [FIPS180], TurboSHAKE128, TurboSHAKE256, KT128, and KT256 use a round function with algebraic degree 2, which makes them more suitable to masking techniques for protections against side-channel attacks.", + "ja": "* [FIPS180] の他の関数とは異なり、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 は代数次数 2 のラウンド関数を使用するため、サイドチャネル攻撃に対する保護のためのマスキング手法により適しています。" + }, + { + "indent": 3, + "text": "This document represents the consensus of the Crypto Forum Research Group (CFRG) in the IRTF. It has been reviewed by two members of the Crypto Review Panel, as well as by several members of the CFRG. It is not an IETF product and is not a standard.", + "ja": "この文書は、IRTF の暗号フォーラム研究グループ (CFRG) の総意を表しています。これは、暗号レビューパネルの 2 人のメンバーと CFRG の数人のメンバーによってレビューされました。これは IETF 製品ではなく、標準でもありません。" + }, + { + "indent": 0, + "text": "1.1. Conventions", + "section_title": true, + "ja": "1.1. 規約" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。" + }, + { + "indent": 3, + "text": "The following notations are used throughout the document:", + "ja": "ドキュメント全体で次の表記が使用されます。" + }, + { + "indent": 6, + "text": "* `...` denotes a string of bytes given in hexadecimal. For example, `0B 80`.", + "ja": "* 「...」は、16 進数で指定されたバイト列を示します。たとえば、「0B 80」です。" + }, + { + "indent": 6, + "text": "* |s| denotes the length of a byte string `s`. For example, |`FF FF`| = 2.", + "ja": "* |s|はバイト列 `s` の長さを示します。たとえば、 |`FF FF`|= 2。" + }, + { + "indent": 6, + "text": "* `00`^b denotes a byte string consisting of the concatenation of b bytes `00`. For example, `00`^7 = `00 00 00 00 00 00 00`.", + "ja": "* '００'＾ｂは、ｂバイトの'００'を連結したバイト列を表す。たとえば、`00`^7 = `00 00 00 00 00 00 00` となります。" + }, + { + "indent": 6, + "text": "* `00`^0 denotes the empty byte string.", + "ja": "* `00`^0 は空のバイト列を表します。" + }, + { + "indent": 6, + "text": "* a||b denotes the concatenation of two strings, a and b. For example, `10`||`F1` = `10 F1`.", + "ja": "* a||b は、2 つの文字列 a と b の連結を示します。たとえば、`10`||`F1` = `10 F1` となります。" + }, + { + "indent": 6, + "text": "* s[n:m] denotes the selection of bytes from n (inclusive) to m (exclusive) of a string s. The indexing of a byte string starts at 0. For example, for s = `A5 C6 D7`, s[0:1] = `A5` and s[1:3] = `C6 D7`.", + "ja": "* s[n:m] は、文字列 s の n (両端を含む) から m (両端を含まない) までのバイトの選択を示します。バイト文字列のインデックスは 0 から始まります。たとえば、s = `A5 C6 D7`、s[0:1] = `A5`、および s[1:3] = `C6 D7` の場合。" + }, + { + "indent": 6, + "text": "* s[n:] denotes the selection of bytes from n to the end of a string s. For example, for s = `A5 C6 D7`, s[0:] = `A5 C6 D7` and s[2:] = `D7`.", + "ja": "* s[n:] は、n から文字列 s の終わりまでのバイトの選択を示します。たとえば、s = `A5 C6 D7`、s[0:] = `A5 C6 D7`、および s[2:] = `D7` の場合。" + }, + { + "indent": 3, + "text": "In the following, x and y are byte strings of equal length:", + "ja": "以下では、x と y は同じ長さのバイト文字列です。" + }, + { + "indent": 6, + "text": "* x^=y denotes x takes the value x XOR y.", + "ja": "* x^=y は、x が値 x XOR y を取ることを示します。" + }, + { + "indent": 6, + "text": "* x & y denotes x AND y.", + "ja": "* x & y は x AND y を表します。" + }, + { + "indent": 3, + "text": "In the following, x and y are integers:", + "ja": "以下では、x と y は整数です。" + }, + { + "indent": 6, + "text": "* x+=y denotes x takes the value x + y.", + "ja": "* x+=y は、x が値 x + y を取ることを示します。" + }, + { + "indent": 6, + "text": "* x-=y denotes x takes the value x - y.", + "ja": "* x-=y は、x が値 x - y を取ることを示します。" + }, + { + "indent": 6, + "text": "* x**y denotes the exponentiation of x by y.", + "ja": "* x**y は、x の y による累乗を表します。" + }, + { + "indent": 6, + "text": "* x mod y denotes the remainder of the division of x by y.", + "ja": "* x mod y は、x を y で割った余りを表します。" + }, + { + "indent": 6, + "text": "* x / y denotes the integer dividend of the division of x by y.", + "ja": "* x / y は、x を y で割った整数の被除数を示します。" + }, + { + "indent": 0, + "text": "2. TurboSHAKE", + "section_title": true, + "ja": "2. ターボシェイク" + }, + { + "indent": 0, + "text": "2.1. Interface", + "section_title": true, + "ja": "2.1. インタフェース" + }, + { + "indent": 3, + "text": "TurboSHAKE is a family of eXtendable-Output Functions (XOFs). Internally, it makes use of the sponge construction, parameterized by two integers, the rate and the capacity, that sum to the permutation width (here, 1600 bits). The rate gives the number of bits processed or produced per call to the permutation, whereas the capacity determines the security level; see [FIPS202] for more details. This document focuses on only two instances, namely TurboSHAKE128 and TurboSHAKE256. (Note that the original definition includes a wider range of instances parameterized by their capacity [TURBOSHAKE].)", + "ja": "TurboSHAKE は、eXtendable-Output Functions (XOF) のファミリーです。内部的には、レートと容量の 2 つの整数でパラメータ化されたスポンジ構造を利用し、その合計が順列幅 (ここでは 1600 ビット) になります。レートは順列への呼び出しごとに処理または生成されるビット数を示しますが、容量はセキュリティ レベルを決定します。詳細については、[FIPS202] を参照してください。このドキュメントでは、TurboSHAKE128 と TurboSHAKE256 という 2 つのインスタンスのみに焦点を当てます。(元の定義には、容量 [TURBOSHAKE] によってパラメーター化された、より広範囲のインスタンスが含まれていることに注意してください。)" + }, + { + "indent": 3, + "text": "A TurboSHAKE instance takes a byte string M, an OPTIONAL byte D, and a positive integer L as input parameters, where:", + "ja": "TurboSHAKE インスタンスは、バイト文字列 M、オプションのバイト D、および正の整数 L を入力パラメータとして受け取ります。" + }, + { + "indent": 6, + "text": "* M byte string is the message,", + "ja": "* M バイトの文字列がメッセージです。" + }, + { + "indent": 6, + "text": "* D byte in the range [`01`, `02`, .. , `7F`] is an OPTIONAL domain separation byte, and", + "ja": "* [`01`, `02`, .. , `7F`] の範囲の D バイトはオプションのドメイン分離バイトであり、" + }, + { + "indent": 6, + "text": "* L positive integer is the requested number of output bytes.", + "ja": "* L の正の整数は、要求された出力バイト数です。" + }, + { + "indent": 3, + "text": "Conceptually, an XOF can be viewed as a hash function with an infinitely long output truncated to L bytes. This means that calling an XOF with the same input parameters but two different lengths yields outputs such that the shorter one is a prefix of the longer one. Specifically, if L1 < L2, then TurboSHAKE(M, D, L1) is the same as the first L1 bytes of TurboSHAKE(M, D, L2).", + "ja": "概念的には、XOF は、L バイトに切り詰められた無限に長い出力を持つハッシュ関数とみなすことができます。これは、同じ入力パラメータで 2 つの異なる長さを指定して XOF を呼び出すと、短い方が長い方のプレフィックスになるような出力が生成されることを意味します。具体的には、L1 < L2 の場合、TurboSHAKE(M, D, L1) は TurboSHAKE(M, D, L2) の最初の L1 バイトと同じになります。" + }, + { + "indent": 3, + "text": "By default, the domain separation byte is `1F`. For an API that does not support a domain separation byte, D MUST be the `1F`.", + "ja": "デフォルトでは、ドメイン分離バイトは「1F」です。ドメイン分離バイトをサポートしない API の場合、D は `1F` でなければなりません。" + }, + { + "indent": 3, + "text": "The TurboSHAKE instance produces output that is a hash of the (M, D) couple. If D is fixed, this becomes a hash of the message M. However, a protocol that requires a number of independent hash functions can choose different values for D to implement these. Specifically, for distinct values D1 and D2, TurboSHAKE(M, D1, L1) and TurboSHAKE(M, D2, L2) yield independent hashes of M.", + "ja": "TurboSHAKE インスタンスは、(M, D) カップルのハッシュである出力を生成します。D が固定されている場合、これはメッセージ M のハッシュになります。ただし、多数の独立したハッシュ関数を必要とするプロトコルでは、これらを実装するために D に異なる値を選択できます。具体的には、個別の値 D1 と D2 の場合、TurboSHAKE(M, D1, L1) と TurboSHAKE(M, D2, L2) は M の独立したハッシュを生成します。" + }, + { + "indent": 3, + "text": "Note that an implementation MAY propose an incremental input interface where the input string M is given in pieces. If so, the output MUST be the same as if the function was called with M equal to the concatenation of the different pieces in the order they were given. Independently, an implementation MAY propose an incremental output interface where the output string is requested in pieces of given lengths. When the output is formed by concatenating the pieces in the requested order, it MUST be the same as if the function was called with L equal to the sum of the given lengths.", + "ja": "実装では、入力文字列 M が分割して与えられるインクリメンタル入力インターフェイスを提案してもよいことに注意してください。そうである場合、出力は、与えられた順序で異なる部分を連結したものに等しい M を指定して関数が呼び出された場合と同じでなければなりません (MUST)。独立して、実装は、出力文字列が指定された長さの断片で要求される増分出力インターフェイスを提案してもよい(MAY)。要求された順序で部分を連結することによって出力が形成される場合、それは、指定された長さの合計に等しい L で関数が呼び出された場合と同じでなければなりません (MUST)。" + }, + { + "indent": 0, + "text": "2.2. Specifications", + "section_title": true, + "ja": "2.2. 仕様" + }, + { + "indent": 3, + "text": "TurboSHAKE makes use of the permutation Keccak-p[1600,n_r=12], i.e., the permutation used in SHAKE and SHA-3 functions reduced to its last n_r=12 rounds as specified in FIPS 202; see Sections 3.3 and 3.4 of [FIPS202]. KP denotes this permutation.", + "ja": "TurboSHAKE は、順列 Keccak-p[1600,n_r=12] を利用します。つまり、FIPS 202 で指定されているように、SHAKE および SHA-3 関数で使用される順列が最後の n_r=12 ラウンドに縮小されます。[FIPS202] のセクション 3.3 および 3.4 を参照。KP はこの順列を示します。" + }, + { + "indent": 3, + "text": "Similarly to SHAKE128, TurboSHAKE128 is a sponge function calling this permutation KP with a rate of 168 bytes or 1344 bits. It follows that TurboSHAKE128 has a capacity of 1600 - 1344 = 256 bits or 32 bytes. Respectively to SHAKE256, TurboSHAKE256 makes use of a rate of 136 bytes or 1088 bits and has a capacity of 512 bits or 64 bytes.", + "ja": "SHAKE128 と同様に、TurboSHAKE128 は、168 バイトまたは 1344 ビットのレートでこの順列 KP を呼び出すスポンジ関数です。したがって、TurboSHAKE128 の容量は 1600 - 1344 = 256 ビットまたは 32 バイトになります。SHAKE256 に対して、TurboSHAKE256 は 136 バイトまたは 1088 ビットのレートを利用し、512 ビットまたは 64 バイトの容量を持ちます。" + }, + { + "indent": 14, + "text": " +---------------+===========+==========+\n | | Rate | Capacity |\n +===============+===========+==========+\n | TurboSHAKE128 | 168 Bytes | 32 Bytes |\n +===============+-----------+----------+\n | TurboSHAKE256 | 136 Bytes | 64 Bytes |\n +===============+-----------+----------+\n\n Table 1", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "We now describe the operations inside TurboSHAKE128.", + "ja": "TurboSHAKE128 内部の動作を説明します。" + }, + { + "indent": 6, + "text": "* First, the input M' is formed by appending the domain separation byte D to the message M.", + "ja": "* まず、入力 M' は、ドメイン分離バイト D をメッセージ M に追加することによって形成されます。" + }, + { + "indent": 6, + "text": "* If the length of M' is not a multiple of 168 bytes, then it is padded with zeros at the end to make it a multiple of 168 bytes. If M' is already a multiple of 168 bytes, then no padding is added. Then, a byte `80` is XORed to the last byte of the padded input M' and the resulting string is split into a sequence of 168-byte blocks.", + "ja": "* M' の長さが 168 バイトの倍数でない場合は、168 バイトの倍数にするために最後にゼロが埋め込まれます。M' がすでに 168 バイトの倍数である場合、パディングは追加されません。次に、バイト「80」がパディングされた入力 M' の最後のバイトと XOR 演算され、結果の文字列が 168 バイトのブロックのシーケンスに分割されます。" + }, + { + "indent": 6, + "text": "* M' never has a length of 0 bytes due to the presence of the domain separation byte.", + "ja": "* ドメイン分離バイトが存在するため、M' の長さが 0 バイトになることはありません。" + }, + { + "indent": 6, + "text": "* As defined by the sponge construction, the process operates on a state and consists of two phases: the absorbing phase, which processes the padded input M', and the squeezing phase, which produces the output.", + "ja": "* スポンジ構造で定義されているように、プロセスは状態に基づいて動作し、パッドされた入力 M' を処理する吸収フェーズと、出力を生成する絞りフェーズの 2 つのフェーズで構成されます。" + }, + { + "indent": 6, + "text": "* In the absorbing phase, the state is initialized to all zero. The message blocks are XORed into the first 168 bytes of the state. Each block absorbed is followed with an application of KP to the state.", + "ja": "* 吸収フェーズでは、状態はすべて 0 に初期化されます。メッセージ ブロックは、状態の最初の 168 バイトに XOR 演算されます。吸収された各ブロックの後に、状態に KP が適用されます。" + }, + { + "indent": 6, + "text": "* In the squeezing phase, the output is formed by taking the first 168 bytes of the state, applying KP to the state, and repeating as many times as is necessary.", + "ja": "* 圧縮フェーズでは、状態の最初の 168 バイトを取得し、その状態に KP を適用し、必要な回数だけ繰り返すことによって出力が形成されます。" + }, + { + "indent": 3, + "text": "TurboSHAKE256 performs the same steps but makes use of 136-byte blocks with respect to the padding, absorbing, and squeezing phases.", + "ja": "TurboSHAKE256 は同じ手順を実行しますが、パディング、吸収、およびスクイージングのフェーズに関して 136 バイトのブロックを使用します。" + }, + { + "indent": 3, + "text": "The definition of the TurboSHAKE functions equivalently implements the pad10*1 rule; see Section 5.1 of [FIPS202] for a definition of pad10*1. While M can be empty, the D byte is always present and is in the `01`-`7F` range. This last byte serves as domain separation and integrates the first bit of padding of the pad10*1 rule (hence, it cannot be `00`). Additionally, it must leave room for the second bit of padding (hence, it cannot have the most significant bit (MSB) set to 1), should it be the last byte of the block. For more details, refer to Section 6.1 of [KT] and Section 3 of [TURBOSHAKE].", + "ja": "TurboSHAKE 関数の定義は、pad10*1 ルールを同等に実装します。Pad10*1 の定義については、[FIPS202] のセクション 5.1 を参照してください。M は空にすることもできますが、D バイトは常に存在し、「01」から「7F」の範囲内にあります。この最後のバイトはドメイン分離として機能し、pad10*1 ルールのパディングの最初のビットを統合します (したがって、「00」にすることはできません)。さらに、それがブロックの最後のバイトである場合、パディングの 2 番目のビット用の余地を残しておく必要があります (したがって、最上位ビット (MSB) を 1 に設定することはできません)。詳細については、[KT] のセクション 6.1 および [TURBOSHAKE] のセクション 3 を参照してください。" + }, + { + "indent": 3, + "text": "The pseudocode versions of TurboSHAKE128 and TurboSHAKE256 are provided in Appendices A.2 and A.3, respectively.", + "ja": "TurboSHAKE128 と TurboSHAKE256 の擬似コード バージョンは、それぞれ付録 A.2 と A.3 に提供されています。" + }, + { + "indent": 0, + "text": "3. KangarooTwelve: Tree Hashing over TurboSHAKE", + "section_title": true, + "ja": "3. KangarooTwelve: TurboSHAKE でのツリー ハッシュ" + }, + { + "indent": 0, + "text": "3.1. Interface", + "section_title": true, + "ja": "3.1. インタフェース" + }, + { + "indent": 3, + "text": "KangarooTwelve is a family of eXtendable-Output Functions (XOFs) consisting of the KT128 and KT256 instances. A KangarooTwelve instance takes two byte strings (M, C) and a positive integer L as input parameters, where:", + "ja": "KangarooTwelve は、KT128 インスタンスと KT256 インスタンスで構成される eXtendable-Output Function (XOF) ファミリです。KangarooTwelve インスタンスは、2 バイト文字列 (M、C) と正の整数 L を入力パラメータとして受け取ります。" + }, + { + "indent": 6, + "text": "* M byte string is the message,", + "ja": "* M バイトの文字列がメッセージです。" + }, + { + "indent": 6, + "text": "* C byte string is an OPTIONAL customization string, and", + "ja": "* C バイト文字列はオプションのカスタマイズ文字列であり、" + }, + { + "indent": 6, + "text": "* L positive integer is the requested number of output bytes.", + "ja": "* L の正の整数は、要求された出力バイト数です。" + }, + { + "indent": 3, + "text": "The customization string MAY serve as domain separation. It is typically a short string such as a name or an identifier (e.g., URI, Object Identifier (OID), etc.). It can serve the same purpose as TurboSHAKE's D input parameter (see Section 2.1) but with a larger range.", + "ja": "カスタマイズ文字列はドメイン分離として機能してもよい(MAY)。これは通常、名前や識別子 (URI、オブジェクト識別子 (OID) など) などの短い文字列です。TurboSHAKE の D 入力パラメータ (セクション 2.1 を参照) と同じ目的を果たすことができますが、範囲がより広くなります。" + }, + { + "indent": 3, + "text": "By default, the customization string is the empty string. For an API that does not support a customization string parameter, C MUST be the empty string.", + "ja": "デフォルトでは、カスタマイズ文字列は空の文字列です。カスタマイズ文字列パラメータをサポートしない API の場合、C は空の文字列でなければなりません。" + }, + { + "indent": 3, + "text": "Note that an implementation MAY propose an interface with the input and/or output provided incrementally, as specified in Section 2.1.", + "ja": "実装は、セクション 2.1 で指定されているように、段階的に提供される入力および/または出力とのインターフェイスを提案してもよいことに注意してください。" + }, + { + "indent": 0, + "text": "3.2. Specification of KT128", + "section_title": true, + "ja": "3.2. KT128の仕様" + }, + { + "indent": 3, + "text": "On top of the sponge function TurboSHAKE128, KT128 uses a Sakura-compatible tree hash mode [SAKURA]. First, merge M and the OPTIONAL C to a single input string S in a reversible way. length_encode( |C| ) gives the length in bytes of C as a byte string. See Section 3.3.", + "ja": "KT128は、スポンジ機能TurboSHAKE128に加えて、さくら互換のツリーハッシュモード[SAKURA]を採用しています。まず、M と OPTIONAL C を単一の入力文字列 S に可逆的な方法でマージします。length_encode( |C| ) は、C のバイト長をバイト文字列として返します。セクション 3.3 を参照してください。" + }, + { + "indent": 7, + "text": "S = M || C || length_encode( |C| )", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Then, split S into n chunks of 8192 bytes.", + "ja": "次に、S を 8192 バイトの n 個のチャンクに分割します。" + }, + { + "indent": 7, + "text": "S = S_0 || .. || S_(n-1)\n|S_0| = .. = |S_(n-2)| = 8192 bytes\n|S_(n-1)| <= 8192 bytes", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "From S_1 .. S_(n-1), compute the 32-byte chaining values CV_1 .. CV_(n-1). In order to be optimally efficient, this computation MAY exploit the parallelism available on the platform, such as single instruction, multiple data (SIMD) instructions.", + "ja": "S_1 .. S_(n-1) から、32 バイトの連鎖値 CV_1 .. CV_(n-1) を計算します。最適な効率を実現するために、この計算は、単一命令複数データ (SIMD) 命令など、プラットフォームで利用可能な並列処理を利用してもよい(MAY)。" + }, + { + "indent": 7, + "text": "CV_i = TurboSHAKE128( S_i, `0B`, 32 )", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Compute the final node: FinalNode.", + "ja": "最終ノード FinalNode を計算します。" + }, + { + "indent": 6, + "text": "* If |S| <= 8192 bytes, FinalNode = S.", + "ja": "* |S| の場合<= 8192 バイト、FinalNode = S。" + }, + { + "indent": 6, + "text": "* Otherwise, compute FinalNode as follows:", + "ja": "* それ以外の場合は、次のように FinalNode を計算します。" + }, + { + "indent": 7, + "text": "FinalNode = S_0 || `03 00 00 00 00 00 00 00`\nFinalNode = FinalNode || CV_1\n ..\nFinalNode = FinalNode || CV_(n-1)\nFinalNode = FinalNode || length_encode(n-1)\nFinalNode = FinalNode || `FF FF`", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Finally, the KT128 output is retrieved:", + "ja": "最後に、KT128 出力が取得されます。" + }, + { + "indent": 6, + "text": "* If |S| <= 8192 bytes, from TurboSHAKE128( FinalNode, `07`, L )", + "ja": "* |S| の場合<= 8192 バイト、TurboSHAKE128( FinalNode, `07`, L ) から" + }, + { + "indent": 7, + "text": "KT128( M, C, L ) = TurboSHAKE128( FinalNode, `07`, L )", + "raw": true, + "ja": "" + }, + { + "indent": 6, + "text": "* Otherwise, from TurboSHAKE128( FinalNode, `06`, L )", + "ja": "* それ以外の場合、TurboSHAKE128( FinalNode, `06`, L ) から" + }, + { + "indent": 7, + "text": "KT128( M, C, L ) = TurboSHAKE128( FinalNode, `06`, L )", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The following figure illustrates the computation flow of KT128 for |S| <= 8192 bytes:", + "ja": "次の図は、|S| に対する KT128 の計算フローを示しています。<= 8192 バイト:" + }, + { + "indent": 7, + "text": "+--------------+ TurboSHAKE128(.., `07`, L)\n| S |-----------------------------> output\n+--------------+", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The following figure illustrates the computation flow of KT128 for |S| > 8192 bytes and where TurboSHAKE128 and length_encode( x ) are abbreviated as TSHK128 and l_e( x ), respectively:", + "ja": "次の図は、|S| に対する KT128 の計算フローを示しています。> 8192 バイトであり、TurboSHAKE128 と length_encode( x ) はそれぞれ TSHK128 と l_e( x ) と省略されます。" + }, + { + "indent": 3, + "text": " +--------------+\n | S_0 |\n +--------------+\n ||\n +--------------+\n | `03`||`00`^7 |\n +--------------+\n ||\n+---------+ TSHK128(..,`0B`,32) +--------------+\n| S_1 |---------------------->| CV_1 |\n+---------+ +--------------+\n ||\n+---------+ TSHK128(..,`0B`,32) +--------------+\n| S_2 |---------------------->| CV_2 |\n+---------+ +--------------+\n ||\n .. ..\n ||\n+---------+ TSHK128(..,`0B`,32) +--------------+\n| S_(n-1) |----------------------->| CV_(n-1) |\n+---------+ +--------------+\n ||\n +--------------+\n | l_e( n-1 ) |\n +--------------+\n ||\n +--------------+\n | `FF FF` |\n +--------------+\n | TSHK128(.., `06`, L)\n +--------------------> output", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "A pseudocode version is provided in Appendix A.4.", + "ja": "疑似コードのバージョンは付録 A.4 に記載されています。" + }, + { + "indent": 3, + "text": "The table below gathers the values of the domain separation bytes used by the tree hash mode:", + "ja": "以下の表は、ツリー ハッシュ モードで使用されるドメイン分離バイトの値をまとめたものです。" + }, + { + "indent": 21, + "text": " +==================+======+\n | Type | Byte |\n +==================+======+\n | SingleNode | `07` |\n +------------------+------+\n | IntermediateNode | `0B` |\n +------------------+------+\n | FinalNode | `06` |\n +------------------+------+\n\n Table 2", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "3.3. length_encode( x )", + "section_title": true, + "ja": "3.3. length_encode( x )" + }, + { + "indent": 3, + "text": "The function length_encode takes as inputs a non-negative integer x < 256**255 and outputs a string of bytes x_(n-1) || .. || x_0 || n where", + "ja": "関数 length_encode は、負でない整数 x < 256**255 を入力として受け取り、バイト文字列 x_(n-1) || を出力します。.. ||x_0 ||どこで" + }, + { + "indent": 7, + "text": "x = sum of 256**i * x_i for i from 0 to n-1", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "and where n is the smallest non-negative integer such that x < 256**n. n is also the length of x_(n-1) || .. || x_0.", + "ja": "ここで、n は、x < 256**n となる最小の非負の整数です。n は x_(n-1) の長さでもあります ||.. ||x_0。" + }, + { + "indent": 3, + "text": "For example, length_encode(0) = `00`, length_encode(12) = `0C 01`, and length_encode(65538) = `01 00 02 03`.", + "ja": "たとえば、length_encode(0) = `00`、length_encode(12) = `0C 01`、および length_encode(65538) = `01 00 02 03` です。" + }, + { + "indent": 3, + "text": "A pseudocode version is as follows, where { b } denotes the byte of numerical value b.", + "ja": "擬似コードのバージョンは次のとおりです。ここで、{ b } は数値 b のバイトを示します。" + }, + { + "indent": 5, + "text": "length_encode(x):\n S = `00`^0\n\n while x > 0\n S = { x mod 256 } || S\n x = x / 256\n\n S = S || { |S| }\n\n return S\n end", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "3.4. Specification of KT256", + "section_title": true, + "ja": "3.4. KT256の仕様" + }, + { + "indent": 3, + "text": "KT256 is specified exactly like KT128, with two differences:", + "ja": "KT256 は KT128 とまったく同じように指定されますが、次の 2 つの違いがあります。" + }, + { + "indent": 6, + "text": "* All the calls to TurboSHAKE128 in KT128 are replaced with calls to TurboSHAKE256 in KT256.", + "ja": "* KT128 の TurboSHAKE128 への呼び出しはすべて、KT256 の TurboSHAKE256 への呼び出しに置き換えられます。" + }, + { + "indent": 6, + "text": "* The chaining values CV_1 to CV_(n-1) are 64 bytes long in KT256 and are computed as follows:", + "ja": "* チェーン値 CV_1 から CV_(n-1) は、KT256 では 64 バイトの長さであり、次のように計算されます。" + }, + { + "indent": 7, + "text": "CV_i = TurboSHAKE256( S_i, `0B`, 64 )", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "A pseudocode version is provided in Appendix A.5.", + "ja": "疑似コード バージョンは付録 A.5 に提供されています。" + }, + { + "indent": 0, + "text": "4. Message Authentication Codes", + "section_title": true, + "ja": "4. メッセージ認証コード" + }, + { + "indent": 3, + "text": "Implementing a Message Authentication Code (MAC) with KT128 or KT256 MAY use a hash-then-MAC construction. This document defines and recommends a method called HopMAC:", + "ja": "KT128 または KT256 を使用したメッセージ認証コード (MAC) の実装では、hash-then-MAC 構造を使用してもよい(MAY)。この文書では、HopMAC と呼ばれる方法を定義し、推奨しています。" + }, + { + "indent": 7, + "text": "HopMAC128(Key, M, C, L) = KT128(Key, KT128(M, C, 32), L)\nHopMAC256(Key, M, C, L) = KT256(Key, KT256(M, C, 64), L)", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Similarly to Hashed Message Authentication Code (HMAC), HopMAC consists of two calls: an inner call compressing the message M and the optional customization string C to a digest and an outer call computing the tag from the key and the digest.", + "ja": "ハッシュ メッセージ認証コード (HMAC) と同様に、HopMAC は 2 つの呼び出しで構成されます。1 つはメッセージ M とオプションのカスタマイズ文字列 C をダイジェストに圧縮する内部呼び出しで、もう 1 つはキーとダイジェストからタグを計算する外部呼び出しです。" + }, + { + "indent": 3, + "text": "Unlike HMAC, the inner call to KangarooTwelve in HopMAC is keyless and does not require additional protection against side channel attacks (SCAs). Consequently, in an implementation that has to protect the HopMAC key against an SCA, only the outer call needs protection, and this amounts to a single execution of the underlying permutation (assuming the key length is at most 69 bytes).", + "ja": "HMAC とは異なり、HopMAC の KangarooTwelve への内部呼び出しはキーレスであり、サイド チャネル攻撃 (SCA) に対する追加の保護を必要としません。したがって、HopMAC キーを SCA から保護する必要がある実装では、保護が必要なのは外側の呼び出しのみであり、これは基礎となる置換の 1 回の実行に相当します (キーの長さが最大 69 バイトであると仮定)。" + }, + { + "indent": 3, + "text": "In any case, TurboSHAKE128, TurboSHAKE256, KT128, and KT256 MAY be used to compute a MAC with the key reversibly prepended or appended to the input. For instance, one MAY compute a MAC on short messages simply calling KT128 with the key as the customization string, i.e., MAC = KT128(M, Key, L).", + "ja": "いずれの場合も、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 を使用して、入力の先頭または末尾に可逆的にキーを付加して MAC を計算できます。たとえば、カスタマイズ文字列としてキーを使用して KT128 を呼び出すだけで、ショート メッセージの MAC を計算できます (つまり、MAC = KT128(M, Key, L))。" + }, + { + "indent": 0, + "text": "5. Test Vectors", + "section_title": true, + "ja": "5. テストベクター" + }, + { + "indent": 3, + "text": "Test vectors are based on the repetition of the pattern `00 01 02 .. F9 FA` with a specific length. ptn(n) defines a string by repeating the pattern `00 01 02 .. F9 FA` as many times as necessary and truncated to n bytes, for example:", + "ja": "テスト ベクトルは、特定の長さのパターン「00 01 02 .. F9 FA」の繰り返しに基づいています。ptn(n) は、パターン「00 01 02 .. F9 FA」を必要なだけ繰り返し、n バイトに切り詰めて文字列を定義します。次に例を示します。" + }, + { + "indent": 7, + "text": "Pattern for a length of 17 bytes:\nptn(17) =\n `00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10`", + "raw": true, + "ja": "" + }, + { + "indent": 7, + "text": "Pattern for a length of 17**2 bytes:\nptn(17**2) =\n `00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F\n 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F\n 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F\n 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F\n 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F\n 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F\n 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F\n 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F\n 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F\n 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F\n A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF\n B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF\n C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF\n D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF\n E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF\n F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA\n 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F\n 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F\n 20 21 22 23 24 25`", + "raw": true, + "ja": "" + }, + { + "indent": 5, + "text": "TurboSHAKE128(M=`00`^0, D=`1F`, 32):\n `1E 41 5F 1C 59 83 AF F2 16 92 17 27 7D 17 BB 53\n 8C D9 45 A3 97 DD EC 54 1F 1C E4 1A F2 C1 B7 4C`\n\nTurboSHAKE128(M=`00`^0, D=`1F`, 64):\n `1E 41 5F 1C 59 83 AF F2 16 92 17 27 7D 17 BB 53\n 8C D9 45 A3 97 DD EC 54 1F 1C E4 1A F2 C1 B7 4C\n 3E 8C CA E2 A4 DA E5 6C 84 A0 4C 23 85 C0 3C 15\n E8 19 3B DF 58 73 73 63 32 16 91 C0 54 62 C8 DF`\n\nTurboSHAKE128(M=`00`^0, D=`1F`, 10032), last 32 bytes:\n `A3 B9 B0 38 59 00 CE 76 1F 22 AE D5 48 E7 54 DA\n 10 A5 24 2D 62 E8 C6 58 E3 F3 A9 23 A7 55 56 07`\n\nTurboSHAKE128(M=ptn(17**0 bytes), D=`1F`, 32):\n `55 CE DD 6F 60 AF 7B B2 9A 40 42 AE 83 2E F3 F5\n 8D B7 29 9F 89 3E BB 92 47 24 7D 85 69 58 DA A9`\n\nTurboSHAKE128(M=ptn(17**1 bytes), D=`1F`, 32):\n `9C 97 D0 36 A3 BA C8 19 DB 70 ED E0 CA 55 4E C6\n E4 C2 A1 A4 FF BF D9 EC 26 9C A6 A1 11 16 12 33`\n\nTurboSHAKE128(M=ptn(17**2 bytes), D=`1F`, 32):\n `96 C7 7C 27 9E 01 26 F7 FC 07 C9 B0 7F 5C DA E1\n E0 BE 60 BD BE 10 62 00 40 E7 5D 72 23 A6 24 D2`\n\nTurboSHAKE128(M=ptn(17**3 bytes), D=`1F`, 32):\n `D4 97 6E B5 6B CF 11 85 20 58 2B 70 9F 73 E1 D6\n 85 3E 00 1F DA F8 0E 1B 13 E0 D0 59 9D 5F B3 72`\n\nTurboSHAKE128(M=ptn(17**4 bytes), D=`1F`, 32):\n `DA 67 C7 03 9E 98 BF 53 0C F7 A3 78 30 C6 66 4E\n 14 CB AB 7F 54 0F 58 40 3B 1B 82 95 13 18 EE 5C`\n\nTurboSHAKE128(M=ptn(17**5 bytes), D=`1F`, 32):\n `B9 7A 90 6F BF 83 EF 7C 81 25 17 AB F3 B2 D0 AE\n A0 C4 F6 03 18 CE 11 CF 10 39 25 12 7F 59 EE CD`\n\nTurboSHAKE128(M=ptn(17**6 bytes), D=`1F`, 32):\n `35 CD 49 4A DE DE D2 F2 52 39 AF 09 A7 B8 EF 0C\n 4D 1C A4 FE 2D 1A C3 70 FA 63 21 6F E7 B4 C2 B1`\n\nTurboSHAKE128(M=`FF FF FF`, D=`01`, 32):\n `BF 32 3F 94 04 94 E8 8E E1 C5 40 FE 66 0B E8 A0\n C9 3F 43 D1 5E C0 06 99 84 62 FA 99 4E ED 5D AB`\n\nTurboSHAKE128(M=`FF`, D=`06`, 32):\n `8E C9 C6 64 65 ED 0D 4A 6C 35 D1 35 06 71 8D 68\n 7A 25 CB 05 C7 4C CA 1E 42 50 1A BD 83 87 4A 67`\n\nTurboSHAKE128(M=`FF FF FF`, D=`07`, 32):\n `B6 58 57 60 01 CA D9 B1 E5 F3 99 A9 F7 77 23 BB\n A0 54 58 04 2D 68 20 6F 72 52 68 2D BA 36 63 ED`\n\nTurboSHAKE128(M=`FF FF FF FF FF FF FF`, D=`0B`, 32):\n `8D EE AA 1A EC 47 CC EE 56 9F 65 9C 21 DF A8 E1\n 12 DB 3C EE 37 B1 81 78 B2 AC D8 05 B7 99 CC 37`\n\nTurboSHAKE128(M=`FF`, D=`30`, 32):\n `55 31 22 E2 13 5E 36 3C 32 92 BE D2 C6 42 1F A2\n 32 BA B0 3D AA 07 C7 D6 63 66 03 28 65 06 32 5B`\n\nTurboSHAKE128(M=`FF FF FF`, D=`7F`, 32):\n `16 27 4C C6 56 D4 4C EF D4 22 39 5D 0F 90 53 BD\n A6 D2 8E 12 2A BA 15 C7 65 E5 AD 0E 6E AF 26 F9`", + "raw": true, + "ja": "" + }, + { + "indent": 5, + "text": "TurboSHAKE256(M=`00`^0, D=`1F`, 64):\n `36 7A 32 9D AF EA 87 1C 78 02 EC 67 F9 05 AE 13\n C5 76 95 DC 2C 66 63 C6 10 35 F5 9A 18 F8 E7 DB\n 11 ED C0 E1 2E 91 EA 60 EB 6B 32 DF 06 DD 7F 00\n 2F BA FA BB 6E 13 EC 1C C2 0D 99 55 47 60 0D B0`\n\nTurboSHAKE256(M=`00`^0, D=`1F`, 10032), last 32 bytes:\n `AB EF A1 16 30 C6 61 26 92 49 74 26 85 EC 08 2F\n 20 72 65 DC CF 2F 43 53 4E 9C 61 BA 0C 9D 1D 75`\n\nTurboSHAKE256(M=ptn(17**0 bytes), D=`1F`, 64):\n `3E 17 12 F9 28 F8 EA F1 05 46 32 B2 AA 0A 24 6E\n D8 B0 C3 78 72 8F 60 BC 97 04 10 15 5C 28 82 0E\n 90 CC 90 D8 A3 00 6A A2 37 2C 5C 5E A1 76 B0 68\n 2B F2 2B AE 74 67 AC 94 F7 4D 43 D3 9B 04 82 E2`\n\nTurboSHAKE256(M=ptn(17**1 bytes), D=`1F`, 64):\n `B3 BA B0 30 0E 6A 19 1F BE 61 37 93 98 35 92 35\n 78 79 4E A5 48 43 F5 01 10 90 FA 2F 37 80 A9 E5\n CB 22 C5 9D 78 B4 0A 0F BF F9 E6 72 C0 FB E0 97\n 0B D2 C8 45 09 1C 60 44 D6 87 05 4D A5 D8 E9 C7`\n\nTurboSHAKE256(M=ptn(17**2 bytes), D=`1F`, 64):\n `66 B8 10 DB 8E 90 78 04 24 C0 84 73 72 FD C9 57\n 10 88 2F DE 31 C6 DF 75 BE B9 D4 CD 93 05 CF CA\n E3 5E 7B 83 E8 B7 E6 EB 4B 78 60 58 80 11 63 16\n FE 2C 07 8A 09 B9 4A D7 B8 21 3C 0A 73 8B 65 C0`\n\nTurboSHAKE256(M=ptn(17**3 bytes), D=`1F`, 64):\n `C7 4E BC 91 9A 5B 3B 0D D1 22 81 85 BA 02 D2 9E\n F4 42 D6 9D 3D 42 76 A9 3E FE 0B F9 A1 6A 7D C0\n CD 4E AB AD AB 8C D7 A5 ED D9 66 95 F5 D3 60 AB\n E0 9E 2C 65 11 A3 EC 39 7D A3 B7 6B 9E 16 74 FB`\n\nTurboSHAKE256(M=ptn(17**4 bytes), D=`1F`, 64):\n `02 CC 3A 88 97 E6 F4 F6 CC B6 FD 46 63 1B 1F 52\n 07 B6 6C 6D E9 C7 B5 5B 2D 1A 23 13 4A 17 0A FD\n AC 23 4E AB A9 A7 7C FF 88 C1 F0 20 B7 37 24 61\n 8C 56 87 B3 62 C4 30 B2 48 CD 38 64 7F 84 8A 1D`\n\nTurboSHAKE256(M=ptn(17**5 bytes), D=`1F`, 64):\n `AD D5 3B 06 54 3E 58 4B 58 23 F6 26 99 6A EE 50\n FE 45 ED 15 F2 02 43 A7 16 54 85 AC B4 AA 76 B4\n FF DA 75 CE DF 6D 8C DC 95 C3 32 BD 56 F4 B9 86\n B5 8B B1 7D 17 78 BF C1 B1 A9 75 45 CD F4 EC 9F`\n\nTurboSHAKE256(M=ptn(17**6 bytes), D=`1F`, 64):\n `9E 11 BC 59 C2 4E 73 99 3C 14 84 EC 66 35 8E F7\n 1D B7 4A EF D8 4E 12 3F 78 00 BA 9C 48 53 E0 2C\n FE 70 1D 9E 6B B7 65 A3 04 F0 DC 34 A4 EE 3B A8\n 2C 41 0F 0D A7 0E 86 BF BD 90 EA 87 7C 2D 61 04`\n\nTurboSHAKE256(M=`FF FF FF`, D=`01`, 64):\n `D2 1C 6F BB F5 87 FA 22 82 F2 9A EA 62 01 75 FB\n 02 57 41 3A F7 8A 0B 1B 2A 87 41 9C E0 31 D9 33\n AE 7A 4D 38 33 27 A8 A1 76 41 A3 4F 8A 1D 10 03\n AD 7D A6 B7 2D BA 84 BB 62 FE F2 8F 62 F1 24 24`\n\nTurboSHAKE256(M=`FF`, D=`06`, 64):\n `73 8D 7B 4E 37 D1 8B 7F 22 AD 1B 53 13 E3 57 E3\n DD 7D 07 05 6A 26 A3 03 C4 33 FA 35 33 45 52 80\n F4 F5 A7 D4 F7 00 EF B4 37 FE 6D 28 14 05 E0 7B\n E3 2A 0A 97 2E 22 E6 3A DC 1B 09 0D AE FE 00 4B`\n\nTurboSHAKE256(M=`FF FF FF`, D=`07`, 64):\n `18 B3 B5 B7 06 1C 2E 67 C1 75 3A 00 E6 AD 7E D7\n BA 1C 90 6C F9 3E FB 70 92 EA F2 7F BE EB B7 55\n AE 6E 29 24 93 C1 10 E4 8D 26 00 28 49 2B 8E 09\n B5 50 06 12 B8 F2 57 89 85 DE D5 35 7D 00 EC 67`\n\nTurboSHAKE256(M=`FF FF FF FF FF FF FF`, D=`0B`, 64):\n `BB 36 76 49 51 EC 97 E9 D8 5F 7E E9 A6 7A 77 18\n FC 00 5C F4 25 56 BE 79 CE 12 C0 BD E5 0E 57 36\n D6 63 2B 0D 0D FB 20 2D 1B BB 8F FE 3D D7 4C B0\n 08 34 FA 75 6C B0 34 71 BA B1 3A 1E 2C 16 B3 C0`\n\nTurboSHAKE256(M=`FF`, D=`30`, 64):\n `F3 FE 12 87 3D 34 BC BB 2E 60 87 79 D6 B7 0E 7F\n 86 BE C7 E9 0B F1 13 CB D4 FD D0 C4 E2 F4 62 5E\n 14 8D D7 EE 1A 52 77 6C F7 7F 24 05 14 D9 CC FC\n 3B 5D DA B8 EE 25 5E 39 EE 38 90 72 96 2C 11 1A`\n\nTurboSHAKE256(M=`FF FF FF`, D=`7F`, 64):\n `AB E5 69 C1 F7 7E C3 40 F0 27 05 E7 D3 7C 9A B7\n E1 55 51 6E 4A 6A 15 00 21 D7 0B 6F AC 0B B4 0C\n 06 9F 9A 98 28 A0 D5 75 CD 99 F9 BA E4 35 AB 1A\n CF 7E D9 11 0B A9 7C E0 38 8D 07 4B AC 76 87 76`", + "raw": true, + "ja": "" + }, + { + "indent": 5, + "text": "KT128(M=`00`^0, C=`00`^0, 32):\n `1A C2 D4 50 FC 3B 42 05 D1 9D A7 BF CA 1B 37 51\n 3C 08 03 57 7A C7 16 7F 06 FE 2C E1 F0 EF 39 E5`\n\nKT128(M=`00`^0, C=`00`^0, 64):\n `1A C2 D4 50 FC 3B 42 05 D1 9D A7 BF CA 1B 37 51\n 3C 08 03 57 7A C7 16 7F 06 FE 2C E1 F0 EF 39 E5\n 42 69 C0 56 B8 C8 2E 48 27 60 38 B6 D2 92 96 6C\n C0 7A 3D 46 45 27 2E 31 FF 38 50 81 39 EB 0A 71`\n\nKT128(M=`00`^0, C=`00`^0, 10032), last 32 bytes:\n `E8 DC 56 36 42 F7 22 8C 84 68 4C 89 84 05 D3 A8\n 34 79 91 58 C0 79 B1 28 80 27 7A 1D 28 E2 FF 6D`\n\nKT128(M=ptn(1 bytes), C=`00`^0, 32):\n `2B DA 92 45 0E 8B 14 7F 8A 7C B6 29 E7 84 A0 58\n EF CA 7C F7 D8 21 8E 02 D3 45 DF AA 65 24 4A 1F`\n\nKT128(M=ptn(17 bytes), C=`00`^0, 32):\n `6B F7 5F A2 23 91 98 DB 47 72 E3 64 78 F8 E1 9B\n 0F 37 12 05 F6 A9 A9 3A 27 3F 51 DF 37 12 28 88`\n\nKT128(M=ptn(17**2 bytes), C=`00`^0, 32):\n `0C 31 5E BC DE DB F6 14 26 DE 7D CF 8F B7 25 D1\n E7 46 75 D7 F5 32 7A 50 67 F3 67 B1 08 EC B6 7C`\n\nKT128(M=ptn(17**3 bytes), C=`00`^0, 32):\n `CB 55 2E 2E C7 7D 99 10 70 1D 57 8B 45 7D DF 77\n 2C 12 E3 22 E4 EE 7F E4 17 F9 2C 75 8F 0D 59 D0`\n\nKT128(M=ptn(17**4 bytes), C=`00`^0, 32):\n `87 01 04 5E 22 20 53 45 FF 4D DA 05 55 5C BB 5C\n 3A F1 A7 71 C2 B8 9B AE F3 7D B4 3D 99 98 B9 FE`\n\nKT128(M=ptn(17**5 bytes), C=`00`^0, 32):\n `84 4D 61 09 33 B1 B9 96 3C BD EB 5A E3 B6 B0 5C\n C7 CB D6 7C EE DF 88 3E B6 78 A0 A8 E0 37 16 82`\n\nKT128(M=ptn(17**6 bytes), C=`00`^0, 32):\n `3C 39 07 82 A8 A4 E8 9F A6 36 7F 72 FE AA F1 32\n 55 C8 D9 58 78 48 1D 3C D8 CE 85 F5 8E 88 0A F8`\n\nKT128(`00`^0, C=ptn(1 bytes), 32):\n `FA B6 58 DB 63 E9 4A 24 61 88 BF 7A F6 9A 13 30\n 45 F4 6E E9 84 C5 6E 3C 33 28 CA AF 1A A1 A5 83`\n\nKT128(`FF`, C=ptn(41 bytes), 32):\n `D8 48 C5 06 8C ED 73 6F 44 62 15 9B 98 67 FD 4C\n 20 B8 08 AC C3 D5 BC 48 E0 B0 6B A0 A3 76 2E C4`\n\nKT128(`FF FF FF`, C=ptn(41**2 bytes), 32):\n `C3 89 E5 00 9A E5 71 20 85 4C 2E 8C 64 67 0A C0\n 13 58 CF 4C 1B AF 89 44 7A 72 42 34 DC 7C ED 74`\n\nKT128(`FF FF FF FF FF FF FF`, C=ptn(41**3 bytes), 32):\n `75 D2 F8 6A 2E 64 45 66 72 6B 4F BC FC 56 57 B9\n DB CF 07 0C 7B 0D CA 06 45 0A B2 91 D7 44 3B CF`\n\nKT128(M=ptn(8191 bytes), C=`00`^0, 32):\n `1B 57 76 36 F7 23 64 3E 99 0C C7 D6 A6 59 83 74\n 36 FD 6A 10 36 26 60 0E B8 30 1C D1 DB E5 53 D6`\n\nKT128(M=ptn(8192 bytes), C=`00`^0, 32):\n `48 F2 56 F6 77 2F 9E DF B6 A8 B6 61 EC 92 DC 93\n B9 5E BD 05 A0 8A 17 B3 9A E3 49 08 70 C9 26 C3`\n\nKT128(M=ptn(8192 bytes), C=ptn(8189 bytes), 32):\n `3E D1 2F 70 FB 05 DD B5 86 89 51 0A B3 E4 D2 3C\n 6C 60 33 84 9A A0 1E 1D 8C 22 0A 29 7F ED CD 0B`\n\nKT128(M=ptn(8192 bytes), C=ptn(8190 bytes), 32):\n `6A 7C 1B 6A 5C D0 D8 C9 CA 94 3A 4A 21 6C C6 46\n 04 55 9A 2E A4 5F 78 57 0A 15 25 3D 67 BA 00 AE`", + "raw": true, + "ja": "" + }, + { + "indent": 5, + "text": "KT256(M=`00`^0, C=`00`^0, 64):\n `B2 3D 2E 9C EA 9F 49 04 E0 2B EC 06 81 7F C1 0C\n E3 8C E8 E9 3E F4 C8 9E 65 37 07 6A F8 64 64 04\n E3 E8 B6 81 07 B8 83 3A 5D 30 49 0A A3 34 82 35\n 3F D4 AD C7 14 8E CB 78 28 55 00 3A AE BD E4 A9`\n\nKT256(M=`00`^0, C=`00`^0, 128):\n `B2 3D 2E 9C EA 9F 49 04 E0 2B EC 06 81 7F C1 0C\n E3 8C E8 E9 3E F4 C8 9E 65 37 07 6A F8 64 64 04\n E3 E8 B6 81 07 B8 83 3A 5D 30 49 0A A3 34 82 35\n 3F D4 AD C7 14 8E CB 78 28 55 00 3A AE BD E4 A9\n B0 92 53 19 D8 EA 1E 12 1A 60 98 21 EC 19 EF EA\n 89 E6 D0 8D AE E1 66 2B 69 C8 40 28 9F 18 8B A8\n 60 F5 57 60 B6 1F 82 11 4C 03 0C 97 E5 17 84 49\n 60 8C CD 2C D2 D9 19 FC 78 29 FF 69 93 1A C4 D0`\n\nKT256(M=`00`^0, C=`00`^0, 10064), last 64 bytes:\n `AD 4A 1D 71 8C F9 50 50 67 09 A4 C3 33 96 13 9B\n 44 49 04 1F C7 9A 05 D6 8D A3 5F 1E 45 35 22 E0\n 56 C6 4F E9 49 58 E7 08 5F 29 64 88 82 59 B9 93\n 27 52 F3 CC D8 55 28 8E FE E5 FC BB 8B 56 30 69`\n\nKT256(M=ptn(1 bytes), C=`00`^0, 64):\n `0D 00 5A 19 40 85 36 02 17 12 8C F1 7F 91 E1 F7\n 13 14 EF A5 56 45 39 D4 44 91 2E 34 37 EF A1 7F\n 82 DB 6F 6F FE 76 E7 81 EA A0 68 BC E0 1F 2B BF\n 81 EA CB 98 3D 72 30 F2 FB 02 83 4A 21 B1 DD D0`\n\nKT256(M=ptn(17 bytes), C=`00`^0, 64):\n `1B A3 C0 2B 1F C5 14 47 4F 06 C8 97 99 78 A9 05\n 6C 84 83 F4 A1 B6 3D 0D CC EF E3 A2 8A 2F 32 3E\n 1C DC CA 40 EB F0 06 AC 76 EF 03 97 15 23 46 83\n 7B 12 77 D3 E7 FA A9 C9 65 3B 19 07 50 98 52 7B`\n\nKT256(M=ptn(17**2 bytes), C=`00`^0, 64):\n `DE 8C CB C6 3E 0F 13 3E BB 44 16 81 4D 4C 66 F6\n 91 BB F8 B6 A6 1E C0 A7 70 0F 83 6B 08 6C B0 29\n D5 4F 12 AC 71 59 47 2C 72 DB 11 8C 35 B4 E6 AA\n 21 3C 65 62 CA AA 9D CC 51 89 59 E6 9B 10 F3 BA`\n\nKT256(M=ptn(17**3 bytes), C=`00`^0, 64):\n `64 7E FB 49 FE 9D 71 75 00 17 1B 41 E7 F1 1B D4\n 91 54 44 43 20 99 97 CE 1C 25 30 D1 5E B1 FF BB\n 59 89 35 EF 95 45 28 FF C1 52 B1 E4 D7 31 EE 26\n 83 68 06 74 36 5C D1 91 D5 62 BA E7 53 B8 4A A5`\n\nKT256(M=ptn(17**4 bytes), C=`00`^0, 64):\n `B0 62 75 D2 84 CD 1C F2 05 BC BE 57 DC CD 3E C1\n FF 66 86 E3 ED 15 77 63 83 E1 F2 FA 3C 6A C8 F0\n 8B F8 A1 62 82 9D B1 A4 4B 2A 43 FF 83 DD 89 C3\n CF 1C EB 61 ED E6 59 76 6D 5C CF 81 7A 62 BA 8D`\n\nKT256(M=ptn(17**5 bytes), C=`00`^0, 64):\n `94 73 83 1D 76 A4 C7 BF 77 AC E4 5B 59 F1 45 8B\n 16 73 D6 4B CD 87 7A 7C 66 B2 66 4A A6 DD 14 9E\n 60 EA B7 1B 5C 2B AB 85 8C 07 4D ED 81 DD CE 2B\n 40 22 B5 21 59 35 C0 D4 D1 9B F5 11 AE EB 07 72`\n\nKT256(M=ptn(17**6 bytes), C=`00`^0, 64):\n `06 52 B7 40 D7 8C 5E 1F 7C 8D CC 17 77 09 73 82\n 76 8B 7F F3 8F 9A 7A 20 F2 9F 41 3B B1 B3 04 5B\n 31 A5 57 8F 56 8F 91 1E 09 CF 44 74 6D A8 42 24\n A5 26 6E 96 A4 A5 35 E8 71 32 4E 4F 9C 70 04 DA`\n\nKT256(`00`^0, C=ptn(1 bytes), 64):\n `92 80 F5 CC 39 B5 4A 5A 59 4E C6 3D E0 BB 99 37\n 1E 46 09 D4 4B F8 45 C2 F5 B8 C3 16 D7 2B 15 98\n 11 F7 48 F2 3E 3F AB BE 5C 32 26 EC 96 C6 21 86\n DF 2D 33 E9 DF 74 C5 06 9C EE CB B4 DD 10 EF F6`\n\nKT256(`FF`, C=ptn(41 bytes), 64):\n `47 EF 96 DD 61 6F 20 09 37 AA 78 47 E3 4E C2 FE\n AE 80 87 E3 76 1D C0 F8 C1 A1 54 F5 1D C9 CC F8\n 45 D7 AD BC E5 7F F6 4B 63 97 22 C6 A1 67 2E 3B\n F5 37 2D 87 E0 0A FF 89 BE 97 24 07 56 99 88 53`\n\nKT256(`FF FF FF`, C=ptn(41**2 bytes), 64):\n `3B 48 66 7A 50 51 C5 96 6C 53 C5 D4 2B 95 DE 45\n 1E 05 58 4E 78 06 E2 FB 76 5E DA 95 90 74 17 2C\n B4 38 A9 E9 1D DE 33 7C 98 E9 C4 1B ED 94 C4 E0\n AE F4 31 D0 B6 4E F2 32 4F 79 32 CA A6 F5 49 69`\n\nKT256(`FF FF FF FF FF FF FF`, C=ptn(41**3 bytes), 64):\n `E0 91 1C C0 00 25 E1 54 08 31 E2 66 D9 4A DD 9B\n 98 71 21 42 B8 0D 26 29 E6 43 AA C4 EF AF 5A 3A\n 30 A8 8C BF 4A C2 A9 1A 24 32 74 30 54 FB CC 98\n 97 67 0E 86 BA 8C EC 2F C2 AC E9 C9 66 36 97 24`\n\nKT256(M=ptn(8191 bytes), C=`00`^0, 64):\n `30 81 43 4D 93 A4 10 8D 8D 8A 33 05 B8 96 82 CE\n BE DC 7C A4 EA 8A 3C E8 69 FB B7 3C BE 4A 58 EE\n F6 F2 4D E3 8F FC 17 05 14 C7 0E 7A B2 D0 1F 03\n 81 26 16 E8 63 D7 69 AF B3 75 31 93 BA 04 5B 20`\n\nKT256(M=ptn(8192 bytes), C=`00`^0, 64):\n `C6 EE 8E 2A D3 20 0C 01 8A C8 7A AA 03 1C DA C2\n 21 21 B4 12 D0 7D C6 E0 DC CB B5 34 23 74 7E 9A\n 1C 18 83 4D 99 DF 59 6C F0 CF 4B 8D FA FB 7B F0\n 2D 13 9D 0C 90 35 72 5A DC 1A 01 B7 23 0A 41 FA`\n\nKT256(M=ptn(8192 bytes), C=ptn(8189 bytes), 64):\n `74 E4 78 79 F1 0A 9C 5D 11 BD 2D A7 E1 94 FE 57\n E8 63 78 BF 3C 3F 74 48 EF F3 C5 76 A0 F1 8C 5C\n AA E0 99 99 79 51 20 90 A7 F3 48 AF 42 60 D4 DE\n 3C 37 F1 EC AF 8D 2C 2C 96 C1 D1 6C 64 B1 24 96`\n\nKT256(M=ptn(8192 bytes), C=ptn(8190 bytes), 64):\n `F4 B5 90 8B 92 9F FE 01 E0 F7 9E C2 F2 12 43 D4\n 1A 39 6B 2E 73 03 A6 AF 1D 63 99 CD 6C 7A 0A 2D\n D7 C4 F6 07 E8 27 7F 9C 9B 1C B4 AB 9D DC 59 D4\n B9 2D 1F C7 55 84 41 F1 83 2C 32 79 A4 24 1B 8B`", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "6. IANA Considerations", + "section_title": true, + "ja": "6. IANAの考慮事項" + }, + { + "indent": 3, + "text": "In the \"Named Information Hash Algorithm Registry\", k12-256 refers to the hash function obtained by evaluating KT128 on the input message with default C (the empty string) and L = 32 bytes (256 bits). Similarly, k12-512 refers to the hash function obtained by evaluating KT256 on the input message with default C (the empty string) and L = 64 bytes (512 bits).", + "ja": "「名前付き情報ハッシュ アルゴリズム レジストリ」では、k12-256 は、デフォルトの C (空の文字列) と L = 32 バイト (256 ビット) を使用して入力メッセージに対して KT128 を評価することによって得られるハッシュ関数を指します。同様に、k12-512 は、デフォルトの C (空の文字列) および L = 64 バイト (512 ビット) を使用して入力メッセージの KT256 を評価することによって取得されたハッシュ関数を指します。" + }, + { + "indent": 3, + "text": "In the \"COSE Algorithms\" registry, IANA has added the following entries for TurboSHAKE and KangarooTwelve:", + "ja": "IANA は、「COSE Algorithms」レジストリに、TurboSHAKE および KangarooTwelve 用の次のエントリを追加しました。" + }, + { + "indent": 4, + "text": " +===============+=======+===================+==============+\n | Name | Value | Description | Capabilities |\n +===============+=======+===================+==============+\n | TurboSHAKE128 | -261 | TurboSHAKE128 XOF | [kty] |\n +---------------+-------+-------------------+--------------+\n | TurboSHAKE256 | -262 | TurboSHAKE256 XOF | [kty] |\n +---------------+-------+-------------------+--------------+\n | KT128 | -263 | KT128 XOF | [kty] |\n +---------------+-------+-------------------+--------------+\n | KT256 | -264 | KT256 XOF | [kty] |\n +---------------+-------+-------------------+--------------+\n\n Table 3", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "7. Security Considerations", + "section_title": true, + "ja": "7. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "This document is meant to serve as a stable reference and an implementation guide for the KangarooTwelve and TurboSHAKE eXtendable-Output Functions. The security assurance of these functions relies on the cryptanalysis of reduced-round versions of Keccak, and they have the same claimed security strength as their corresponding SHAKE functions.", + "ja": "このドキュメントは、KangarooTwelve および TurboSHAKE eXtendable-Output 関数の安定したリファレンスおよび実装ガイドとして機能することを目的としています。これらの関数のセキュリティ保証は Keccak の縮小ラウンド バージョンの暗号解析に依存しており、対応する SHAKE 関数と同じセキュリティ強度が主張されています。" + }, + { + "indent": 11, + "text": " +---------------+=============================+\n | | Security Claim |\n +===============+=============================+\n | TurboSHAKE128 | 128 bits (same as SHAKE128) |\n +===============+-----------------------------+\n | KT128 | 128 bits (same as SHAKE128) |\n +===============+-----------------------------+\n | TurboSHAKE256 | 256 bits (same as SHAKE256) |\n +===============+-----------------------------+\n | KT256 | 256 bits (same as SHAKE256) |\n +===============+-----------------------------+\n\n Table 4", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "To be more precise, KT128 is made of two layers:", + "ja": "より正確に言うと、KT128 は 2 つの層で構成されています。" + }, + { + "indent": 6, + "text": "* The inner function TurboSHAKE128. The security assurance of this layer relies on cryptanalysis. The TurboSHAKE128 function is exactly Keccak[r=1344, c=256] (as in SHAKE128) reduced to 12 rounds. Any cryptanalysis of reduced-round Keccak is also cryptanalysis of reduced-round TurboSHAKE128 (provided the number of rounds attacked is not higher than 12).", + "ja": "* 内部関数 TurboSHAKE128。この層のセキュリティ保証は暗号解析に依存しています。TurboSHAKE128 関数は、正確に Keccak[r=1344, c=256] (SHAKE128 と同様) を 12 ラウンドに削減したものです。縮小ラウンド Keccak の暗号解析は、縮小ラウンド TurboSHAKE128 の暗号解析でもあります (攻撃ラウンド数が 12 を超えない場合)。" + }, + { + "indent": 6, + "text": "* The tree hashing over TurboSHAKE128. This layer is a mode on top of TurboSHAKE128 that does not introduce any vulnerability thanks to the use of Sakura coding proven secure in [SAKURA].", + "ja": "* TurboSHAKE128 をハッシュするツリー。このレイヤは、TurboSHAKE128 の上位にあるモードで、[SAKURA] で安全性が証明されたサクラ コーディングを使用しているため、脆弱性は発生しません。" + }, + { + "indent": 3, + "text": "This reasoning is detailed and formalized in [KT].", + "ja": "この推論は [KT] で詳しく説明され、形式化されています。" + }, + { + "indent": 3, + "text": "KT256 is structured as KT128, except that it uses TurboSHAKE256 as the inner function. The TurboSHAKE256 function is exactly Keccak[r=1088, c=512] (as in SHAKE256) reduced to 12 rounds, and the same reasoning on cryptanalysis applies.", + "ja": "KT256 は、内部関数として TurboSHAKE256 を使用することを除いて、KT128 と同じ構造になっています。TurboSHAKE256 関数は、正確に Keccak[r=1088, c=512] (SHAKE256 と同様) を 12 ラウンドに削減したもので、暗号解析と同じ推論が適用されます。" + }, + { + "indent": 3, + "text": "TurboSHAKE128 and KT128 aim at 128-bit security. To achieve 128-bit security strength, L, the chosen output length, MUST be large enough so that there are no generic attacks that violate 128-bit security. So for 128-bit (second) preimage security, the output should be at least 128 bits; for 128 bits of security against multi-target preimage attacks with T targets, the output should be at least 128+log_2(T) bits; and for 128-bit collision security, the output should be at least 256 bits. Furthermore, when the output length is at least 256 bits, TurboSHAKE128 and KT128 achieve NIST's post-quantum security level 2 [NISTPQ].", + "ja": "TurboSHAKE128 と KT128 は 128 ビットのセキュリティを目指しています。128 ビットのセキュリティ強度を達成するには、128 ビットのセキュリティを侵害する一般的な攻撃が存在しないように、選択した出力長 L が十分に大きくなければなりません。したがって、128 ビット (2 番目) のプリイメージ セキュリティの場合、出力は少なくとも 128 ビットである必要があります。T 個のターゲットによるマルチターゲット プリイメージ攻撃に対する 128 ビットのセキュリティの場合、出力は少なくとも 128+log_2(T) ビットである必要があります。128 ビットの衝突セキュリティの場合、出力は少なくとも 256 ビットである必要があります。さらに、出力長が少なくとも 256 ビットの場合、TurboSHAKE128 と KT128 は NIST のポスト量子セキュリティ レベル 2 [NISTPQ] を達成します。" + }, + { + "indent": 3, + "text": "Similarly, TurboSHAKE256 and KT256 aim at 256-bit security. To achieve 256-bit security strength, L, the chosen output length, MUST be large enough so that there are no generic attacks that violate 256-bit security. So for 256-bit (second) preimage security, the output should be at least 256 bits; for 256 bits of security against multi-target preimage attacks with T targets, the output should be at least 256+log_2(T) bits; and for 256-bit collision security, the output should be at least 512 bits. Furthermore, when the output length is at least 512 bits, TurboSHAKE256 and KT256 achieve NIST's post-quantum security level 5 [NISTPQ].", + "ja": "同様に、TurboSHAKE256 と KT256 は 256 ビットのセキュリティを目指しています。256 ビットのセキュリティ強度を達成するには、選択した出力長である L は、256 ビットのセキュリティを侵害する一般的な攻撃が存在しないように十分な大きさでなければなりません。したがって、256 ビット (2 番目) のプリイメージ セキュリティの場合、出力は少なくとも 256 ビットである必要があります。T 個のターゲットによるマルチターゲット プリイメージ攻撃に対する 256 ビットのセキュリティの場合、出力は少なくとも 256+log_2(T) ビットである必要があります。256 ビットの衝突セキュリティの場合、出力は少なくとも 512 ビットである必要があります。さらに、出力長が少なくとも 512 ビットの場合、TurboSHAKE256 と KT256 は NIST のポスト量子セキュリティ レベル 5 [NISTPQ] を達成します。" + }, + { + "indent": 3, + "text": "Unlike the SHA-256 and SHA-512 functions, TurboSHAKE128, TurboSHAKE256, KT128, and KT256 do not suffer from the length extension weakness and therefore do not require the use of the HMAC construction, for instance, when used for MAC computation [FIPS198]. Also, they can naturally be used as a key derivation function. The input must be an injective encoding of secret and diversification material, and the output can be taken as the derived key(s). The input does not need to be uniformly distributed, e.g., it can be a shared secret produced by the Diffie-Hellman or Elliptic Curve Diffie-Hellman (ECDH) protocol, but it needs to have sufficient min-entropy.", + "ja": "SHA-256 および SHA-512 関数とは異なり、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 は長さ拡張の弱点に悩まされないため、たとえば MAC 計算に使用される場合に HMAC 構造を使用する必要がありません [FIPS198]。また、当然ながら鍵導出関数としても利用できます。入力は秘密および多様化マテリアルの単射エンコーディングである必要があり、出力は派生キーとして取得できます。入力は均一に分散される必要はなく、たとえば、Diffie-Hellman または Elliptic Curve Diffie-Hellman (ECDH) プロトコルによって生成された共有秘密でも構いませんが、十分な最小エントロピーが必要です。" + }, + { + "indent": 3, + "text": "Lastly, as KT128 and KT256 use TurboSHAKE with three values for D, namely 0x06, 0x07, and 0x0B, protocols that use both KT128 and TurboSHAKE128 or both KT256 and TurboSHAKE256 SHOULD avoid using these three values for D.", + "ja": "最後に、KT128 と KT256 は D に 3 つの値、つまり 0x06、0x07、0x0B を指定して TurboSHAKE を使用するため、KT128 と TurboSHAKE128 の両方、または KT256 と TurboSHAKE256 の両方を使用するプロトコルは、D にこれら 3 つの値を使用することを避けるべきです(SHOULD)。" + }, + { + "indent": 0, + "text": "8. References", + "section_title": true, + "ja": "8. 参考文献" + }, + { + "indent": 0, + "text": "8.1. Normative References", + "section_title": true, + "ja": "8.1. 引用文献" + }, + { + "indent": 3, + "text": "[FIPS202] NIST, \"SHA-3 Standard: Permutation-Based Hash and\n Extendable-Output Functions\", NIST FIPS 202,\n DOI 10.6028/NIST.FIPS.202, August 2015,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[SP800-185]\n Kelsey, J., Chang, S., and R. Perlner, \"SHA-3 Derived\n Functions: cSHAKE, KMAC, TupleHash and ParallelHash\",\n National Institute of Standards and Technology, NIST\n SP 800-185, DOI 10.6028/NIST.SP.800-185, December 2016,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "8.2. Informative References", + "section_title": true, + "ja": "8.2. 参考引用" + }, + { + "indent": 3, + "text": "[FIPS180] NIST, \"Secure Hash Standard\", NIST FIPS 180-4,\n DOI 10.6028/NIST.FIPS.180-4, August 2015,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[FIPS198] NIST, \"The Keyed-Hash Message Authentication Code (HMAC)\",\n NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 2008,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[KECCAK_CRYPTANALYSIS]\n Keccak Team, \"Summary of Third-party cryptanalysis of\n Keccak\", .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[KT] Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., Van\n Keer, R., and B. Viguier, \"KangarooTwelve: Fast Hashing\n Based on Keccak-p\", Applied Cryptography and Network\n Security (ACNS 2018), Lecture Notes in Computer Science,\n vol. 10892, pp. 400-418, DOI 10.1007/978-3-319-93387-0_21,\n June 2018, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[NISTPQ] NIST, \"Submission Requirements and Evaluation Criteria for\n the Post-Quantum Cryptography Standardization Process\",\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[SAKURA] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche,\n \"Sakura: a Flexible Coding for Tree Hashing\", Applied\n Cryptography and Network Security (ACNS 2014), Lecture\n Notes in Computer Science, vol. 8479, pp. 217-234,\n DOI 10.1007/978-3-319-07536-5_14, 2014,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TURBOSHAKE]\n Bertoni, G., Daemen, J., Hoffert, S., Peeters, M., Van\n Assche, G., Van Keer, R., and B. Viguier, \"TurboSHAKE\",\n Cryptology ePrint Archive, Paper 2023/342, March 2023,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[XKCP] \"eXtended Keccak Code Package\", commit 64404bee, December\n 2022, .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Appendix A. Pseudocode", + "section_title": true, + "ja": "付録A. 擬似コード" + }, + { + "indent": 3, + "text": "The subsections of this appendix contain pseudocode definitions of TurboSHAKE128, TurboSHAKE256, and KangarooTwelve. Standalone Python versions are also available in the Keccak Code Package [XKCP] and in [KT]", + "ja": "この付録のサブセクションには、TurboSHAKE128、TurboSHAKE256、および KangarooTwelve の疑似コード定義が含まれています。スタンドアロン Python バージョンは Keccak コード パッケージ [XKCP] および [KT] でも入手できます。" + }, + { + "indent": 0, + "text": "A.1. Keccak-p[1600,n_r=12]", + "section_title": true, + "ja": "A.1. ケチャック-p[1600,n_r=12]" + }, + { + "indent": 3, + "text": "KP(state):\n RC[0] = `8B 80 00 80 00 00 00 00`\n RC[1] = `8B 00 00 00 00 00 00 80`\n RC[2] = `89 80 00 00 00 00 00 80`\n RC[3] = `03 80 00 00 00 00 00 80`\n RC[4] = `02 80 00 00 00 00 00 80`\n RC[5] = `80 00 00 00 00 00 00 80`\n RC[6] = `0A 80 00 00 00 00 00 00`\n RC[7] = `0A 00 00 80 00 00 00 80`\n RC[8] = `81 80 00 80 00 00 00 80`\n RC[9] = `80 80 00 00 00 00 00 80`\n RC[10] = `01 00 00 80 00 00 00 00`\n RC[11] = `08 80 00 80 00 00 00 80`\n\n for x from 0 to 4\n for y from 0 to 4\n lanes[x][y] = state[8*(x+5*y):8*(x+5*y)+8]\n\n for round from 0 to 11\n # theta\n for x from 0 to 4\n C[x] = lanes[x][0]\n C[x] ^= lanes[x][1]\n C[x] ^= lanes[x][2]\n C[x] ^= lanes[x][3]\n C[x] ^= lanes[x][4]\n for x from 0 to 4\n D[x] = C[(x+4) mod 5] ^ ROL64(C[(x+1) mod 5], 1)\n for y from 0 to 4\n for x from 0 to 4\n lanes[x][y] = lanes[x][y]^D[x]\n\n # rho and pi\n (x, y) = (1, 0)\n current = lanes[x][y]\n for t from 0 to 23\n (x, y) = (y, (2*x+3*y) mod 5)\n (current, lanes[x][y]) =\n (lanes[x][y], ROL64(current, (t+1)*(t+2)/2))\n\n # chi\n for y from 0 to 4\n for x from 0 to 4\n T[x] = lanes[x][y]\n for x from 0 to 4\n lanes[x][y] = T[x] ^((not T[(x+1) mod 5]) & T[(x+2) mod 5])\n\n # iota\n lanes[0][0] ^= RC[round]\n\n state = `00`^0\n for y from 0 to 4\n for x from 0 to 4\n state = state || lanes[x][y]\n\n return state\n end", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "where ROL64(x, y) is a rotation of the 'x' 64-bit word toward the bits with higher indexes by 'y' positions. The 8-bytes byte string x is interpreted as a 64-bit word in little-endian format.", + "ja": "ここで、ROL64(x, y) は、「x」の 64 ビット ワードを、より高いインデックスを持つビットに向けて「y」位置だけ回転させたものです。8 バイトのバイト文字列 x は、リトル エンディアン形式の 64 ビット ワードとして解釈されます。" + }, + { + "indent": 0, + "text": "A.2. TurboSHAKE128", + "section_title": true, + "ja": "A.2. ターボシェイク128" + }, + { + "indent": 3, + "text": "TurboSHAKE128(message, separationByte, outputByteLen):\n offset = 0\n state = `00`^200\n input = message || separationByte\n\n # === Absorb complete blocks ===\n while offset < |input| - 168\n state ^= input[offset : offset + 168] || `00`^32\n state = KP(state)\n offset += 168\n\n # === Absorb last block and treatment of padding ===\n LastBlockLength = |input| - offset\n state ^= input[offset:] || `00`^(200-LastBlockLength)\n state ^= `00`^167 || `80` || `00`^32\n state = KP(state)\n\n # === Squeeze ===\n output = `00`^0\n while outputByteLen > 168\n output = output || state[0:168]\n outputByteLen -= 168\n state = KP(state)\n\n output = output || state[0:outputByteLen]\n\n return output", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "A.3. TurboSHAKE256", + "section_title": true, + "ja": "A.3. ターボシェイク256" + }, + { + "indent": 3, + "text": "TurboSHAKE256(message, separationByte, outputByteLen):\n offset = 0\n state = `00`^200\n input = message || separationByte\n\n # === Absorb complete blocks ===\n while offset < |input| - 136\n state ^= input[offset : offset + 136] || `00`^64\n state = KP(state)\n offset += 136\n\n # === Absorb last block and treatment of padding ===\n LastBlockLength = |input| - offset\n state ^= input[offset:] || `00`^(200-LastBlockLength)\n state ^= `00`^135 || `80` || `00`^64\n state = KP(state)\n\n # === Squeeze ===\n output = `00`^0\n while outputByteLen > 136\n output = output || state[0:136]\n outputByteLen -= 136\n state = KP(state)\n\n output = output || state[0:outputByteLen]\n\n return output", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "A.4. KT128", + "section_title": true, + "ja": "A.4. KT128" + }, + { + "indent": 3, + "text": "KT128(inputMessage, customString, outputByteLen):\n S = inputMessage || customString\n S = S || length_encode( |customString| )\n\n if |S| <= 8192\n return TurboSHAKE128(S, `07`, outputByteLen)\n else\n # === Kangaroo hopping ===\n FinalNode = S[0:8192] || `03` || `00`^7\n offset = 8192\n numBlock = 0\n while offset < |S|\n blockSize = min( |S| - offset, 8192)\n CV = TurboSHAKE128(S[offset : offset+blockSize], `0B`, 32)\n FinalNode = FinalNode || CV\n numBlock += 1\n offset += blockSize\n\n FinalNode = FinalNode || length_encode( numBlock ) || `FF FF`\n\n return TurboSHAKE128(FinalNode, `06`, outputByteLen)\n end", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "A.5. KT256", + "section_title": true, + "ja": "A.5. KT256" + }, + { + "indent": 3, + "text": "KT256(inputMessage, customString, outputByteLen):\n S = inputMessage || customString\n S = S || length_encode( |customString| )\n\n if |S| <= 8192\n return TurboSHAKE256(S, `07`, outputByteLen)\n else\n # === Kangaroo hopping ===\n FinalNode = S[0:8192] || `03` || `00`^7\n offset = 8192\n numBlock = 0\n while offset < |S|\n blockSize = min( |S| - offset, 8192)\n CV = TurboSHAKE256(S[offset : offset+blockSize], `0B`, 64)\n FinalNode = FinalNode || CV\n numBlock += 1\n offset += blockSize\n\n FinalNode = FinalNode || length_encode( numBlock ) || `FF FF`\n\n return TurboSHAKE256(FinalNode, `06`, outputByteLen)\n end", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Authors' Addresses", + "section_title": true, + "ja": "著者の住所" + }, + { + "indent": 3, + "text": "Benoît Viguier\nABN AMRO Bank\nGroenelaan 2\nAmstelveen\nNetherlands\nEmail: cs.ru.nl@viguier.nl", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "David Wong (editor)\nzkSecurity\nEmail: davidwong.crypto@gmail.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Gilles Van Assche (editor)\nSTMicroelectronics\nEmail: gilles.vanassche@st.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Quynh Dang (editor)\nNational Institute of Standards and Technology\nEmail: quynh.dang@nist.gov", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Joan Daemen (editor)\nRadboud University\nEmail: joan@cs.ru.nl", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9866-trans.json b/data/9000/rfc9866-trans.json new file mode 100644 index 000000000..c52fa67fa --- /dev/null +++ b/data/9000/rfc9866-trans.json @@ -0,0 +1,1304 @@ +{ + "title": { + "text": "RFC 9866 - Root Node Failure Detector (RNFD): Fast Detection of Border Router Crashes in the Routing Protocol for Low-Power and Lossy Networks (RPL)", + "ja": "RFC 9866 - ルート ノード障害検出器 (RNFD): 低電力および損失の多いネットワーク (RPL) のルーティング プロトコルにおけるボーダー ルーターのクラッシュを迅速に検出" + }, + "number": 9866, + "created_at": "2025-10-16 23:24:10.953476+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) K. Iwanicki\nRequest for Comments: 9866 University of Warsaw\nCategory: Standards Track October 2025\nISSN: 2070-1721", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": " Root Node Failure Detector (RNFD): Fast Detection of Border Router Crashes in the Routing Protocol for Low-Power and Lossy Networks (RPL)", + "section_title": true, + "ja": "ルート ノード障害検出器 (RNFD): 低電力および損失の多いネットワーク (RPL) のルーティング プロトコルにおけるボーダー ルーターのクラッシュを迅速に検出" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "By and large, correct operation of a network running the Routing Protocol for Low-Power and Lossy Networks (RPL) requires border routers to be up. In many applications, it is beneficial for the nodes to detect a failure of a border router as soon as possible to trigger fallback actions. This document specifies the Root Node Failure Detector (RNFD), an extension to RPL that expedites detection of border router crashes by having nodes collaboratively monitor the status of a given border router. The extension introduces an additional state at each node, a new type of RPL Control Message Option for synchronizing this state among different nodes, and the coordination algorithm itself.", + "ja": "一般に、低電力および損失の多いネットワーク用のルーティング プロトコル (RPL) を実行しているネットワークが正しく動作するには、境界ルーターが稼働している必要があります。多くのアプリケーションでは、ノードがボーダー ルーターの障害をできるだけ早く検出してフォールバック アクションをトリガーすることが有益です。この文書では、ノードが連携して特定の境界ルータのステータスを監視することで、境界ルータのクラッシュの検出を迅速化する RPL の拡張機能である、ルート ノード障害検出器 (RNFD) を指定します。この拡張機能では、各ノードでの追加の状態、異なるノード間でこの状態を同期するための新しいタイプの RPL 制御メッセージ オプション、および調整アルゴリズム自体が導入されます。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This is an Internet Standards Track document.", + "ja": "これはインターネット標準化トラックの文書です。" + }, + { + "indent": 3, + "text": "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 Internet Standards is available in Section 2 of RFC 7841.", + "ja": "このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。" + }, + { + "indent": 3, + "text": "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/rfc9866.", + "ja": "この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9866 で入手できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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.", + "ja": "この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n 1.1. Effects of LBR Crashes\n 1.2. Design Principles\n 1.3. Other Solutions\n2. Terminology\n3. Overview\n 3.1. Protocol State Machine\n 3.2. Counters and Communication\n4. The RNFD Option\n 4.1. General CFRC Requirements\n 4.2. Format of the Option\n5. RPL Router Behavior\n 5.1. Joining a DODAG Version and Changing the RNFD Role\n 5.2. Detecting and Verifying Problems with the DODAG Root\n 5.3. Disseminating Observations and Reaching Agreement\n 5.4. DODAG Root's Behavior\n 5.5. Activating and Deactivating the Protocol on Demand\n 5.6. Processing CFRCs of Incompatible Lengths\n 5.7. Summary of RNFD's Interactions with RPL\n 5.8. Summary of RNFD's Constants\n6. Manageability Considerations\n 6.1. Role Assignment and CFRC Size Adjustment\n 6.2. Virtual DODAG Roots\n 6.3. Monitoring\n7. Security Considerations\n8. IANA Considerations\n9. References\n 9.1. Normative References\n 9.2. Informative References\nAcknowledgements\nAuthor's Address", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "RPL is an IPv6 routing protocol for Low-Power and Lossy Networks (LLNs) [RFC6550]. Such networks are usually constrained in device energy and channel capacity. They are formed largely of nodes that offer little processing power and memory, and links that are of variable qualities and support low data rates. Therefore, a significant challenge that a routing protocol for LLNs has to address is minimizing resource consumption without sacrificing reaction time to network changes.", + "ja": "RPL は、低電力および損失の多いネットワーク (LLN) 用の IPv6 ルーティング プロトコル [RFC6550] です。このようなネットワークは通常、デバイスのエネルギーとチャネル容量に制約があります。これらは主に、処理能力とメモリがほとんどないノードと、品質が変動し、低いデータ レートをサポートするリンクで構成されています。したがって、LLN のルーティング プロトコルが対処しなければならない重要な課題は、ネットワークの変更に対する反応時間を犠牲にすることなくリソースの消費を最小限に抑えることです。" + }, + { + "indent": 3, + "text": "One of the main design principles adopted in RPL to minimize node resource consumption is delegating much of the responsibility for routing to LLN Border Routers (LBRs). A network is organized into Destination-Oriented Directed Acyclic Graphs (DODAGs), each corresponding to an LBR and having all its paths terminate at the LBR. To this end, every node is dynamically assigned a Rank representing its distance to a given LBR, measured in some metric, with the LBR having the minimal Rank, which reflects its role as the DODAG root. The Ranks allow each non-LBR node to select from among its neighbors (i.e., nodes to which the node has links) those that are closer to the LBR than the node itself (i.e., the node's parents in the graph). The resulting DODAG paths, consisting of the node-parent links, are utilized for routing packets upward to the LBR and outside the LLN. They are also used by nodes to periodically report their connectivity upward to the LBR, which allows for directing packets downward from the LBR to these nodes (e.g., by means of source routing [RFC6554]). All in all, not only do LBRs participate in routing, but they also drive the process of DODAG construction and maintenance underlying the protocol.", + "ja": "ノード リソースの消費を最小限に抑えるために RPL で採用されている主な設計原則の 1 つは、ルーティングの責任の多くを LLN ボーダー ルーター (LBR) に委任することです。ネットワークは、Destination-Oriented Directed Acyclic Graphs (DODAG) に編成され、各 DODAG は LBR に対応し、すべてのパスが LBR で終端します。この目的を達成するために、すべてのノードには、特定のメトリックで測定された特定の LBR までの距離を表すランクが動的に割り当てられます。LBR は、DODAG ルートとしての役割を反映する最小ランクを持ちます。ランクにより、各非 LBR ノードは、その隣接ノード (つまり、ノードがリンクを持つノード) の中から、ノード自体 (つまり、グラフ内のノードの親) よりも LBR に近いものを選択できます。結果として生じる DODAG パスは、ノードと親のリンクで構成され、LBR および LLN の外側へ上向きにパケットをルーティングするために利用されます。これらは、ノードが LBR に上向きの接続を定期的に報告するためにも使用され、これにより、LBR からこれらのノードにパケットを下向きに送信することが可能になります (たとえば、ソース ルーティング [RFC6554] によって)。全体として、LBR はルーティングに参加するだけでなく、プロトコルの基礎となる DODAG 構築および保守のプロセスも推進します。" + }, + { + "indent": 3, + "text": "To play this central role, LBRs are expected to be more capable than regular LLN nodes. They are assumed not to be constrained in computing power, memory, and energy, which often entails a more involved hardware-software architecture and tethered power supply. However, this also makes them prone to failures, especially since it is often difficult to ensure a backup power supply for every LBR in large deployments.", + "ja": "この中心的な役割を果たすために、LBR には通常の LLN ノードよりも高い能力が期待されます。これらは、コンピューティング能力、メモリ、エネルギーの制約を受けないと想定されており、多くの場合、より複雑なハードウェア/ソフトウェア アーキテクチャと接続された電源が必要になります。ただし、特に大規模な導入ではすべての LBR にバックアップ電源を確保することが困難な場合が多いため、これにより障害が発生しやすくなります。" + }, + { + "indent": 0, + "text": "1.1. Effects of LBR Crashes", + "section_title": true, + "ja": "1.1. LBR クラッシュの影響" + }, + { + "indent": 3, + "text": "When an LBR crashes, or more generally, fails in a way that prevents other nodes in its DODAG from communicating with it, the nodes also lose the ability to communicate with other Internet hosts. In addition, a significant fraction of DODAG paths interconnecting the nodes become invalid, as they pass through the dead LBR. The others also degenerate as a result of DODAG repair attempts, which are bound to fail. In effect, routing inside the DODAG also becomes largely impossible. Consequently, it is desirable that an LBR crash be detected by the nodes fast, so that they can leave the broken DODAG and join another one or trigger additional application- or deployment-dependent fallback mechanisms, thereby minimizing the negative impact of the disconnection.", + "ja": "LBR がクラッシュすると、より一般的には、DODAG 内の他のノードが LBR と通信できなくなるような障害が発生すると、ノードは他のインターネット ホストと通信する能力も失います。さらに、ノードを相互接続する DODAG パスのかなりの部分が、デッド LBR を通過するため無効になります。他のものも DODAG 修復試行の結果として縮退しますが、失敗することは間違いありません。実際、DODAG 内のルーティングもほとんど不可能になります。したがって、LBR クラッシュがノードによって迅速に検出され、壊れた DODAG を離れて別の DODAG に参加したり、追加のアプリケーション依存またはデプロイメント依存のフォールバック メカニズムをトリガーしたりして、切断による悪影響を最小限に抑えることができることが望ましいです。" + }, + { + "indent": 3, + "text": "Since all DODAG paths lead to the corresponding LBR, detecting its crash by a node entails dropping all parents and adopting an infinite Rank, which reflects the node's inability to reach the dead LBR. Depending on the deployment settings, the node can then remain in such a state, join a different DODAG, or even become the root of a floating DODAG. In any case, however, achieving this state for all nodes is slow, can generate heavy traffic, and is difficult to implement correctly [Iwanicki16] [Paszkowska19] [Ciolkosz19].", + "ja": "すべての DODAG パスは対応する LBR につながるため、ノードによってそのクラッシュを検出するには、すべての親を削除し、ノードがデッド LBR に到達できないことを反映する無限ランクを採用する必要があります。デプロイメント設定に応じて、ノードはそのような状態を維持したり、別の DODAG に参加したり、フローティング DODAG のルートになることもあります。ただし、いずれの場合も、すべてのノードでこの状態を達成するには時間がかかり、大量のトラフィックが発生する可能性があり、正しく実装するのが困難です [Iwanicki16] [Paszkowska19] [Ciolkosz19]。" + }, + { + "indent": 3, + "text": "To start with, tearing down all DODAG paths requires each of the dead LBR's neighbors to detect that its link with the LBR is no longer up. Otherwise, any of the neighbors unaware of this fact can keep advertising a finite Rank and can thus be other nodes' parent or ancestor in the DODAG; such nodes will incorrectly believe they have a valid path to the dead LBR. Detecting a crash of a link by a node normally happens when the node has observed a sufficient number of forwarding failures over the link. Therefore, considering the low-data-rate applications of LLNs, the period from the crash to the moment of eliminating the last link to the dead LBR from the DODAG may be long. Subsequently, learning by all nodes that none of their links can form any path leading to the dead LBR also adds latency, partly due to parent changes that the nodes independently perform in attempts to repair their broken paths locally. Since a non-LBR node has only local knowledge of the network, potentially inconsistent with that of other nodes, such parent changes often produce paths containing loops, which have to be broken before all nodes can conclude that no path to the dead LBR exists globally. Even with RPL's dedicated loop detection mechanisms [RFC6553], this also requires traffic and hence time. Finally, switching a parent or discovering a loop can also generate cascaded bursts of control traffic, owing to the adaptive Trickle algorithm for exchanging DODAG information [RFC6206]. Overall, the behavior of the network when handling an LBR crash is highly suboptimal, thereby not being in line with RPL's goals of minimizing resource consumption and reaction latencies.", + "ja": "まず、すべての DODAG パスを切断するには、停止した LBR の各隣接ノードが、その LBR とのリンクがもうアップしていないことを検出する必要があります。そうしないと、この事実に気づかない近隣ノードが有限のランクをアドバタイズし続ける可能性があり、DODAG 内の他のノードの親または祖先になる可能性があります。このようなノードは、デッド LBR への有効なパスがあると誤って信じてしまいます。ノードによるリンクのクラッシュの検出は、通常、ノードがリンク上で十分な数の転送障害を観察した場合に発生します。したがって、LLN の低データ レートのアプリケーションを考慮すると、クラッシュから、DODAG からデッド LBR への最後のリンクが削除されるまでの期間が長くなる可能性があります。その後、すべてのノードが、どのリンクもデッド LBR につながるパスを形成できないことを学習すると、遅延が増加します。これは、ノードが壊れたパスをローカルで修復しようとして独自に実行する親の変更が部分的に原因です。非 LBR ノードはネットワークについてローカルな情報しか持たず、他のノードの情報と矛盾する可能性があるため、このような親の変更によりループを含むパスが生成されることが多く、すべてのノードが無効な LBR へのパスがグローバルに存在しないと結論付ける前にループを解除する必要があります。RPL の専用ループ検出メカニズム [RFC6553] を使用しても、これにはトラフィックが必要となり、時間がかかります。最後に、DODAG 情報を交換するための適応トリクル アルゴリズム [RFC6206] により、親を切り替えるかループを発見すると、制御トラフィックのカスケード バーストが生成される可能性があります。全体として、LBR クラッシュを処理するときのネットワークの動作は非常に最適ではないため、リソース消費と反応遅延を最小限に抑えるという RPL の目標とは一致しません。" + }, + { + "indent": 0, + "text": "1.2. Design Principles", + "section_title": true, + "ja": "1.2. 設計原則" + }, + { + "indent": 3, + "text": "To address this issue, this document proposes an extension to RPL, dubbed the \"Root Node Failure Detector (RNFD)\". To minimize the time and traffic required to handle an LBR crash, the RNFD algorithm adopts the following design principles, derived directly from the previous observations:", + "ja": "この問題に対処するために、この文書では「Root Node Failure Detector (RNFD)」と呼ばれる RPL の拡張機能を提案します。LBR クラッシュの処理に必要な時間とトラフィックを最小限に抑えるために、RNFD アルゴリズムは、以前の観察から直接導き出された次の設計原則を採用しています。" + }, + { + "indent": 8, + "text": "1. Explicitly coordinating LBR monitoring between nodes instead of relying only on the emergent behavior resulting from their independent operation.", + "ja": "1. ノードの独立した動作から生じる緊急の動作のみに依存するのではなく、ノード間の LBR 監視を明示的に調整します。" + }, + { + "indent": 8, + "text": "2. Avoiding probing all links to the dead LBR so as to reduce the tail latency when eliminating these links from the DODAG.", + "ja": "2. DODAG からこれらのリンクを削除するときに、デッド LBR へのすべてのリンクをプローブすることを回避し、テール レイテンシを短縮します。" + }, + { + "indent": 8, + "text": "3. Exploiting concurrency by prompting proactive checking for a possible LBR crash when some nodes suspect such a failure may have taken place, which aims to further reduce the overall latency.", + "ja": "3. 一部のノードで LBR クラッシュの可能性が疑われる場合に、そのような障害が発生した可能性があることを事前にチェックすることで同時実行性を利用し、全体的なレイテンシーをさらに短縮することを目的としています。" + }, + { + "indent": 8, + "text": "4. Minimizing changes to RPL's existing algorithms by operating in parallel and largely independently (in the background) and by introducing few additional assumptions.", + "ja": "4. 並行してほぼ独立して (バックグラウンドで) 動作し、追加の仮定をいくつか導入することにより、RPL の既存のアルゴリズムへの変更を最小限に抑えます。" + }, + { + "indent": 3, + "text": "While these principles do improve RPL's performance under a wide range of LBR crashes, their probabilistic nature precludes hard guarantees for all possible corner cases. In particular, in some scenarios, RNFD's operation may result in false negatives, but these situations are peculiar and will eventually be handled by RPL's own aforementioned mechanisms. Likewise, in some scenarios, notably involving highly unstable links, false positives may occur, but they can be alleviated as well. In any case, the principles also guarantee that RNFD can be deactivated at any time if needed, in which case RPL's operation is unaffected.", + "ja": "これらの原則は、広範囲の LBR クラッシュの下で RPL のパフォーマンスを向上させますが、その確率的な性質により、考えられるすべての例外的なケースに対する確実な保証は不可能です。特に、一部のシナリオでは、RNFD の操作により偽陰性が発生する可能性がありますが、これらの状況は特殊であり、最終的には RPL 独自の前述のメカニズムによって処理されます。同様に、一部のシナリオでは、特に非常に不安定なリンクが関係する場合、誤検知が発生する可能性がありますが、同様に軽減することができます。いずれの場合でも、この原則は、必要に応じていつでも RNFD を非アクティブ化できることも保証しており、その場合でも RPL の動作は影響を受けません。" + }, + { + "indent": 0, + "text": "1.3. Other Solutions", + "section_title": true, + "ja": "1.3. その他のソリューション" + }, + { + "indent": 3, + "text": "Given the consequences of LBR failures, it is also worth considering other solutions to the problem. More specifically, power outages can be alleviated by provisioning redundant power sources or emergency batteries. Likewise, RPL's so-called virtual DODAG roots can help tolerate some failures of individual LBRs.", + "ja": "LBR 障害の影響を考慮すると、この問題に対する他の解決策を検討する価値もあります。具体的には、冗長電源や非常用バッテリーを設置することで停電を軽減できます。同様に、RPL のいわゆる仮想 DODAG ルートは、個々の LBR の一部の障害を許容するのに役立ちます。" + }, + { + "indent": 3, + "text": "As mentioned previously, RNFD has been designed to be largely independent of those solutions; that is, rather than aiming to be their replacement, RNFD can complement them. In particular, the operation of RNFD with different variants of virtual DODAG roots is covered in Section 6.2.", + "ja": "前述したように、RNFD はこれらのソリューションからほとんど独立するように設計されています。つまり、RNFD はそれらの代替となることを目指すのではなく、それらを補完することができます。特に、仮想 DODAG ルートのさまざまなバリアントを使用した RNFD の操作については、セクション 6.2 で説明します。" + }, + { + "indent": 0, + "text": "2. Terminology", + "section_title": true, + "ja": "2. 用語" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。" + }, + { + "indent": 3, + "text": "The terminology used in this document is consistent with and incorporates that described in \"Terms Used in Routing for Low-Power and Lossy Networks\" [RFC7102], \"RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks\" [RFC6550], and \"The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams\" [RFC6553]. Other terms used in LLNs can be found in \"Terminology for Constrained-Node Networks\" [RFC7228].", + "ja": "この文書で使用される用語は、「低電力および損失の多いネットワークのルーティングで使用される用語」[RFC7102]、「RPL: 低電力および損失の多いネットワークのための IPv6 ルーティング プロトコル」[RFC6550]、および「データプレーン データグラムで RPL 情報を搬送するための低電力および損失の多いネットワーク用のルーティング プロトコル (RPL) オプション」と一致しており、それらを組み込んでいます。\n\n[RFC6553]。LLN で使用されるその他の用語は、「Terminology for Constrained-Node Networks」[RFC7228] に記載されています。" + }, + { + "indent": 3, + "text": "In particular, the following acronyms appear in the document:", + "ja": "特に、この文書には次の頭字語が使用されます。" + }, + { + "indent": 3, + "text": "DIO:", + "ja": "DIO:" + }, + { + "indent": 12, + "text": "DODAG Information Object (a RPL message)", + "ja": "DODAG 情報オブジェクト (RPL メッセージ)" + }, + { + "indent": 3, + "text": "DIS:", + "ja": "DIS:" + }, + { + "indent": 12, + "text": "DODAG Information Solicitation (a RPL message)", + "ja": "DODAG 情報要請 (RPL メッセージ)" + }, + { + "indent": 3, + "text": "DODAG:", + "ja": "ドーダグ:" + }, + { + "indent": 12, + "text": "Destination-Oriented Directed Acyclic Graph", + "ja": "宛先指向の有向非巡回グラフ" + }, + { + "indent": 3, + "text": "LLN:", + "ja": "LLN:" + }, + { + "indent": 12, + "text": "Low-Power and Lossy Network", + "ja": "低電力で損失の多いネットワーク" + }, + { + "indent": 3, + "text": "LBR:", + "ja": "LBR:" + }, + { + "indent": 12, + "text": "LLN Border Router", + "ja": "LLN ボーダールーター" + }, + { + "indent": 3, + "text": "In addition, the document introduces the following concepts:", + "ja": "さらに、このドキュメントでは次の概念が紹介されています。" + }, + { + "indent": 3, + "text": "Sentinel:", + "ja": "センチネル:" + }, + { + "indent": 12, + "text": "One of the two roles that a node can play in RNFD. For a given DODAG Version, a Sentinel node is a DODAG root's neighbor that monitors the DODAG root's status. There are normally multiple Sentinels for a DODAG root. However, being the DODAG root's neighbor need not imply being a Sentinel.", + "ja": "RNFD でノードが果たせる 2 つの役割の 1 つ。特定の DODAG バージョンの場合、Sentinel ノードは DODAG ルートのステータスを監視する DODAG ルートの近隣ノードです。通常、DODAG ルートには複数の Sentinel が存在します。ただし、DODAG ルートのネイバーであることは、センチネルであることを意味する必要はありません。" + }, + { + "indent": 3, + "text": "Acceptor:", + "ja": "アクセプター:" + }, + { + "indent": 12, + "text": "The other of the two roles that a node can play in RNFD. For a given DODAG Version, an Acceptor node is a node that is not a Sentinel.", + "ja": "RNFD でノードが果たせる 2 つの役割のうちのもう 1 つ。特定の DODAG バージョンの場合、アクセプター ノードはセンチネルではないノードです。" + }, + { + "indent": 3, + "text": "Locally Observed DODAG Root's State (LORS):", + "ja": "ローカルで観測された DODAG ルート状態 (LORS):" + }, + { + "indent": 12, + "text": "A node's local knowledge of the DODAG root's status, specifying in particular whether the DODAG root is up.", + "ja": "DODAG ルートのステータスに関するノードのローカル情報。特に、DODAG ルートが稼働しているかどうかを指定します。" + }, + { + "indent": 3, + "text": "Conflict-Free Replicated Counter (CFRC):", + "ja": "競合のない複製カウンター (CFRC):" + }, + { + "indent": 12, + "text": "Conceptually represents a dynamic set whose cardinality can be estimated. It defines a partial order on its values and supports element addition and union. The union operation is order- and duplicate-insensitive, that is, idempotent, commutative, and associative.", + "ja": "カーディナリティを推定できる動的セットを概念的に表します。値の半順序を定義し、要素の追加と結合をサポートします。結合演算は順序や重複に影響されません。つまり、冪等、可換、結合です。" + }, + { + "indent": 0, + "text": "3. Overview", + "section_title": true, + "ja": "3. 概要" + }, + { + "indent": 3, + "text": "As mentioned previously, LBRs are DODAG roots in RPL; hence, a crash of an LBR is global in that it affects all nodes in the corresponding DODAG. Therefore, each node running RNFD for a given DODAG explicitly tracks the DODAG root's current condition, which is referred to as Locally Observed DODAG Root's State (LORS), and synchronizes its local knowledge with other nodes.", + "ja": "前述したように、LBR は RPL の DODAG ルートです。したがって、LBR のクラッシュは、対応する DODAG 内のすべてのノードに影響するという点でグローバルです。したがって、特定の DODAG に対して RNFD を実行している各ノードは、ローカルで観察された DODAG ルートの状態 (LORS) と呼ばれる DODAG ルートの現在の状態を明示的に追跡し、そのローカルな情報を他のノードと同期します。" + }, + { + "indent": 3, + "text": "Since monitoring the condition of the DODAG root is performed by tracking the status of its links (i.e., whether they are up or down), it can only be done by the root's neighbors; other nodes must accept their observations. Consequently, depending on their roles, non-root nodes are divided in RNFD into two disjoint groups: Sentinels and Acceptors. A Sentinel node is a DODAG root's neighbor that monitors its link with the root. Thus, the DODAG root normally has multiple Sentinels, but being its neighbor need not imply being a Sentinel. An Acceptor node is a node that is not a Sentinel. Acceptors thus mainly collect and propagate Sentinels' observations. More information on Sentinel selection can be found in Section 6.1.", + "ja": "DODAG ルートの状態の監視は、そのリンクのステータス (つまり、アップかダウンか) を追跡することによって実行されるため、ルートの近隣者によってのみ実行できます。他のノードはその観察を受け入れる必要があります。その結果、RNFD では、その役割に応じて、ルート以外のノードが 2 つの独立したグループ (センチネルとアクセプター) に分割されます。Sentinel ノードは、ルートとのリンクを監視する DODAG ルートの近隣ノードです。したがって、DODAG ルートには通常複数の Sentinel がありますが、その近隣であることは Sentinel であることを意味する必要はありません。アクセプター ノードはセンチネルではないノードです。したがって、アクセプターは主にセンチネルの観察を収集し、広めます。Sentinel の選択の詳細については、セクション 6.1 を参照してください。" + }, + { + "indent": 0, + "text": "3.1. Protocol State Machine", + "section_title": true, + "ja": "3.1. プロトコルステートマシン" + }, + { + "indent": 3, + "text": "The possible values of LORS and transitions between them are depicted in Figure 1. States \"UP\" and \"GLOBALLY DOWN\" can be attained by both Sentinels and Acceptors; states \"SUSPECTED DOWN\" and \"LOCALLY DOWN\" can be attained by Sentinels only.", + "ja": "LORS の可能な値とそれらの間の遷移を図 1 に示します。状態「UP」と「GLOBALLY DOWN」はセンチネルとアクセプターの両方で達成できます。「SUSPECTED DOWN」と「LOCALLY DOWN」はセンチネルのみが達成できると述べています。" + }, + { + "indent": 3, + "text": " +---------------------------------------------------------+\n | |---------------------------+ 3a |\n | +-----------------+---------+ 3b | |\n | | 2b | v v v\n+-+----+-+ 1 +---------+-+ +-----------+ +-+------+-+\n| UP +---->+ SUSPECTED +---->+ LOCALLY +---->+ GLOBALLY |\n| +<----+ DOWN | 2a | DOWN | 3c | DOWN |\n+-+----+-+ 4a +-----------+ +-+---------+ +-+--------+\n ^ ^ | |\n | | 4b | |\n | +---------------------------+ 5 |\n +--------------------------------------------------+", + "raw": true, + "ja": "" + }, + { + "indent": 19, + "text": "Figure 1: RNFD States and Transitions", + "ja": "図 1: RNFD の状態と遷移" + }, + { + "indent": 3, + "text": "To begin with, when any node joins a DODAG Version, the DODAG root must appear alive, so the node initializes RNFD with its LORS equal to \"UP\". For a properly working DODAG root, the node remains in state \"UP\".", + "ja": "まず、いずれかのノードが DODAG バージョンに参加すると、DODAG ルートが生きているように見える必要があるため、ノードは LORS を「UP」に設定して RNFD を初期化します。DODAG ルートが適切に動作している場合、ノードは「UP」状態のままです。" + }, + { + "indent": 3, + "text": "However, when a node acting as a Sentinel starts suspecting that the root may have crashed, it changes its LORS to \"SUSPECTED DOWN\" (transition 1 in Figure 1). The transition from \"UP\" to \"SUSPECTED DOWN\" can happen based on the node's observations at either the data plane (e.g., link-layer triggers about missing hop-by-hop acknowledgments for packets forwarded over the node's link to the root) or at the control plane (e.g., a significant growth in the number of Sentinels already suspecting the root to be dead). In state \"SUSPECTED DOWN\", the Sentinel node may verify its suspicion and/or inform other nodes about the suspicion. When this has been done, it changes its LORS to \"LOCALLY DOWN\" (transition 2a). In some cases, the verification need not be performed, and as an optimization, a direct transition from \"UP\" to \"LOCALLY DOWN\" (transition 2b) can be done instead.", + "ja": "ただし、Sentinel として機能するノードがルートがクラッシュした可能性があると疑い始めると、LORS を「SUSPECTED DOWN」に変更します (図 1 の遷移 1)。「UP」から「SUSPECTED DOWN」への遷移は、データ プレーン (例: ノードのリンクを介してルートに転送されたパケットのホップバイホップ確認応答の欠落に関するリンク層トリガー) またはコントロール プレーン (例: ルートが停止していると既に疑っているセンチネルの数の大幅な増加) でのノードの観察に基づいて発生する可能性があります。「SUSPECTED DOWN」状態では、Sentinel ノードはその疑いを検証し、および/またはその疑いについて他のノードに通知することができます。これが完了すると、LORS が「LOCALLY DOWN」に変更されます (遷移 2a)。場合によっては、検証を実行する必要がなく、最適化として、代わりに「UP」から「LOCALLY DOWN」への直接遷移 (遷移 2b) を実行できます。" + }, + { + "indent": 3, + "text": "If a sufficient number of Sentinels have their LORS equal to \"LOCALLY DOWN\", all nodes (Sentinels and Acceptors) consent globally that the DODAG root must have crashed and set their LORS to \"GLOBALLY DOWN\", irrespective of the previous value (transitions 3a, 3b, and 3c). State \"GLOBALLY DOWN\" is terminal in that the only transition any node can perform from this to another state (transition 5) takes place when the node joins a new DODAG Version. When a node is in state \"GLOBALLY DOWN\", RNFD forces RPL to maintain an infinite Rank and no parent, thereby preventing routing packets upward in the DODAG. In other words, this state represents a situation in which all non-root nodes agree that the current DODAG Version is unusable; hence, to recover, the root has to give a proof of being alive by initiating a new DODAG Version.", + "ja": "十分な数の Sentinel の LORS が「LOCALLY DOWN」に等しい場合、すべてのノード (Sentinel と Acceptor) は、DODAG ルートがクラッシュし、以前の値に関係なく LORS を「GLOBALLY DOWN」に設定する必要があることにグローバルに同意します (遷移 3a、3b、および 3c)。「GLOBALLY DOWN」状態は、ノードが新しい DODAG バージョンに参加するときに、ノードが実行できる唯一の状態から別の状態への遷移 (遷移 5) が発生するという点で終端です。ノードが「GLOBALLY DOWN」状態にある場合、RNFD は RPL に無限ランクを維持させ、親を持たないよう強制するため、パケットが DODAG 内で上向きにルーティングされるのを防ぎます。言い換えれば、この状態は、ルート以外のすべてのノードが現在の DODAG バージョンが使用できないことに同意している状況を表します。したがって、回復するには、ルートが新しい DODAG バージョンを開始して生存の証明を提供する必要があります。" + }, + { + "indent": 3, + "text": "In contrast, if a node (either a Sentinel or Acceptor) is in state \"UP\", RNFD does not influence RPL's packet forwarding; a node can route packets upward if it has a parent. The same is true for states \"SUSPECTED DOWN\" and \"LOCALLY DOWN\", attainable only by Sentinels. Finally, while in any of the two states, a Sentinel node may observe some activity of the DODAG root and hence decide that its suspicion is a mistake. In such a case, it returns to state \"UP\" (transitions 4a and 4b).", + "ja": "対照的に、ノード (センチネルまたはアクセプター) が状態「UP」にある場合、RNFD は RPL のパケット転送に影響を与えません。ノードに親がある場合、ノードはパケットを上向きにルーティングできます。「SUSPECTED DOWN」および「LOCALLY DOWN」状態についても同様であり、センチネルのみが到達できます。最後に、2 つの状態のいずれかにあるときに、Sentinel ノードが DODAG ルートのアクティビティを観察し、その疑いが間違いであると判断する可能性があります。このような場合には、状態「ＵＰ」に戻る（遷移４ａおよび４ｂ）。" + }, + { + "indent": 0, + "text": "3.2. Counters and Communication", + "section_title": true, + "ja": "3.2. カウンターとコミュニケーション" + }, + { + "indent": 3, + "text": "To enable arriving at a global conclusion that the DODAG root has crashed (i.e., transiting to state \"GLOBALLY DOWN\"), all nodes count locally and synchronize among each other the number of Sentinels considering the root to be dead (i.e., those in state \"LOCALLY DOWN\"). This process employs structures referred to as Conflict-Free Replicated Counters (CFRCs). They are stored and modified independently by each node and are disseminated throughout the network in options added to RPL link-local control messages: DODAG Information Objects (DIOs) and DODAG Information Solicitations (DISs). Upon reception of such an option from its neighbor, a node merges the received counter with its local one, thereby obtaining a new content for its local counter.", + "ja": "DODAG ルートがクラッシュした (つまり、「GLOBALLY DOWN」状態に移行した) というグローバルな結論に達することを可能にするために、すべてのノードがローカルでカウントし、ルートが停止しているとみなされるセンチネル (つまり、「LOCALLY DOWN」状態にあるセンチネル) の数を相互に同期します。このプロセスでは、Conflict-Free Replicated Counters (CFRC) と呼ばれる構造が使用されます。これらは、各ノードによって個別に保存および変更され、RPL リンクローカル制御メッセージに追加されるオプションである DODAG Information Object (DIO) および DODAG Information Solicitations (DIS) でネットワーク全体に配布されます。近隣ノードからそのようなオプションを受信すると、ノードは受信したカウンタをローカルのカウンタとマージし、それによってローカル カウンタの新しい内容を取得します。" + }, + { + "indent": 3, + "text": "The merging operation is idempotent, commutative, and associative. Moreover, all possible counter values are partially ordered. This enables ensuring eventual consistency of the counters across all nodes, irrespective of the particular sequence of merges, shape of the DODAG, or general network topology. In effect, as long as the network is connected, all nodes will be able to arrive at the same conclusion regarding the DODAG root, in particular when no two Sentinels have a direct link with each other.", + "ja": "マージ操作は冪等性、可換性、結合性があります。さらに、すべての可能なカウンタ値は部分的に順序付けされています。これにより、マージの特定のシーケンス、DODAG の形状、または一般的なネットワーク トポロジに関係なく、すべてのノードにわたるカウンターの最終的な一貫性を確保できます。実際、ネットワークが接続されている限り、特に 2 つの Sentinel が互いに直接リンクしていない場合、すべてのノードは DODAG ルートに関して同じ結論に達することができます。" + }, + { + "indent": 3, + "text": "Each node in RNFD maintains two CFRCs for a DODAG:", + "ja": "RNFD の各ノードは、DODAG に対して 2 つの CFRC を維持します。" + }, + { + "indent": 3, + "text": "PositiveCFRC:", + "ja": "ポジティブCFRC:" + }, + { + "indent": 12, + "text": "Counts Sentinels that consider or have previously considered the root node as alive in the current DODAG Version.", + "ja": "現在の DODAG バージョンでルート ノードが生きているとみなしている、または以前にみなしていたセンチネルをカウントします。" + }, + { + "indent": 3, + "text": "NegativeCFRC:", + "ja": "ネガティブCFRC:" + }, + { + "indent": 12, + "text": "Counts Sentinels that consider or have previously considered the root node as dead in the current DODAG Version.", + "ja": "現在の DODAG バージョンでルート ノードが停止しているとみなしている、または以前にルート ノードが停止しているとみなしたセンチネルをカウントします。" + }, + { + "indent": 3, + "text": "The PositiveCFRC is always greater than or equal to the NegativeCFRC in terms of the partial order defined for the counters. The difference between the value of the PositiveCFRC and the value of the NegativeCFRC is thus nonnegative and estimates the number of Sentinels that still consider the DODAG root node as alive.", + "ja": "PositiveCFRC は、カウンタに定義された半順序の点で常に NegativeCFRC 以上です。したがって、PositiveCFRC の値と NegativeCFRC の値の差は負ではなく、DODAG ルート ノードがまだ生きているとみなしているセンチネルの数を推定します。" + }, + { + "indent": 0, + "text": "4. The RNFD Option", + "section_title": true, + "ja": "4. RNFD オプション" + }, + { + "indent": 3, + "text": "RNFD state synchronization between nodes takes place through the RNFD Option. It is a new type of RPL Control Message Option that is carried in link-local RPL control messages, notably DIOs and DISs. Its main task is allowing the receivers to merge their two CFRCs with the sender's CFRCs.", + "ja": "ノード間の RNFD 状態の同期は、RNFD オプションを通じて行われます。これは、リンクローカル RPL 制御メッセージ、特に DIO および DIS で伝送される新しいタイプの RPL 制御メッセージ オプションです。その主なタスクは、受信者が 2 つの CFRC を送信者の CFRC とマージできるようにすることです。" + }, + { + "indent": 0, + "text": "4.1. General CFRC Requirements", + "section_title": true, + "ja": "4.1. CFRC の一般要件" + }, + { + "indent": 3, + "text": "CFRCs in RNFD MUST support the following operations:", + "ja": "RNFD の CFRC は、次の操作をサポートしなければなりません。" + }, + { + "indent": 3, + "text": "value(c)", + "ja": "値(c)" + }, + { + "indent": 12, + "text": "Returns a nonnegative integer value corresponding to the number of nodes counted by a given CFRC, c.", + "ja": "指定された CFRC によってカウントされたノードの数に対応する非負の整数値を返します。 c." + }, + { + "indent": 3, + "text": "zero()", + "ja": "ゼロ（）" + }, + { + "indent": 12, + "text": "Returns a CFRC that counts no nodes, that is, has its value equal to 0.", + "ja": "ノードをカウントしない、つまり値が 0 に等しい CFRC を返します。" + }, + { + "indent": 3, + "text": "self()", + "ja": "自己（）" + }, + { + "indent": 12, + "text": "Returns a CFRC that counts only the node executing the operation.", + "ja": "操作を実行しているノードのみをカウントする CFRC を返します。" + }, + { + "indent": 3, + "text": "infinity()", + "ja": "無限大()" + }, + { + "indent": 12, + "text": "Returns a CFRC that counts all possible nodes and represents a special value, infinity.", + "ja": "考えられるすべてのノードをカウントし、特別な値である無限大を表す CFRC を返します。" + }, + { + "indent": 3, + "text": "merge(c1, c2)", + "ja": "マージ(c1, c2)" + }, + { + "indent": 12, + "text": "Returns a CFRC that is a union of c1 and c2 (i.e., counts all nodes that are counted by either c1, c2, or both c1 and c2).", + "ja": "c1 と c2 の和集合である CFRC を返します (つまり、c1、c2、または c1 と c2 の両方によってカウントされるすべてのノードをカウントします)。" + }, + { + "indent": 3, + "text": "compare(c1, c2)", + "ja": "比較(c1, c2)" + }, + { + "indent": 12, + "text": "Returns the result of comparing c1 to c2.", + "ja": "c1 と c2 を比較した結果を返します。" + }, + { + "indent": 3, + "text": "saturated(c)", + "ja": "飽和(c)" + }, + { + "indent": 12, + "text": "Returns TRUE if a given CFRC, c, is saturated (i.e., no more new nodes should be counted by it); returns FALSE otherwise.", + "ja": "指定された CFRC c が飽和している (つまり、これ以上新しいノードをカウントする必要がない) 場合は TRUE を返します。それ以外の場合は FALSE を返します。" + }, + { + "indent": 3, + "text": "The partial ordering of CFRCs implies that the result of compare(c1, c2) can be either:", + "ja": "CFRC の部分的な順序付けは、compare(c1, c2) の結果が次のいずれかになることを意味します。" + }, + { + "indent": 6, + "text": "* smaller, if c1 is ordered before c2 (i.e., c2 counts all nodes that c1 counts and at least one node that c1 does not count);", + "ja": "* c1 が c2 より前に順序付けされている場合 (つまり、c2 は、c1 がカウントするすべてのノードと、c1 がカウントしない少なくとも 1 つのノードをカウントします) の場合は小さくなります。" + }, + { + "indent": 6, + "text": "* greater, if c1 is ordered after c2 (i.e., c1 counts all nodes that c2 counts and at least one node that c2 does not count);", + "ja": "* c1 が c2 の後に順序付けされている場合は大きくなります (つまり、c1 は、c2 がカウントするすべてのノードと、c2 がカウントしない少なくとも 1 つのノードをカウントします)。" + }, + { + "indent": 6, + "text": "* equal, if c1 and c2 are the same (i.e., they count the same nodes); or", + "ja": "* c1 と c2 が同じ (つまり、同じノードを数える) 場合は等しい。または" + }, + { + "indent": 6, + "text": "* incomparable, otherwise.", + "ja": "* そうでなければ、比類のないもの。" + }, + { + "indent": 3, + "text": "In particular, zero() is smaller than all other values, and infinity() is greater than any other value.", + "ja": "特に、zero() は他のすべての値より小さく、infinity() は他のどの値よりも大きくなります。" + }, + { + "indent": 3, + "text": "The properties of merging can be formalized as follows for any c1, c2, and c3:", + "ja": "マージのプロパティは、c1、c2、および c3 について次のように形式化できます。" + }, + { + "indent": 6, + "text": "* idempotence: c1 = merge(c1, c1);", + "ja": "* べき等: c1 = merge(c1, c1);" + }, + { + "indent": 6, + "text": "* commutativity: merge(c1, c2) = merge(c2, c1); and", + "ja": "* 可換性: マージ(c1, c2) = マージ(c2, c1);そして" + }, + { + "indent": 6, + "text": "* associativity: merge(c1, merge(c2, c3)) = merge(merge(c1, c2), c3).", + "ja": "* 結合性: マージ(c1, マージ(c2, c3)) = マージ(マージ(c1, c2), c3)。" + }, + { + "indent": 3, + "text": "In particular, merge(c, zero()) always equals c, while merge(c, infinity()) always equals infinity().", + "ja": "特に、merge(c, zero()) は常に c と等しくなりますが、merge(c, infinity()) は常に infinity() と等しくなります。" + }, + { + "indent": 3, + "text": "There are many algorithmic structures that can provide the aforementioned properties of CFRC. Although in principle RNFD does not rely on any specific one, the option adopts so-called linear counting [Whang90].", + "ja": "前述の CFRC の特性を提供できるアルゴリズム構造は数多くあります。原則として RNFD は特定のものに依存しませんが、このオプションはいわゆる線形カウンティングを採用しています [Whang90]。" + }, + { + "indent": 0, + "text": "4.2. Format of the Option", + "section_title": true, + "ja": "4.2. オプションの形式" + }, + { + "indent": 3, + "text": "The format of the RNFD Option conforms to the generic format of RPL Control Message Options (see Section 6.7.1 of [RFC6550]):", + "ja": "RNFD オプションの形式は、RPL 制御メッセージ オプションの一般的な形式に準拠しています ([RFC6550] のセクション 6.7.1 を参照)。" + }, + { + "indent": 5, + "text": " 0 1 2 3\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| Type = 0x0E | Option Length | |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +\n| |\n+ +\n| PosCFRC, NegCFRC (Variable Length*) |\n. .\n. .\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", + "raw": true, + "ja": "" + }, + { + "indent": 20, + "text": "Figure 2: Format of the RNFD Option", + "ja": "図 2: RNFD オプションのフォーマット" + }, + { + "indent": 3, + "text": "The \"*\" denotes that, if present, the fields have equal lengths.", + "ja": "「*」は、存在する場合、フィールドの長さが等しいことを示します。" + }, + { + "indent": 3, + "text": "Option Type:", + "ja": "オプションの種類:" + }, + { + "indent": 12, + "text": "0x0E", + "ja": "0x0E" + }, + { + "indent": 3, + "text": "Option Length:", + "ja": "オプションの長さ:" + }, + { + "indent": 12, + "text": "8-bit unsigned integer. Denotes the length of the option in octets, excluding the Option Type and Option Length fields. Its value MUST be even. A value of 0 denotes that RNFD is disabled in the current DODAG Version.", + "ja": "8 ビットの符号なし整数。「オプション タイプ」フィールドと「オプション長」フィールドを除く、オプションの長さをオクテット単位で示します。その値は偶数でなければなりません。値 0 は、RNFD が現在の DODAG バージョンで無効になっていることを示します。" + }, + { + "indent": 3, + "text": "PosCFRC, NegCFRC:", + "ja": "PosCFRC、NegCFRC:" + }, + { + "indent": 12, + "text": "Two variable-length, octet-aligned bit arrays carrying the sender's PositiveCFRC and NegativeCFRC, respectively.", + "ja": "送信者の PositiveCFRC と NegativeCFRC をそれぞれ伝送する 2 つの可変長の、オクテットに位置合わせされたビット配列。" + }, + { + "indent": 3, + "text": "The length of the arrays constituting the PosCFRC and NegCFRC fields is the same and is derived from Option Length as follows. The value of Option Length is divided by 2 to obtain the number of octets each of the two arrays occupies. The resulting number of octets is multiplied by 8, which yields an upper bound on the number of bits in each array. As the actual bit length of each of the arrays, the largest prime number less than the upper bound is assumed. For example, if the value of Option Length is 16, then each array occupies 8 octets, and its actual bit length is 61, as this is the largest prime number less than 64.", + "ja": "PosCFRC フィールドと NegCFRC フィールドを構成する配列の長さは同じであり、次のように Option Length から導出されます。Option Length の値を 2 で割ると、2 つの配列がそれぞれ占有するオクテット数が得られます。結果のオクテット数は 8 倍され、各配列のビット数の上限が決まります。各配列の実際のビット長としては、上限値以下の最大の素数を仮定する。たとえば、オプションの長さの値が 16 の場合、各配列は 8 オクテットを占有し、実際のビット長は 61 になります。これは、64 未満の最大の素数であるためです。" + }, + { + "indent": 3, + "text": "Furthermore, for any bit equal to 1 in the NegCFRC, the bit with the same index MUST also be equal to 1 in the PosCFRC. Any unused bits (i.e., the bits beyond the actual bit length of each of the arrays) MUST be equal to 0. Finally, if PosCFRC has all its bits equal to 1, then NegCFRC MUST also have all its bits equal to 1.", + "ja": "さらに、NegCFRC で 1 に等しいビットについては、同じインデックスを持つビットも PosCFRC で 1 に等しくなければなりません (MUST)。未使用のビット (つまり、各配列の実際のビット長を超えるビット) は 0 に等しくなければなりません (MUST)。 最後に、PosCFRC のすべてのビットが 1 に等しい場合、NegCFRC もすべてのビットが 1 に等しくなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "The CFRC operations are defined for such bit arrays of a given length as follows:", + "ja": "CFRC 演算は、指定された長さのビット配列に対して次のように定義されます。" + }, + { + "indent": 3, + "text": "value(c)", + "ja": "値(c)" + }, + { + "indent": 12, + "text": "Returns the smallest integer value not less than -LT*ln(L0/LT), where ln() is the natural logarithm function, L0 is the number of bits equal to 0 in the array corresponding to c, and LT is the bit length of the array.", + "ja": "-LT*ln(L0/LT) 以上の最小の整数値を返します。ここで、ln() は自然対数関数、L0 は c に対応する配列内の 0 に等しいビット数、LT は配列のビット長です。" + }, + { + "indent": 3, + "text": "zero()", + "ja": "ゼロ（）" + }, + { + "indent": 12, + "text": "Returns an array with all bits equal to 0.", + "ja": "すべてのビットが 0 に等しい配列を返します。" + }, + { + "indent": 3, + "text": "self()", + "ja": "自己（）" + }, + { + "indent": 12, + "text": "Returns an array with a single bit, selected uniformly at random, equal to 1.", + "ja": "均一にランダムに選択された 1 に等しい単一ビットの配列を返します。" + }, + { + "indent": 3, + "text": "infinity()", + "ja": "無限大()" + }, + { + "indent": 12, + "text": "Returns an array with all bits equal to 1.", + "ja": "すべてのビットが 1 に等しい配列を返します。" + }, + { + "indent": 3, + "text": "merge(c1, c2)", + "ja": "マージ(c1, c2)" + }, + { + "indent": 12, + "text": "Returns a bit array that constitutes a bitwise OR of c1 and c2. That is, a bit in the resulting array is equal to 0 only if the same bit is equal to 0 in both c1 and c2.", + "ja": "c1 と c2 のビット単位の OR を構成するビット配列を返します。つまり、結果の配列内のビットが 0 になるのは、c1 と c2 の両方で同じビットが 0 に等しい場合のみです。" + }, + { + "indent": 3, + "text": "compare(c1, c2)", + "ja": "比較(c1, c2)" + }, + { + "indent": 12, + "text": "Returns:", + "ja": "戻り値:" + }, + { + "indent": 6, + "text": "* equal, if each bit of c1 is equal to the corresponding bit of c2;", + "ja": "* c1 の各ビットが c2 の対応するビットと等しい場合は等しい。" + }, + { + "indent": 6, + "text": "* less, if c1 and c2 are not equal, and for each bit equal to 1 in c1, the corresponding bit in c2 is also equal to 1;", + "ja": "* 以下、c1 と c2 が等しくなく、c1 の各ビットが 1 に等しい場合、c2 の対応するビットも 1 に等しくなります。" + }, + { + "indent": 6, + "text": "* greater, if c1 and c2 are not equal, and for each bit equal to 1 in c2, the corresponding bit in c1 is also equal to 1; or", + "ja": "* より大きい場合、c1 と c2 が等しくなく、c2 の各ビットが 1 に等しい場合、c1 の対応するビットも 1 に等しくなります。または" + }, + { + "indent": 6, + "text": "* incomparable, otherwise.", + "ja": "* そうでなければ、比類のないもの。" + }, + { + "indent": 3, + "text": "saturated(c)", + "ja": "飽和(c)" + }, + { + "indent": 12, + "text": "Returns TRUE if more than RNFD_CFRC_SATURATION_THRESHOLD of the bits in c are equal to 1; returns FALSE otherwise.", + "ja": "c のビットのうち RNFD_CFRC_SATURATION_THRESHOLD を超えるビットが 1 に等しい場合は TRUE を返します。それ以外の場合は FALSE を返します。" + }, + { + "indent": 0, + "text": "5. RPL Router Behavior", + "section_title": true, + "ja": "5. RPL ルーターの動作" + }, + { + "indent": 3, + "text": "Although RNFD operates largely independently of RPL, it does need to interact with RPL and the overall protocol stack. These interactions are described next and can be realized, for instance, by means of event triggers.", + "ja": "RNFD は主に RPL とは独立して動作しますが、RPL およびプロトコル スタック全体と対話する必要があります。これらの対話については次に説明しますが、たとえばイベント トリガーによって実現できます。" + }, + { + "indent": 0, + "text": "5.1. Joining a DODAG Version and Changing the RNFD Role", + "section_title": true, + "ja": "5.1. DODAG バージョンへの参加と RNFD ロールの変更" + }, + { + "indent": 3, + "text": "Whenever RPL is running at a node and joins a DODAG Version, RNFD (if active) MUST assume the role of Acceptor for the node. Accordingly, it MUST set its LORS to \"UP\" and its PositiveCFRC and NegativeCFRC to zero().", + "ja": "RPL がノードで実行され、DODAG バージョンに参加するときは常に、RNFD (アクティブな場合) がノードのアクセプターの役割を引き受けなければなりません (MUST)。したがって、LORS を「UP」に設定し、PositiveCFRC と NegativeCFRC を zero() に設定しなければなりません。" + }, + { + "indent": 3, + "text": "The role may then change between Acceptor and Sentinel at any time. However, while a switch from Sentinel to Acceptor has no preconditions, in order for a switch from Acceptor to Sentinel to be possible, _all_ of the following conditions MUST hold:", + "ja": "その後、役割はいつでもアクセプターとセンチネルの間で変更される可能性があります。ただし、Sentinel から Acceptor への切り替えには前提条件がありませんが、Acceptor から Sentinel への切り替えを可能にするためには、次の条件のすべてが満たされなければなりません。" + }, + { + "indent": 8, + "text": "1. LORS is \"UP\";", + "ja": "1. LORS は「アップ」です。" + }, + { + "indent": 8, + "text": "2. saturated(PositiveCFRC) is FALSE;", + "ja": "2. 飽和(PositiveCFRC) は FALSE です。" + }, + { + "indent": 8, + "text": "3. a neighbor entry for the DODAG root is present in RPL's DODAG parent set; and", + "ja": "3. DODAG ルートの隣接エントリが RPL の DODAG 親セットに存在します。そして" + }, + { + "indent": 8, + "text": "4. the neighbor is considered reachable via its link-local IPv6 address.", + "ja": "4. 近隣ノードは、そのリンクローカル IPv6 アドレスを介して到達可能であるとみなされます。" + }, + { + "indent": 3, + "text": "A role change also requires appropriate updates to LORS and CFRCs, so that the node is properly accounted for. More specifically, when changing its role from Acceptor to Sentinel, the node MUST add itself to its PositiveCFRC as follows. It MUST generate a new CFRC value, selfc = self(), and it MUST replace its PositiveCFRC, denoted oldpc, with newpc = merge(oldpc, selfc). In contrast, the effects of a switch from Sentinel to Acceptor vary depending on the node's value of LORS before the switch:", + "ja": "ロールの変更には、ノードが適切に考慮されるように、LORS と CFRC に対する適切な更新も必要です。より具体的には、その役割をアクセプターからセンチネルに変更するとき、ノードは次のように自身をその PositiveCFRC に追加しなければなりません (MUST)。新しい CFRC 値 selfc = self() を生成しなければならず、oldpc で示される PositiveCFRC を newpc = merge(oldpc, selfc) に置き換えなければなりません。対照的に、Sentinel から Acceptor への切り替えの効果は、切り替え前のノードの LORS の値に応じて異なります。" + }, + { + "indent": 6, + "text": "* For \"GLOBALLY DOWN\", the node MUST NOT modify its LORS, PositiveCFRC, and NegativeCFRC.", + "ja": "* 「GLOBALLY DOWN」の場合、ノードは LORS、PositiveCFRC、および NegativeCFRC を変更してはなりません (MUST NOT)。" + }, + { + "indent": 6, + "text": "* For \"LOCALLY DOWN\", the node MUST set its LORS to \"UP\" but MUST NOT modify its PositiveCFRC and NegativeCFRC.", + "ja": "* 「LOCALLY DOWN」の場合、ノードは LORS を「UP」に設定しなければなりませんが、PositiveCFRC と NegativeCFRC を変更してはなりません。" + }, + { + "indent": 6, + "text": "* For \"UP\" and \"SUSPECTED DOWN\", the node MUST set its LORS to \"UP\" and MUST NOT modify its PositiveCFRC, but the node MUST add itself to NegativeCFRC, by replacing its NegativeCFRC, denoted oldnc, with newnc = merge(oldnc, selfc), where selfc is the counter generated with self() when the node last added itself to its PositiveCFRC.", + "ja": "* 「UP」および「SUSPECTED DOWN」の場合、ノードは LORS を「UP」に設定しなければならず、PositiveCFRC を変更してはなりません。ただし、ノードは、oldnc で示される NegativeCFRC を newnc = merge(oldnc, selfc) に置き換えることによって、自身を NegativeCFRC に追加しなければなりません。ここで、selfc は、ノードが最後に自身を PositiveCFRC に追加したときに self() で生成されたカウンターです。" + }, + { + "indent": 0, + "text": "5.2. Detecting and Verifying Problems with the DODAG Root", + "section_title": true, + "ja": "5.2. DODAG ルートの問題の検出と検証" + }, + { + "indent": 3, + "text": "Only nodes that are Sentinels take an active part in detecting crashes of the DODAG root; Acceptors just disseminate their observations, reflected in the CFRCs.", + "ja": "Sentinel であるノードのみが、DODAG ルートのクラッシュの検出に積極的に関与します。受け入れ者は、CFRC に反映された観察結果を広めるだけです。" + }, + { + "indent": 3, + "text": "The DODAG root monitoring SHOULD be based on both internal inputs, notably the values of CFRCs and LORS, and external inputs, such as triggers from RPL and other protocols. External input monitoring SHOULD be performed preferably in a reactive fashion, also independently of RPL, and at both the data plane and control plane. In particular, it is RECOMMENDED that RNFD be directly notified of events relevant to the routing adjacency maintenance mechanisms on which RPL relies, such as Layer 2 (L2) triggers [RFC5184] or the Neighbor Unreachability Detection [RFC4861] mechanism. In addition, depending on the underlying protocol stack, there may be other potential sources of such events, for instance, neighbor communication overhearing. In any case, only events concerning the DODAG root need to be monitored. For example, RNFD can conclude that there may be problems with the DODAG root if it observes a lack of multiple consecutive L2 acknowledgments for packets transmitted by the node via the link to the DODAG root. Internally, in turn, it is RECOMMENDED that RNFD take action whenever there is a change to its local CFRCs, so that a node can have a chance to participate in detecting potential problems even when normally it would not exchange packets over the link with the DODAG root during some period. In particular, RNFD SHOULD conclude that there may be problems with the DODAG root when the fraction value(NegativeCFRC)/value(PositiveCFRC) has grown by at least RNFD_SUSPICION_GROWTH_THRESHOLD since the node last set its LORS to \"UP\".", + "ja": "DODAG ルート監視は、内部入力、特に CFRC と LORS の値と、RPL や他のプロトコルからのトリガーなどの外部入力の両方に基づくべきです(SHOULD)。外部入力モニタリングは、RPL とは独立して、データ プレーンとコントロール プレーンの両方で事後対応的に実行することが望ましいです (SHOULD)。特に、レイヤ 2 (L2) トリガー [RFC5184] や近隣到達不能検出 [RFC4861] メカニズムなど、RPL が依存するルーティング隣接関係維持メカニズムに関連するイベントを RNFD に直接通知することが推奨されます。さらに、基礎となるプロトコル スタックによっては、近隣通信の傍聴など、このようなイベントの潜在的な原因が他にも存在する可能性があります。いずれの場合も、DODAG ルートに関するイベントのみを監視する必要があります。たとえば、RNFD は、ノードによって DODAG ルートへのリンクを介して送信されたパケットに対する複数の連続した L2 確認応答の欠如を観察した場合、DODAG ルートに問題がある可能性があると結論付けることができます。内部的には、ローカル CFRC に変更があるたびに RNFD がアクションを起こすことが推奨されます。これにより、ノードは、通常は一定期間 DODAG ルートとのリンク上でパケットを交換しない場合でも、潜在的な問題の検出に参加する機会を得ることができます。特に、RNFD は、ノードが最後に LORS を「UP」に設定してから、端数の値 (NegativeCFRC)/値 (PositiveCFRC) が少なくとも RNFD_SUSPICION_GROWTH_THRESHOLD だけ増加した場合、DODAG ルートに問題がある可能性があると結論付ける必要があります (SHOULD)。" + }, + { + "indent": 3, + "text": "Whenever, having its LORS set to \"UP\", RNFD concludes (based on either external or internal inputs) that there may be problems with the link with the DODAG root, it MUST set its LORS either to \"SUSPECTED DOWN\" or, as an optimization, to \"LOCALLY DOWN\".", + "ja": "LORS が「UP」に設定されている場合、RNFD は、DODAG ルートとのリンクに問題がある可能性があると (外部入力または内部入力に基づいて) 結論付けるたびに、LORS を「SUSPECTED DOWN」、または最適化として「LOCALLY DOWN」に設定しなければなりません。" + }, + { + "indent": 3, + "text": "The \"SUSPECTED DOWN\" value of LORS is temporary: its aim is to give RNFD an additional opportunity to verify whether the link with the DODAG root is indeed down. Depending on the outcome of such verification, RNFD MUST set its LORS to either \"UP\", if the link has been confirmed not to be down, or \"LOCALLY DOWN\", otherwise. The verification can be performed, for example, by transmitting RPL DIS or ICMPv6 Echo Request messages to the DODAG root's link-local IPv6 address and expecting replies confirming that the root is up and reachable through the link. Care should be taken not to overload the DODAG root with traffic due to simultaneous probes, for instance, random backoffs can be employed to this end. It is RECOMMENDED that the \"SUSPECTED DOWN\" value of LORS be attained and verification take place if RNFD's conclusion on the state of the DODAG root is based only on indirect observations, for example, the aforementioned growth of the CFRC values. In contrast, for direct observations, such as missing L2 acknowledgments, the verification MAY be skipped, with the node's LORS effectively changing from \"UP\" directly to \"LOCALLY DOWN\".", + "ja": "LORS の「SUSPECTED DOWN」値は一時的なものです。その目的は、RNFD に DODAG ルートとのリンクが実際にダウンしているかどうかを確認する追加の機会を与えることです。そのような検証の結果に応じて、RNFD はリンクがダウンしていないことが確認された場合は LORS を「UP」に設定し、そうでない場合は「LOCALLY DOWN」に設定しなければなりません。検証は、たとえば、RPL DIS または ICMPv6 Echo Request メッセージを DODAG ルートのリンクローカル IPv6 アドレスに送信し、ルートが稼働中でリンク経由で到達可能であることを確認する応答を期待することによって実行できます。同時プローブにより DODAG ルートにトラフィックが過負荷にならないように注意する必要があります。たとえば、この目的のためにランダム バックオフを使用できます。DODAG ルートの状態に関する RNFD の結論が間接的な観察、たとえば、前述の CFRC 値の増加のみに基づいている場合、LORS の「SUSPECTED DOWN」値に達し、検証が行われることが推奨されます。対照的に、L2 確認応答の欠落などの直接観察の場合、ノードの LORS が事実上「UP」から直接「LOCALLY DOWN」に変更されるため、検証がスキップされてもよい(MAY)。" + }, + { + "indent": 3, + "text": "For consistency with RPL, when detecting potential problems with the DODAG root, RNFD also must make use of RPL's independent knowledge. More specifically, a node MUST switch its LORS from \"UP\" or \"SUSPECTED DOWN\" directly to \"LOCALLY DOWN\" if a neighbor entry for the DODAG root is removed from RPL's DODAG parent set or the neighbor ceases to be considered reachable via its link-local IPv6 address.", + "ja": "RPL との一貫性を保つために、DODAG ルートの潜在的な問題を検出する場合、RNFD は RPL の独立した知識も利用する必要があります。より具体的には、DODAG ルートの隣接エントリが RPL の DODAG 親セットから削除された場合、または隣接ノードがそのリンクローカル IPv6 アドレス経由で到達可能であると見なされなくなった場合、ノードはその LORS を「UP」または「SUSPECTED DOWN」から「LOCALLY DOWN」に直接切り替えなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "Finally, while having its LORS already equal to \"LOCALLY DOWN\", a node may make an observation confirming that its link with the DODAG root is actually up. In such a case, it SHOULD set its LORS back to \"UP\" but MUST NOT do this before conditions 2-4 in Section 5.1, which are necessary for a node to change its role from Acceptor to Sentinel, all hold.", + "ja": "最後に、LORS がすでに「LOCALLY DOWN」に等しい場合、ノードは、DODAG ルートとのリンクが実際にアップしていることを確認する観察を行うことができます。このような場合、LORS を「UP」に戻す必要があります (SHOULD) が、ノードがその役割をアクセプターからセンチネルに変更するために必要なセクション 5.1 の条件 2 ～ 4 がすべて成立する前にこれを行ってはなりません (MUST NOT)。" + }, + { + "indent": 3, + "text": "To appropriately account for the node's observations on the state of the DODAG root, the aforementioned LORS transitions are accompanied by changes to the node's local CFRCs as follows. Transitions between \"UP\" and \"SUSPECTED DOWN\" do not affect either of the two CFRCs. In contrast, during a switch from \"UP\" or \"SUSPECTED DOWN\" to \"LOCALLY DOWN\", the node MUST add itself to its NegativeCFRC, as explained previously. By symmetry, if there is a transition from \"LOCALLY DOWN\" to \"UP\", the node MUST add itself to its PositiveCFRC, as explained previously.", + "ja": "DODAG ルートの状態に関するノードの観察を適切に説明するために、前述の LORS 遷移には、次のようにノードのローカル CFRC への変更が伴います。「UP」と「SUSPECTED DOWN」の間の遷移は、2 つの CFRC のどちらにも影響しません。対照的に、「UP」または「SUSPECTED DOWN」から「LOCALLY DOWN」への切り替え中は、前に説明したように、ノードは自身を NegativeCFRC に追加しなければなりません (MUST)。対称性により、「LOCALLY DOWN」から「UP」への遷移がある場合、前に説明したように、ノードは自身を PositiveCFRC に追加しなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "Such changes to a node's local CFRCs, if performed repeatedly due to incorrect decisions regarding the status of the node's link with the DODAG root, may lead to those CFRCs becoming saturated. An implementation should thus try to minimize false-positive transitions from \"UP\" and \"SUSPECTED DOWN\" to \"LOCALLY DOWN\". The exact approach depends on the specific solutions employed for assessing the state of a link. For instance, one can utilize additional mechanisms for increasing the confidence of individual decisions, such as during the aforementioned verification in the \"SUSPECTED DOWN\" state, or can limit the number of transitions per node, possibly in an adaptive fashion.", + "ja": "DODAG ルートとのノードのリンクのステータスに関する誤った決定により、ノードのローカル CFRC に対するこのような変更が繰り返し実行されると、それらの CFRC が飽和状態になる可能性があります。したがって、実装では、「UP」および「SUSPECTED DOWN」から「LOCALLY DOWN」への誤検知遷移を最小限に抑えるように努める必要があります。正確なアプローチは、リンクの状態を評価するために採用される特定のソリューションによって異なります。たとえば、前述の「SUSPECTED DOWN」状態での検証中など、個々の決定の信頼性を高めるための追加メカニズムを利用したり、場合によっては適応的な方法でノードごとの遷移数を制限したりできます。" + }, + { + "indent": 0, + "text": "5.3. Disseminating Observations and Reaching Agreement", + "section_title": true, + "ja": "5.3. 観察結果を広めて合意に達する" + }, + { + "indent": 3, + "text": "Nodes disseminate their observations by exchanging CFRCs in the RNFD Options embedded in link-local RPL control messages, notably DIOs and DISs. When processing such a received option, a node (acting as a Sentinel or Acceptor) MUST update its PositiveCFRC and NegativeCFRC to newpc = merge(oldpc, recvpc) and newnc = merge(oldnc, recvnc), respectively. Here, oldpc and oldnc are the values of the node's PositiveCFRC and NegativeCFRC before the update, while recvpc and recvnc are the received values of option fields PosCFRC and NegCFRC, respectively.", + "ja": "ノードは、リンクローカル RPL 制御メッセージ (特に DIO と DIS) に埋め込まれた RNFD オプションの CFRC を交換することによって、観測結果を広めます。このような受信したオプションを処理するとき、ノード (センチネルまたはアクセプターとして機能する) は、その PositiveCFRC と NegativeCFRC をそれぞれ newpc = merge(oldpc, recvpc) と newnc = merge(oldnc, recvnc) に更新しなければなりません (MUST)。ここで、oldpc と oldnc は更新前のノードの PositiveCFRC と NegativeCFRC の値であり、recvpc と recvnc はそれぞれオプション フィールド PosCFRC と NegCFRC の受信値です。" + }, + { + "indent": 3, + "text": "In effect, the node's value of the fraction value(NegativeCFRC)/value(PositiveCFRC) may change. If the fraction reaches at least RNFD_CONSENSUS_THRESHOLD (with value(PositiveCFRC) being greater than zero), then the node consents on the DODAG root being down. Accordingly, it MUST change its LORS to \"GLOBALLY DOWN\" and set its PositiveCFRC and NegativeCFRC both to infinity().", + "ja": "実際には、ノードの分数値 (NegativeCFRC)/値 (PositiveCFRC) の値が変更される可能性があります。この割合が少なくとも RNFD_CONSENSUS_THRESHOLD (value(PositiveCFRC) がゼロより大きい場合) に達すると、ノードは DODAG ルートがダウンしていることに同意します。したがって、LORS を「GLOBALLY DOWN」に変更し、PositiveCFRC と NegativeCFRC の両方を infinity() に設定しなければなりません。" + }, + { + "indent": 3, + "text": "The \"GLOBALLY DOWN\" value of LORS is terminal; the node MUST NOT change it and MUST NOT modify its CFRCs until it joins a new DODAG Version. With this value of LORS, RNFD at the node MUST also prevent RPL from having any DODAG parent and advertising any Rank other than INFINITE_RANK.", + "ja": "LORS の「GLOBALLY DOWN」値は最終的なものです。ノードは新しい DODAG バージョンに参加するまで、それを変更してはならず、CFRC を変更してはなりません。LORS のこの値により、ノードの RNFD は、RPL が DODAG 親を持ち、INFINITE_RANK 以外のランクをアドバタイズすることも防止しなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "Since the RNFD Option is embedded, among others, in RPL DIO control messages, updates to a node's CFRCs may affect the sending schedule of these messages, which is driven by the DIO Trickle timer [RFC6206]. It is RECOMMENDED to use a dedicated Trickle timer for RNFD that is different from RPL's original DIO Trickle timer. In such a setting, whenever the dedicated timer fires and no DIO message containing the RNFD Option has been sent to the link-local all-RPL-nodes multicast IPv6 address since the previous firing, the node sends a DIO message containing the RNFD Option to the address. The minimal and maximal interval sizes of the dedicated timer SHOULD NOT be smaller than those of RPL's original DIO Trickle timer. In contrast, in the absence of the dedicated Trickle timer for RNFD, an implementation SHOULD ensure that the RNFD Option is present in multicast DIO messages sufficiently often to quickly propagate changes to the node's CFRCs and, notably, as soon as possible after a reset of the timer triggered by RNFD. In the remainder of this document, we will refer to the Trickle timer utilized by RNFD (either the dedicated one or RPL's original one, depending on the implementation) simply as \"Trickle timer\". In particular, a node MUST reset its Trickle timer when it changes its LORS to \"GLOBALLY DOWN\", so that information about the detected crash of the DODAG root is disseminated in the DODAG fast. Likewise, a node SHOULD reset its Trickle timer when any of its local CFRCs change significantly.", + "ja": "RNFD オプションは特に RPL DIO 制御メッセージに埋め込まれているため、ノードの CFRC の更新は、DIO Trickle タイマー [RFC6206] によって駆動されるこれらのメッセージの送信スケジュールに影響を与える可能性があります。RPL のオリジナルの DIO トリクル タイマーとは異なる、RNFD 専用のトリクル タイマーを使用することをお勧めします。このような設定では、専用タイマーが起動し、前回の起動以降、RNFD オプションを含む DIO メッセージがリンクローカルの全 RPL ノードのマルチキャスト IPv6 アドレスに送信されていない場合、ノードは RNFD オプションを含む DIO メッセージをそのアドレスに送信します。専用タイマーの最小間隔サイズと最大間隔サイズは、RPL のオリジナルの DIO Trickle タイマーの間隔サイズより小さくてはいけません (SHOULD NOT)。対照的に、RNFD 専用の Trickle タイマーが存在しない場合、実装では、変更をノードの CFRC に迅速に伝播するのに十分な頻度で、特に RNFD によってトリガーされたタイマーのリセット後できるだけ早く、RNFD オプションがマルチキャスト DIO メッセージに存在することを保証する必要があります (SHOULD)。このドキュメントの残りの部分では、RNFD によって利用されるトリクル タイマー (実装に応じて、専用のものまたは RPL のオリジナルのもの) を単に「トリクル タイマー」と呼びます。特に、ノードは LORS を「GLOBALLY DOWN」に変更するときにトリクル タイマーをリセットし、DODAG ルートの検出されたクラッシュに関する情報が DODAG ファストで広められるようにしなければなりません。同様に、ノードは、ローカル CFRC のいずれかが大幅に変化したときに、その Trickle タイマーをリセットする必要があります (SHOULD)。" + }, + { + "indent": 0, + "text": "5.4. DODAG Root's Behavior", + "section_title": true, + "ja": "5.4. DODAG ルートの動作" + }, + { + "indent": 3, + "text": "The DODAG root node MUST assume the role of Acceptor in RNFD and MUST NOT ever switch this role. It MUST also monitor its LORS and local CFRCs, so that it can react to various events.", + "ja": "DODAG ルート ノードは、RNFD でのアクセプターの役割を引き受けなければならず、この役割を決して切り替えてはなりません。また、さまざまなイベントに対応できるように、LORS とローカル CFRC を監視しなければなりません。" + }, + { + "indent": 3, + "text": "To start with, the DODAG root MUST generate a new DODAG Version, thereby restarting the protocol, if it changes its LORS to \"GLOBALLY DOWN\", which may happen when the root has restarted after a crash or the nodes have falsely detected its crash. It MAY also generate a new DODAG Version if the fraction value(NegativeCFRC)/value(PositiveCFRC) approaches RNFD_CONSENSUS_THRESHOLD, so as to avoid potential interruptions to routing.", + "ja": "まず、DODAG ルートは、LORS を「GLOBALLY DOWN」に変更する場合、新しい DODAG バージョンを生成し、それによってプロトコルを再起動しなければなりません。これは、ルートがクラッシュ後に再起動した場合、またはノードがクラッシュを誤って検出した場合に発生する可能性があります。また、ルーティングの潜在的な中断を避けるために、小数値 (NegativeCFRC)/値 (PositiveCFRC) が RNFD_CONSENSUS_THRESHOLD に近づいた場合、新しい DODAG バージョンを生成してもよい (MAY)。" + }, + { + "indent": 3, + "text": "Furthermore, the DODAG root SHOULD either generate a new DODAG Version or increase the bit length of its CFRCs if saturated(PositiveCFRC) becomes TRUE. This is a self-regulation mechanism that helps adjust the CFRCs to a potentially large number of Sentinels (see Section 6.1).", + "ja": "さらに、DODAG ルートは、saturated(PositiveCFRC) が TRUE になった場合、新しい DODAG バージョンを生成するか、その CFRC のビット長を増やす必要があります (SHOULD)。これは、潜在的に多数のセンチネルに合わせて CFRC を調整するのに役立つ自己調整メカニズムです (セクション 6.1 を参照)。" + }, + { + "indent": 3, + "text": "In general, issuing a new DODAG Version effectively restarts RNFD. Thus, the DODAG root MAY also perform this operation in other situations.", + "ja": "一般に、新しい DODAG バージョンを発行すると、実質的に RNFD が再起動されます。したがって、DODAG ルートは他の状況でもこの操作を実行してもよい(MAY)。" + }, + { + "indent": 0, + "text": "5.5. Activating and Deactivating the Protocol on Demand", + "section_title": true, + "ja": "5.5. オンデマンドでのプロトコルのアクティブ化と非アクティブ化" + }, + { + "indent": 3, + "text": "RNFD can be activated and deactivated on demand, once per DODAG Version. The particular policies for activating and deactivating the protocol are outside the scope of this document. However, the activation and deactivation MUST be done at the DODAG root node; other nodes MUST comply.", + "ja": "RNFD は、DODAG バージョンごとに 1 回、オンデマンドでアクティブ化および非アクティブ化できます。プロトコルをアクティブ化および非アクティブ化するための特定のポリシーは、このドキュメントの範囲外です。ただし、アクティブ化と非アクティブ化は DODAG ルート ノードで行う必要があります。他のノードも従わなければなりません。" + }, + { + "indent": 3, + "text": "More specifically, when a non-root node joins a DODAG Version, RNFD at the node is initially inactive. The node MUST NOT activate the protocol unless it receives for this DODAG Version a valid RNFD Option containing some CFRCs, that is, having its Option Length field positive. In particular, if the option accompanies the message that causes the node to join the DODAG Version, the protocol MUST be active from the moment of the joining. RNFD then remains active at the node until it is explicitly deactivated or the node joins a new DODAG Version. An explicit deactivation MUST take place when the node receives an RNFD Option for the DODAG Version with no CFRCs, that is, having its Option Length field equal to zero. When explicitly deactivated, RNFD MUST NOT be reactivated unless the node joins a new DODAG Version. In particular, when the first RNFD Option received by the node has its Option Length field equal to zero, the protocol MUST remain deactivated for the entire time the node belongs to the current DODAG Version.", + "ja": "より具体的には、非ルート ノードが DODAG バージョンに参加すると、ノードの RNFD は最初は非アクティブになります。ノードは、この DODAG バージョンに対して、いくつかの CFRC を含む有効な RNFD オプション、つまり、オプション長フィールドが正のものを受信しない限り、プロトコルをアクティブにしてはなりません (MUST NOT)。特に、オプションがノードを DODAG バージョンに参加させるメッセージを伴う場合、プロトコルは参加の瞬間からアクティブでなければなりません (MUST)。RNFD は、明示的に非アクティブ化されるか、ノードが新しい DODAG バージョンに参加するまで、ノードでアクティブなままになります。ノードが CFRC のない DODAG バージョンの RNFD オプションを受信したとき、つまりオプション長フィールドがゼロに等しいとき、明示的な非アクティブ化が行われなければなりません (MUST)。明示的に非アクティブ化された場合、ノードが新しい DODAG バージョンに参加しない限り、RNFD を再アクティブ化してはなりません (MUST NOT)。特に、ノードが受信した最初の RNFD オプションのオプション長フィールドが 0 に等しい場合、そのノードが現在の DODAG バージョンに属している間、プロトコルは非アクティブのままでなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "When RNFD at a node is initially inactive for a DODAG Version, the node MUST NOT attach any RNFD Option to the messages it sends (in particular, because it may not know the desired CFRC length; see Section 5.6). When the protocol has been explicitly deactivated, the node MAY also decide not to attach the option to its outgoing messages. However, it is RECOMMENDED that it send a sufficient number of messages with the option to the link-local all-RPL-nodes multicast IPv6 address to allow its neighbors to learn that RNFD has been deactivated in the current DODAG Version. In particular, it MAY reset its Trickle timer to this end but MAY also use some reactive mechanisms. For example, it might reply with a unicast DIO or DIS containing the RNFD Option with no CFRCs to a message from a neighbor that contains the option with some CFRCs, as such a neighbor appears not to have learned about the deactivation of RNFD.", + "ja": "ノードの RNFD が最初に DODAG バージョンに対して非アクティブである場合、ノードは送信するメッセージに RNFD オプションを付加してはなりません (特に、必要な CFRC 長がわからない可能性があるため、セクション 5.6 を参照)。プロトコルが明示的に非アクティブ化されている場合、ノードは発信メッセージにオプションを付加しないことを決定してもよい(MAY)。ただし、現在の DODAG バージョンで RNFD が非アクティブ化されていることを近隣のルータが認識できるように、リンク ローカルの全 RPL ノードのマルチキャスト IPv6 アドレスにオプション付きで十分な数のメッセージを送信することが推奨されます。特に、この目的のために Trickle タイマーをリセットしてもよい (MAY) が、いくつかの反応メカニズムを使用してもよい (MAY)。たとえば、一部の CFRC を含むオプションを含むネイバーからのメッセージに対して、CFRC を含まない RNFD オプションを含むユニキャスト DIO または DIS で応答する可能性があります。これは、そのようなネイバーが RNFD の非アクティブ化について学習していないように見えるためです。" + }, + { + "indent": 0, + "text": "5.6. Processing CFRCs of Incompatible Lengths", + "section_title": true, + "ja": "5.6. 互換性のない長さの CFRC の処理" + }, + { + "indent": 3, + "text": "The merge() and compare() operations on CFRCs require both arguments to be compatible, that is, to have the same bit length. However, the processing rules for the RNFD Option (see Section 4.2) do not necessitate this. This fact is made use of not only in the mechanisms for activating and deactivating the protocol (see Section 5.5), but also in mechanisms for dynamic adjustments of CFRCs, which aim to enable deployment-specific policies (see Section 6.1). A node thus must be prepared to receive the RNFD Option with fields PosCFRC and NegCFRC of a different bit length than the node's own PositiveCFRC and NegativeCFRC. Assuming that it has RNFD active and that fields PosCFRC and NegCFRC in the option have a positive length, the node MUST react as follows.", + "ja": "CFRC の merge() および Compare() 操作では、両方の引数に互換性があること、つまり同じビット長であることが必要です。ただし、RNFD オプションの処理規則 (セクション 4.2 を参照) ではこれは必要ありません。この事実は、プロトコルをアクティブ化および非アクティブ化するメカニズム (セクション 5.5 を参照) だけでなく、展開固有のポリシーを有効にすることを目的とした CFRC の動的調整のメカニズム (セクション 6.1 を参照) でも利用されます。したがって、ノードは、ノード自身の PositiveCFRC および NegativeCFRC とは異なるビット長のフィールド PosCFRC および NegCFRC を含む RNFD オプションを受信できるように準備する必要があります。RNFD がアクティブであり、オプションの PosCFRC フィールドと NegCFRC フィールドが正の長さを持っていると仮定すると、ノードは次のように反応しなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "If the bit length of fields PosCFRC and NegCFRC is the same as that of the node's local PositiveCFRC and NegativeCFRC, then the node MUST perform the merges, as detailed previously (see Section 5.3).", + "ja": "フィールド PosCFRC および NegCFRC のビット長がノードのローカル PositiveCFRC および NegativeCFRC のビット長と同じである場合、ノードは以前に詳述したようにマージを実行しなければなりません (セクション 5.3 を参照)。" + }, + { + "indent": 3, + "text": "If the bit length of fields PosCFRC and NegCFRC is smaller than that of the node's local PositiveCFRC and NegativeCFRC, then the node MUST ignore the option and MAY reset its Trickle timer.", + "ja": "フィールド PosCFRC および NegCFRC のビット長がノードのローカル PositiveCFRC および NegativeCFRC のビット長より小さい場合、ノードはオプションを無視しなければならず (MUST)、トリクル タイマーをリセットしてもよい (MAY)。" + }, + { + "indent": 3, + "text": "If the bit length of fields PosCFRC and NegCFRC is greater than that of the node's local PositiveCFRC and NegativeCFRC, then the node MUST extend the bit length of its local CFRCs to be equal to that in the option and set the CFRCs as follows:", + "ja": "フィールド PosCFRC および NegCFRC のビット長がノードのローカル PositiveCFRC および NegativeCFRC のビット長より大きい場合、ノードはローカル CFRC のビット長をオプションのビット長と等しくなるように拡張し、CFRC を次のように設定しなければなりません。" + }, + { + "indent": 6, + "text": "* If the node's LORS is \"GLOBALLY DOWN\", then both of its local CFRCs MUST be set to infinity().", + "ja": "* ノードの LORS が「GLOBALLY DOWN」の場合、そのローカル CFRC の両方を infinity() に設定しなければなりません。" + }, + { + "indent": 6, + "text": "* Otherwise, they both MUST be set to zero(), and the node MUST account for itself in so initialized CFRCs. More specifically, if the node is a Sentinel, then it MUST add itself to its PositiveCFRC, as detailed previously. In addition, if its LORS is \"LOCALLY DOWN\", then it MUST also add itself to its NegativeCFRC, as explained previously. Finally, the node MUST perform merges of its local CFRCs and the ones received in the option (see Section 5.3) and MAY reset its Trickle timer.", + "ja": "* それ以外の場合、それらは両方とも zero() に設定されなければならず、ノードはそのように初期化された CFRC 内でそれ自体を考慮しなければなりません。より具体的には、ノードが Sentinel の場合、前に説明したように、ノード自体を PositiveCFRC に追加しなければなりません (MUST)。さらに、LORS が「LOCALLY DOWN」の場合は、前に説明したように、自身を NegativeCFRC に追加しなければなりません。最後に、ノードはローカル CFRC とオプション (セクション 5.3 を参照) で受信した CFRC のマージを実行しなければならず (MUST)、トリクル タイマーをリセットしてもよい (MAY)。" + }, + { + "indent": 3, + "text": "In contrast, if the node is unable to extend its local CFRCs, for example, because it lacks resources, then it MUST stop participating in RNFD. That is, until it joins a new DODAG Version, it MUST NOT send the RNFD Option and MUST ignore this option in received messages.", + "ja": "対照的に、ノードがリソース不足などの理由でローカル CFRC を拡張できない場合は、RNFD への参加を停止しなければなりません。つまり、新しい DODAG バージョンに参加するまで、RNFD オプションを送信してはならず、受信メッセージ内のこのオプションを無視しなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "A DODAG root node can be requested to increase the bit length of its CFRCs externally, as part of the management policies (see Section 6.1). If it cannot fulfill such a request, then it MUST NOT stop participating in RNFD and SHOULD return an error to the requester instead. Otherwise, since it is always an Acceptor, the above rules require it to extend both CFRCs to the requested length and to set them both to either zero() or infinity(), depending on whether its LORS is different from or equal to \"GLOBALLY DOWN\", respectively. In the latter case, given the earlier rules governing the root's behavior upon reaching the \"GLOBALLY DOWN\" state (cf. Section 5.4), the root is also bound to eventually set its CFRCs to zero() and, in addition, generate a new DODAG Version and change its LORS back to \"UP\". Therefore, these two steps can be optimized into one, meaning that effectively, irrespective of its LORS, when increasing the bit length of its CFRCs in response to an external request, the root also sets the CFRCs to zero().", + "ja": "DODAG ルート ノードは、管理ポリシーの一環として、外部から CFRC のビット長を増やすように要求できます (セクション 6.1 を参照)。そのような要求を満たすことができない場合、RNFD への参加を停止してはならず、代わりに要求者にエラーを返す必要があります (SHOULD)。それ以外の場合、常にアクセプターであるため、上記のルールでは、両方の CFRC を要求された長さまで拡張し、LORS が「GLOBALLY DOWN」と異なるか等しいかに応じて両方を zero() または infinity() に設定する必要があります。後者の場合、「GLOBALLY DOWN」状態に達したときのルートの動作を管理する以前のルール (セクション 5.4 を参照) を考慮すると、ルートは最終的に CFRC を zero() に設定し、さらに新しい DODAG バージョンを生成して LORS を「UP」に戻すことになります。したがって、これらの 2 つのステップは 1 つに最適化できます。つまり、LORS に関係なく、外部要求に応じて CFRC のビット長を増やすときに、ルートは CFRC を zero() に設定することになります。" + }, + { + "indent": 0, + "text": "5.7. Summary of RNFD's Interactions with RPL", + "section_title": true, + "ja": "5.7. RNFD と RPL との関係の概要" + }, + { + "indent": 3, + "text": "In summary, RNFD interacts with RPL in the following manner:", + "ja": "要約すると、RNFD は次の方法で RPL と対話します。" + }, + { + "indent": 6, + "text": "* While having its LORS equal to \"GLOBALLY DOWN\", RNFD prevents RPL from routing packets and advertising upward routes in the corresponding DODAG (see Section 5.3).", + "ja": "* LORS を「GLOBALLY DOWN」に設定している間、RNFD は、RPL がパケットをルーティングし、対応する DODAG 内で上向きルートをアドバタイズすることを防ぎます (セクション 5.3 を参照)。" + }, + { + "indent": 6, + "text": "* In some scenarios, RNFD triggers RPL to issue a new DODAG Version (see Section 5.4).", + "ja": "* 一部のシナリオでは、RNFD が RPL をトリガーして新しい DODAG バージョンを発行します (セクション 5.4 を参照)。" + }, + { + "indent": 6, + "text": "* Depending on the implementation, RNFD may cause RPL's DIO Trickle timer resets (see Sections 5.3, 5.5, and 5.6).", + "ja": "* 実装によっては、RNFD が RPL の DIO Trickle タイマー リセットを引き起こす可能性があります (セクション 5.3、5.5、および 5.6 を参照)。" + }, + { + "indent": 6, + "text": "* RNFD monitors events relevant to routing adjacency maintenance as well as those affecting RPL's DODAG parent set (see Sections 5.1 and 5.2).", + "ja": "* RNFD は、ルーティング隣接関係の維持に関連するイベントと、RPL の DODAG 親セットに影響を与えるイベントを監視します (セクション 5.1 および 5.2 を参照)。" + }, + { + "indent": 6, + "text": "* Using RNFD entails embedding the RNFD Option into link-local RPL control messages (see Section 4.2).", + "ja": "* RNFD を使用するには、RNFD オプションをリンクローカル RPL 制御メッセージに埋め込む必要があります (セクション 4.2 を参照)。" + }, + { + "indent": 0, + "text": "5.8. Summary of RNFD's Constants", + "section_title": true, + "ja": "5.8. RNFDの定数の概要" + }, + { + "indent": 3, + "text": "The following is a summary of RNFD's constants:", + "ja": "以下は RNFD の定数の概要です。" + }, + { + "indent": 3, + "text": "RNFD_CONSENSUS_THRESHOLD:", + "ja": "RNFD_CONSENSUS_THRESHOLD:" + }, + { + "indent": 12, + "text": "A threshold concerning the value of the fraction value(NegativeCFRC)/value(PositiveCFRC). If the value at a Sentinel or Acceptor node reaches the threshold, then the node's LORS is set to \"GLOBALLY DOWN\", which implies that consensus has been reached on the DODAG root node being down (see Section 5.3). The default value of the threshold is 0.51, which indicates that a majority of Sentinels must consider the root to be down to reach the consensus. In general, when the value is higher, the detection period is longer, but the risk of false positives is lower.", + "ja": "端数値(NegativeCFRC)/値(PositiveCFRC)の値に関する閾値。Sentinel または Acceptor ノードの値がしきい値に達すると、ノードの LORS は「GLOBALLY DOWN」に設定されます。これは、DODAG ルート ノードがダウンしていることについて合意が得られたことを意味します (セクション 5.3 を参照)。しきい値のデフォルト値は 0.51 で、これは、コンセンサスに達するには、大多数の Sentinel がルートがダウンしていると見なす必要があることを示します。一般に、値が高いほど検出期間は長くなりますが、誤検知のリスクは低くなります。" + }, + { + "indent": 3, + "text": "RNFD_SUSPICION_GROWTH_THRESHOLD:", + "ja": "RNFD_SUSPICION_GROWTH_THRESHOLD:" + }, + { + "indent": 12, + "text": "A threshold concerning the value of the fraction value(NegativeCFRC)/value(PositiveCFRC). If the value at a Sentinel node grows at least by this threshold since the time the node's LORS was last set to \"UP\", then the node's LORS is set to \"SUSPECTED DOWN\" or \"LOCALLY DOWN\", which implies that the node starts suspecting or assumes a crash of the DODAG root (see Section 5.2). When the value is higher, the duration of detecting true crashes is longer, but the risk of increased traffic due to verifying false suspicions is lower. The default value of the threshold is 0.12, which in sparse networks (up to 8 neighbors per node) triggers a suspicion at a Sentinel node after just one other Sentinel starts considering the root as dead, while being gradually more conservative in denser networks.", + "ja": "端数値(NegativeCFRC)/値(PositiveCFRC)の値に関する閾値。ノードの LORS が最後に「UP」に設定されてから、Sentinel ノードの値が少なくともこのしきい値だけ増加した場合、ノードの LORS は「SUSPECTED DOWN」または「LOCALLY DOWN」に設定されます。これは、ノードが DODAG ルートのクラッシュを疑うか、または想定し始めることを意味します (セクション 5.2 を参照)。値が大きいほど、本当のクラッシュを検出するまでの時間は長くなりますが、誤った疑いの検証によってトラフィックが増加するリスクは低くなります。しきい値のデフォルト値は 0.12 で、疎なネットワーク (ノードごとに最大 8 つの隣接ノード) では、他の 1 つの Sentinel がルートをデッドとみなし始めると、Sentinel ノードで疑わしい値がトリガーされますが、高密度のネットワークでは徐々に保守的になります。" + }, + { + "indent": 3, + "text": "RNFD_CFRC_SATURATION_THRESHOLD:", + "ja": "RNFD_CFRC_SATURATION_THRESHOLD:" + }, + { + "indent": 12, + "text": "A threshold concerning the percentage of bits set to 1 in a CFRC, c. If the percentage for c is equal to or greater than this threshold, then saturated(c) returns TRUE, which hints the DODAG root to generate a new DODAG Version or increase the bit length of the CFRCs (see Section 5.4). The default value of the threshold is 0.63. When the value is higher, the probability of bit collisions is higher, and the results of function value(c) may thus be more erratic.", + "ja": "ＣＦＲＣにおいて１に設定されるビットのパーセンテージに関する閾値、 ｃ．c のパーセンテージがこのしきい値以上の場合、saturated(c) は TRUE を返し、DODAG ルートに新しい DODAG バージョンを生成するか、CFRC のビット長を増やすよう示唆します (セクション 5.4 を参照)。しきい値のデフォルト値は 0.63 です。値が大きいほど、ビット衝突の確率が高くなるため、関数 value(c) の結果がより不安定になる可能性があります。" + }, + { + "indent": 3, + "text": "The means of configuring the constants at individual nodes are outside the scope of this document.", + "ja": "個々のノードで定数を設定する方法は、このドキュメントの範囲外です。" + }, + { + "indent": 0, + "text": "6. Manageability Considerations", + "section_title": true, + "ja": "6. 管理性に関する考慮事項" + }, + { + "indent": 3, + "text": "RNFD is largely self-managed, with the exception of protocol activation and deactivation, as well as node role assignment and the related CFRC size adjustment, for which only the aforementioned mechanisms are defined, so as to enable adopting deployment-specific policies. This section discusses the manageability issues.", + "ja": "RNFD は、プロトコルのアクティブ化と非アクティブ化、ノードの役割の割り当て、および関連する CFRC サイズの調整を除いて、大部分が自己管理されます。これらについては、展開固有のポリシーの採用を可能にするために、前述のメカニズムのみが定義されています。このセクションでは、管理性の問題について説明します。" + }, + { + "indent": 0, + "text": "6.1. Role Assignment and CFRC Size Adjustment", + "section_title": true, + "ja": "6.1. 役割の割り当てと CFRC サイズの調整" + }, + { + "indent": 3, + "text": "One approach to node role and CFRC size selection is to manually designate specific nodes as Sentinels in RNFD, assuming that they will have chances to satisfy the necessary conditions for attaining this role (see Section 5.1), and to fix the CFRC bit length to accommodate these nodes.", + "ja": "ノードの役割と CFRC サイズの選択に対する 1 つのアプローチは、特定のノードがこの役割を達成するために必要な条件を満たす機会があると仮定して (セクション 5.1 を参照)、特定のノードを RNFD のセンチネルとして手動で指定し、これらのノードに対応するために CFRC ビット長を固定することです。" + }, + { + "indent": 3, + "text": "Another approach is to automate the selection process. In principle, any node satisfying the necessary conditions for becoming a Sentinel (see Section 5.1) can attain this role. However, in networks where the DODAG root node has many neighbors, this approach may lead to saturated(PositiveCFRC) quickly becoming TRUE, which may degrade RNFD's performance without additional measures. This issue can be handled with a probabilistic solution: if PositiveCFRC becomes saturated with little or no increase in NegativeCFRC, then a new DODAG Version can be issued, and a node satisfying the necessary conditions can become a Sentinel in this version only with probability 1/2. This process can be continued with the probability being halved in each new DODAG Version until PositiveCFRC is no longer quickly saturated. Another solution is to increase, potentially multiple times, the bit length of the CFRCs by the DODAG root if PositiveCFRC becomes saturated with little or no growth in NegativeCFRC. This does not require issuing a new DODAG Version but lengthens the RNFD Option. In this way, a sufficient bit length can be dynamically discovered, or the root can conclude that a given bit length is excessive for (some) nodes and resort to the previous solution. Increasing the bit length can be done, for instance, by doubling it, respecting the condition that it has to be a prime number (see Section 4.2).", + "ja": "もう 1 つのアプローチは、選択プロセスを自動化することです。原則として、センチネルになるために必要な条件 (セクション 5.1 を参照) を満たすノードは、この役割を達成できます。ただし、DODAG ルート ノードに多くの隣接ノードがあるネットワークでは、このアプローチでは飽和(PositiveCFRC) がすぐに TRUE になり、追加の対策がなければ RNFD のパフォーマンスが低下する可能性があります。この問題は確率論的な解決策で処理できます。つまり、NegativeCFRC がほとんどまたはまったく増加せずに PositiveCFRC が飽和状態になった場合、新しい DODAG バージョンを発行することができ、必要な条件を満たすノードはこのバージョンで確率 1/2 でのみ Sentinel になることができます。このプロセスは、PositiveCFRC が急速に飽和しなくなるまで、新しい DODAG バージョンごとに確率を半分にして継続できます。もう 1 つの解決策は、PositiveCFRC が飽和し、NegativeCFRC がほとんどまたはまったく増加しない場合に、DODAG ルートによって CFRC のビット長をおそらく複数倍に増やすことです。これには新しい DODAG バージョンを発行する必要はありませんが、RNFD オプションが長くなります。このようにして、十分なビット長を動的に見つけることができます。あるいは、ルートは、特定のビット長が (一部の) ノードにとって過剰であると結論付け、前の解決策に頼ることもできます。ビット長を増やすには、たとえば、ビット長が素数である必要があるという条件を考慮してビット長を 2 倍にすることができます (セクション 4.2 を参照)。" + }, + { + "indent": 3, + "text": "In either of the solutions, Sentinel nodes should preferably be stable themselves and have stable links to the DODAG root. Otherwise, they may often exhibit LORS transitions between \"UP\" and \"LOCALLY DOWN\" or switches between Acceptor and Sentinel roles, which gradually saturates CFRCs. As a mitigation, the number of such transitions and switches per node MAY be limited; however, having Sentinels be stable SHOULD be preferred.", + "ja": "どちらのソリューションでも、Sentinel ノード自体が安定しており、DODAG ルートへの安定したリンクを持つことが望ましいです。それ以外の場合は、「UP」と「LOCALLY DOWN」の間で LORS 遷移が発生したり、アクセプターとセンチネルの役割が切り替わったりすることが多く、これにより CFRC が徐々に飽和状態になります。緩和策として、ノードごとのそのような遷移とスイッチの数を制限してもよい(MAY)。ただし、Sentinel を安定させることが好ましいはずです。" + }, + { + "indent": 0, + "text": "6.2. Virtual DODAG Roots", + "section_title": true, + "ja": "6.2. 仮想 DODAG ルート" + }, + { + "indent": 3, + "text": "RPL allows a DODAG to have a so-called \"virtual root\", that is, a collection of nodes coordinating to act as a single root of the DODAG. The details of the coordination process are left open in [RFC6550], but from RNFD's perspective, two possible realizations are worth consideration:", + "ja": "RPL を使用すると、DODAG はいわゆる「仮想ルート」、つまり、DODAG の単一のルートとして機能するように調整するノードの集合を持つことができます。調整プロセスの詳細は [RFC6550] で未公開のままですが、RNFD の観点からは、次の 2 つの実現可能性を検討する価値があります。" + }, + { + "indent": 6, + "text": "* Just a single (primary) node of the nodes comprising the virtual root acts as the actual root of the DODAG. Only when this node fails does another (backup) node take over. As a result, at any time, at most one of the nodes comprising the virtual root is the actual root.", + "ja": "* 仮想ルートを構成するノードのうちの 1 つの (プライマリ) ノードだけが、DODAG の実際のルートとして機能します。このノードに障害が発生した場合にのみ、別の (バックアップ) ノードが引き継ぎます。その結果、いつでも、仮想ルートを構成するノードのうち最大 1 つが実際のルートになります。" + }, + { + "indent": 6, + "text": "* More than one of the nodes comprising the virtual root act as actual roots of the DODAG, all advertising the same Rank in the DODAG. When some of the nodes fail, the other nodes may or may not react in any specific way. In other words, at any time, more than one node can be the actual root.", + "ja": "* 仮想ルートを構成する複数のノードが DODAG の実際のルートとして機能し、すべて DODAG 内の同じランクをアドバタイズします。一部のノードに障害が発生した場合、他のノードは特定の方法で反応する場合もあれば、反応しない場合もあります。言い換えれば、いつでも複数のノードが実際のルートになる可能性があります。" + }, + { + "indent": 3, + "text": "In the first realization, RNFD's operation is largely unaffected. The necessary conditions for a node to become a Sentinel (Section 5.1) guarantee that only the current primary root node is monitored by the protocol. This SHOULD be taken into account in the policies for node role assignment, CFRC size selection, and, possibly, the setting of the three thresholds (Section 5.8). Moreover, when a new primary has been elected, a new DODAG Version MUST be issued to avoid polluting CFRCs with observations on the previous primary.", + "ja": "最初の実現では、RNFD の動作はほとんど影響を受けません。ノードが Sentinel になるための必要条件 (セクション 5.1) により、現在のプライマリ ルート ノードのみがプロトコルによって監視されることが保証されます。これは、ノードの役割の割り当て、CFRC サイズの選択、および場合によっては 3 つのしきい値の設定 (セクション 5.8) のポリシーで考慮されるべきです (SHOULD)。さらに、新しい予備選挙が選出された場合、以前の予備選挙に関する観察結果によって CFRC が汚染されるのを避けるために、新しい DODAG バージョンを発行しなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "In the second realization, the fact that the virtual root consists of multiple nodes is transparent to RNFD. Therefore, employing RNFD in such a setting can be beneficial only if the nodes comprising the virtual root may suffer from correlated crashes, for instance, due to global power outages.", + "ja": "2 番目の実現では、仮想ルートが複数のノードで構成されているという事実は、RNFD に対して透過的です。したがって、このような設定で RNFD を採用することは、仮想ルートを構成するノードが、たとえば世界規模の停電によって相関クラッシュに見舞われる可能性がある場合にのみ有益となり得ます。" + }, + { + "indent": 0, + "text": "6.3. Monitoring", + "section_title": true, + "ja": "6.3. 監視" + }, + { + "indent": 3, + "text": "For monitoring the operation of RNFD, its implementation SHOULD provide the following information about a node:", + "ja": "RNFD の動作を監視するために、その実装はノードに関する次の情報を提供する必要があります (SHOULD)。" + }, + { + "indent": 6, + "text": "* whether the protocol is active, and", + "ja": "* プロトコルがアクティブかどうか、および" + }, + { + "indent": 6, + "text": "* whether LORS is \"GLOBALLY DOWN\".", + "ja": "* LORS が「世界的にダウン」しているかどうか。" + }, + { + "indent": 3, + "text": "This information MUST be accompanied by the monitoring parameters defined by RPL [RFC6550], including at least the DODAG Version Number and the Rank. To offer even finer-grained visibility into RNFD's state at the node, the implementation MAY also provide:", + "ja": "この情報には、少なくとも DODAG バージョン番号とランクを含む、RPL [RFC6550] で定義された監視パラメータが伴わなければなりません (MUST)。ノードでの RNFD の状態に対するさらにきめ細かい可視性を提供するために、実装は以下を提供してもよい (MAY)。" + }, + { + "indent": 6, + "text": "* the assigned role (i.e., Sentinel or Acceptor),", + "ja": "* 割り当てられた役割 (つまり、センチネルまたはアクセプター)、" + }, + { + "indent": 6, + "text": "* the exact value of LORS (i.e., \"UP\", \"SUSPECTED DOWN\", \"LOCALLY DOWN\", or \"GLOBALLY DOWN\"),", + "ja": "* LORS の正確な値 (つまり、「UP」、「SUSPECTED DOWN」、「LOCALLY DOWN」、または「GLOBALLY DOWN」)、" + }, + { + "indent": 6, + "text": "* the two CFRCs (i.e., PositiveCFRC and NegativeCFRC), and", + "ja": "* 2 つの CFRC (つまり、ポジティブ CFRC とネガティブ CFRC)、および" + }, + { + "indent": 6, + "text": "* the constants listed in Section 5.8.", + "ja": "* セクション 5.8 にリストされている定数。" + }, + { + "indent": 0, + "text": "7. Security Considerations", + "section_title": true, + "ja": "7. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "RNFD is an extension to RPL and thus is vulnerable to and benefits from the security issues and solutions described in [RFC6550] and [RFC7416]. Its specification in this document does not introduce new traffic patterns or new messages, for which specific mitigation techniques would be required beyond what can already be adopted for RPL.", + "ja": "RNFD は RPL の拡張であるため、[RFC6550] および [RFC7416] で説明されているセキュリティ問題と解決策に対して脆弱ですが、その恩恵を受けます。このドキュメントの仕様では、RPL に既に採用されているものを超えた特定の緩和手法が必要となる新しいトラフィック パターンや新しいメッセージは導入されていません。" + }, + { + "indent": 3, + "text": "In particular, RNFD depends on information exchanged in the RNFD Option. If the contents of this option were compromised, then failure misdetection may occur. One possibility is that the DODAG root may be falsely detected as crashed, which would result in an inability of the nodes to route packets, at least until a new DODAG Version is issued by the root. Another possibility is that a crash of the DODAG root may not be detected by RNFD, in which case RPL would have to rely on its own mechanisms. Moreover, compromising the contents of the RNFD Option may also lead to increased DIO traffic due to Trickle timer resets. Consequently, RNFD deployments are RECOMMENDED to use RPL security mechanisms if there is a risk that control information might be modified or spoofed.", + "ja": "特に、RNFD は RNFD オプションで交換される情報に依存します。このオプションの内容が侵害された場合、障害の誤検出が発生する可能性があります。可能性の 1 つは、DODAG ルートがクラッシュしていると誤って検出される可能性であり、その結果、少なくともルートによって新しい DODAG バージョンが発行されるまで、ノードはパケットをルーティングできなくなります。もう 1 つの可能性としては、DODAG ルートのクラッシュが RNFD によって検出されない可能性があり、その場合、RPL は独自のメカニズムに依存する必要があります。さらに、RNFD オプションの内容が侵害されると、トリクル タイマーのリセットにより DIO トラフィックが増加する可能性もあります。したがって、制御情報が変更またはなりすましされるリスクがある場合、RNFD 導入では RPL セキュリティ メカニズムを使用することが推奨されます。" + }, + { + "indent": 3, + "text": "In this context, two features of RNFD are worth highlighting. First, unless all neighbors of a DODAG root are compromised, a false positive can always be detected by the root based on its local CFRCs. If the frequency of such false positives becomes problematic, RNFD can be disabled altogether, for instance, until the problem has been diagnosed. This procedure can be largely automated at LBRs. Second, some types of false negatives can also be detected this way. Those that do pass undetected are likely not to have major negative consequences on RPL apart from the lack of improvement to its performance upon a DODAG root's crash, at least if RPL's other components are not attacked as well.", + "ja": "これに関連して、RNFD の 2 つの機能は強調する価値があります。まず、DODAG ルートの近隣すべてが侵害されない限り、ルートはローカル CFRC に基づいて誤検知を常に検出できます。このような誤検知の頻度が問題になる場合は、たとえば、問題が診断されるまで RNFD を完全に無効にすることができます。この手順は、LBR で大部分が自動化できます。第 2 に、一部のタイプの偽陰性もこの方法で検出できます。検出されずに通過するコンポーネントは、少なくとも RPL の他のコンポーネントが同様に攻撃されない限り、DODAG ルートのクラッシュ時にパフォーマンスが改善されないことを除けば、RPL に大きな悪影響を与えることはないと考えられます。" + }, + { + "indent": 0, + "text": "8. IANA Considerations", + "section_title": true, + "ja": "8. IANAの考慮事項" + }, + { + "indent": 3, + "text": "IANA has allocated the following value in the \"RPL Control Message Options\" registry within the \"Routing Protocol for Low Power and Lossy Networks (RPL)\" registry group (https://www.iana.org/assignments/rpl).", + "ja": "IANA は、「Routing Protocol for Low Power and Lossy Networks (RPL)」レジストリ グループ (https://www.iana.org/assignments/rpl) 内の「RPL Control Message Options」レジストリに次の値を割り当てました。" + }, + { + "indent": 17, + "text": " +=======+=============+===========+\n | Value | Meaning | Reference |\n +=======+=============+===========+\n | 0x0E | RNFD Option | RFC 9866 |\n +-------+-------------+-----------+\n\n Table 1", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "9. References", + "section_title": true, + "ja": "9. 参考文献" + }, + { + "indent": 0, + "text": "9.1. Normative References", + "section_title": true, + "ja": "9.1. 引用文献" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,\n \"The Trickle Algorithm\", RFC 6206, DOI 10.17487/RFC6206,\n March 2011, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,\n Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,\n JP., and R. Alexander, \"RPL: IPv6 Routing Protocol for\n Low-Power and Lossy Networks\", RFC 6550,\n DOI 10.17487/RFC6550, March 2012,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6553] Hui, J. and JP. Vasseur, \"The Routing Protocol for Low-\n Power and Lossy Networks (RPL) Option for Carrying RPL\n Information in Data-Plane Datagrams\", RFC 6553,\n DOI 10.17487/RFC6553, March 2012,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, \"An IPv6\n Routing Header for Source Routes with the Routing Protocol\n for Low-Power and Lossy Networks (RPL)\", RFC 6554,\n DOI 10.17487/RFC6554, March 2012,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "9.2. Informative References", + "section_title": true, + "ja": "9.2. 参考引用" + }, + { + "indent": 3, + "text": "[Ciolkosz19]\n Ciolkosz, P., \"Integration of the RNFD Algorithm for\n Border Router Failure Detection with the RPL Standard for\n Routing IPv6 Packets\", Master's Thesis, University of\n Warsaw, 2019.", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[Iwanicki16]\n Iwanicki, K., \"RNFD: Routing-Layer Detection of DODAG\n (Root) Node Failures in Low-Power Wireless Networks\", 2016\n 15th ACM/IEEE International Conference on Information\n Processing in Sensor Networks (IPSN), pp. 1-12,\n DOI 10.1109/IPSN.2016.7460720, 2016,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[Paszkowska19]\n Paszkowska, A. and K. Iwanicki, \"Failure Handling in RPL\n Implementations: An Experimental Qualitative Study\",\n Mission-Oriented Sensor Networks and Systems: Art and\n Science, Springer International Publishing, pp. 49-95,\n DOI 10.1007/978-3-319-91146-5_3, 2019,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,\n \"Neighbor Discovery for IP version 6 (IPv6)\", RFC 4861,\n DOI 10.17487/RFC4861, September 2007,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.\n Mitani, \"Unified Layer 2 (L2) Abstractions for Layer 3\n (L3)-Driven Fast Handover\", RFC 5184,\n DOI 10.17487/RFC5184, May 2008,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7102] Vasseur, JP., \"Terms Used in Routing for Low-Power and\n Lossy Networks\", RFC 7102, DOI 10.17487/RFC7102, January\n 2014, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7228] Bormann, C., Ersue, M., and A. Keranen, \"Terminology for\n Constrained-Node Networks\", RFC 7228,\n DOI 10.17487/RFC7228, May 2014,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,\n and M. Richardson, Ed., \"A Security Threat Analysis for\n the Routing Protocol for Low-Power and Lossy Networks\n (RPLs)\", RFC 7416, DOI 10.17487/RFC7416, January 2015,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[Whang90] Whang, K.-Y., Vander-Zanden, B.T., and H.M. Taylor, \"A\n Linear-time Probabilistic Counting Algorithm for Database\n Applications\", ACM Transactions on Database Systems\n (TODS), vol. 15, no. 2, pp. 208-229,\n DOI 10.1145/78922.78925, 1990,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Acknowledgements", + "section_title": true, + "ja": "謝辞" + }, + { + "indent": 3, + "text": "The author would like to acknowledge Piotr Ciolkosz and Agnieszka Paszkowska. Agnieszka contributed to deeper understanding and formally proving various aspects of RPL's behavior upon an LBR crash. Piotr developed a prototype implementation of RNFD dedicated for RPL to verify earlier performance claims.", + "ja": "著者は、ピョートル・チョルコシュとアグニエシュカ・パスコウスカに感謝したいと思います。アグニエシュカは、LBR 墜落時の RPL の動作のさまざまな側面についての理解を深め、正式に証明することに貢献しました。Piotr は、以前のパフォーマンス主張を検証するために、RPL 専用の RNFD のプロトタイプ実装を開発しました。" + }, + { + "indent": 0, + "text": "Author's Address", + "section_title": true, + "ja": "著者の連絡先" + }, + { + "indent": 3, + "text": "Konrad Iwanicki\nUniversity of Warsaw\nBanacha 2\n02-097 Warszawa\nPoland\nPhone: +48 22 55 44 428\nEmail: iwanicki@mimuw.edu.pl", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9869-trans.json b/data/9000/rfc9869-trans.json new file mode 100644 index 000000000..1f6aa84fd --- /dev/null +++ b/data/9000/rfc9869-trans.json @@ -0,0 +1,680 @@ +{ + "title": { + "text": "RFC 9869 - Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options", + "ja": "RFC 9869 - UDP オプションのデータグラム パケット化層パス MTU 検出 (DPLPMTUD)" + }, + "number": 9869, + "created_at": "2025-10-11 23:24:06.594189+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) G. Fairhurst\nRequest for Comments: 9869 T. Jones\nCategory: Standards Track University of Aberdeen\nISSN: 2070-1721 October 2025", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options", + "section_title": true, + "ja": "UDP オプションのデータグラム パケット化層パス MTU 検出 (DPLPMTUD)" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document specifies how a UDP Options sender implements Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) as a robust method for Path MTU Discovery (PMTUD). This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across a network path. It also provides a way to allow the application to periodically verify the current Maximum Packet Size (MPS) supported by a path and to update this when required.", + "ja": "この文書では、UDP オプションの送信者が、Path MTU Discovery (PMTUD) の堅牢な方法として Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) を実装する方法を指定します。この方法では、UDP オプションのパケット化層を使用します。これにより、アプリケーションはネットワーク パス経由で送信できる最大サイズのデータグラムを検出できるようになります。また、アプリケーションがパスでサポートされている現在の最大パケット サイズ (MPS) を定期的に確認し、必要に応じてこれを更新できるようにする方法も提供します。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This is an Internet Standards Track document.", + "ja": "これはインターネット標準化トラックの文書です。" + }, + { + "indent": 3, + "text": "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 Internet Standards is available in Section 2 of RFC 7841.", + "ja": "このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。" + }, + { + "indent": 3, + "text": "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/rfc9869.", + "ja": "この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9869 で入手できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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.", + "ja": "この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n2. Terminology\n3. DPLPMTUD for UDP Options\n 3.1. Packet Formats\n 3.2. Sending Probe Packets with the Request Option\n 3.3. Receiving UDP Options Probe Packets and Sending the RES\n Option\n4. DPLPMTUD Sender Procedures for UDP Options\n 4.1. Confirmation of Connectivity Across a Path\n 4.2. Sending Probe Packets to Increase the PLPMTU\n 4.3. Validating the Path with UDP Options\n 4.4. Probe Packets That Do Not Include Application Data\n 4.5. Probe Packets That Include Application Data\n5. Receiving Events from the Network\n 5.1. Changes in the Path\n 5.2. Validation of PTB Messages\n6. Examples with Different Receiver Behaviors\n7. IANA Considerations\n8. Security Considerations\n9. References\n 9.1. Normative References\n 9.2. Informative References\nAcknowledgements\nAuthors' Addresses", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "The User Datagram Protocol (UDP) [RFC0768] offers a minimal transport service on top of IP and is frequently used as a substrate for other protocols. Section 3.2 of UDP Guidelines [RFC8085] recommends that applications implement some form of Path MTU Discovery (PMTUD) to avoid the generation of IP fragments:", + "ja": "ユーザー データグラム プロトコル (UDP) [RFC0768] は、IP 上で最小限のトランスポート サービスを提供し、他のプロトコルの基盤として頻繁に使用されます。UDP ガイドライン [RFC8085] のセクション 3.2 では、IP フラグメントの生成を回避するために、アプリケーションが何らかの形式の Path MTU Discovery (PMTUD) を実装することを推奨しています。" + }, + { + "indent": 0, + "text": "Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself [RFC1191] [RFC1981] [RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation.", + "ja": "したがって、アプリケーションは、IP 層によって提供されるパス MTU 情報を使用するか、Path MTU Discovery (PMTUD) 自体 [RFC1191] [RFC1981] [RFC4821] を実装して、宛先へのパスが断片化せずに希望のメッセージ サイズをサポートするかどうかを決定する必要があります (SHOULD)。" + }, + { + "indent": 3, + "text": "The UDP API [RFC8304] offers calls for applications to receive ICMP Packet Too Big (PTB) messages and to control the maximum size of datagrams that are sent, but it does not offer any automated mechanisms for an application to discover the MPS supported by a path. Upper Layer protocols, which include applications, can implement mechanisms for PMTUD above the UDP API.", + "ja": "UDP API [RFC8304] は、アプリケーションが ICMP Packet Too Big (PTB) メッセージを受信し、送信されるデータグラムの最大サイズを制御するための呼び出しを提供しますが、アプリケーションがパスでサポートされている MPS を検出するための自動メカニズムは提供しません。アプリケーションを含む上位層プロトコルは、UDP API の上に PMTUD のメカニズムを実装できます。" + }, + { + "indent": 3, + "text": "Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] describes a method for a bidirectional Packetization Layer (PL) to search for the largest Packetization Layer PMTU (PLPMTU) supported on a path. DPLPMTUD [RFC8899] specifies this support for datagram transports. PLPMTUD and DPLPMTUD gain robustness by using a probing mechanism that does not solely rely on ICMP PTB messages and works on paths that drop ICMP PTB messages.", + "ja": "パケット化層パス MTU 検出 (PLPMTUD) [RFC4821] は、双方向パケット化層 (PL) がパス上でサポートされる最大のパケット化層 PMTU (PLPMTU) を検索する方法を説明しています。DPLPMTUD [RFC8899] は、データグラムトランスポートに対するこのサポートを指定しています。PLPMTUD および DPLPMTUD は、ICMP PTB メッセージのみに依存せず、ICMP PTB メッセージをドロップするパス上で動作するプローブ メカニズムを使用することで堅牢性を実現します。" + }, + { + "indent": 3, + "text": "UDP Options [RFC9868] supplies functionality that can be used to implement DPLPMTUD within the transport service or in an Upper Layer protocol (including an application) that uses UDP Options. This document specifies how DPLPMTUD using UDP Options is implemented (Section 6.1 of [RFC8899]) and requires support to be enabled at both the sender and receiver.", + "ja": "UDP オプション [RFC9868] は、トランスポート サービス内、または UDP オプションを使用する上位層プロトコル (アプリケーションを含む) 内で DPLPMTUD を実装するために使用できる機能を提供します。この文書は、UDP オプションを使用した DPLPMTUD がどのように実装されるかを指定し ([RFC8899] のセクション 6.1)、送信者と受信者の両方でサポートを有効にする必要があります。" + }, + { + "indent": 3, + "text": "Implementing DPLPMTUD within the transport service above UDP Options avoids the need for each Upper Layer protocol to implement the DPLPMTUD method. It provides a standard method for applications to discover the current MPS for a path and to detect when this changes. It can be used with Equal-Cost Multipath (ECMP) routing and/or multihoming. If multipath or multihoming is supported, a state machine is needed for each path.", + "ja": "UDP オプション上のトランスポート サービス内に DPLPMTUD を実装すると、各上位層プロトコルで DPLPMTUD メソッドを実装する必要がなくなります。これは、アプリケーションがパスの現在の MPS を検出し、これがいつ変更されたかを検出するための標準的な方法を提供します。Equal-Cost Multipath (ECMP) ルーティングやマルチホーミングと併用できます。マルチパスまたはマルチホーミングがサポートされている場合は、パスごとにステート マシンが必要です。" + }, + { + "indent": 3, + "text": "DPLPMTUD is not specified for multicast. The method requires explicit acknowledgement of probe packets provided by UDP Options, which is primarily intended for unicast use (see Section 23 of [RFC9868]).", + "ja": "DPLPMTUD はマルチキャストに指定されていません。この方法は、主にユニキャストでの使用を目的とした UDP オプションによって提供されるプローブ パケットの明示的な確認応答を必要とします ([RFC9868] のセクション 23 を参照)。" + }, + { + "indent": 0, + "text": "2. Terminology", + "section_title": true, + "ja": "2. 用語" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。" + }, + { + "indent": 3, + "text": "This document uses the terms defined for DPLPMTUD (Sections 2 and 5 of [RFC8899]).", + "ja": "この文書では、DPLPMTUD ([RFC8899] のセクション 2 および 5) に対して定義された用語を使用します。" + }, + { + "indent": 0, + "text": "3. DPLPMTUD for UDP Options", + "section_title": true, + "ja": "3. UDP オプションの DPLPMTUD" + }, + { + "indent": 3, + "text": "A UDP Options sender implementing DPLPMTUD uses the method specified in [RFC8899]. In this specification, DPLPMTUD is realized using a pair of UDP Options: the Request (REQ) Option and the Response (RES) Option (Section 11.7 of [RFC9868]). The method also uses the End of Options List (EOL) Option (Section 11.1 of [RFC9868]) to introduce padding to set the size of a probe packet.", + "ja": "DPLPMTUD を実装する UDP オプション送信側は、[RFC8899] で指定されたメソッドを使用します。この仕様では、DPLPMTUD は、一対の UDP オプション、つまり要求 (REQ) オプションと応答 (RES) オプションを使用して実現されます ([RFC9868] のセクション 11.7)。このメソッドはまた、オプション リストの終わり (EOL) オプション ([RFC9868] のセクション 11.1) を使用して、プローブ パケットのサイズを設定するためのパディングを導入します。" + }, + { + "indent": 3, + "text": "Use of DPLPMTUD MUST be explicitly enabled by the application, for instance, once an application has established connectivity and is ready to exchange data with the remote Upper Layer protocol. Similarly, a DPLPMTUD receiver MUST NOT respond to a UDP REQ Option until DPLPMTUD has been enabled. This is to help protect from misuse of the mechanism for other forms of probing.", + "ja": "たとえば、アプリケーションが接続を確立し、リモートの上位層プロトコルとデータを交換する準備ができたら、DPLPMTUD の使用をアプリケーションによって明示的に有効にする必要があります。同様に、DPLPMTUD 受信者は、DPLPMTUD が有効になるまで、UDP REQ オプションに応答してはなりません (MUST NOT)。これは、他の形式のプローブのメカニズムの悪用を防ぐために役立ちます。" + }, + { + "indent": 3, + "text": "Probe packets consume network capacity and incur endpoint processing (Section 4.1 of [RFC8899]). Implementations ought to send a probe packet with a UDP REQ Option only when required by their local DPLPMTUD state machine, i.e., when confirming the base PMTU for the path, probing to increase the PLPMTU, or confirming the current PLPMTU.", + "ja": "プローブ パケットはネットワーク容量を消費し、エンドポイント処理が発生します ([RFC8899] のセクション 4.1)。実装では、ローカルの DPLPMTUD ステート マシンで必要な場合、つまり、パスのベース PMTU を確認する場合、PLPMTU を増やすためにプローブする場合、または現在の PLPMTU を確認する場合にのみ、UDP REQ オプションを含むプローブ パケットを送信する必要があります。" + }, + { + "indent": 3, + "text": "DPLPMTUD can be implemented over UDP Options in two ways:", + "ja": "DPLPMTUD は、次の 2 つの方法で UDP オプション上に実装できます。" + }, + { + "indent": 6, + "text": "* Implementation within the UDP transport service.", + "ja": "* UDP トランスポート サービス内での実装。" + }, + { + "indent": 6, + "text": "* Implementation in an Upper Layer protocol (or application) that uses UDP Options.", + "ja": "* UDP オプションを使用する上位層プロトコル (またはアプリケーション) での実装。" + }, + { + "indent": 3, + "text": "When DPLPMTUD is implemented within the UDP transport service, the DPLPMTUD state machine is responsible for sending probe packets to determine a PLPMTU, as described in this document. This determines an MPS, the largest size of application data block that can be sent across a network path using a single datagram. The Upper Layer protocol is responsible for deciding when a session enables DPLPMTUD.", + "ja": "DPLPMTUD が UDP トランスポート サービス内に実装されている場合、DPLPMTUD ステート マシンは、このドキュメントで説明されているように、プローブ パケットを送信して PLPMTU を決定する役割を果たします。これにより、単一のデータグラムを使用してネットワーク パスを介して送信できるアプリケーション データ ブロックの最大サイズである MPS が決まります。上位層プロトコルは、セッションで DPLPMTUD をいつ有効にするかを決定します。" + }, + { + "indent": 3, + "text": "The discovered PLPMTU can be used to either:", + "ja": "検出された PLPMTU は次のいずれかに使用できます。" + }, + { + "indent": 6, + "text": "* set the maximum datagram size for the current path or", + "ja": "* 現在のパスの最大データグラム サイズを設定するか、" + }, + { + "indent": 6, + "text": "* set the maximum fragment size when a sender uses the UDP Fragmentation Option to divide a datagram into multiple UDP fragments for transmission. The size of each UDP fragment is then less than or equal to the size of the discovered largest IP packet that can be received across the current path.", + "ja": "* 送信者が UDP フラグメンテーション オプションを使用してデータグラムを複数の UDP フラグメントに分割して送信する場合の最大フラグメント サイズを設定します。各 UDP フラグメントのサイズは、現在のパスを介して受信できる、検出された最大の IP パケットのサイズ以下になります。" + }, + { + "indent": 3, + "text": "The figure below shows an implementation of DPLPMTUD within the UDP transport service. It illustrates key interactions between the layers. This design requires an API primitive to allow the application to control whether the DPLPMTUD state machine is enabled for a specific UDP port. By default, this API MUST disable DPLPMTUD processing.", + "ja": "次の図は、UDP トランスポート サービス内での DPLPMTUD の実装を示しています。これは、レイヤー間の重要な相互作用を示しています。この設計には、アプリケーションが特定の UDP ポートに対して DPLPMTUD ステート マシンを有効にするかどうかを制御できるようにする API プリミティブが必要です。デフォルトでは、この API は DPLPMTUD 処理を無効にしなければなりません。" + }, + { + "indent": 3, + "text": "+--------------------------------+\n| Upper Layer Protocol |\n| or Application |\n+---------------------------+----+\n ^ | Messages (with UDP Options)\n | receive send v Primitives for MPS, Min_PMTU, etc.\n+---+----------------------------+\n| DPLPMTUD State Machine |\n| Maximum Packet Size (MPS) |\n| PLPMTU, Probed-Size, Min_PMTU|\n| Token Values & Probes, etc. |\n+---------------------------+----+\n ^ | Messages (with UDP Options)\n | | Send/Receive: Probes with Options\n | receive send v Events: ICMP, Interface MTU, etc.\n+---+----------------------------+\n| UDP Options Transport |\n+---------------------------+----+\n ^ | Datagrams (with UDP Options)\n | | Fragmented Datagrams with UDP Options\n | receive send v Events: ICMP, Interface MTU, etc.", + "raw": true, + "ja": "" + }, + { + "indent": 12, + "text": "Note: UDP allows an Upper Layer protocol to send datagrams with or without payload data (with or without UDP Options). These are delivered across the network to the remote Upper Layer. When DPLPMTUD is implemented within the UDP transport service, probe packets that include a REQ or RES UDP Option can be sent with no UDP payload. In this case, these probe packets were not generated by a sending application; therefore, the corresponding received datagrams are not delivered to the remote application.", + "ja": "注: UDP を使用すると、上位層プロトコルでペイロード データの有無にかかわらず (UDP オプションの有無にかかわらず) データグラムを送信できます。これらは、ネットワークを介してリモートの上位層に配信されます。DPLPMTUD が UDP トランスポート サービス内に実装されている場合、REQ または RES UDP オプションを含むプローブ パケットは、UDP ペイロードなしで送信できます。この場合、これらのプローブ パケットは送信アプリケーションによって生成されたものではありません。したがって、対応する受信データグラムはリモート アプリケーションに配信されません。" + }, + { + "indent": 3, + "text": "When DPLPMTUD is instead implemented by an Upper Layer protocol, the format and content of probe packets are determined by the Upper Layer protocol. This design is also permitted to use the REQ and RES Options provided by UDP Options.", + "ja": "代わりに DPLPMTUD が上位層プロトコルによって実装される場合、プローブ パケットの形式と内容は上位層プロトコルによって決定されます。このデザインでは、UDP オプションによって提供される REQ および RES オプションの使用も許可されます。" + }, + { + "indent": 3, + "text": "If DPLPMTUD is active at more than one layer, then the values of the tokens used in REQ Options need to be coordinated with any values used for other DPLPMTUD probe packets to ensure that each probe packet can be identified by a unique token. When configurable, a configuration ought to avoid performing such discovery both within UDP Options and also by an Upper Layer protocol that sends and receives probe packets via UDP Options. Section 6.1 of [RFC8899] recommends that: \"An application SHOULD avoid using DPLPMTUD when the underlying transport system provides this capability.\"", + "ja": "DPLPMTUD が複数のレイヤーでアクティブである場合、REQ オプションで使用されるトークンの値は、他の DPLPMTUD プローブ パケットに使用される値と調整して、各プローブ パケットが一意のトークンで識別できるようにする必要があります。構成可能な場合、構成では、UDP オプション内で、また UDP オプションを介してプローブ パケットを送受信する上位層プロトコルによっても、そのような検出を実行することを回避する必要があります。[RFC8899] のセクション 6.1 では、「基盤となるトランスポート システムがこの機能を提供する場合、アプリケーションは DPLPMTUD の使用を避けるべきです (SHOULD)」と推奨しています。" + }, + { + "indent": 0, + "text": "3.1. Packet Formats", + "section_title": true, + "ja": "3.1. パケットフォーマット" + }, + { + "indent": 3, + "text": "The UDP Options used in this document are described in [RFC9868] and are used in the following ways:", + "ja": "この文書で使用される UDP オプションは [RFC9868] で説明されており、次の方法で使用されます。" + }, + { + "indent": 6, + "text": "* The REQ Option is set by a sending PL to solicit a response from a remote receiver. A four-byte (four-octet) token identifies each request.", + "ja": "* REQ オプションは、リモート受信者からの応答を要求するために送信側 PL によって設定されます。4 バイト (4 オクテット) のトークンが各リクエストを識別します。" + }, + { + "indent": 6, + "text": "* A sending PL can use the EOL Option together with a minimum datagram length to pad probe packets.", + "ja": "* 送信側 PL は、EOL オプションを最小データグラム長とともに使用して、プローブ パケットをパディングできます。" + }, + { + "indent": 6, + "text": "* The RES Option is sent by a UDP Options receiver in response to a previously received REQ Option. Each RES Option echoes the last received four-byte token.", + "ja": "* RES オプションは、以前に受信した REQ オプションに応答して UDP オプション受信機によって送信されます。各 RES オプションは、最後に受信した 4 バイトのトークンをエコーします。" + }, + { + "indent": 6, + "text": "* If a UDP Options endpoint creates and sends a datagram with a RES Option solely as response to a received REQ Option, the responder MUST limit the rate of these responses (e.g., limiting each pair of ports to send 1 per measured RTT or 1 per second). This rate limit is to mitigate the DoS vector without significantly impacting the operation of DPLPMTUD. An example in Section 6 describes a case where this might be used.", + "ja": "* UDP オプションのエンドポイントが、受信した REQ オプションへの応答としてのみ RES オプションを含むデータグラムを作成して送信する場合、応答側はこれらの応答のレートを制限しなければなりません (たとえば、ポートの各ペアが測定された RTT ごとに 1 つ、または 1 秒あたり 1 つ送信するように制限する)。このレート制限は、DPLPMTUD の動作に大きな影響を与えることなく、DoS ベクトルを軽減することを目的としています。セクション 6 の例では、これが使用されるケースについて説明します。" + }, + { + "indent": 6, + "text": "* Reception of a RES Option by the REQ sender confirms that a specific probe packet has been received by the remote UDP Options receiver.", + "ja": "* REQ 送信者による RES オプションの受信により、特定のプローブ パケットがリモート UDP オプション受信者によって受信されたことが確認されます。" + }, + { + "indent": 3, + "text": "The token allows a UDP Options sender to distinguish between acknowledgements for initial probe packets and acknowledgements confirming receipt of subsequent probe packets (e.g., travelling along alternate paths with a larger RTT). Each probe packet MUST be uniquely identifiable by the UDP Options sender within the Maximum Segment Lifetime (MSL) [RFC8085]. The UDP Options sender MUST NOT reuse a token value within the MSL. A four-byte value for the token field provides sufficient space for multiple unique probe packets to be made within the MSL. Since UDP Options operates over UDP, the token values only need to be unique for the specific 5-tuple over which it is operating.", + "ja": "このトークンにより、UDP オプションの送信者は、最初のプローブ パケットに対する確認応答と、後続のプローブ パケットの受信を確認する確認応答 (たとえば、より大きな RTT で代替パスに沿って移動する) を区別できるようになります。各プローブ パケットは、最大セグメント ライフタイム (MSL) [RFC8085] 内で UDP オプション送信者によって一意に識別可能でなければなりません (MUST)。UDP オプションの送信者は、MSL 内のトークン値を再利用してはなりません (MUST NOT)。トークン フィールドの 4 バイト値は、MSL 内で作成される複数の一意のプローブ パケットに十分なスペースを提供します。UDP オプションは UDP 上で動作するため、トークン値は、動作している特定の 5 タプルに対して一意である必要があるだけです。" + }, + { + "indent": 3, + "text": "The value of the four-byte token field SHOULD be initialized to a randomized value to enhance protection from off-path attacks, as described in Section 5.1 of [RFC8085].", + "ja": "[RFC8085]のセクション5.1で説明されているように、オフパス攻撃からの保護を強化するために、4バイトのトークンフィールドの値はランダム化された値に初期化されるべきです(SHOULD)。" + }, + { + "indent": 0, + "text": "3.2. Sending Probe Packets with the Request Option", + "section_title": true, + "ja": "3.2. リクエスト オプションを使用したプローブ パケットの送信" + }, + { + "indent": 3, + "text": "DPLPMTUD relies upon sending a probe packet with a specific size. Each probe packet includes the UDP Options area containing a REQ Option and any other required options concluded with an EOL Option (Section 11.1 of [RFC9868]), followed by any padding needed to inflate to the required probe size.", + "ja": "DPLPMTUD は、特定のサイズのプローブ パケットの送信に依存します。各プローブ パケットには、REQ オプションと、EOL オプション ([RFC9868] のセクション 11.1) で終了するその他の必要なオプションを含む UDP オプション領域が含まれており、その後に必要なプローブ サイズに拡張するために必要なパディングが続きます。" + }, + { + "indent": 3, + "text": "A probe packet can therefore be up to the maximum size supported by the local interface (i.e., the Interface MTU). Item 2 in Section 3 of [RFC8899] requires the network interface below DPLPMTUD to provide a way to transmit a probe packet that is larger than the current PLPMTU. The size of this probe packet MUST NOT be constrained by the maximum PMTU set by network layer mechanisms (such as discovered by PMTUD [RFC1191][RFC8201] or the PMTU size held in the IP-layer cache), as noted in item 2 in Section 3 of [RFC8899]).", + "ja": "したがって、プローブ パケットは、ローカル インターフェイスでサポートされる最大サイズ (つまり、インターフェイス MTU) にすることができます。[RFC8899] のセクション 3 の項目 2 では、現在の PLPMTU より大きいプローブ パケットを送信する方法を提供するために、DPLPMTUD の下のネットワーク インターフェイスが必要です。このプローブパケットのサイズは、ネットワーク層メカニズムによって設定された最大 PMTU ([RFC8899] のセクション 3 の項目 2 に記載されているように、PMTUD [RFC1191][RFC8201] によって発見されたものや IP 層キャッシュに保持されている PMTU サイズなど) によって制限されてはなりません (MUST NOT)。" + }, + { + "indent": 3, + "text": "UDP datagrams used as DPLPMTUD probe packets, as described in this document, MUST NOT be fragmented at the UDP or IP layer. Therefore, Section 3 of [RFC8899] requires: \"In IPv4, a probe packet MUST be sent with the Don't Fragment (DF) bit set in the IP header and without network layer endpoint fragmentation.\"", + "ja": "この文書で説明されているように、DPLPMTUD プローブ パケットとして使用される UDP データグラムは、UDP 層または IP 層で断片化してはなりません (MUST NOT)。したがって、[RFC8899] のセクション 3 では、「IPv4 では、プローブ パケットは、IP ヘッダーに Don't Fragment (DF) ビットを設定して、ネットワーク層のエンドポイント フラグメンテーションを行わずに送信しなければなりません (MUST)」と規定しています。" + }, + { + "indent": 0, + "text": "3.3. Receiving UDP Options Probe Packets and Sending the RES Option", + "section_title": true, + "ja": "3.3. UDP オプション プローブ パケットの受信と RES オプションの送信" + }, + { + "indent": 3, + "text": "When DPLPMTUD is enabled, a UDP Options receiver responds by sending a UDP datagram with the RES Option when it receives a UDP Options datagram with the REQ Option.", + "ja": "DPLPMTUD が有効な場合、UDP オプション受信側は、REQ オプション付きの UDP オプション データグラムを受信すると、RES オプション付きの UDP データグラムを送信して応答します。" + }, + { + "indent": 3, + "text": "The operation of DPLPMTUD can depend on the support at the remote UDP Options endpoint, the way in which DPLPMTUD is implemented, and in some cases, the application data that is exchanged over the UDP transport service. When UDP Options is not supported by the remote receiver, DPLPMTUD will be unable to confirm the path or to discover the PLPMTU. This will result in the minimum configured PLPMTU (MIN_PLPMTU). More explanation of usage is provided in Section 6.", + "ja": "DPLPMTUD の動作は、リモート UDP オプション エンドポイントでのサポート、DPLPMTUD の実装方法、および場合によっては UDP トランスポート サービス経由で交換されるアプリケーション データに依存します。UDP オプションがリモート受信側でサポートされていない場合、DPLPMTUD はパスを確認したり、PLPMTU を検出したりできません。これにより、最小構成 PLPMTU (MIN_PLPMTU) が得られます。使用法の詳細についてはセクション 6 で説明します。" + }, + { + "indent": 12, + "text": "Note: A receiver that only responds when there is a datagram queued for transmission by the Upper Layer could potentially receive multiple datagrams with a REQ Option before it can respond. When sent, the RES Option will only acknowledge the latest received token value. A sender would then conclude that any earlier REQ Options were not successfully received. However, DPLPMTUD does not usually result in sending more than one probe packet per timeout interval, and a delay in responding will already have been treated as a failed probe attempt. Therefore, this does not significantly impact performance, although a more prompt response would have resulted in DPLPMTUD recording reception of all probe packets.", + "ja": "注: 上位層による送信のためにキューに入れられたデータグラムがある場合にのみ応答する受信機は、応答する前に REQ オプションを使用して複数のデータグラムを受信する可能性があります。送信時に、RES オプションは最後に受信したトークン値のみを確認します。その後、送信者は、以前の REQ オプションは正常に受信されなかったと結論付けます。ただし、DPLPMTUD では通常、タイムアウト間隔ごとに複数のプローブ パケットが送信されることはなく、応答の遅延はすでにプローブ試行の失敗として扱われています。したがって、これはパフォーマンスに大きな影響を与えませんが、より迅速な応答により、DPLPMTUD はすべてのプローブ パケットの受信を記録することになります。" + }, + { + "indent": 0, + "text": "4. DPLPMTUD Sender Procedures for UDP Options", + "section_title": true, + "ja": "4. UDP オプションの DPLPMTUD 送信者手順" + }, + { + "indent": 3, + "text": "DPLPMTUD utilizes three types of probe. These are described in the following sections:", + "ja": "DPLPMTUD は 3 種類のプローブを利用します。これらについては、次のセクションで説明します。" + }, + { + "indent": 6, + "text": "* Probes to confirm the path can support the BASE_PLPMTU (Section 5.1.4 of [RFC8899]).", + "ja": "* パスが BASE_PLPMTU をサポートできることを確認するためのプローブ ([RFC8899] のセクション 5.1.4)。" + }, + { + "indent": 6, + "text": "* Probes to detect whether the path can support a larger PLPMTU.", + "ja": "* パスがより大きな PLPMTU をサポートできるかどうかを検出するためのプローブ。" + }, + { + "indent": 6, + "text": "* Probes to validate that the path supports the current PLPMTU.", + "ja": "* パスが現在の PLPMTU をサポートしていることを検証するためのプローブ。" + }, + { + "indent": 0, + "text": "4.1. Confirmation of Connectivity Across a Path", + "section_title": true, + "ja": "4.1. パス間の接続の確認" + }, + { + "indent": 3, + "text": "The DPLPMTUD method requires a PL to confirm connectivity over the path (Section 5.1.4 of [RFC8899]), but UDP itself does not offer a mechanism for this.", + "ja": "DPLPMTUD メソッドでは、PL がパス上の接続を確認する必要があります ([RFC8899] のセクション 5.1.4) が、UDP 自体はこれのためのメカニズムを提供しません。" + }, + { + "indent": 3, + "text": "UDP Options can provide this required functionality. A UDP Options sender implementing this specification MUST elicit a positive confirmation of connectivity for the path by sending a probe packet padded to size BASE_PLPMTU. This confirmation probe MUST include the REQ UDP Option to elicit a response from the remote DPLPMTUD. Reception of a datagram with the corresponding RES Option confirms the reception of a packet of the probed size that has successfully traversed the path to the receiver. This also confirms that the remote endpoint supports the RES Option.", + "ja": "UDP オプションは、この必要な機能を提供できます。この仕様を実装する UDP オプション送信者は、サイズ BASE_PLPMTU にパディングされたプローブ パケットを送信することによって、パスの接続性の肯定的な確認を引き出しなければなりません (MUST)。この確認プローブには、リモート DPLPMTUD からの応答を引き出すための REQ UDP オプションが含まれなければなりません (MUST)。対応する RES オプションを使用してデータグラムを受信すると、受信者へのパスを正常に通過した、調査されたサイズのパケットの受信が確認されます。これにより、リモート エンドポイントが RES オプションをサポートしていることも確認されます。" + }, + { + "indent": 0, + "text": "4.2. Sending Probe Packets to Increase the PLPMTU", + "section_title": true, + "ja": "4.2. PLPMTU を増やすためのプローブ パケットの送信" + }, + { + "indent": 3, + "text": "From time to time, DPLPMTUD enters the SEARCHING state, described in Section 5.2 of [RFC8899], (e.g., after expiry of the PMTU_RAISE_TIMER) to detect whether the current path can support a larger PLPMTU. When the remote endpoint advertises a UDP Maximum Datagram Size (MDS) Option (see Section 11.5 of [RFC9868]), this value MAY be used as a hint to initialize this search to increase the PLPMTU.", + "ja": "時折、DPLPMTUD は [RFC8899] のセクション 5.2 で説明されている SEARCHING 状態に入り (例: PMTU_RAISE_TIMER の期限切れ後)、現在のパスがより大きな PLPMTU をサポートできるかどうかを検出します。リモートエンドポイントが UDP 最大データグラムサイズ (MDS) オプション ([RFC9868] のセクション 11.5 を参照) をアドバタイズする場合、この値は、PLPMTU を増やすためにこの検索を初期化するためのヒントとして使用されてもよい(MAY)。" + }, + { + "indent": 3, + "text": "Probe packets seeking to increase the PLPMTU SHOULD NOT carry application data (see \"Probing using padding data\" in Section 4.1 of [RFC8899]), since they will be lost whenever their size exceeds the actual PMTU. [RFC8899] requires a probe packet to elicit a positive acknowledgement that the path has delivered a datagram of the specific probed size; therefore, a probe packet MUST include the REQ Option when using transport options for UDP [RFC9868].", + "ja": "PLPMTU を増加しようとするプローブ パケットは、サイズが実際の PMTU を超えるたびに失われるため、アプリケーション データを伝送すべきではありません ([RFC8899] のセクション 4.1 の「パディング データを使用したプローブ」を参照)。[RFC8899] では、パスが特定のプローブされたサイズのデータグラムを配信したという肯定的な確認応答を引き出すためにプローブ パケットを要求しています。したがって、UDP [RFC9868] のトランスポート オプションを使用する場合、プローブ パケットには REQ オプションが含まれなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "At the receiver, a received probe packet that does not carry application data does not form a part of the end-to-end transport data and is not delivered to the Upper Layer protocol (i.e., application or protocol layered above UDP). A zero-length payload notification could still be delivered to the application (see Section 5 of [RFC8085]), although Section 18 of [RFC9868] discusses the implications when using UDP Options.", + "ja": "受信側では、アプリケーション データを伝送しない受信プローブ パケットは、エンドツーエンドのトランスポート データの一部を形成せず、上位層プロトコル (つまり、UDP の上層にあるアプリケーションまたはプロトコル) に配信されません。[RFC9868] のセクション 18 では、UDP オプションを使用する場合の影響について説明していますが、長さゼロのペイロード通知は依然としてアプリケーションに配信される可能性があります ([RFC8085] のセクション 5 を参照)。" + }, + { + "indent": 0, + "text": "4.3. Validating the Path with UDP Options", + "section_title": true, + "ja": "4.3. UDP オプションを使用したパスの検証" + }, + { + "indent": 3, + "text": "A PL using DPLPMTUD MUST validate that a path continues to support the PLPMTU discovered in a previous search for a suitable PLPMTU value, as defined in Section 6.1.4 of [RFC8899]. This validation sends probe packets in the DPLPMTUD SEARCH_COMPLETE state (Section 5.2 of [RFC8899]) to detect black-holing of data (Section 4.3 of [RFC8899] defines a DPLPMTUD black hole).", + "ja": "DPLPMTUD を使用する PL は、[RFC8899] のセクション 6.1.4 で定義されているように、適切な PLPMTU 値の以前の検索で発見された PLPMTU をパスが引き続きサポートしていることを検証しなければなりません (MUST)。この検証は、データのブラックホールを検出するために DPLPMTUD SEARCH_COMPLETE 状態 ([RFC8899] のセクション 5.2) でプローブ パケットを送信します ([RFC8899] のセクション 4.3 は DPLPMTUD ブラック ホールを定義しています)。" + }, + { + "indent": 3, + "text": "Path validation can be implemented within UDP Options by generating a probe packet of size PLPMTU, which MUST include a REQ Option to elicit a positive confirmation that the path has delivered this probe packet. A probe packet used to validate the path MAY use either \"Probing using padding data\" to construct a probe packet that does not carry any application data or \"Probing using application data and padding data\"; see Section 4.1 of [RFC8899]. When using \"Probing using padding data\", the UDP Options API does not indicate receipt of the zero-length probe packet (see Section 6 of [RFC9868]).", + "ja": "パス検証は、サイズ PLPMTU のプローブ パケットを生成することで UDP オプション内で実装できます。これには、パスがこのプローブ パケットを配信したという肯定的な確認を引き出すための REQ オプションが含まれなければなりません。パスの検証に使用されるプローブ パケットは、アプリケーション データを運ばないプローブ パケットを構築するために「パディング データを使用したプローブ」、または「アプリケーション データとパディング データを使用したプローブ」のいずれかを使用してもよい(MAY)。[RFC8899] のセクション 4.1 を参照してください。「パディングデータを使用したプローブ」を使用する場合、UDP オプション API は長さゼロのプローブパケットの受信を示しません ([RFC9868] のセクション 6 を参照)。" + }, + { + "indent": 0, + "text": "4.4. Probe Packets That Do Not Include Application Data", + "section_title": true, + "ja": "4.4. アプリケーション データを含まないパケットの調査" + }, + { + "indent": 3, + "text": "A simple implementation of the method might be designed to only use probe packets in a UDP datagram that includes no application data. The size of each probe packet is padded to the required probe size including the REQ Option. This implements \"Probing using padding data\" (Section 4.1 of [RFC8899]) and avoids having to retransmit application data when a probe fails. This could be achieved by setting a minimum datagram length, such that the options list ends in EOL (Section 11.1 of [RFC9868]) with any additional space zero-filled as needed (see Section 15 of [RFC9868]). In this use, the probe packets do not form a part of the end-to-end transport data and a receiver does not deliver them to the Upper Layer protocol.", + "ja": "このメソッドの単純な実装は、アプリケーション データを含まない UDP データグラム内のプローブ パケットのみを使用するように設計される場合があります。各プローブ パケットのサイズは、REQ オプションを含む必要なプローブ サイズにパディングされます。これにより、「パディング データを使用したプローブ」([RFC8899] のセクション 4.1) が実装され、プローブが失敗した場合にアプリケーション データを再送信する必要がなくなります。これは、オプションリストが EOL ([RFC9868] のセクション 11.1) で終了し、必要に応じて追加のスペースにゼロが埋められるように、データグラムの最小長を設定することで実現できます ([RFC9868] のセクション 15 を参照)。この使用法では、プローブ パケットはエンドツーエンドのトランスポート データの一部を形成せず、受信機はそれらを上位層プロトコルに配信しません。" + }, + { + "indent": 0, + "text": "4.5. Probe Packets That Include Application Data", + "section_title": true, + "ja": "4.5. アプリケーション データを含むパケットの調査" + }, + { + "indent": 3, + "text": "An implementation always uses the format in Section 4.4 when DPLPMTUD searches to increase the PLPMTU.", + "ja": "DPLPMTUD が PLPMTU を増やすために検索する場合、実装では常にセクション 4.4 の形式が使用されます。" + }, + { + "indent": 3, + "text": "An alternative format is permitted for a probe packet that is used to confirm the connectivity or to validate the path. These probe packets MAY carry application data. (UDP payload data is permitted because these probe packets perform black-hole detection and will therefore usually have a higher probability of successful transmission, similar to other packets sent by the Upper Layer protocol.) Section 4.1 of [RFC8899] provides a discussion of the merits and demerits of including application data. For example, this reduces the need to send additional datagrams.", + "ja": "接続性の確認またはパスの検証に使用されるプローブ パケットには、代替フォーマットが許可されています。これらのプローブ パケットはアプリケーション データを伝送してもよい(MAY)。(UDP ペイロード データが許可されるのは、これらのプローブ パケットがブラック ホール検出を実行するため、通常、上位層プロトコルによって送信される他のパケットと同様に、送信が成功する確率が高くなります。) [RFC8899] のセクション 4.1 では、アプリケーション データを含めることの長所と短所について説明しています。たとえば、これにより追加のデータグラムを送信する必要性が減ります。" + }, + { + "indent": 3, + "text": "This type of probe packet MAY use a control message format defined by the Upper Layer protocol, provided that the message does not need to be delivered reliably. The REQ Option MUST be included when the sending Upper Layer protocol performs DPLPMTUD. The DPLPMTUD method tracks the transmission of probe packets (using the REQ Option token).", + "ja": "このタイプのプローブ パケットは、メッセージを確実に配信する必要がない場合、上位層プロトコルで定義された制御メッセージ フォーマットを使用してもよい(MAY)。REQ オプションは、送信側上位層プロトコルが DPLPMTUD を実行するときに含める必要があります。DPLPMTUD メソッドは、(REQ オプション トークンを使用して) プローブ パケットの送信を追跡します。" + }, + { + "indent": 3, + "text": "A receiver that responds to DPLPMTUD MUST process the REQ Option and include the corresponding RES Option with an Upper Layer protocol message that it returns to the requester (examples of receiver processing are provided in Section 6).", + "ja": "DPLPMTUD に応答する受信者は、REQ オプションを処理し、要求者に返す上位層プロトコル メッセージに対応する RES オプションを含めなければなりません (受信者の処理の例はセクション 6 で提供されます)。" + }, + { + "indent": 3, + "text": "Probe packets that use this format form a part of the end-to-end transport data and can be used to manage the PLPMTU in just one direction or can be used for both directions.", + "ja": "この形式を使用するプローブ パケットは、エンドツーエンドのトランスポート データの一部を形成し、一方向のみで PLPMTU を管理するために使用することも、両方向に使用することもできます。" + }, + { + "indent": 0, + "text": "5. Receiving Events from the Network", + "section_title": true, + "ja": "5. ネットワークからのイベントの受信" + }, + { + "indent": 3, + "text": "This specification does not rely upon reception of events from the network, but an implementation can utilize these events when they are provided.", + "ja": "この仕様はネットワークからのイベントの受信には依存しませんが、実装ではこれらのイベントが提供されたときにそれを利用できます。" + }, + { + "indent": 0, + "text": "5.1. Changes in the Path", + "section_title": true, + "ja": "5.1. パスの変更" + }, + { + "indent": 3, + "text": "A change in the path or the loss of a probe packet can result in DPLPMTUD updating the PLPMTU. DPLPMTUD [RFC8899] recommends that methods are robust to path changes that could have occurred since the path characteristics were last confirmed and to the possibility of inconsistent path information being received. For example, a notification that a path has changed could trigger path validation to provide black-hole protection (Section 4.3 of [RFC8899]).", + "ja": "パスの変更またはプローブ パケットの損失により、DPLPMTUD が PLPMTU を更新する可能性があります。DPLPMTUD [RFC8899] は、パス特性が最後に確認されてから発生した可能性のあるパス変更や、受信される一貫性のないパス情報の可能性に対して、方法が堅牢であることを推奨しています。たとえば、パスが変更されたという通知は、ブラックホール保護を提供するためにパスの検証をトリガーできます ([RFC8899] のセクション 4.3)。" + }, + { + "indent": 3, + "text": "An Upper Layer protocol could trigger DPLPMTUD to validate the path when it observes a high packet loss rate (or a repeated protocol timeout) [RFC8899].", + "ja": "上位層プロトコルは、高いパケット損失率 (またはプロトコル タイムアウトの繰り返し) [RFC8899] を観察した場合に、DPLPMTUD をトリガーしてパスを検証する可能性があります。" + }, + { + "indent": 3, + "text": "Section 3 of [RFC8899] requires any methods designed to share the PLPMTU between PLs (such as updating the IP cache PMTU for an interface/destination) to be robust to the wide variety of underlying network forwarding behaviors. For example, an implementation could avoid sharing PMTU information that could potentially relate to packets sent with the same address over a different interface.", + "ja": "[RFC8899] のセクション 3 では、基盤となるさまざまなネットワーク転送動作に対して堅牢であるために、PL 間で PLPMTU を共有するように設計された方法 (インターフェイス/宛先の IP キャッシュ PMTU の更新など) を要求しています。たとえば、実装では、異なるインターフェイスを介して同じアドレスで送信されたパケットに関連する可能性がある PMTU 情報の共有を回避できます。" + }, + { + "indent": 0, + "text": "5.2. Validation of PTB Messages", + "section_title": true, + "ja": "5.2. PTB メッセージの検証" + }, + { + "indent": 3, + "text": "Support for receiving ICMP PTB messages is OPTIONAL for DPLPMTUD. A UDP Options sender can therefore ignore received ICMP PTB messages.", + "ja": "ICMP PTB メッセージの受信のサポートは、DPLPMTUD ではオプションです。したがって、UDP オプションの送信者は、受信した ICMP PTB メッセージを無視できます。" + }, + { + "indent": 3, + "text": "Before processing an ICMP PTB message, the DPLPMTUD method needs to perform two checks to ensure that the message was received in response to a sent probe packet:", + "ja": "ICMP PTB メッセージを処理する前に、DPLPMTUD メソッドは 2 つのチェックを実行して、送信されたプローブ パケットに対する応答としてメッセージが受信されたことを確認する必要があります。" + }, + { + "indent": 6, + "text": "* DPLPMTUD first utilizes the quoted information in each PTB message. The receiver MUST validate the protocol information in the quoted packet carried in an ICMP PTB message payload to validate the message originated from the sending node (see Section 4.6.1 of [RFC8899]).", + "ja": "* DPLPMTUD は、まず各 PTB メッセージ内で引用された情報を利用します。受信者は、送信ノードから発信されたメッセージを検証するために、ICMP PTB メッセージ ペイロードで運ばれる引用パケット内のプロトコル情報を検証しなければなりません ([RFC8899] のセクション 4.6.1 を参照)。" + }, + { + "indent": 6, + "text": "* The receiver SHOULD utilize information that is not simple for an off-path attacker to determine (see Section 4.6.1 of [RFC8899]). Specifically, a UDP Options receiver SHOULD confirm that the token contained in the UDP REQ Option of the quoted packet has a value that corresponds to a probe packet that was recently sent by the current endpoint.", + "ja": "* 受信者は、オフパス攻撃者にとって判断が容易ではない情報を利用すべきである(SHOULD)([RFC8899]のセクション4.6.1を参照)。具体的には、UDP オプション受信者は、引用されたパケットの UDP REQ オプションに含まれるトークンが、現在のエンドポイントによって最近送信されたプローブ パケットに対応する値を持つことを確認する必要があります (SHOULD)。" + }, + { + "indent": 3, + "text": "An implementation unable to support this validation MUST ignore received ICMP PTB messages.", + "ja": "この検証をサポートできない実装は、受信した ICMP PTB メッセージを無視しなければなりません (MUST)。" + }, + { + "indent": 0, + "text": "6. Examples with Different Receiver Behaviors", + "section_title": true, + "ja": "6. さまざまな受信機の動作の例" + }, + { + "indent": 3, + "text": "When enabled, a DPLPMTUD endpoint that implements UDP Options normally responds with a UDP datagram with a RES Option when requested by a sender.", + "ja": "有効にすると、UDP オプションを実装する DPLPMTUD エンドポイントは、通常、送信者から要求されたときに、RES オプションを含む UDP データグラムで応答します。" + }, + { + "indent": 3, + "text": "The following examples describe various possible receiver behaviors:", + "ja": "次の例は、考えられるさまざまな受信機の動作を説明しています。" + }, + { + "indent": 6, + "text": "* No DPLPMTUD receiver support: One case is when a sender supports this specification, but no RES Option is received from the remote endpoint. In this example, the method is unable to discover the PLPMTU. This will result in using the MIN_PLPMTU. Such a remote endpoint might be not configured to process UDP Options or might not return a datagram with a RES Option for some other reason (e.g., packet loss, insufficient space to include the option, filtering on the path, etc.).", + "ja": "* DPLPMTUD 受信側サポートなし: 1 つのケースは、送信側がこの仕様をサポートしているが、リモート エンドポイントから RES オプションを受信しない場合です。この例では、メソッドは PLPMTU を検出できません。これにより、MIN_PLPMTU が使用されます。このようなリモート エンドポイントは、UDP オプションを処理するように構成されていない可能性や、他の理由 (例: パケット損失、オプションを含めるスペースの不足、パス上のフィルタリングなど) により RES オプションを含むデータグラムを返さない可能性があります。" + }, + { + "indent": 6, + "text": "* DPLPMTUD receiver uses application datagrams: In a second case, both the sender and receiver support DPLPMTUD using the specification, and the receiver only returns a RES Option with the next UDP datagram that is sent to the requester. Therefore, reception of a REQ Option does not systematically trigger a response. This allows DPLPMTUD to operate when there is a flow of datagrams in both directions, provided there is periodic feedback (e.g., one acknowledgement packet per RTT). It requires the PLPMTU at the receiver to be sufficiently large enough that the RES Option can be included in the feedback packets that are sent in the return direction. This method avoids opportunities to misuse the method as a DoS attack. However, when there is a low rate of transmission (or no datagrams are sent) in the return direction, this will prevent prompt delivery of the RES Option. At the DPLPMTUD sender, this results in probe packets failing to be acknowledged in time and could result in a smaller PLPMTU than is actually supported by the path or in using the MIN_PLPMTU.", + "ja": "* DPLPMTUD 受信者はアプリケーション データグラムを使用します。2 番目のケースでは、送信者と受信者の両方が仕様を使用して DPLPMTUD をサポートし、受信者はリクエスターに送信される次の UDP データグラムとともに RES オプションのみを返します。したがって、REQ オプションの受信は体系的に応答をトリガーしません。これにより、定期的なフィードバック (例: RTT ごとに 1 つの確認パケット) がある場合、両方向のデータグラム フローがある場合に DPLPMTUD が動作できるようになります。戻り方向に送信されるフィードバック パケットに RES オプションを含めることができるように、受信側の PLPMTU が十分に大きいことが必要です。この方法により、この方法が DoS 攻撃として悪用される機会が回避されます。ただし、戻り方向の送信速度が低い (またはデータグラムが送信されない) 場合、RES オプションの迅速な配信が妨げられます。これにより、DPLPMTUD 送信側でプローブ パケットが時間内に確認応答されなくなり、パスまたは MIN_PLPMTU の使用で実際にサポートされるよりも PLPMTU が小さくなる可能性があります。" + }, + { + "indent": 6, + "text": "* Unidirectional transfer: Another case is where an application only transfers data in one direction (or predominantly in one direction). In this case, the wait at the receiver for a datagram to be queued before returning a RES Option could easily result in a probe timeout at the DPLPMTUD sender. In this case, DPLPMTUD could allow exchanging datagrams without a payload (as discussed in earlier sections) to return the RES Option.", + "ja": "* 単方向転送: アプリケーションがデータを一方向のみ (または主に一方向) に転送するもう 1 つのケースがあります。この場合、RES オプションを返す前にデータグラムがキューに入れられるまで受信側で待機すると、DPLPMTUD 送信側でプローブ タイムアウトが簡単に発生する可能性があります。この場合、DPLPMTUD により、(前のセクションで説明したように) ペイロードなしでデータグラムを交換して RES オプションを返すことができます。" + }, + { + "indent": 6, + "text": "* DPLPMTUD receiver permitted to send responses in UDP datagrams with no payload: A DPLPMTUD receiver can generate a datagram (e.g., with zero payload data) solely to return a RES Option (e.g., sent when no other datagrams are queued for transmission). This would allow an endpoint to probe the set of UDP ports that have been configured with support for this specification using a DPLPMTUD probe packet. Although this results in some additional traffic overhead, it has the advantage that it can ensure timely progress of DPLPMTUD. Section 3.1 specifies: \"If a UDP Options endpoint creates and sends a datagram with a RES Option solely as response to a received REQ Option, the responder MUST limit the rate of these responses (e.g., limiting each pair of ports to send 1 per measured RTT or 1 per second)\". This rate limit is to mitigate the DoS vector, without significantly impacting the operation of DPLPMTUD.", + "ja": "* DPLPMTUD 受信機は、ペイロードのない UDP データグラムで応答を送信することを許可されています: DPLPMTUD 受信機は、RES オプションを返すためだけにデータグラム (たとえば、ペイロード データがゼロ) を生成できます (たとえば、他のデータグラムが送信のためにキューに入れられていないときに送信されます)。これにより、エンドポイントは、DPLPMTUD プローブ パケットを使用して、この仕様をサポートするように構成された UDP ポートのセットをプローブできるようになります。これにより、追加のトラフィック オーバーヘッドが発生しますが、DPLPMTUD をタイムリーに進行させることができるという利点があります。セクション 3.1 では、「UDP オプションのエンドポイントが、受信した REQ オプションへの応答としてのみ RES オプションを含むデータグラムを作成して送信する場合、レスポンダーはこれらの応答のレートを制限しなければなりません (例: 測定された RTT ごとに 1 つ、または 1 秒あたり 1 つ送信するようにポートの各ペアを制限する)」と規定されています。このレート制限は、DPLPMTUD の動作に大きな影響を与えることなく、DoS ベクトルを軽減することを目的としています。" + }, + { + "indent": 0, + "text": "7. IANA Considerations", + "section_title": true, + "ja": "7. IANAの考慮事項" + }, + { + "indent": 3, + "text": "This document has no IANA actions.", + "ja": "この文書には IANA のアクションはありません。" + }, + { + "indent": 0, + "text": "8. Security Considerations", + "section_title": true, + "ja": "8. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "The security considerations for using UDP Options are described in [RFC9868]. The method does not change the integrity protection offered by the UDP Options method.", + "ja": "UDP オプションを使用する場合のセキュリティに関する考慮事項は、[RFC9868] で説明されています。このメソッドは、UDP オプション メソッドによって提供される整合性保護を変更しません。" + }, + { + "indent": 3, + "text": "The security considerations for using DPLPMTUD are described in [RFC8899]. On-path attackers could maliciously drop or modify probe packets to seek to decrease the PMTU or to maliciously modify probe packets in an attempt to black-hole traffic.", + "ja": "DPLPMTUD を使用する場合のセキュリティに関する考慮事項は [RFC8899] で説明されています。パス上の攻撃者は、PMTU を減少させようとしてプローブ パケットを悪意を持ってドロップまたは変更したり、トラフィックをブラックホール化するためにプローブ パケットを悪意を持って変更したりする可能性があります。" + }, + { + "indent": 3, + "text": "The specification recommends that the token value in the REQ Option is initialized to a randomized value. This is to enhance protection from off-path attacks. If a subsequent probe packet uses a token value that is easily derived from the initial value (e.g., incrementing the value), a misbehaving on-path observer could then determine the token values used for subsequent probe packets from that sender, even if these probe packets are not transiting via the observer. This would allow probe packets to be forged, with an impact similar to other on-path attacks against probe packets. This attack could be mitigated by using an unpredictable token value for each probe packet.", + "ja": "仕様では、REQ オプションのトークン値をランダムな値に初期化することが推奨されています。これは、オフパス攻撃からの保護を強化するためです。後続のプローブ パケットが初期値から容易に導出されるトークン値を使用する場合 (値をインクリメントするなど)、不正な動作を行うオンパス オブザーバーは、たとえこれらのプローブ パケットがオブザーバーを経由していない場合でも、その送信者からの後続のプローブ パケットに使用されるトークン値を決定する可能性があります。これにより、プローブ パケットが偽造される可能性があり、プローブ パケットに対する他のパス上の攻撃と同様の影響が生じます。この攻撃は、各プローブ パケットに予測不可能なトークン値を使用することで軽減できる可能性があります。" + }, + { + "indent": 3, + "text": "The method does not change the ICMP PTB message validation method described by DPLPMTUD: A UDP Options sender that utilizes ICMP PTB messages received to a probe packet MUST use the quoted packet to validate the UDP port information in combination with the token contained in the UDP Option before processing the packet using the DPLPMTUD method.", + "ja": "このメソッドは、DPLPMTUD で説明されている ICMP PTB メッセージ検証メソッドを変更しません。プローブ パケットに対して受信した ICMP PTB メッセージを利用する UDP オプション送信者は、DPLPMTUD メソッドを使用してパケットを処理する前に、引用符付きパケットを使用して、UDP オプションに含まれるトークンと組み合わせて UDP ポート情報を検証しなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "Upper Layer protocols or applications that employ encryption ought to perform DPLPMTUD at a layer above UDP Options and not enable UDP Options support for DPLPMTUD. This allows the application to control when DPLPMTUD is used to control the additional traffic that this generates. This also ensures that DPLPMTUD probe packets are encrypted.", + "ja": "暗号化を使用する上位層のプロトコルまたはアプリケーションは、UDP オプションより上の層で DPLPMTUD を実行する必要があり、DPLPMTUD に対する UDP オプションのサポートを有効にしないでください。これにより、アプリケーションは、生成される追加トラフィックを制御するために DPLPMTUD を使用するタイミングを制御できるようになります。これにより、DPLPMTUD プローブ パケットが確実に暗号化されます。" + }, + { + "indent": 0, + "text": "9. References", + "section_title": true, + "ja": "9. 参考文献" + }, + { + "indent": 0, + "text": "9.1. Normative References", + "section_title": true, + "ja": "9.1. 引用文献" + }, + { + "indent": 3, + "text": "[RFC0768] Postel, J., \"User Datagram Protocol\", STD 6, RFC 768,\n DOI 10.17487/RFC0768, August 1980,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.\n Völker, \"Packetization Layer Path MTU Discovery for\n Datagram Transports\", RFC 8899, DOI 10.17487/RFC8899,\n September 2020, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9868] Touch, J. and C. Heard, Ed., \"Transport Options for UDP\",\n RFC 9868, DOI 10.17487/RFC9868, October 2025,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "9.2. Informative References", + "section_title": true, + "ja": "9.2. 参考引用" + }, + { + "indent": 3, + "text": "[RFC1191] Mogul, J. and S. Deering, \"Path MTU discovery\", RFC 1191,\n DOI 10.17487/RFC1191, November 1990,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4821] Mathis, M. and J. Heffner, \"Packetization Layer Path MTU\n Discovery\", RFC 4821, DOI 10.17487/RFC4821, March 2007,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, \"UDP Usage\n Guidelines\", BCP 145, RFC 8085, DOI 10.17487/RFC8085,\n March 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,\n \"Path MTU Discovery for IP version 6\", STD 87, RFC 8201,\n DOI 10.17487/RFC8201, July 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8304] Fairhurst, G. and T. Jones, \"Transport Features of the\n User Datagram Protocol (UDP) and Lightweight UDP (UDP-\n Lite)\", RFC 8304, DOI 10.17487/RFC8304, February 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Acknowledgements", + "section_title": true, + "ja": "謝辞" + }, + { + "indent": 3, + "text": "Gorry Fairhurst and Tom Jones are supported by funding provided by the University of Aberdeen. The authors would like to thank Magnus Westerlund and Mohamed Boucadair for their detailed comments and also other people who contributed to completing this document.", + "ja": "ゴリー・フェアハーストとトム・ジョーンズは、アバディーン大学から提供された資金によってサポートされています。著者らは、詳細なコメントを寄せてくれた Magnus Westerlund と Mohamed Boucadair、そしてこの文書の完成に貢献した他の人々に感謝の意を表します。" + }, + { + "indent": 0, + "text": "Authors' Addresses", + "section_title": true, + "ja": "著者の住所" + }, + { + "indent": 3, + "text": "Godred Fairhurst\nUniversity of Aberdeen\nSchool of Engineering\nFraser Noble Building\nAberdeen\nAB24 3UE\nUnited Kingdom\nEmail: gorry@erg.abdn.ac.uk", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Tom Jones\nUniversity of Aberdeen\nSchool of Engineering\nFraser Noble Building\nAberdeen\nAB24 3UE\nUnited Kingdom\nEmail: tom@erg.abdn.ac.uk", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9870-trans.json b/data/9000/rfc9870-trans.json new file mode 100644 index 000000000..7fe366c6c --- /dev/null +++ b/data/9000/rfc9870-trans.json @@ -0,0 +1,969 @@ +{ + "title": { + "text": "RFC 9870 - Export of UDP Options Information in IP Flow Information Export (IPFIX)", + "ja": "RFC 9870 - IP フロー情報エクスポート (IPFIX) での UDP オプション情報のエクスポート" + }, + "number": 9870, + "created_at": "2025-10-12 23:24:35.694915+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) M. Boucadair\nRequest for Comments: 9870 Orange\nCategory: Standards Track T. Reddy.K\nISSN: 2070-1721 Nokia\n October 2025", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Export of UDP Options Information in IP Flow Information Export (IPFIX)", + "section_title": true, + "ja": "IP フロー情報エクスポート (IPFIX) での UDP オプション情報のエクスポート" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP Options.", + "ja": "この文書では、UDP オプションの新しい IP フロー情報エクスポート (IPFIX) 情報要素を指定します。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This is an Internet Standards Track document.", + "ja": "これはインターネット標準化トラックの文書です。" + }, + { + "indent": 3, + "text": "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 Internet Standards is available in Section 2 of RFC 7841.", + "ja": "このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。" + }, + { + "indent": 3, + "text": "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/rfc9870.", + "ja": "この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9870 で入手できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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.", + "ja": "この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n2. Conventions and Definitions\n3. UDP Options at a Glance\n4. New UDP IPFIX Information Elements\n 4.1. udpSafeOptions\n 4.2. udpUnsafeOptions\n 4.3. udpExID\n 4.4. udpSafeExIDList\n 4.5. udpUnsafeExIDList\n5. Examples\n 5.1. Reduced-Size Encoding\n 5.2. SAFE Experimental Option\n 5.3. ExIDs and Reduced-Size Encoding\n6. Security Considerations\n7. IANA Considerations\n 7.1. IPFIX Information Elements\n8. References\n 8.1. Normative References\n 8.2. Informative References\nAcknowledgments\nAuthors' Addresses", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "IP Flow Information Export (IPFIX) [RFC7011] is a protocol that is widely deployed in networks for traffic management purposes (Section 2 of [RFC6632]). The protocol specifies the encoding of a set of basic data types and how the various Information Elements (IEs) are transmitted. In order to support the export of new Flow-related measurement data, new IEs can be defined and registered in a dedicated IANA registry [IANA-IPFIX] for interoperability.", + "ja": "IP フロー情報エクスポート (IPFIX) [RFC7011] は、トラフィック管理の目的でネットワークに広く導入されているプロトコルです ([RFC6632] のセクション 2)。このプロトコルは、一連の基本データ型のエンコーディングと、さまざまな情報要素 (IE) の送信方法を指定します。新しいフロー関連の測定データのエクスポートをサポートするために、新しい IE を定義し、相互運用性を確保する専用の IANA レジストリ [IANA-IPFIX] に登録できます。" + }, + { + "indent": 3, + "text": "This document specifies new IPFIX Information Elements for UDP Options (Section 4). A brief overview of UDP Options is provided in Section 3.", + "ja": "この文書では、UDP オプションの新しい IPFIX 情報要素を指定します (セクション 4)。UDP オプションの簡単な概要はセクション 3 で説明されています。" + }, + { + "indent": 3, + "text": "The IE specified in Section 4.1 uses the new abstract data type (\"unsigned256\") defined in [RFC9740].", + "ja": "セクション 4.1 で規定されている IE は、[RFC9740] で定義されている新しい抽象データ型 (\"unsigned256\") を使用します。" + }, + { + "indent": 3, + "text": "Transport (including MTU) considerations are discussed in Section 10 of [RFC7011].", + "ja": "トランスポート (MTU を含む) に関する考慮事項は、[RFC7011] のセクション 10 で説明されています。" + }, + { + "indent": 3, + "text": "Examples to illustrate the use of the new IPFIX Information Elements are provided in Section 5.", + "ja": "新しい IPFIX 情報要素の使用例をセクション 5 に示します。" + }, + { + "indent": 0, + "text": "2. Conventions and Definitions", + "section_title": true, + "ja": "2. 規則と定義" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。" + }, + { + "indent": 3, + "text": "This document uses the IPFIX-specific terminology (e.g., Flow) defined in Section 2 of [RFC7011]. As in the base IPFIX specification [RFC7011], these IPFIX-specific terms have the first letter of a word capitalized.", + "ja": "この文書では、[RFC7011] のセクション 2 で定義されている IPFIX 固有の用語 (例: フロー) を使用します。基本 IPFIX 仕様 [RFC7011] と同様、これらの IPFIX 固有の用語では、単語の最初の文字が大文字になります。" + }, + { + "indent": 3, + "text": "The document adheres to the naming conventions for Information Elements per Section 2.3 of [RFC7012].", + "ja": "この文書は、[RFC7012] のセクション 2.3 に基づく情報要素の命名規則に準拠しています。" + }, + { + "indent": 3, + "text": "Also, this document uses the terms defined in Section 3 of [RFC9868], especially \"datagram\" and \"surplus area\".", + "ja": "また、この文書では、[RFC9868] のセクション 3 で定義されている用語、特に「データグラム」と「余剰領域」を使用します。" + }, + { + "indent": 0, + "text": "3. UDP Options at a Glance", + "section_title": true, + "ja": "3. UDP オプションの概要" + }, + { + "indent": 3, + "text": "UDP [RFC0768] does not support an extension mechanism similar to the options supported by other transport protocols, such as TCP [RFC9293], Stream Control Transmission Protocol (SCTP) [RFC9260], or Datagram Congestion Control Protocol (DCCP) [RFC4340]. Such a mechanism can be useful for various applications, e.g., to discover a path MTU or share timestamps. To fill that void, [RFC9868] extends UDP with a mechanism to insert extensions in datagrams. To do so, and unlike the conventional approach that relies upon transport headers, [RFC9868] uses trailers. Concretely, UDP Options are placed in the surplus area (that is, the area of an IP payload that follows a UDP packet). See Figure 1. An example of the use of UDP Options for Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) is described in [RFC9869].", + "ja": "UDP [RFC0768] は、TCP [RFC9293]、ストリーム制御伝送プロトコル (SCTP) [RFC9260]、またはデータグラム輻輳制御プロトコル (DCCP) [RFC4340] などの他のトランスポート プロトコルでサポートされるオプションと同様の拡張メカニズムをサポートしません。このようなメカニズムは、パス MTU の検出やタイムスタンプの共有など、さまざまなアプリケーションに役立ちます。この空白を埋めるために、[RFC9868] はデータグラムに拡張機能を挿入するメカニズムを使用して UDP を拡張します。そうするために、トランスポートヘッダーに依存する従来のアプローチとは異なり、[RFC9868] はトレーラーを使用します。具体的には、ＵＤＰオプションは余剰領域（ＵＤＰパケットに続くＩＰペイロードの領域）に配置される。図 1 を参照してください。データグラム パケット化層パス MTU 検出のための UDP オプション (DPLPMTUD) の使用例は、[RFC9869] で説明されています。" + }, + { + "indent": 6, + "text": " IP transport payload\n <------------------------------------------------->\n+--------+---------+----------------------+------------------+\n| IP Hdr | UDP Hdr | UDP user data | surplus area |\n+--------+---------+----------------------+------------------+\n <------------------------------>\n UDP Length", + "raw": true, + "ja": "" + }, + { + "indent": 27, + "text": "Figure 1: Surplus Area", + "ja": "図 1: 余剰領域" + }, + { + "indent": 3, + "text": "Sections 4.1 and 4.2 introduce new IEs to export the observed UDP Options.", + "ja": "セクション 4.1 と 4.2 では、観察された UDP オプションをエクスポートするための新しい IE を紹介します。" + }, + { + "indent": 3, + "text": "UDP Options are unambiguously identified by means of a 1-byte field, called \"Kind\".", + "ja": "UDP オプションは、「Kind」と呼ばれる 1 バイトのフィールドによって明確に識別されます。" + }, + { + "indent": 3, + "text": "Options indicated by Kind values in the range 0-191 are called SAFE Options. Such options can be silently ignored by legacy receivers because they do not alter the UDP user data (Section 11 of [RFC9868]). SAFE Options are exported using the IE defined in Section 4.1.", + "ja": "0 ～ 191 の範囲の Kind 値で示されるオプションは SAFE オプションと呼ばれます。このようなオプションは、UDP ユーザーデータを変更しないため、レガシー受信機では黙って無視できます ([RFC9868] のセクション 11)。SAFE オプションは、セクション 4.1 で定義された IE を使用してエクスポートされます。" + }, + { + "indent": 3, + "text": "Options indicated by Kind values in the range 192-255 are called UNSAFE Options. Such options are not safe for legacy receivers to ignore because they alter the UDP user data (Section 12 of [RFC9868]). UNSAFE Options are exported using the IE defined in Section 4.2.", + "ja": "192 ～ 255 の範囲の Kind 値で示されるオプションは、UNSAFE オプションと呼ばれます。このようなオプションは、UDP ユーザーデータを変更するため、レガシー受信機にとって無視するのは安全ではありません ([RFC9868] のセクション 12)。UNSAFE オプションは、セクション 4.2 で定義された IE を使用してエクスポートされます。" + }, + { + "indent": 3, + "text": "UDP Options occur per-packet within a Flow and can be inserted at any time in the Flow.", + "ja": "UDP オプションはフロー内のパケットごとに発生し、フロー内でいつでも挿入できます。" + }, + { + "indent": 3, + "text": "[RFC9868] reserves two options for experiments: the Experimental (EXP, Kind=127) Option for SAFE Options and the UNSAFE Experimental (UEXP, Kind=254) Option. For both options, Experiment Identifiers (ExIDs) are used to differentiate concurrent use of these options. Known ExIDs are expected to be registered within IANA. Section 4.4 specifies a new IPFIX IE to export observed ExIDs in the EXP Options. Also, Section 4.5 specifies a new IPFIX IE to export observed ExIDs in the UEXP Options. Only 16-bit ExIDs are supported in [RFC9868].", + "ja": "[RFC9868] は実験用に 2 つのオプションを予約しています。SAFE オプションの実験 (EXP、Kind=127) オプションと UNSAFE 実験 (UEXP、Kind=254) オプションです。どちらのオプションでも、実験識別子 (ExID) を使用して、これらのオプションの同時使用を区別します。既知の ExID は IANA 内に登録されることが期待されます。セクション 4.4 では、EXP オプションで監視された ExID をエクスポートするための新しい IPFIX IE を指定しています。また、セクション 4.5 では、UEXP オプションで監視された ExID をエクスポートするための新しい IPFIX IE を指定しています。[RFC9868] では 16 ビット ExID のみがサポートされています。" + }, + { + "indent": 3, + "text": "This document does not intend to elaborate operational guidance/ implications of UDP Options. The document focuses exclusively on exporting observed UDP Options in datagrams.", + "ja": "この文書は、UDP オプションの運用上のガイダンスや影響について詳しく説明することを目的としたものではありません。このドキュメントでは、データグラム内の監視された UDP オプションのエクスポートのみに焦点を当てています。" + }, + { + "indent": 0, + "text": "4. New UDP IPFIX Information Elements", + "section_title": true, + "ja": "4. 新しい UDP IPFIX 情報要素" + }, + { + "indent": 3, + "text": "Given the Kind structure of SAFE and UNSAFE UDP Options, using one single IE that would multiplex both types of options will limit the benefits of reduced-size encoding in the presence of UNSAFE Options. For example, at least 24 octets would be needed to report mandatory SAFE Options that are observed in a Flow. In order to use less bits to report observed UDP Options, distinct IEs are thus defined to report SAFE (Section 4.1) and UNSAFE (Section 4.2) UDP Options. As further detailed in Section 5.1, only one octet is needed to report mandatory SAFE Options.", + "ja": "SAFE および UNSAFE UDP オプションの Kind 構造を考慮すると、両方のタイプのオプションを多重化する 1 つの IE を使用すると、UNSAFE オプションが存在する場合のサイズ縮小エンコードの利点が制限されます。たとえば、フロー内で観察される必須の SAFE オプションを報告するには、少なくとも 24 オクテットが必要になります。観測された UDP オプションをレポートするために使用するビットを少なくするために、SAFE (セクション 4.1) および UNSAFE (セクション 4.2) の UDP オプションをレポートするために別個の IE が定義されます。セクション 5.1 で詳しく説明するように、必須の SAFE オプションを報告するために必要なオクテットは 1 つだけです。" + }, + { + "indent": 0, + "text": "4.1. udpSafeOptions", + "section_title": true, + "ja": "4.1. udpSafeオプション" + }, + { + "indent": 3, + "text": "Name:", + "ja": "名前：" + }, + { + "indent": 12, + "text": "udpSafeOptions", + "ja": "udpSafeオプション" + }, + { + "indent": 3, + "text": "ElementID:", + "ja": "要素ID:" + }, + { + "indent": 12, + "text": "525", + "ja": "525" + }, + { + "indent": 3, + "text": "Description:", + "ja": "説明：" + }, + { + "indent": 12, + "text": "Observed SAFE UDP Options in a Flow. The information is encoded in a set of bit fields.", + "ja": "フロー内で観察された SAFE UDP オプション。情報は一連のビットフィールドにエンコードされます。" + }, + { + "indent": 12, + "text": "Options are mapped to bits according to their option numbers. UDP Option Kind 0 corresponds to the least significant bit in the udpSafeOptions IE, while Kind 191 corresponds to the 65th most significant bit of the IE. The bit is set to 1 if the corresponding SAFE UDP Option is observed at least once in the Flow. The bit is set to 0 if the option is never observed in the Flow. The 64 most significant bits MUST be set to 0.", + "ja": "オプションは、オプション番号に従ってビットにマッピングされます。UDP オプション Kind 0 は udpSafeOptions IE の最下位ビットに対応し、Kind 191 は IE の 65 番目の最上位ビットに対応します。対応する SAFE UDP オプションがフロー内で少なくとも 1 回観察されると、このビットは 1 に設定されます。オプションがフロー内で観察されない場合、ビットは 0 に設定されます。最上位 64 ビットは 0 に設定しなければなりません。" + }, + { + "indent": 12, + "text": "The reduced-size encoding per Section 6.2 of [RFC7011] is followed whenever fewer octets are needed to report observed SAFE UDP Options. For example, if only option Kinds <= 31 are observed, then the value of the udpSafeOptions IE can be encoded as unsigned32, or if only option Kinds <= 63 are observed, then the value of the udpSafeOptions IE can be encoded as unsigned64.", + "ja": "観測された SAFE UDP オプションを報告するために必要なオクテットが少ない場合は常に、[RFC7011] のセクション 6.2 に従った縮小サイズのエンコーディングが適用されます。たとえば、オプション Kinds <= 31 のみが観察される場合、udpSafeOptions IE の値は unsigned32 としてエンコードでき、オプション Kinds <= 63 のみが観察される場合、udpSafeOptions IE の値は unsigned64 としてエンコードできます。" + }, + { + "indent": 12, + "text": "The presence of udpSafeExIDList is an indication that the SAFE Experimental Option is observed in a Flow. The presence of udpSafeExIDList takes precedence over setting the corresponding bit in the udpSafeOptions IE for the same Flow. In order to optimize the use of the reduced-size encoding in the presence of udpSafeExIDList IE, the Exporter MUST NOT set the EXP flag of the udpSafeOptions IE that is reported for the same Flow to 1.", + "ja": "udpSafeExIDList の存在は、SAFE 実験的オプションがフロー内で観察されていることを示します。udpSafeExIDList の存在は、同じフローの udpSafeOptions IE の対応するビットの設定よりも優先されます。udpSafeExIDList IE の存在下で縮小サイズのエンコーディングの使用を最適化するために、エクスポーターは、同じフローについて報告される udpSafeOptions IE の EXP フラグを 1 に設定してはなりません。" + }, + { + "indent": 3, + "text": "Abstract Data Type:", + "ja": "抽象データ型:" + }, + { + "indent": 12, + "text": "unsigned256", + "ja": "署名なし256" + }, + { + "indent": 3, + "text": "Data Type Semantics:", + "ja": "データ型のセマンティクス:" + }, + { + "indent": 12, + "text": "flags", + "ja": "フラグ" + }, + { + "indent": 3, + "text": "Additional Information:", + "ja": "追加情報：" + }, + { + "indent": 12, + "text": "See the \"UDP Option Kind Numbers\" registry at [UDP_OPTIONS].", + "ja": "[UDP_OPTIONS] の「UDP オプションの種類番号」レジストリを参照してください。" + }, + { + "indent": 12, + "text": "See [RFC9868] for more details about UDP Options.", + "ja": "UDP オプションの詳細については、[RFC9868] を参照してください。" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "RFC 9870", + "ja": "RFC 9870" + }, + { + "indent": 0, + "text": "4.2. udpUnsafeOptions", + "section_title": true, + "ja": "4.2. udpUnsafeオプション" + }, + { + "indent": 3, + "text": "Name:", + "ja": "名前：" + }, + { + "indent": 12, + "text": "udpUnsafeOptions", + "ja": "udpUnsafeオプション" + }, + { + "indent": 3, + "text": "ElementID:", + "ja": "要素ID:" + }, + { + "indent": 12, + "text": "526", + "ja": "526" + }, + { + "indent": 3, + "text": "Description:", + "ja": "説明：" + }, + { + "indent": 12, + "text": "Observed UNSAFE UDP Options in a Flow. The information is encoded in a set of bit fields.", + "ja": "フロー内で検出された安全でない UDP オプション。情報は一連のビットフィールドにエンコードされます。" + }, + { + "indent": 12, + "text": "Options are mapped to bits according to their option numbers. UDP Option Kind 192 corresponds to the least significant bit in the udpUnsafeOptions IE, while Kind 255 corresponds to the most significant bit of the IE. The bit is set to 1 if the corresponding UNSAFE UDP Option is observed at least once in the Flow. The bit is set to 0 if the option is never observed in the Flow.", + "ja": "オプションは、オプション番号に従ってビットにマッピングされます。UDP オプションの種類 192 は udpUnsafeOptions IE の最下位ビットに対応し、種類 255 は IE の最上位ビットに対応します。対応する UNSAFE UDP オプションがフロー内で少なくとも 1 回検出された場合、このビットは 1 に設定されます。オプションがフロー内で観察されない場合、ビットは 0 に設定されます。" + }, + { + "indent": 12, + "text": "The reduced-size encoding per Section 6.2 of [RFC7011] is followed whenever fewer octets are needed to report observed UNSAFE UDP Options.", + "ja": "観察された UNSAFE UDP オプションを報告するためにより少ないオクテットが必要な場合は常に、[RFC7011] のセクション 6.2 に従った縮小サイズのエンコーディングが適用されます。" + }, + { + "indent": 12, + "text": "The presence of udpUnsafeExIDList is an indication that the UNSAFE Experimental Option is observed in a Flow. The presence of udpUnsafeExIDList takes precedence over setting the corresponding bit in the udpUnsafeOptions IE for the same Flow. In order to optimize the use of the reduced-size encoding in the presence of udpUnsafeExIDList IE, the Exporter MUST NOT set the UEXP flag of the udpUnsafeOptions IE that is reported for the same Flow to 1.", + "ja": "udpUnsafeExIDList の存在は、UNSAFE 実験的オプションがフロー内で観察されていることを示します。udpUnsafeExIDList の存在は、同じフローの udpUnsafeOptions IE 内の対応するビットの設定よりも優先されます。udpUnsafeExIDList IE の存在下で縮小サイズのエンコーディングの使用を最適化するために、エクスポーターは、同じフローについて報告される udpUnsafeOptions IE の UEXP フラグを 1 に設定してはなりません (MUST NOT)。" + }, + { + "indent": 3, + "text": "Abstract Data Type:", + "ja": "抽象データ型:" + }, + { + "indent": 12, + "text": "unsigned64", + "ja": "署名なし64" + }, + { + "indent": 3, + "text": "Data Type Semantics:", + "ja": "データ型のセマンティクス:" + }, + { + "indent": 12, + "text": "flags", + "ja": "フラグ" + }, + { + "indent": 3, + "text": "Additional Information:", + "ja": "追加情報：" + }, + { + "indent": 12, + "text": "See the \"UDP Option Kind Numbers\" registry at [UDP_OPTIONS].", + "ja": "[UDP_OPTIONS] の「UDP オプションの種類番号」レジストリを参照してください。" + }, + { + "indent": 12, + "text": "See [RFC9868] for more details about UDP Options.", + "ja": "UDP オプションの詳細については、[RFC9868] を参照してください。" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "RFC 9870", + "ja": "RFC 9870" + }, + { + "indent": 0, + "text": "4.3. udpExID", + "section_title": true, + "ja": "4.3. udpExID" + }, + { + "indent": 3, + "text": "Name:", + "ja": "名前：" + }, + { + "indent": 12, + "text": "udpExID", + "ja": "udpExID" + }, + { + "indent": 3, + "text": "ElementID:", + "ja": "要素ID:" + }, + { + "indent": 12, + "text": "527", + "ja": "527" + }, + { + "indent": 3, + "text": "Description:", + "ja": "説明：" + }, + { + "indent": 12, + "text": "Observed ExID in an Experimental (EXP, Kind=127) Option or an UNSAFE Experimental (UEXP, Kind=254) Option.", + "ja": "実験的 (EXP、Kind=127) オプションまたは UNSAFE 実験的 (UEXP、Kind=254) オプションで観察された ExID。" + }, + { + "indent": 12, + "text": "A basicList of udpExID is used to report udpSafeExIDList and udpUnsafeExIDList values.", + "ja": "udpExID の BasicList は、udpSafeExIDList および udpUnsafeExIDList の値を報告するために使用されます。" + }, + { + "indent": 3, + "text": "Abstract Data Type:", + "ja": "抽象データ型:" + }, + { + "indent": 12, + "text": "unsigned16", + "ja": "署名なし16" + }, + { + "indent": 3, + "text": "Data Type Semantics:", + "ja": "データ型のセマンティクス:" + }, + { + "indent": 12, + "text": "identifier", + "ja": "識別子" + }, + { + "indent": 3, + "text": "Additional Information:", + "ja": "追加情報：" + }, + { + "indent": 12, + "text": "See the \"TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)\" registry at [UDP_ExIDs].", + "ja": "[UDP_ExIDs] の「TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)」レジストリを参照してください。" + }, + { + "indent": 12, + "text": "See [RFC9868] for more details about ExIDs.", + "ja": "ExID の詳細については、[RFC9868] を参照してください。" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "RFC 9870", + "ja": "RFC 9870" + }, + { + "indent": 0, + "text": "4.4. udpSafeExIDList", + "section_title": true, + "ja": "4.4. udpSafeExIDList" + }, + { + "indent": 3, + "text": "Name:", + "ja": "名前：" + }, + { + "indent": 12, + "text": "udpSafeExIDList", + "ja": "udpSafeExIDList" + }, + { + "indent": 3, + "text": "ElementID:", + "ja": "要素ID:" + }, + { + "indent": 12, + "text": "528", + "ja": "528" + }, + { + "indent": 3, + "text": "Description:", + "ja": "説明：" + }, + { + "indent": 12, + "text": "Observed ExIDs in the Experimental (EXP, Kind=127) Option.", + "ja": "実験的 (EXP、Kind=127) オプションで観察された ExID。" + }, + { + "indent": 12, + "text": "A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an EXP Option.", + "ja": "udpExID 情報要素の BasicList。各 udpExID 情報要素は、EXP オプションで観察される ExID を保持します。" + }, + { + "indent": 3, + "text": "Abstract Data Type:", + "ja": "抽象データ型:" + }, + { + "indent": 12, + "text": "basicList", + "ja": "基本リスト" + }, + { + "indent": 3, + "text": "Data Type Semantics:", + "ja": "データ型のセマンティクス:" + }, + { + "indent": 12, + "text": "list", + "ja": "リスト" + }, + { + "indent": 3, + "text": "Additional Information:", + "ja": "追加情報：" + }, + { + "indent": 12, + "text": "See the \"TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)\" registry at [UDP_ExIDs].", + "ja": "[UDP_ExIDs] の「TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)」レジストリを参照してください。" + }, + { + "indent": 12, + "text": "See [RFC9868] for more details about ExIDs.", + "ja": "ExID の詳細については、[RFC9868] を参照してください。" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "RFC 9870", + "ja": "RFC 9870" + }, + { + "indent": 0, + "text": "4.5. udpUnsafeExIDList", + "section_title": true, + "ja": "4.5. udpUnsafeExIDList" + }, + { + "indent": 3, + "text": "Name:", + "ja": "名前：" + }, + { + "indent": 12, + "text": "udpUnsafeExIDList", + "ja": "udpUnsafeExIDList" + }, + { + "indent": 3, + "text": "ElementID:", + "ja": "要素ID:" + }, + { + "indent": 12, + "text": "529", + "ja": "529" + }, + { + "indent": 3, + "text": "Description:", + "ja": "説明：" + }, + { + "indent": 12, + "text": "Observed ExIDs in the UNSAFE Experimental (UEXP, Kind=254) Option.", + "ja": "UNSAFE Experimental (UEXP、Kind=254) オプションで観察された ExID。" + }, + { + "indent": 12, + "text": "A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an UEXP Option.", + "ja": "udpExID 情報要素の BasicList。各 udpExID 情報要素は、UEXP オプションで観察される ExID を保持します。" + }, + { + "indent": 3, + "text": "Abstract Data Type:", + "ja": "抽象データ型:" + }, + { + "indent": 12, + "text": "basicList", + "ja": "基本リスト" + }, + { + "indent": 3, + "text": "Data Type Semantics:", + "ja": "データ型のセマンティクス:" + }, + { + "indent": 12, + "text": "list", + "ja": "リスト" + }, + { + "indent": 3, + "text": "Additional Information:", + "ja": "追加情報：" + }, + { + "indent": 12, + "text": "See the \"TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)\" registry at [UDP_ExIDs].", + "ja": "[UDP_ExIDs] の「TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)」レジストリを参照してください。" + }, + { + "indent": 12, + "text": "See [RFC9868] for more details about ExIDs.", + "ja": "ExID の詳細については、[RFC9868] を参照してください。" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "RFC 9870", + "ja": "RFC 9870" + }, + { + "indent": 0, + "text": "5. Examples", + "section_title": true, + "ja": "5. 例" + }, + { + "indent": 0, + "text": "5.1. Reduced-Size Encoding", + "section_title": true, + "ja": "5.1. 縮小サイズのエンコーディング" + }, + { + "indent": 3, + "text": "Given the UDP Kind allocation in Section 10 of [RFC9868] and the option mapping defined in Section 4.1 of this document, fewer octets are likely to be used for Flows with mandatory UDP Options.", + "ja": "[RFC9868] のセクション 10 の UDP Kind 割り当てと、この文書のセクション 4.1 で定義されているオプション マッピングを考慮すると、必須の UDP オプションを持つフローに使用されるオクテットは少なくなる可能性があります。" + }, + { + "indent": 3, + "text": "Figure 2 shows an example of the Kind/bit mappings in the udpSafeOptions IE for a Flow in which End of Options List (EOL, Kind=0) and Additional Payload Checksum (APC, Kind=2) Options are observed. Only the bits that corresponds to EOL and APC Options are set to 1.", + "ja": "図 2 は、オプション リストの終わり (EOL、Kind=0) および追加のペイロード チェックサム (APC、Kind=2) オプションが観察されるフローの udpSafeOptions IE の Kind/ビット マッピングの例を示しています。EOL および APC オプションに対応するビットのみが 1 に設定されます。" + }, + { + "indent": 7, + "text": "MSB LSB\n 1 25\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 ... 8 9 0 1 2 3 4 5\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+\n|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| |0|0|0|0|0|1|0|1|\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+-+", + "raw": true, + "ja": "" + }, + { + "indent": 5, + "text": "Figure 2: An Example of udpSafeOptions IE with EOL and APC Options", + "ja": "図 2: EOL および APC オプションを使用した udpSafeOptions IE の例" + }, + { + "indent": 3, + "text": "One octet is sufficient to report these observed options because the leading zeros are dropped per the reduced-size encoding guidance. Concretely, the reported udpSafeOptions IE will be set to 0x05 (Figure 3).", + "ja": "サイズ縮小エンコードのガイダンスに従って先頭のゼロが削除されるため、これらの観察されたオプションを報告するには 1 オクテットで十分です。具体的には、報告された udpSafeOptions IE は 0x05 に設定されます (図 3)。" + }, + { + "indent": 29, + "text": "MSB LSB\n 0 1 2 3 4 5 6 7\n+-+-+-+-+-+-+-+-+\n|0|0|0|0|0|1|0|1|\n+-+-+-+-+-+-+-+-+", + "raw": true, + "ja": "" + }, + { + "indent": 5, + "text": "Figure 3: An Example of the Wire udpSafeOptions IE Value with EOL and APC Options", + "ja": "図 3: EOL および APC オプションを使用したワイヤ udpSafeOptions IE 値の例" + }, + { + "indent": 0, + "text": "5.2. SAFE Experimental Option", + "section_title": true, + "ja": "5.2. SAFE 実験的オプション" + }, + { + "indent": 3, + "text": "Let us now consider a UDP Flow in which SAFE Experimental Options are observed. If a udpSafeOptions IE is exported for this Flow, then that IE will have the EXP bit set to 1 (Figure 4). This example does not make any assumption about the presence of other UDP Options (\"X\" can be set to 0 or 1).", + "ja": "次に、SAFE 実験的オプションが観察される UDP フローを考えてみましょう。udpSafeOptions IE がこのフローに対してエクスポートされる場合、その IE の EXP ビットは 1 に設定されます (図 4)。この例では、他の UDP オプションの存在については何も想定していません (「X」は 0 または 1 に設定できます)。" + }, + { + "indent": 8, + "text": "MSB LSB\n 12 25\n 0 1 2 3 ... 7 8 9 0 1 2 3 4 5 6 7 8 9 ... 8 9 0 1 2 3 4 5\n+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+\n|X|X|X|X| |X|X|X|X|X|X|X|X|X|X|X|1|X|X| |X|X|X|X|X|X|X|\n+-+-+-+-+...+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+", + "raw": true, + "ja": "" + }, + { + "indent": 11, + "text": "Figure 4: An Example of udpSafeOptions with EXP Option", + "ja": "図 4: EXP オプションを使用した udpSafeOptions の例" + }, + { + "indent": 0, + "text": "5.3. ExIDs and Reduced-Size Encoding", + "section_title": true, + "ja": "5.3. ExID と縮小サイズのエンコーディング" + }, + { + "indent": 3, + "text": "Now assume that EOL, APC, EXP, and UEXP Options are observed in a Flow. Let us also consider that the observed SAFE Experimental Options have ExIDs set to 0x9858 and 0xE2D4 and UNSAFE Experimental Options have ExIDs set to 0xC3D9 and 0x1234. Figure 5 shows an excerpt of the Data Set encoding with a focus on SAFE Experimental Options that have ExIDs. The fields are defined in [RFC6313].", + "ja": "ここで、EOL、APC、EXP、および UEXP オプションがフローで観察されると仮定します。また、観察された SAFE 実験的オプションの ExID は 0x9858 および 0xE2D4 に設定されており、UNSAFE 実験的オプションの ExID は 0xC3D9 および 0x1234 に設定されていることも考えてみましょう。図 5 は、ExID を持つ SAFE Experimental Options に焦点を当てたデータ セット エンコーディングの抜粋を示しています。フィールドは [RFC6313] で定義されています。" + }, + { + "indent": 5, + "text": " MSB LSB\n 0 1 2 3\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n: ... :\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| 255 | List Length = 9 |semantic=allof |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| udpExID = 527 | Field Length = 2 |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| SAFE ExID = 0x9858 | SAFE ExID = 0xE2D4 |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| 255 | List Length = 9 |semantic=allof |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| udpExID = 527 | Field Length = 2 |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| UNSAFE ExID = 0xC3D9 | UNSAFE ExID = 0x1234 |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n: ... :", + "raw": true, + "ja": "" + }, + { + "indent": 11, + "text": "Figure 5: Example of UDP Experimental Option ExID IEs", + "ja": "図 5: UDP 実験的オプション ExID IE の例" + }, + { + "indent": 3, + "text": "Following the guidance in Section 4.1, the reported udpSafeOptions IE will be set to 0x05 even in the presence of EXP Options.", + "ja": "セクション 4.1 のガイダンスに従って、報告される udpSafeOptions IE は、EXP オプションが存在する場合でも 0x05 に設定されます。" + }, + { + "indent": 0, + "text": "6. Security Considerations", + "section_title": true, + "ja": "6. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "This document does not introduce new security considerations other than those already discussed in Section 11 of [RFC7011] and Section 8 of [RFC7012].", + "ja": "この文書は、[RFC7011] のセクション 11 および [RFC7012] のセクション 8 で既に説明されているもの以外の、新しいセキュリティに関する考慮事項を紹介しません。" + }, + { + "indent": 3, + "text": "The reader may refer to Section 24 of [RFC9868] for the security considerations related to UDP Options.", + "ja": "UDP オプションに関連するセキュリティ上の考慮事項については、[RFC9868] のセクション 24 を参照してください。" + }, + { + "indent": 0, + "text": "7. IANA Considerations", + "section_title": true, + "ja": "7. IANAの考慮事項" + }, + { + "indent": 0, + "text": "7.1. IPFIX Information Elements", + "section_title": true, + "ja": "7.1. IPFIX 情報要素" + }, + { + "indent": 3, + "text": "IANA has added the following new IEs to the \"IPFIX Information Elements\" registry under the \"IP Flow Information Export (IPFIX) Entities\" registry group [IANA-IPFIX]:", + "ja": "IANA は、「IP フロー情報エクスポート (IPFIX) エンティティ」レジストリ グループ [IANA-IPFIX] の下の「IPFIX 情報要素」レジストリに次の新しい IE を追加しました。" + }, + { + "indent": 8, + "text": "+===========+===================+=========================+\n| ElementID | Name | Reference |\n+===========+===================+=========================+\n| 525 | udpSafeOptions | Section 4.1 of RFC 9870 |\n+-----------+-------------------+-------------------------+\n| 526 | udpUnsafeOptions | Section 4.2 of RFC 9870 |\n+-----------+-------------------+-------------------------+\n| 527 | udpExID | Section 4.3 of RFC 9870 |\n+-----------+-------------------+-------------------------+\n| 528 | udpSafeExIDList | Section 4.4 of RFC 9870 |\n+-----------+-------------------+-------------------------+\n| 529 | udpUnsafeExIDList | Section 4.5 of RFC 9870 |\n+-----------+-------------------+-------------------------+", + "raw": true, + "ja": "" + }, + { + "indent": 18, + "text": "Table 1: New IPFIX Information Elements", + "ja": "表 1: 新しい IPFIX 情報要素" + }, + { + "indent": 3, + "text": "udpSafeOptions uses the abstract data type (\"unsigned256\") defined in [RFC9740].", + "ja": "udpSafeOptions は、[RFC9740] で定義されている抽象データ型 (\"unsigned256\") を使用します。" + }, + { + "indent": 0, + "text": "8. References", + "section_title": true, + "ja": "8. 参考文献" + }, + { + "indent": 0, + "text": "8.1. Normative References", + "section_title": true, + "ja": "8.1. 引用文献" + }, + { + "indent": 3, + "text": "[RFC0768] Postel, J., \"User Datagram Protocol\", STD 6, RFC 768,\n DOI 10.17487/RFC0768, August 1980,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates,\n \"Export of Structured Data in IP Flow Information Export\n (IPFIX)\", RFC 6313, DOI 10.17487/RFC6313, July 2011,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,\n \"Specification of the IP Flow Information Export (IPFIX)\n Protocol for the Exchange of Flow Information\", STD 77,\n RFC 7011, DOI 10.17487/RFC7011, September 2013,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7012] Claise, B., Ed. and B. Trammell, Ed., \"Information Model\n for IP Flow Information Export (IPFIX)\", RFC 7012,\n DOI 10.17487/RFC7012, September 2013,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9740] Boucadair, M. and B. Claise, \"New IPFIX Information\n Elements for TCP Options and IPv6 Extension Headers\",\n RFC 9740, DOI 10.17487/RFC9740, March 2025,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9868] Touch, J. and C. Heard, Ed., \"Transport Options for UDP\",\n RFC 9868, DOI 10.17487/RFC9868, October 2025,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "8.2. Informative References", + "section_title": true, + "ja": "8.2. 参考引用" + }, + { + "indent": 3, + "text": "[IANA-IPFIX]\n IANA, \"IP Flow Information Export (IPFIX) Entities\",\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4340] Kohler, E., Handley, M., and S. Floyd, \"Datagram\n Congestion Control Protocol (DCCP)\", RFC 4340,\n DOI 10.17487/RFC4340, March 2006,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6632] Ersue, M., Ed. and B. Claise, \"An Overview of the IETF\n Network Management Standards\", RFC 6632,\n DOI 10.17487/RFC6632, June 2012,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, \"Stream Control\n Transmission Protocol\", RFC 9260, DOI 10.17487/RFC9260,\n June 2022, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9293] Eddy, W., Ed., \"Transmission Control Protocol (TCP)\",\n STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9869] Fairhurst, G. and T. Jones, \"Datagram Packetization Layer\n Path MTU Discovery (DPLPMTUD) for UDP Options\", RFC 9869,\n DOI 10.17487/RFC9869, October 2025,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[UDP_ExIDs]\n IANA, \"TCP/UDP Experimental Option Experiment Identifiers\n (TCP/UDP ExIDs)\", .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[UDP_OPTIONS]\n IANA, \"UDP Option Kind Numbers\",\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Acknowledgments", + "section_title": true, + "ja": "謝辞" + }, + { + "indent": 3, + "text": "Thanks to Benoît Claise for the discussion on the ordering of IPFIX IEs. Thanks to Paul Aitken for the review and comments.", + "ja": "IPFIX IE の順序について議論してくれた Benoit Claise に感謝します。レビューとコメントをくださった Paul Aitken に感謝します。" + }, + { + "indent": 3, + "text": "Thanks to Tommy Pauly for the TSVART review, Joe Touch for the INTDIR review, Robert Sparks for the GENART review, Watson Ladd for the SECDIR review, and Jouni Korhonen for the OPSDIR review.", + "ja": "TSVART レビューの Tommy Pauly、INTDIR レビューの Joe Touch、GENART レビューの Robert Sparks、SECDIR レビューの Watson Ladd、OPSDIR レビューの Jouni Korhonen に感謝します。" + }, + { + "indent": 3, + "text": "Thanks to Thomas Graf for the shepherd review.", + "ja": "羊飼いのレビューを書いてくれた Thomas Graf に感謝します。" + }, + { + "indent": 3, + "text": "Thanks to Mahesh Jethanandani for the AD review.", + "ja": "AD レビューを投稿してくださった Mahesh Jethanandani に感謝します。" + }, + { + "indent": 3, + "text": "Thanks to Éric Vyncke, Roman Danyliw, and Zahed Sarker for the IESG review.", + "ja": "IESG のレビューに協力してくれた Éric Vyncke、Roman Danyliw、Zahed Sarker に感謝します。" + }, + { + "indent": 0, + "text": "Authors' Addresses", + "section_title": true, + "ja": "著者の住所" + }, + { + "indent": 3, + "text": "Mohamed Boucadair\nOrange\n35000 Rennes\nFrance\nEmail: mohamed.boucadair@orange.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Tirumaleswar Reddy.K\nNokia\nIndia\nEmail: kondtir@gmail.com", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9883-trans.json b/data/9000/rfc9883-trans.json new file mode 100644 index 000000000..34e611474 --- /dev/null +++ b/data/9000/rfc9883-trans.json @@ -0,0 +1,596 @@ +{ + "title": { + "text": "RFC 9883 - An Attribute for Statement of Possession of a Private Key", + "ja": "RFC 9883 - 秘密鍵の所有を宣言するための属性" + }, + "number": 9883, + "created_at": "2025-10-14 23:24:06.677679+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) R. Housley\nRequest for Comments: 9883 Vigil Security\nCategory: Standards Track October 2025\nISSN: 2070-1721", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "An Attribute for Statement of Possession of a Private Key", + "section_title": true, + "ja": "秘密鍵の所有を宣言するための属性" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate.", + "ja": "この文書は、証明書サブジェクトによる秘密キーの所有を宣言するための属性を指定します。X.509 証明書の登録の一環として、認証局 (CA) は通常、認証される公開キーに対応する秘密キーをサブジェクトが所有しているという証明を要求します。場合によっては、CA が証明書サブジェクトからの署名付きステートメントを受け入れる場合があります。たとえば、証明書サブジェクトが署名とキーの確立に別個の証明書を必要とする場合、同じサブジェクトに対して以前に発行された署名証明書で検証できるステートメントは、その後のキー確立証明書の発行には適切である可能性があります。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This is an Internet Standards Track document.", + "ja": "これはインターネット標準化トラックの文書です。" + }, + { + "indent": 3, + "text": "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 Internet Standards is available in Section 2 of RFC 7841.", + "ja": "このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。" + }, + { + "indent": 3, + "text": "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/rfc9883.", + "ja": "この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9883 で入手できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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.", + "ja": "この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n 1.1. ASN.1\n 1.2. Terminology\n2. Overview\n3. Attribute for Statement of Possession of a Private Key\n4. Conventions for PKCS#10\n5. Conventions for CRMF\n6. Security Considerations\n7. IANA Considerations\n8. References\n 8.1. Normative References\n 8.2. Informative References\nAppendix A. ASN.1 Module\nAppendix B. Example Use of the privateKeyPossessionStatement\n Attribute\nAcknowledgements\nAuthor's Address", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "This document specifies an attribute for a statement of possession of a private key by a certificate subject. X.509 certificate [RFC5280] enrollment often depends on PKCS#10 [RFC2986] or the Certificate Request Message Format (CRMF) [RFC4211]. As part of enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. Alternatively, a CA may accept a signed statement from the certificate subject claiming knowledge of that private key. When a certificate subject needs separate certificates for signature and key establishment, a signed statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate.", + "ja": "この文書は、証明書サブジェクトによる秘密キーの所有を宣言するための属性を指定します。X.509 証明書 [RFC5280] の登録は、多くの場合、PKCS#10 [RFC2986] または証明書要求メッセージ形式 (CRMF) [RFC4211] に依存します。登録の一環として、認証局 (CA) は通常、認証対象の公開キーに対応する秘密キーをサブジェクトが所有しているという証明を要求します。あるいは、CA は、その秘密鍵の知識を主張する証明書主体からの署名付きステートメントを受け入れることもできます。証明書サブジェクトが署名と鍵の確立に別個の証明書を必要とする場合、同じサブジェクトに対して以前に発行された署名証明書で検証できる署名付きステートメントは、その後の鍵確立証明書の発行に適している可能性があります。" + }, + { + "indent": 3, + "text": "For example, a subject may need a signature certificate that contains an ML-DSA (Module-Lattice-Based Digital Signature Algorithm) public key and a key establishment certificate that contains an ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) public key. For another example, a subject may need a signature certificate that contains an ECDSA (Elliptic Curve Digital Signature Algorithm) public key and a key establishment certificate that contains an ECDH (Elliptic Curve Diffie-Hellman) public key.", + "ja": "たとえば、サブジェクトは、ML-DSA (モジュール格子ベースのデジタル署名アルゴリズム) 公開キーを含む署名証明書と、ML-KEM (モジュール格子ベースのキーカプセル化メカニズム) 公開キーを含むキー確立証明書を必要とする場合があります。別の例として、サブジェクトは、ECDSA (楕円曲線デジタル署名アルゴリズム) 公開鍵を含む署名証明書と、ECDH (楕円曲線ディフィーヘルマン) 公開鍵を含む鍵確立証明書を必要とする場合があります。" + }, + { + "indent": 3, + "text": "A statement of possession may be used in lieu of the usual proof-of-possession mechanisms. The statement is simply a signed assertion that the requestor of a key establishment certificate has possession of the key establishment private key and that statement is signed using a signature private key that was previously shown to be in the possession of the same certificate subject. If allowed by the Certificate Policy [RFC3647], the CA is permitted to accept this statement in lieu of proof that the requestor has possession of the private key, such as [RFC6955].", + "ja": "通常の所有証明メカニズムの代わりに所有声明が使用される場合があります。このステートメントは、キー確立証明書の要求者がキー確立秘密キーを所有しており、そのステートメントは、同じ証明書サブジェクトが所有していることが以前に示されている署名秘密キーを使用して署名されているという署名付きアサーションにすぎません。証明書ポリシー [RFC3647] で許可されている場合、CA は、[RFC6955] など、要求者が秘密鍵を所有していることを証明する代わりに、このステートメントを受け入れることが許可されます。" + }, + { + "indent": 3, + "text": "Note that [RFC6955] offers some algorithms that provide proof of possession for Diffie-Hellman private keys; however, these algorithms are not suitable for use with PKCS#10 [RFC2986]. In addition, the algorithms in [RFC6955] do not support key encapsulation mechanism algorithms, such as ML-KEM. The attribute specified in this document, on the other hand, is suitable for use with both PKCS#10 and the CRMF [RFC4211].", + "ja": "[RFC6955] は、Diffie-Hellman 秘密鍵の所有証明を提供するいくつかのアルゴリズムを提供していることに注意してください。ただし、これらのアルゴリズムは PKCS#10 [RFC2986] での使用には適していません。さらに、[RFC6955] のアルゴリズムは、ML-KEM などの鍵カプセル化メカニズムのアルゴリズムをサポートしていません。一方、この文書で指定された属性は、PKCS#10 と CRMF [RFC4211] の両方での使用に適しています。" + }, + { + "indent": 0, + "text": "1.1. ASN.1", + "section_title": true, + "ja": "1.1. ASN.1" + }, + { + "indent": 3, + "text": "The attribute defined in this document is generated using ASN.1 [X680], using the Distinguished Encoding Rules (DER) [X690].", + "ja": "この文書で定義される属性は、ASN.1 [X680]、Distinguished Encoding Rules (DER) [X690] を使用して生成されます。" + }, + { + "indent": 0, + "text": "1.2. Terminology", + "section_title": true, + "ja": "1.2. 用語" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。" + }, + { + "indent": 0, + "text": "2. Overview", + "section_title": true, + "ja": "2. 概要" + }, + { + "indent": 3, + "text": "When using the attribute defined in this document to make a statement about the possession of the key establishment private key, the process to obtain two certificates with PKCS#10 is as follows:", + "ja": "この文書で定義されている属性を使用して鍵確立秘密鍵の所有についてステートメントを作成する場合、PKCS#10 で 2 つの証明書を取得するプロセスは次のとおりです。" + }, + { + "indent": 8, + "text": "1. The subject generates the signature key pair.", + "ja": "1. サブジェクトは署名鍵ペアを生成します。" + }, + { + "indent": 8, + "text": "2. The subject composes a PKCS#10 Certificate Signing Request (CSR) in the usual manner. It includes a signature that is produced with the private key from step 1.", + "ja": "2. サブジェクトは通常の方法で PKCS#10 証明書署名要求 (CSR) を作成します。これには、手順 1 の秘密キーを使用して生成された署名が含まれています。" + }, + { + "indent": 8, + "text": "3. The subject sends the CSR to the CA, and it gets back a signature certificate. The signature certificate includes a key usage of digitalSignature, nonRepudiation, or both (see Section 4.2.1.3 of [RFC5280]).", + "ja": "3. サブジェクトは CSR を CA に送信し、CA は署名証明書を返します。署名証明書には、digitalSignature、nonRepudiation、またはその両方の鍵の使用法が含まれています（[RFC5280] のセクション 4.2.1.3 を参照）。" + }, + { + "indent": 8, + "text": "4. The subject generates the key establishment key pair.", + "ja": "4. サブジェクトは鍵確立鍵ペアを生成します。" + }, + { + "indent": 8, + "text": "5. The subject composes a PKCS#10 CSR containing the key establishment public key. The CSR attributes include the attribute specified in Section 3 of this document. The subject name matches the one from step 3. The CSR includes a signature that is produced with the private key from step 1.", + "ja": "5. サブジェクトは、鍵確立公開鍵を含む PKCS#10 CSR を作成します。CSR 属性には、この文書のセクション 3 で指定された属性が含まれます。サブジェクト名はステップ 3 の名前と一致します。CSR には、ステップ 1 の秘密キーを使用して生成された署名が含まれています。" + }, + { + "indent": 8, + "text": "6. The subject sends the CSR to the CA, and it gets back a key establishment certificate. The key establishment certificate includes a key usage of keyEncipherment or keyAgreement (see Section 4.2.1.3 of [RFC5280]).", + "ja": "6. サブジェクトは CSR を CA に送信し、CA はキー確立証明書を返します。鍵確立証明書には、keyEncipherment または keyAgreement の鍵使用法が含まれます ([RFC5280] のセクション 4.2.1.3 を参照)。" + }, + { + "indent": 3, + "text": "In general, the issuer of the key establishment certificate will be the same as the issuer of the signature certificate. If the issuers of the two certificates will be different, then the certificate policy of the issuer of the key establishment certificate MUST explain the procedure that is used to verify the subject and subject alternative names.", + "ja": "一般に、鍵確立証明書の発行者は署名証明書の発行者と同じになります。2 つの証明書の発行者が異なる場合、鍵確立証明書の発行者の証明書ポリシーで、サブジェクトとサブジェクトの代替名の検証に使用される手順を説明しなければなりません (MUST)。" + }, + { + "indent": 0, + "text": "3. Attribute for Statement of Possession of a Private Key", + "section_title": true, + "ja": "3. 秘密鍵の所有を宣言するための属性" + }, + { + "indent": 3, + "text": "The attribute for statement of possession of a private key is included in a certificate request to make the following statement:", + "ja": "秘密キーの所有に関するステートメントの属性は、次のステートメントを作成するために証明書リクエストに含まれています。" + }, + { + "indent": 3, + "text": " The subject of the signature certificate that is used to validate the signature on this certificate request states, without providing proof, that it has possession of the private key that corresponds to the public key in the certificate request.", + "ja": "この証明書要求の署名を検証するために使用される署名証明書の件名は、証明を提供することなく、証明書要求の公開キーに対応する秘密キーを所有していると述べています。" + }, + { + "indent": 3, + "text": "The CA MUST perform certification path validation for the signature certificate as specified in Section 6 of [RFC5280]. If the certification path is not valid, then the CA MUST reject the request for the key establishment certificate.", + "ja": "CA は、[RFC5280] のセクション 6 に規定されているように、署名証明書の証明書パス検証を実行しなければなりません (MUST)。認証パスが有効でない場合、CA は鍵確立証明書の要求を拒否しなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "The CA MUST validate the signature on the certificate request using the public key from the signature certificate. If the signature is not valid, then the CA MUST reject the certificate request.", + "ja": "CA は、署名証明書の公開鍵を使用して、証明書リクエストの署名を検証しなければなりません (MUST)。署名が有効でない場合、CA は証明書要求を拒否しなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "The subject in the signature certificate SHOULD be the same as the subject name in the certificate request. If they are different, the certificate policy MUST describe how the CA can determine that the two subject names identify the same entity. If the CA is unable to determine that the two subject names identify the same entity, then the CA MUST reject the certificate request.", + "ja": "署名証明書のサブジェクトは、証明書リクエストのサブジェクト名と同じである必要があります (SHOULD)。それらが異なる場合、証明書ポリシーは、CA が 2 つのサブジェクト名が同じエンティティを識別していることをどのように判断できるかを記述しなければなりません (MUST)。CA が 2 つのサブジェクト名が同じエンティティを識別していると判断できない場合、CA は証明書要求を拒否しなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "If subject alternative names are present in the certificate request, they SHOULD match subject alternative names in the signature certificate. If they are different, the certificate policy MUST describe how the CA can determine that the two subject alternative names identify the same entity. If the CA is unable to determine that each of subject alternative names identifies the same entity as is named in the signature certificate, then the CA MUST reject the certificate request.", + "ja": "証明書リクエストにサブジェクト代替名が存在する場合、それらは署名証明書内のサブジェクト代替名と一致する必要があります(SHOULD)。それらが異なる場合、証明書ポリシーは、CA が 2 つのサブジェクト代替名が同じエンティティを識別していることをどのように判断できるかを記述しなければなりません (MUST)。CA が、各サブジェクト代替名が署名証明書で指定されているのと同じエンティティを識別していると判断できない場合、CA は証明書要求を拒否しなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "When the CA rejects a certificate request for any of the reasons listed above, the CA should provide information to the requestor about the reason for the rejection to aid with diagnostic efforts. Likewise, the CA should log the rejection events.", + "ja": "CA が上記のいずれかの理由で証明書要求を拒否した場合、CA は診断作業を支援するために、拒否の理由に関する情報を要求者に提供する必要があります。同様に、CA は拒否イベントをログに記録する必要があります。" + }, + { + "indent": 3, + "text": "The attribute for statement of possession of a private key has the following structure:", + "ja": "秘密鍵の所有を宣言するための属性は次の構造になっています。" + }, + { + "indent": 6, + "text": "id-at-statementOfPossession OBJECT IDENTIFIER ::=\n { 1 3 6 1 4 1 22112 2 1 }\n\nprivateKeyPossessionStatement ATTRIBUTE ::= {\n TYPE PrivateKeyPossessionStatement\n IDENTIFIED BY id-at-statementOfPossession }\n\nPrivateKeyPossessionStatement ::= SEQUENCE {\n signer IssuerAndSerialNumber,\n cert Certificate OPTIONAL }", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The components of the PrivateKeyStatement SEQUENCE have the following semantics:", + "ja": "PrivateKeyStatement SEQUENCE のコンポーネントには次のセマンティクスがあります。" + }, + { + "indent": 3, + "text": "signer:", + "ja": "署名者:" + }, + { + "indent": 12, + "text": "The issuer name and certificate serial number of the signature certificate.", + "ja": "署名証明書の発行者名と証明書のシリアル番号。" + }, + { + "indent": 3, + "text": "cert:", + "ja": "証明書:" + }, + { + "indent": 12, + "text": "The signature certificate. If the issuer of the key establishment certificate will be the same as the issuer of the signature certificate, then this component MAY be omitted. When the signature certificate is omitted, the signer is assuming that the CA has a mechanism to obtain all valid certificates that it issued.", + "ja": "署名証明書。鍵確立証明書の発行者が署名証明書の発行者と同じである場合、このコンポーネントは省略してもよい(MAY)。署名証明書が省略された場合、署名者は、CA が発行したすべての有効な証明書を取得するメカニズムを備えていると想定します。" + }, + { + "indent": 0, + "text": "4. Conventions for PKCS#10", + "section_title": true, + "ja": "4. PKCS#10 の規則" + }, + { + "indent": 3, + "text": "This section specifies the conventions for using the attribute for statement of possession of a private key with PKCS#10 [RFC2986] when requesting a key establishment certificate.", + "ja": "このセクションでは、鍵確立証明書を要求する際に、PKCS#10 [RFC2986] で秘密鍵の所有を宣言するための属性を使用するための規則を指定します。" + }, + { + "indent": 3, + "text": "The PKCS#10 CertificationRequest always has three components, as follows:", + "ja": "PKCS#10 CertificationRequest には、次の 3 つのコンポーネントが常に含まれます。" + }, + { + "indent": 3, + "text": "certificationRequestInfo:", + "ja": "認証要求情報:" + }, + { + "indent": 12, + "text": "The subject name SHOULD be the same as the subject name in the signature certificate, the subjectPKInfo MUST contain the public key for the key establishment algorithm, and the attributes MUST include privateKeyPossessionStatement attribute as specified in Section 3 of this document.", + "ja": "サブジェクト名は署名証明書のサブジェクト名と同じである必要があり (SHOULD)、subjectPKInfo には鍵確立アルゴリズムの公開鍵が含まれなければならず、属性にはこの文書のセクション 3 で指定されている privateKeyPossessionStatement 属性が含まれなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "signatureAlgorithm:", + "ja": "署名アルゴリズム:" + }, + { + "indent": 12, + "text": "The signature algorithm MUST be one that can be validated with the public key in the signature certificate.", + "ja": "署名アルゴリズムは、署名証明書内の公開キーを使用して検証できるものでなければなりません。" + }, + { + "indent": 3, + "text": "signature:", + "ja": "サイン：" + }, + { + "indent": 12, + "text": "The signature over certificationRequestInfo MUST validate with the public key in the signature certificate, and certification path validation for the signature certificate MUST be successful as specified in Section 6 of [RFC5280].", + "ja": "[RFC5280] のセクション 6 に規定されているように、certificationRequestInfo に対する署名は署名証明書内の公開鍵を使用して検証しなければならず (MUST)、署名証明書の証明書パスの検証は成功しなければなりません (MUST)。" + }, + { + "indent": 0, + "text": "5. Conventions for CRMF", + "section_title": true, + "ja": "5. CRMF の規約" + }, + { + "indent": 3, + "text": "This section specifies the conventions for using the attribute for statement of possession of a private key with the CRMF [RFC4211] when requesting a key establishment certificate.", + "ja": "このセクションでは、鍵確立証明書を要求する際に、CRMF [RFC4211] で秘密鍵の所有を宣言するための属性を使用するための規則を指定します。" + }, + { + "indent": 3, + "text": "The following ASN.1 types are defined for use with CRMF. They have exactly the same semantics and syntax as the attribute discussed above, but they offer a similar naming convention to the Registration Controls in [RFC4211].", + "ja": "次の ASN.1 タイプは、CRMF で使用するために定義されています。これらは、上で説明した属性とまったく同じセマンティクスと構文を持ちますが、[RFC4211] の登録コントロールと同様の命名規則を提供します。" + }, + { + "indent": 5, + "text": "regCtrl-privateKeyPossessionStatement ATTRIBUTE ::=\n privateKeyPossessionStatement\n\nid-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=\n id-at-statementOfPossession", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The CRMF CertificationRequest always has three components, as follows:", + "ja": "CRMF CertificationRequest には、次の 3 つのコンポーネントが常に含まれます。" + }, + { + "indent": 3, + "text": "certReq:", + "ja": "証明書要求:" + }, + { + "indent": 12, + "text": "The certTemplate MUST include the subject and the publicKey components. The same subject name SHOULD match the subject name in the signature certificate, and publicKey MUST contain the public key for the key establishment algorithm.", + "ja": "certTemplate には、件名と publicKey コンポーネントが含まれなければなりません。同じサブジェクト名が署名証明書内のサブジェクト名と一致する必要があり (SHOULD)、publicKey には鍵確立アルゴリズムの公開鍵が含まれなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "popo:", + "ja": "ポポ:" + }, + { + "indent": 12, + "text": "The ProofOfPossession MUST use the signature CHOICE, the poposkInput MUST be present, POPOSigningKeyInput.authInfo MUST use the sender CHOICE, the sender SHOULD be set to the subject name that appears in the signature certificate, the publicKey MUST contain a copy of the public key from the certTemplate, the algorithmIdentifier MUST identify a signature algorithm that can be validated with the public key in the signature certificate, the signature over the poposkInput MUST validate with the public key in the signature certificate, and certification path validation for the signature certificate MUST be successful as specified in Section 6 of [RFC5280].", + "ja": "ProofOfPossession は署名 CHOICE を使用しなければならず、poposkInput が存在しなければならず、POPOSigningKeyInput.authInfo は送信者 CHOICE を使用しなければならず、送信者は署名証明書に表示されるサブジェクト名に設定される必要があり、publicKey には certTemplate からの公開鍵のコピーが含まれなければならず、algorithmIdentifier は署名証明書内の公開鍵で検証できる署名アルゴリズムを識別しなければなりません。署名終了\n\nPoposkInput は、署名証明書内の公開鍵を使用して検証しなければならず (MUST)、[RFC5280] のセクション 6 に規定されているように、署名証明書の証明書パスの検証が成功しなければなりません (MUST)。" + }, + { + "indent": 3, + "text": "regInfo:", + "ja": "登録情報:" + }, + { + "indent": 12, + "text": "The attributes MUST include the privateKeyPossessionStatement attribute as specified in Section 3 of this document.", + "ja": "このドキュメントのセクション 3 で指定されているように、属性には privateKeyPossessionStatement 属性を含める必要があります。" + }, + { + "indent": 0, + "text": "6. Security Considerations", + "section_title": true, + "ja": "6. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "The privateKeyPossessionStatement attribute MUST NOT be used to obtain a signature certificate. Performing proof of possession of the signature private key is easily accomplished by signing the certificate request.", + "ja": "privateKeyPossessionStatement 属性を署名証明書の取得に使用してはなりません (MUST NOT)。署名秘密キーの所有証明は、証明書要求に署名することで簡単に実行できます。" + }, + { + "indent": 3, + "text": "The subject is signing the privateKeyPossessionStatement attribute to tell the CA that it has possession of the key establishment private key. This is being done instead of providing technical proof of possession. If the subject has lost control of the signature private key, then the signed privateKeyPossessionStatement attribute could be generated by some other party. Timely revocation of the compromised signature certificate is the only protection against such loss of control.", + "ja": "サブジェクトは、privateKeyPossessionStatement 属性に署名して、キー確立秘密キーを所有していることを CA に伝えます。これは、所有の技術的証拠を提供する代わりに行われます。サブジェクトが署名秘密キーの制御を失った場合、署名された privateKeyPossessionStatement 属性が他の当事者によって生成される可能性があります。侵害された署名証明書を適時に取り消すことが、このような制御の喪失を防ぐ唯一の方法です。" + }, + { + "indent": 3, + "text": "If the CA revokes a compromised signature certificate, then the CA SHOULD also revoke all key establishment certificates that were obtained with privateKeyPossessionStatement attributes signed by that compromised signature certificate.", + "ja": "CA が侵害された署名証明書を取り消す場合、CA は、その侵害された署名証明書によって署名された privateKeyPossessionStatement 属性を使用して取得されたすべての鍵確立証明書も取り消す必要があります (SHOULD)。" + }, + { + "indent": 3, + "text": "The signature key pair and the key establishment key pair are expected to have roughly the same security strength. To ensure that the signature on the statement is not the weakest part of the certificate enrollment, the signature key pair SHOULD be at least as strong as the key establishment key pair.", + "ja": "署名キー ペアとキー確立キー ペアは、ほぼ同じセキュリティ強度を持つことが期待されます。ステートメントの署名が証明書登録の最も弱い部分にならないようにするには、署名キー ペアは少なくともキー確立キー ペアと同じくらい強力である必要があります (SHOULD)。" + }, + { + "indent": 3, + "text": "If a CA allows a subject in the key establishment certificate to be different than the subject name in the signature certificate, then certificate policy MUST describe how to determine that the two subject names identify the same entity. Likewise, if a CA allows subject alternative names in the key establishment certificate that are not present in the signature certificate, then certificate policy MUST describe how to determine that the subject alternative names identify the same entity as is named in the signature certificate.", + "ja": "CA が鍵確立証明書のサブジェクトが署名証明書のサブジェクト名と異なることを許可する場合、証明書ポリシーは、2 つのサブジェクト名が同じエンティティを識別することを判断する方法を記述しなければなりません (MUST)。同様に、CA が署名証明書に存在しないサブジェクト代替名を鍵確立証明書で許可する場合、証明書ポリシーは、サブジェクト代替名が署名証明書に指定されているものと同じエンティティを識別することを決定する方法を記述しなければなりません (MUST)。" + }, + { + "indent": 0, + "text": "7. IANA Considerations", + "section_title": true, + "ja": "7. IANAの考慮事項" + }, + { + "indent": 3, + "text": "For the ASN.1 Module in Appendix A of this document, IANA has assigned an object identifier (OID) for the module identifier (118) with a Description of \"id-mod-private-key-possession-stmt-2025\" in the \"SMI Security for PKIX Module Identifier\" registry (1.3.6.1.5.5.7.0).", + "ja": "この文書の付録 A の ASN.1 モジュールについて、IANA は、「SMI Security for PKIX Module Identifier」レジストリ (1.3.6.1.5.5.7.0) 内の「id-mod-private-key-possession-stmt-2025」の説明を持つモジュール識別子 (118) にオブジェクト識別子 (OID) を割り当てました。" + }, + { + "indent": 0, + "text": "8. References", + "section_title": true, + "ja": "8. 参考文献" + }, + { + "indent": 0, + "text": "8.1. Normative References", + "section_title": true, + "ja": "8.1. 引用文献" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2986] Nystrom, M. and B. Kaliski, \"PKCS #10: Certification\n Request Syntax Specification Version 1.7\", RFC 2986,\n DOI 10.17487/RFC2986, November 2000,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4211] Schaad, J., \"Internet X.509 Public Key Infrastructure\n Certificate Request Message Format (CRMF)\", RFC 4211,\n DOI 10.17487/RFC4211, September 2005,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,\n Housley, R., and W. Polk, \"Internet X.509 Public Key\n Infrastructure Certificate and Certificate Revocation List\n (CRL) Profile\", RFC 5280, DOI 10.17487/RFC5280, May 2008,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5912] Hoffman, P. and J. Schaad, \"New ASN.1 Modules for the\n Public Key Infrastructure Using X.509 (PKIX)\", RFC 5912,\n DOI 10.17487/RFC5912, June 2010,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6268] Schaad, J. and S. Turner, \"Additional New ASN.1 Modules\n for the Cryptographic Message Syntax (CMS) and the Public\n Key Infrastructure Using X.509 (PKIX)\", RFC 6268,\n DOI 10.17487/RFC6268, July 2011,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[X680] ITU-T, \"Information technology -- Abstract Syntax Notation\n One (ASN.1): Specification of basic notation\", ITU-T\n Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[X690] ITU-T, \"Information technology -- ASN.1 encoding rules:\n Specification of Basic Encoding Rules (BER), Canonical\n Encoding Rules (CER) and Distinguished Encoding Rules\n (DER)\", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,\n February 2021, .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "8.2. Informative References", + "section_title": true, + "ja": "8.2. 参考引用" + }, + { + "indent": 3, + "text": "[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.\n Wu, \"Internet X.509 Public Key Infrastructure Certificate\n Policy and Certification Practices Framework\", RFC 3647,\n DOI 10.17487/RFC3647, November 2003,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6955] Schaad, J. and H. Prafullchandra, \"Diffie-Hellman Proof-\n of-Possession Algorithms\", RFC 6955, DOI 10.17487/RFC6955,\n May 2013, .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Appendix A. ASN.1 Module", + "section_title": true, + "ja": "付録A. ASN.1モジュール" + }, + { + "indent": 3, + "text": "This ASN.1 Module uses the conventions established by [RFC5912] and [RFC6268].", + "ja": "この ASN.1 モジュールは、[RFC5912] および [RFC6268] によって確立された規則を使用します。" + }, + { + "indent": 3, + "text": "PrivateKeyPossessionStatement-2025\n { iso(1) identified-organization(3) dod(6) internet(1)\n security(5) mechanisms(5) pkix(7) id-mod(0)\n id-mod-private-key-possession-stmt-2025(118) }\n\nDEFINITIONS IMPLICIT TAGS ::= BEGIN\n\nEXPORTS ALL;\n\nIMPORTS\n ATTRIBUTE\n FROM PKIX-CommonTypes-2009 -- in [RFC5912]\n { iso(1) identified-organization(3) dod(6) internet(1)\n security(5) mechanisms(5) pkix(7) id-mod(0)\n id-mod-pkixCommon-02(57) }\n\n Certificate\n FROM PKIX1Explicit-2009 -- in [RFC5912]\n { iso(1) identified-organization(3) dod(6) internet(1)\n security(5) mechanisms(5) pkix(7) id-mod(0)\n id-mod-pkix1-explicit-02(51) }\n\n IssuerAndSerialNumber\n FROM CryptographicMessageSyntax-2010 -- [RFC6268]\n { iso(1) member-body(2) us(840) rsadsi(113549)\n pkcs(1) pkcs-9(9) smime(16) modules(0)\n id-mod-cms-2009(58) } ;\n\n--\n-- Private Key Possession Statement Attribute\n--\n\nid-at-statementOfPossession OBJECT IDENTIFIER ::=\n { 1 3 6 1 4 1 22112 2 1 }\n\nprivateKeyPossessionStatement ATTRIBUTE ::= {\n TYPE PrivateKeyPossessionStatement\n IDENTIFIED BY id-at-statementOfPossession }\n\nPrivateKeyPossessionStatement ::= SEQUENCE {\n signer IssuerAndSerialNumber,\n cert Certificate OPTIONAL }\n\n--\n-- Registration Control Support\n--\n\nRegControlSet ATTRIBUTE ::=\n { regCtrl-privateKeyPossessionStatement, ... }\n\nregCtrl-privateKeyPossessionStatement ATTRIBUTE ::=\n privateKeyPossessionStatement\n\nid-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=\n id-at-statementOfPossession\n\nEND", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Appendix B. Example Use of the privateKeyPossessionStatement Attribute", + "section_title": true, + "ja": "付録B. privateKeyPossessionStatement 属性の使用例" + }, + { + "indent": 3, + "text": "In this example, the self-signed certificate for the CA is as follows:", + "ja": "この例では、CA の自己署名証明書は次のとおりです。" + }, + { + "indent": 3, + "text": "-----BEGIN CERTIFICATE-----\nMIIB7DCCAXKgAwIBAgIUL149AUxHunELBZMELEQm+isgKCQwCgYIKoZIzj0EAwMw\nNzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh\nLmV4YW1wbGUwHhcNMjUwMTAzMjAyNzA5WhcNMzUwMTAzMjAyNzA5WjA3MQswCQYD\nVQQGEwJVUzETMBEGA1UEChMKRXhhbXBsZSBDQTETMBEGA1UEAxMKY2EuZXhhbXBs\nZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABDxZdB/Glcxdk1p6Jf1j5en6QfliY9OS\nfjZbtje/w6M58PN8Sb3VFln1rPdvD17UXeazSG9Hr/Dq3enbsHHO0pPntcFOgb8n\nr8R8LUGhxRzjlxkaEJN+pa6Nf7qk49JDeaM/MD0wDwYDVR0TAQH/BAUwAwEB/zAL\nBgNVHQ8EBAMCAgQwHQYDVR0OBBYEFD6YvLLv3DQbvnGS0qP6bbzyZkCqMAoGCCqG\nSM49BAMDA2gAMGUCMGfb61IigoJ3QDnlsRdoktREHe0Dpm6DKw3qOyLL6A0cFK9Z\ng8m11xIwvptlran52gIxAK1VrOjzRsFiHRptO+gFXstTXnQkKBb2/3WQz2SqcIS/\nBWEp+siJ19OXOlz6APDB7w==\n-----END CERTIFICATE-----", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Alice generates her ECDSA signature key pair. Then, Alice composes a PKCS#10 Certificate Signing Request (CSR) in the usual manner as specified in [RFC2986]. The CSR includes a signature that is produced with her ECDSA private key. The CSR is as follows:", + "ja": "アリスは ECDSA 署名鍵ペアを生成します。次に、アリスは [RFC2986] で指定されている通常の方法で PKCS#10 証明書署名要求 (CSR) を作成します。CSR には、彼女の ECDSA 秘密キーを使用して生成された署名が含まれています。CSRは以下の通りです。" + }, + { + "indent": 3, + "text": "-----BEGIN CERTIFICATE REQUEST-----\nMIIBhTCCAQsCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH\nEwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB2MBAGByqGSM49AgEGBSuBBAAiA2IA\nBIAc+6lXN1MIM/82QeWNb55H0zr+lVgWVeF0bf4jzxCb5MCjVaM0eFEvcjXMV5p4\nkzqiJTHC0V2JAoqYMX/DMFIcwZ7xP9uQd9ep6KZ+RXut211L8+W1QI1QJSDNxANR\nsaBQME4GCSqGSIb3DQEJDjFBMD8wDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCB4Aw\nIgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wCgYIKoZIzj0EAwMD\naAAwZQIwPa2rOCe60edAF43C/t57IW8liyy+69FE04hMAFgw3Ga+nR+8zDuUsVLw\nxXGAHtcDAjEA6LbvNkZjo6j2z5xRIjrHzEbGgiV4MF4xtnpfSSRI4dB0zT52bWkj\nTZsuS1YWIkjt\n-----END CERTIFICATE REQUEST-----", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The CA issues a signature certificate to Alice:", + "ja": "CA は、アリスに署名証明書を発行します。" + }, + { + "indent": 3, + "text": "-----BEGIN CERTIFICATE-----\nMIICJzCCAa6gAwIBAgIUf3Sj/ANs4hR4XFlhTm+N8kxHqHkwCgYIKoZIzj0EAwMw\nNzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh\nLmV4YW1wbGUwHhcNMjUwMTA5MTcwMzQ4WhcNMjYwMTA5MTcwMzQ4WjA8MQswCQYD\nVQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT\nBUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEgBz7qVc3Uwgz/zZB5Y1vnkfT\nOv6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxXmniTOqIlMcLRXYkCipgxf8MwUhzB\nnvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3EA1Gxo3YwdDAMBgNVHRMBAf8EAjAA\nMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A0f7tCzkQEZgYzH3NcM2L05IwHwYD\nVR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJmQKowFwYDVR0gBBAwDjAMBgpghkgB\nZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/Uypd7BaVnUjB36UtX9m5ZmPi78y5\n1RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIwRJ6U91048NAb3nicHcrGFf1UYrhb\nDlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u\n-----END CERTIFICATE-----", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Alice generates her ECDH key establishment key pair. Then, Alice composes a PKCS#10 CSR. The CSR attributes include the privateKeyPossessionStatement attribute, which points to her ECDSA signature certificate. The CSR includes her ECDH public key and a signature that is produced with her ECDSA private key. The CSR is as follows:", + "ja": "アリスは、ECDH 鍵確立鍵ペアを生成します。次に、アリスは PKCS#10 CSR を作成します。CSR 属性には、ECDSA 署名証明書を指す privateKeyPossessionStatement 属性が含まれます。CSR には、彼女の ECDH 公開キーと、ECDSA 秘密キーを使用して生成された署名が含まれています。CSRは以下の通りです。" + }, + { + "indent": 3, + "text": "-----BEGIN CERTIFICATE REQUEST-----\nMIIEMTCCA7gCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH\nEwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB0MA4GBSuBBAEMBgUrgQQAIgNiAAQB\nRyQTH+cq1s5F94uFqFe7l1LqGdEC8Tm+e5VYBCfKAC8MJySQMj1GixEEXL+1Wjtg\n23XvnJouCDoxSpDCSMqf3kvp5+naM37uxa3ZYgD6DPY3me5EZvyZPvSRJTFl/Bag\nggL9MGcGCSqGSIb3DQEJDjFaMFgwDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCAwgw\nIgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wFwYDVR0gBBAwDjAM\nBgpghkgBZQMCATAwMIICkAYKKwYBBAGBrGACATGCAoAwggJ8ME8wNzELMAkGA1UE\nBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUC\nFH90o/wDbOIUeFxZYU5vjfJMR6h5MIICJzCCAa6gAwIBAgIUf3Sj/ANs4hR4XFlh\nTm+N8kxHqHkwCgYIKoZIzj0EAwMwNzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4\nYW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUwHhcNMjUwMTA5MTcwMzQ4WhcN\nMjYwMTA5MTcwMzQ4WjA8MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNV\nBAcTB0hlcm5kb24xDjAMBgNVBAMTBUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACID\nYgAEgBz7qVc3Uwgz/zZB5Y1vnkfTOv6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxX\nmniTOqIlMcLRXYkCipgxf8MwUhzBnvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3E\nA1Gxo3YwdDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A\n0f7tCzkQEZgYzH3NcM2L05IwHwYDVR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJm\nQKowFwYDVR0gBBAwDjAMBgpghkgBZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/\nUypd7BaVnUjB36UtX9m5ZmPi78y51RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIw\nRJ6U91048NAb3nicHcrGFf1UYrhbDlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u\nMAoGCCqGSM49BAMDA2cAMGQCL2TNHPULWcCS2DqZCCiQeSwx2JPLMI14Vi977bzy\nrImq5p0H3Bel6fAS8BnQ00WNAjEAhHDAlcbRuHhqdW6mOgDd5kWEGGqgixIuvEEc\nfVbnNCEyEE4n0mQ99PHURnXoHwqF\n-----END CERTIFICATE REQUEST-----", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The CSR decodes to the following:", + "ja": "CSR は次のようにデコードされます。" + }, + { + "indent": 3, + "text": " 0 1073: SEQUENCE {\n 4 952: SEQUENCE {\n 8 1: INTEGER 0\n 11 60: SEQUENCE {\n 13 11: SET {\n 15 9: SEQUENCE {\n 17 3: OBJECT IDENTIFIER countryName (2 5 4 6)\n 22 2: PrintableString 'US'\n : }\n : }\n 26 11: SET {\n 28 9: SEQUENCE {\n 30 3: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)\n 35 2: PrintableString 'VA'\n : }\n : }\n 39 16: SET {\n 41 14: SEQUENCE {\n 43 3: OBJECT IDENTIFIER localityName (2 5 4 7)\n 48 7: PrintableString 'Herndon'\n : }\n : }\n 57 14: SET {\n 59 12: SEQUENCE {\n 61 3: OBJECT IDENTIFIER commonName (2 5 4 3)\n 66 5: PrintableString 'Alice'\n : }\n : }\n : }\n 73 116: SEQUENCE {\n 75 14: SEQUENCE {\n 77 5: OBJECT IDENTIFIER ECDH (1 3 132 1 12)\n 84 5: OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)\n : }\n 91 98: BIT STRING\n : 04 01 47 24 13 1F E7 2A D6 CE 45 F7 8B 85 A8 57\n : BB 97 52 EA 19 D1 02 F1 39 BE 7B 95 58 04 27 CA\n : 00 2F 0C 27 24 90 32 3D 46 8B 11 04 5C BF B5 5A\n : 3B 60 DB 75 EF 9C 9A 2E 08 3A 31 4A 90 C2 48 CA\n : 9F DE 4B E9 E7 E9 DA 33 7E EE C5 AD D9 62 00 FA\n : 0C F6 37 99 EE 44 66 FC 99 3E F4 91 25 31 65 FC\n : 16\n : }\n 191 765: [0] {\n 195 103: SEQUENCE {\n 197 9: OBJECT IDENTIFIER\n : extensionRequest (1 2 840 113549 1 9 14)\n 208 90: SET {\n 210 88: SEQUENCE {\n 212 12: SEQUENCE {\n 214 3: OBJECT IDENTIFIER\n : basicConstraints (2 5 29 19)\n 219 1: BOOLEAN TRUE\n 222 2: OCTET STRING, encapsulates {\n 224 0: SEQUENCE {}\n : }\n : }\n 226 11: SEQUENCE {\n 228 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)\n 233 4: OCTET STRING, encapsulates {\n 235 2: BIT STRING 3 unused bits\n : '10000'B (bit 4)\n : }\n : }\n 239 34: SEQUENCE {\n 241 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)\n 246 27: OCTET STRING, encapsulates {\n 248 25: SEQUENCE {\n 250 23: [1] 'alice@email.example.com'\n : }\n : }\n : }\n 275 23: SEQUENCE {\n 277 3: OBJECT IDENTIFIER\n : certificatePolicies (2 5 29 32)\n 282 16: OCTET STRING, encapsulates {\n 284 14: SEQUENCE {\n 286 12: SEQUENCE {\n 288 10: OBJECT IDENTIFIER\n : testCertPolicy (2 16 840 1 101 3 2 1 48 48)\n : }\n : }\n : }\n : }\n : }\n : }\n : }\n 300 656: SEQUENCE {\n 304 10: OBJECT IDENTIFIER\n : statementOfPossession (1 3 6 1 4 1 22112 2 1)\n 316 640: SET {\n 320 636: SEQUENCE {\n 324 79: SEQUENCE {\n 326 55: SEQUENCE {\n 328 11: SET {\n 330 9: SEQUENCE {\n 332 3: OBJECT IDENTIFIER countryName (2 5 4 6)\n 337 2: PrintableString 'US'\n : }\n : }\n 341 19: SET {\n 343 17: SEQUENCE {\n 345 3: OBJECT IDENTIFIER\n : organizationName (2 5 4 10)\n 350 10: PrintableString 'Example CA'\n : }\n : }\n 362 19: SET {\n 364 17: SEQUENCE {\n 366 3: OBJECT IDENTIFIER commonName (2 5 4 3)\n 371 10: PrintableString 'ca.example'\n : }\n : }\n : }\n 383 20: INTEGER\n : 7F 74 A3 FC 03 6C E2 14 78 5C 59 61 4E 6F 8D F2\n : 4C 47 A8 79\n : }\n 405 551: SEQUENCE {\n 409 430: SEQUENCE {\n 413 3: [0] {\n 415 1: INTEGER 2\n : }\n 418 20: INTEGER\n : 7F 74 A3 FC 03 6C E2 14 78 5C 59 61 4E 6F 8D F2\n : 4C 47 A8 79\n 440 10: SEQUENCE {\n 442 8: OBJECT IDENTIFIER\n : ecdsaWithSHA384 (1 2 840 10045 4 3 3)\n : }\n 452 55: SEQUENCE {\n 454 11: SET {\n 456 9: SEQUENCE {\n 458 3: OBJECT IDENTIFIER\n : countryName (2 5 4 6)\n 463 2: PrintableString 'US'\n : }\n : }\n 467 19: SET {\n 469 17: SEQUENCE {\n 471 3: OBJECT IDENTIFIER\n : organizationName (2 5 4 10)\n 476 10: PrintableString 'Example CA'\n : }\n : }\n 488 19: SET {\n 490 17: SEQUENCE {\n 492 3: OBJECT IDENTIFIER\n : commonName (2 5 4 3)\n 497 10: PrintableString 'ca.example'\n : }\n : }\n : }\n 509 30: SEQUENCE {\n 511 13: UTCTime 09/01/2025 17:03:48 GMT\n 526 13: UTCTime 09/01/2026 17:03:48 GMT\n : }\n 541 60: SEQUENCE {\n 543 11: SET {\n 545 9: SEQUENCE {\n 547 3: OBJECT IDENTIFIER\n : countryName (2 5 4 6)\n 552 2: PrintableString 'US'\n : }\n : }\n 556 11: SET {\n 558 9: SEQUENCE {\n 560 3: OBJECT IDENTIFIER\n : stateOrProvinceName (2 5 4 8)\n 565 2: PrintableString 'VA'\n : }\n : }\n 569 16: SET {\n 571 14: SEQUENCE {\n 573 3: OBJECT IDENTIFIER\n : localityName (2 5 4 7)\n 578 7: PrintableString 'Herndon'\n : }\n : }\n 587 14: SET {\n 589 12: SEQUENCE {\n 591 3: OBJECT IDENTIFIER\n : commonName (2 5 4 3)\n 596 5: PrintableString 'Alice'\n : }\n : }\n : }\n 603 118: SEQUENCE {\n 605 16: SEQUENCE {\n 607 7: OBJECT IDENTIFIER\n : ecPublicKey (1 2 840 10045 2 1)\n 616 5: OBJECT IDENTIFIER\n : secp384r1 (1 3 132 0 34)\n : }\n 623 98: BIT STRING\n : 04 80 1C FB A9 57 37 53 08 33 FF 36 41 E5 8D 6F\n : 9E 47 D3 3A FE 95 58 16 55 E1 74 6D FE 23 CF 10\n : 9B E4 C0 A3 55 A3 34 78 51 2F 72 35 CC 57 9A 78\n : 93 3A A2 25 31 C2 D1 5D 89 02 8A 98 31 7F C3 30\n : 52 1C C1 9E F1 3F DB 90 77 D7 A9 E8 A6 7E 45 7B\n : AD DB 5D 4B F3 E5 B5 40 8D 50 25 20 CD C4 03 51\n : B1\n : }\n 723 118: [3] {\n 725 116: SEQUENCE {\n 727 12: SEQUENCE {\n 729 3: OBJECT IDENTIFIER\n : basicConstraints (2 5 29 19)\n 734 1: BOOLEAN TRUE\n 737 2: OCTET STRING, encapsulates {\n 739 0: SEQUENCE {}\n : }\n : }\n 741 11: SEQUENCE {\n 743 3: OBJECT IDENTIFIER\n : keyUsage (2 5 29 15)\n 748 4: OCTET STRING, encapsulates {\n 750 2: BIT STRING 7 unused bits\n : '1'B (bit 0)\n : }\n : }\n 754 29: SEQUENCE {\n 756 3: OBJECT IDENTIFIER\n : subjectKeyIdentifier (2 5 29 14)\n 761 22: OCTET STRING, encapsulates {\n 763 20: OCTET STRING\n : 23 1D 00 D1 FE ED 0B 39 10 11 98 18 CC 7D CD 70\n : CD 8B D3 92\n : }\n : }\n 785 31: SEQUENCE {\n 787 3: OBJECT IDENTIFIER\n : authorityKeyIdentifier (2 5 29 35)\n 792 24: OCTET STRING, encapsulates {\n 794 22: SEQUENCE {\n 796 20: [0]\n : 3E 98 BC B2 EF DC 34 1B BE 71 92 D2 A3 FA 6D BC\n : F2 66 40 AA\n : }\n : }\n : }\n 818 23: SEQUENCE {\n 820 3: OBJECT IDENTIFIER\n : certificatePolicies (2 5 29 32)\n 825 16: OCTET STRING, encapsulates {\n 827 14: SEQUENCE {\n 829 12: SEQUENCE {\n 831 10: OBJECT IDENTIFIER\n : testCertPolicy (2 16 840 1 101 3 2 1 48 48)\n : }\n : }\n : }\n : }\n : }\n : }\n : }\n 843 10: SEQUENCE {\n 845 8: OBJECT IDENTIFIER\n : ecdsaWithSHA384 (1 2 840 10045 4 3 3)\n : }\n 855 103: BIT STRING, encapsulates {\n 858 100: SEQUENCE {\n 860 48: INTEGER\n : 6B BF 53 2A 5D EC 16 95 9D 48 C1 DF A5 2D 5F D9\n : B9 66 63 E2 EF CC B9 D5 10 3C 5A 16 CE BF 42 90\n : 56 B7 18 B6 3E 2A 39 D8 8C 54 A0 5C A1 57 1E C8\n 910 48: INTEGER\n : 44 9E 94 F7 5D 38 F0 D0 1B DE 78 9C 1D CA C6 15\n : FD 54 62 B8 5B 0E 5C AD 2B 8B 42 6B 91 C1 C4 3F\n : EA 02 0C B8 FD E5 33 03 93 59 C1 56 8B 2B BF 2E\n : }\n : }\n : }\n : }\n : }\n : }\n : }\n : }\n 960 10: SEQUENCE {\n 962 8: OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)\n : }\n 972 103: BIT STRING, encapsulates {\n 975 100: SEQUENCE {\n 977 47: INTEGER\n : 64 CD 1C F5 0B 59 C0 92 D8 3A 99 08 28 90 79 2C\n : 31 D8 93 CB 30 8D 78 56 2F 7B ED BC F2 AC 89 AA\n : E6 9D 07 DC 17 A5 E9 F0 12 F0 19 D0 D3 45 8D\n1026 49: INTEGER\n : 00 84 70 C0 95 C6 D1 B8 78 6A 75 6E A6 3A 00 DD\n : E6 45 84 18 6A A0 8B 12 2E BC 41 1C 7D 56 E7 34\n : 21 32 10 4E 27 D2 64 3D F4 F1 D4 46 75 E8 1F 0A\n : 85\n : }\n : }\n : }", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The CA issues a key establishment certificate to Alice:", + "ja": "CA は鍵確立証明書をアリスに発行します。" + }, + { + "indent": 3, + "text": "-----BEGIN CERTIFICATE-----\nMIICJTCCAaygAwIBAgIUf3Sj/ANs4hR4XFlhTm+N8kxHqHowCgYIKoZIzj0EAwMw\nNzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh\nLmV4YW1wbGUwHhcNMjUwMTA5MTcwNTAwWhcNMjYwMTA5MTcwNTAwWjA8MQswCQYD\nVQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT\nBUFsaWNlMHQwDgYFK4EEAQwGBSuBBAAiA2IABAFHJBMf5yrWzkX3i4WoV7uXUuoZ\n0QLxOb57lVgEJ8oALwwnJJAyPUaLEQRcv7VaO2Dbde+cmi4IOjFKkMJIyp/eS+nn\n6dozfu7FrdliAPoM9jeZ7kRm/Jk+9JElMWX8FqN2MHQwDAYDVR0TAQH/BAIwADAL\nBgNVHQ8EBAMCAwgwHQYDVR0OBBYEFAnLfJvnEUcvLXaPUDZMZlQ/zZ3WMB8GA1Ud\nIwQYMBaAFD6YvLLv3DQbvnGS0qP6bbzyZkCqMBcGA1UdIAQQMA4wDAYKYIZIAWUD\nAgEwMDAKBggqhkjOPQQDAwNnADBkAjARQ5LuV6yz8A5DZCll1S/gfxZ+QSJl/pKc\ncTL6Sdr1IS18U/zY8VUJeB2H0nBamLwCMBRQ6sEWpNoeeR8Bonpoot/zYD2luQ1V\n2jevmYsnBihKF0debgfhGvh8WIgBR69DZg==\n-----END CERTIFICATE-----", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Acknowledgements", + "section_title": true, + "ja": "謝辞" + }, + { + "indent": 3, + "text": "Thanks to Sean Turner, Joe Mandel, Mike StJohns, Mike Ounsworth, John Gray, Carl Wallace, Corey Bonnell, Hani Ezzadeen, Deb Cooley, Mohamed Boucadair, and Bron Gondwana for their constructive comments.", + "ja": "Sean Turner、Joe Mandel、Mike StJohns、Mike Ounsworth、John Gray、Carl Wallace、Corey Bonnell、Hani Ezzadeen、Deb Cooley、Mohamed Boucadair、Bron Gondwana の建設的なコメントに感謝します。" + }, + { + "indent": 0, + "text": "Author's Address", + "section_title": true, + "ja": "著者の連絡先" + }, + { + "indent": 3, + "text": "Russ Housley\nVigil Security, LLC\nHerndon, VA\nUnited States of America\nEmail: housley@vigilsec.com", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/html/data-rfc-list.json b/html/data-rfc-list.json index b8ca3d14a..00785bf17 100644 --- a/html/data-rfc-list.json +++ b/html/data-rfc-list.json @@ -52384,10 +52384,16 @@ "st": "Proposed Standard", "wg": "bess" }, + "9858": { + "st": "Informational" + }, "9859": { "st": "Proposed Standard", "wg": "dnsop" }, + "9861": { + "st": "Informational" + }, "9865": { "upd": [ "7643", @@ -52419,10 +52425,18 @@ "st": "Informational", "wg": "v6ops" }, + "9873": { + "st": "Proposed Standard", + "wg": "regext" + }, "9874": { "st": "Best Current Practice", "wg": "regext" }, + "9877": { + "st": "Proposed Standard", + "wg": "regext" + }, "9879": { "obs": [ "9579" @@ -52433,5 +52447,9 @@ ], "st": "Informational", "wg": "lamps" + }, + "9883": { + "st": "Proposed Standard", + "wg": "lamps" } } \ No newline at end of file diff --git a/html/index.html b/html/index.html index bdc2b7bfa..ffb6ba271 100644 --- a/html/index.html +++ b/html/index.html @@ -62,6 +62,9 @@

RFC文書を自動翻訳したページ一覧

+ + RFC 9883 - An Attribute for Statement of Possession of a Private Key + RFC 9879 - Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax @@ -71,15 +74,30 @@

RFC文書を自動翻訳したページ一覧

RFC 9872 - Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis + + RFC 9870 - Export of UDP Options Information in IP Flow Information Export (IPFIX) + + + RFC 9869 - Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options + RFC 9868 - Transport Options for UDP + + RFC 9866 - Root Node Failure Detector (RNFD): Fast Detection of Border Router Crashes in the Routing Protocol for Low-Power and Lossy Networks (RPL) + RFC 9865 - Cursor-Based Pagination of System of Cross-domain Identity Management (SCIM) Resources + + RFC 9861 - KangarooTwelve and TurboSHAKE + RFC 9859 - Generalized DNS Notifications + + RFC 9858 - Additional Parameter Sets for HSS/LMS Hash-Based Signatures + RFC 9856 - Multicast Source Redundancy in EVPNs diff --git a/html/rfc9858.html b/html/rfc9858.html new file mode 100644 index 000000000..e02d23a49 --- /dev/null +++ b/html/rfc9858.html @@ -0,0 +1,2446 @@ + + + + + + RFC 9858 - Additional Parameter Sets for HSS/LMS Hash-Based Signatures 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Research Task Force (IRTF)                           S. Fluhrer
+Request for Comments: 9858                                 Cisco Systems
+Category: Informational                                          Q. Dang
+ISSN: 2070-1721                                                     NIST
+                                                            October 2025
+
+
+
+
+
+
+Additional Parameter Sets for HSS/LMS Hash-Based Signatures +
+
+
+
+HSS/LMS ハッシュベース署名の追加パラメーター セット +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document extends HSS/LMS (RFC 8554) by defining parameter sets that use alternative hash functions. These include hash functions that result in signatures with significantly smaller sizes than the signatures that use the RFC 8554 parameter sets and should have sufficient security. +

+
+
+

+このドキュメントは、代替ハッシュ関数を使用するパラメータ セットを定義することにより、HSS/LMS (RFC 8554) を拡張します。これらには、RFC 8554 パラメーター セットを使用する署名よりも大幅に小さいサイズの署名が生成され、十分なセキュリティが必要なハッシュ関数が含まれます。 +

+
+
+
+
+

+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 Crypto Forum 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. +

+
+
+

+この文書は Internet Research Task Force (IRTF) の成果物です。IRTF は、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開には適していない可能性があります。この RFC は、インターネット研究タスクフォース (IRTF) の暗号フォーラム研究グループの合意を表しています。IRSG によって公開が承認された文書は、どのレベルのインターネット標準の候補でもありません。RFC 7841 のセクション 2 を参照してください。 +

+
+
+
+
+
+Status of This Memo +
+
+
+
+本文書の位置付け +
+
+
+
+
+

+This document is not an Internet Standards Track specification; it is published for informational purposes. +

+
+
+

+この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。 +

+
+
+
+
+

+This document is a product of the Internet 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 Crypto Forum 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. +

+
+
+

+この文書は Internet Research Task Force (IRTF) の成果物です。IRTF は、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開には適していない可能性があります。この RFC は、インターネット研究タスクフォース (IRTF) の暗号フォーラム研究グループの合意を表しています。IRSG によって公開が承認された文書は、どのレベルのインターネット標準の候補でもありません。RFC 7841 のセクション 2 を参照してください。 +

+
+
+
+
+

+Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9858. +

+
+
+

+この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9858 で入手できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+Copyright (c) 2025 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+   2.  Additional Hash Function Definitions
+     2.1.  192-Bit Hash Function Based on SHA-256
+     2.2.  256-Bit Hash Function Based on SHAKE256
+     2.3.  192-Bit Hash Function Based on SHAKE256
+   3.  Additional LM-OTS Parameter Sets
+   4.  Additional LMS Parameter Sets
+   5.  Usage for These Additional Hash Functions within HSS
+   6.  Parameter Set Selection
+   7.  Comparisons of 192-Bit and 256-Bit Parameter Sets
+   8.  Security Considerations
+     8.1.  Note on the Version of SHAKE
+   9.  IANA Considerations
+   10. References
+     10.1.  Normative References
+     10.2.  Informative References
+   Appendix A.  Test Cases
+     A.1.  Test Case 1 - SHA-256/192
+     A.2.  Test Vector for SHAKE256/192
+     A.3.  Test Vector for SHA-256/256
+     A.4.  Test Vector for SHA-256/192, W=4
+   Acknowledgements
+   Authors' Addresses
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+Stateful hash-based signatures have small private and public keys, are efficient to compute, and are believed to have excellent security. One disadvantage is that the signatures they produce tend to be somewhat large (possibly 1-4 kilobytes). This document defines a set of parameter sets for the HSS/LMS stateful hash-based signature method [RFC8554] that reduce the size of the signature significantly or rely on a hash function other than SHA-256 (to increase cryptodiversity). +

+
+
+

+ステートフル ハッシュ ベースの署名には小さな秘密キーと公開キーがあり、計算が効率的で、セキュリティが優れていると考えられています。欠点の 1 つは、生成される署名がやや大きくなる傾向があることです (おそらく 1 ～ 4 キロバイト)。この文書は、署名のサイズを大幅に削減するか、(暗号多様性を高めるために) SHA-256 以外のハッシュ関数に依存する、HSS/LMS ステートフル ハッシュベースの署名方法 [RFC8554] の一連のパラメーター セットを定義します。 +

+
+
+
+
+

+This document represents the consensus of the Crypto Forum Research Group (CFRG) in the IRTF. It is not an IETF product and is not a standard. +

+
+
+

+この文書は、IRTF の暗号フォーラム研究グループ (CFRG) の総意を表しています。これは IETF 製品ではなく、標準でもありません。 +

+
+
+
+
+

+According to official definitions and common usage, a Leighton-Micali Signature (LMS) is a stateful hash-based signature scheme that is based on a single-level Merkle tree. The Hierarchical Signature System (HSS) is a way of binding several LMS signatures together in a hierarchical manner to increase the number of signatures available. Strictly speaking, all the signatures discussed in this document are HSS signatures (even if the HSS signature consists of a single LMS signature). However, it is common to refer to these signatures as "LMS signatures". This document uses the term "HSS/LMS" to cover both the pedantic and the common meanings. +

+
+
+

+公式の定義と一般的な使用法によれば、Leighton-Micali Signature (LMS) は、単一レベルのマークル ツリーに基づくステートフル ハッシュ ベースの署名スキームです。階層署名システム (HSS) は、複数の LMS 署名を階層的にバインドして、利用可能な署名の数を増やす方法です。厳密に言えば、このドキュメントで説明するすべての署名は HSS 署名です (HSS 署名が単一の LMS 署名で構成されている場合でも)。ただし、これらの署名を「LMS 署名」と呼ぶのが一般的です。このドキュメントでは、衒学的な意味と一般的な意味の両方をカバーするために「HSS/LMS」という用語を使用します。 +

+
+
+
+
+

+This document is intended to be compatible with the NIST document [NIST_SP_800-208]. +

+
+
+

+この文書は、NIST 文書 [NIST_SP_800-208] と互換性を持つことを目的としています。 +

+
+
+
+
+
+2. Additional Hash Function Definitions +
+
+
+
+2. 追加のハッシュ関数定義 +
+
+
+
+
+

+This section defines three hash functions that are used with the parameter sets defined in Sections 3 and 4. These hash functions are used where SHA-256 is used in the original parameter sets from [RFC8554]. The hash function used is specified by the parameter set that is selected. +

+
+
+

+このセクションでは、セクション 3 と 4 で定義されたパラメータ セットで使用される 3 つのハッシュ関数を定義します。これらのハッシュ関数は、[RFC8554] の元のパラメータ セットで SHA-256 が使用される場合に使用されます。使用されるハッシュ関数は、選択されたパラメータ セットによって指定されます。 +

+
+
+
+
+
+2.1. 192-Bit Hash Function Based on SHA-256 +
+
+
+
+2.1. SHA-256 に基づく 192 ビット ハッシュ関数 +
+
+
+
+
+

+This document defines a SHA-2-based hash function with a 192-bit output. As such, we define SHA-256/192 as a truncated version of SHA-256 [FIPS180]. That is, it is the result of performing a SHA-256 operation to a message and then omitting the final 64 bits of the output. This procedure for truncating the hash output to 192 bits is described in Section 7 of [FIPS180]. +

+
+
+

+このドキュメントでは、192 ビット出力の SHA-2 ベースのハッシュ関数を定義します。そのため、SHA-256/192 を SHA-256 [FIPS180] の短縮バージョンとして定義します。つまり、メッセージに対して SHA-256 操作を実行し、出力の最後の 64 ビットを省略した結果です。ハッシュ出力を 192 ビットに切り詰めるこの手順は、[FIPS180] のセクション 7 で説明されています。 +

+
+
+
+
+

+The following test vector illustrates this: +

+
+
+

+次のテスト ベクトルはこれを示しています。 +

+
+
+
+
+ 
+     SHA-256("abc")     = ba7816bf 8f01cfea 414140de 5dae2223
+                          b00361a3 96177a9c b410ff61 f20015ad
+     SHA-256/192("abc") = ba7816bf 8f01cfea 414140de 5dae2223
+                          b00361a3 96177a9c
+
+
+
+
+
+

+We use the same initial hash value (initialization vector) as the untruncated SHA-256, rather than defining a distinct one, so that we can use a standard SHA-256 hash implementation without modification. In addition, the fact that anyone gets partial knowledge of the SHA-256 hash of a message by examining the SHA-256/192 hash of the same message is not a concern for this application. Each message that is hashed is randomized. Any message being signed includes the C randomizer (a value that is selected by the signer and is included in the hash), which varies per message. Therefore, signing the same message by SHA-256 and by SHA-256/192 will not result in the same value being hashed, and so the latter hash value is not a prefix of the former one. In addition, all hashes include the I identifier, which is included as a part of the signature process in [RFC8554]. This I identifier is selected randomly for each private key (and hence two keys will have different I values with high probability), and so two intermediate hashes computed as a part of signing with two HSS private keys (one with a SHA-256 parameter set and one with a SHA-256/192 parameter set) will also be distinct with high probability. +

+
+
+

+標準の SHA-256 ハッシュ実装を変更せずに使用できるように、別個のハッシュ値を定義するのではなく、切り捨てられていない SHA-256 と同じ初期ハッシュ値 (初期化ベクトル) を使用します。さらに、同じメッセージの SHA-256/192 ハッシュを調べることで、メッセージの SHA-256 ハッシュの部分的な知識が誰でも得られるという事実は、このアプリケーションでは問題になりません。ハッシュ化される各メッセージはランダム化されます。署名されるメッセージには C ランダマイザー (署名者によって選択され、ハッシュに含まれる値) が含まれており、これはメッセージごとに異なります。したがって、SHA-256 と SHA-256/192 で同じメッセージに署名しても、同じ値がハッシュされることはなく、後者のハッシュ値は前者のハッシュ値のプレフィックスではありません。さらに、すべてのハッシュには I 識別子が含まれており、これは [RFC8554] の署名プロセスの一部として含まれています。この I 識別子は秘密キーごとにランダムに選択されます (したがって、2 つのキーは高い確率で異なる I 値を持つことになります)。そのため、2 つの HSS 秘密キー (SHA-256 パラメーター セットを持つ 1 つと SHA-256/192 パラメーター セットを持つ 1 つ) を使用した署名の一部として計算される 2 つの中間ハッシュも、高い確率で区別されます。 +

+
+
+
+
+
+2.2. 256-Bit Hash Function Based on SHAKE256 +
+
+
+
+2.2. SHAKE256に基づく256ビットハッシュ関数 +
+
+
+
+
+

+This document defines a SHAKE-based hash function with a 256-bit output. As such, we define SHAKE256/256 to be the first 256 bits of the SHAKE256 extendable-output function (XOF). That is, it is the result of performing a SHAKE-256 operation to a message and then using the first 256 bits of output. See [FIPS202] for more detail. +

+
+
+

+このドキュメントでは、256 ビット出力の SHAKE ベースのハッシュ関数を定義します。そのため、SHAKE256/256 を SHAKE256 拡張可能出力関数 (XOF) の最初の 256 ビットとして定義します。つまり、メッセージに対して SHAKE-256 操作を実行し、出力の最初の 256 ビットを使用した結果です。詳細については、[FIPS202] を参照してください。 +

+
+
+
+
+
+2.3. 192-Bit Hash Function Based on SHAKE256 +
+
+
+
+2.3. SHAKE256に基づく192ビットハッシュ関数 +
+
+
+
+
+

+This document defines a SHAKE-based hash function with a 192-bit output. As such, we define SHAKE256/192 to be the first 192 bits of the SHAKE256 XOF. That is, it is the result of performing a SHAKE-256 operation to a message and then using the first 192 bits of output. See [FIPS202] for more detail. +

+
+
+

+This document defines a SHAKE-based hash function with a 192-bit output.そのため、SHAKE256/192 を SHAKE256 XOF の最初の 192 ビットとして定義します。つまり、これはメッセージに対して SHAKE-256 操作を実行し、出力の最初の 192 ビットを使用した結果です。詳細については、[FIPS202] を参照してください。 +

+
+
+
+
+
+3. Additional LM-OTS Parameter Sets +
+
+
+
+3. 追加のLM-OTSパラメータセット +
+
+
+
+
+

+The table below defines the Leighton-Micali One-Time Signature (LM-OTS) parameters that use the hashes defined in Section 2: +

+
+
+

+以下の表は、セクション 2 で定義されたハッシュを使用する Leighton-Micali ワンタイム署名 (LM-OTS) パラメーターを定義しています。 +

+
+
+
+
+ 
+  +=====================+==============+==+=+=====+====+============+
+  | Parameter Set Name  |      H       | n|w|   p | ls |     id     |
+  +=====================+==============+==+=+=====+====+============+
+  | LMOTS_SHA256_N24_W1 | SHA-256/192  |24|1| 200 |  8 | 0x00000005 |
+  +---------------------+--------------+--+-+-----+----+------------+
+  | LMOTS_SHA256_N24_W2 | SHA-256/192  |24|2| 101 |  6 | 0x00000006 |
+  +---------------------+--------------+--+-+-----+----+------------+
+  | LMOTS_SHA256_N24_W4 | SHA-256/192  |24|4|  51 |  4 | 0x00000007 |
+  +---------------------+--------------+--+-+-----+----+------------+
+  | LMOTS_SHA256_N24_W8 | SHA-256/192  |24|8|  26 |  0 | 0x00000008 |
+  +---------------------+--------------+--+-+-----+----+------------+
+  | LMOTS_SHAKE_N32_W1  | SHAKE256/256 |32|1| 265 |  7 | 0x00000009 |
+  +---------------------+--------------+--+-+-----+----+------------+
+  | LMOTS_SHAKE_N32_W2  | SHAKE256/256 |32|2| 133 |  6 | 0x0000000A |
+  +---------------------+--------------+--+-+-----+----+------------+
+  | LMOTS_SHAKE_N32_W4  | SHAKE256/256 |32|4|  67 |  4 | 0x0000000B |
+  +---------------------+--------------+--+-+-----+----+------------+
+  | LMOTS_SHAKE_N32_W8  | SHAKE256/256 |32|8|  34 |  0 | 0x0000000C |
+  +---------------------+--------------+--+-+-----+----+------------+
+  | LMOTS_SHAKE_N24_W1  | SHAKE256/192 |24|1| 200 |  8 | 0x0000000D |
+  +---------------------+--------------+--+-+-----+----+------------+
+  | LMOTS_SHAKE_N24_W2  | SHAKE256/192 |24|2| 101 |  6 | 0x0000000E |
+  +---------------------+--------------+--+-+-----+----+------------+
+  | LMOTS_SHAKE_N24_W4  | SHAKE256/192 |24|4|  51 |  4 | 0x0000000F |
+  +---------------------+--------------+--+-+-----+----+------------+
+  | LMOTS_SHAKE_N24_W8  | SHAKE256/192 |24|8|  26 |  0 | 0x00000010 |
+  +---------------------+--------------+--+-+-----+----+------------+
+
+                                Table 1
+
+
+
+
+
+

+Parameter Set Name: +

+
+
+

+パラメータセット名: +

+
+
+
+
+

+The human-readable name of the parameter set. +

+
+
+

+人間が判読できるパラメータ セットの名前。 +

+
+
+
+
+

+H: +

+
+
+

+ひ: +

+
+
+
+
+

+The second-preimage-resistant cryptographic hash function used within this parameter set. +

+
+
+

+このパラメータ セット内で使用される 2 番目のプリイメージ耐性のある暗号化ハッシュ関数。 +

+
+
+
+
+

+n: +

+
+
+

+n: +

+
+
+
+
+

+The number of bytes of the output of the hash function. +

+
+
+

+ハッシュ関数の出力のバイト数。 +

+
+
+
+
+

+w: +

+
+
+

+w: +

+
+
+
+
+

+The width (in bits) of the Winternitz coefficients; that is, the number of bits from the hash or checksum that is used with a single Winternitz chain. It is a member of the set { 1, 2, 4, 8 }. +

+
+
+

+Winternitz 係数の幅 (ビット単位)。つまり、単一の Winternitz チェーンで使用されるハッシュまたはチェックサムのビット数です。これは集合 { 1, 2, 4, 8 } のメンバーです。 +

+
+
+
+
+

+p: +

+
+
+

+p: +

+
+
+
+
+

+The number of n-byte string elements that make up the LM-OTS signature. +

+
+
+

+LM-OTS 署名を構成する n バイトの文字列要素の数。 +

+
+
+
+
+

+ls: +

+
+
+

+ls: +

+
+
+
+
+

+The number of left-shift bits used in the checksum function Cksm (used by algorithm 2 of [RFC8554]). +

+
+
+

+チェックサム関数 Cksm ([RFC8554] のアルゴリズム 2 で使用) で使用される左シフト ビットの数。 +

+
+
+
+
+

+id: +

+
+
+

+id: +

+
+
+
+
+

+The IANA-defined identifier used to denote this specific parameter set, which appears in both public keys and signatures. +

+
+
+

+この特定のパラメータ セットを示すために使用される IANA 定義の識別子。公開鍵と署名の両方に表示されます。 +

+
+
+
+
+

+These values are additions to the entries in Table 1 of [RFC8554]. +

+
+
+

+これらの値は、[RFC8554] の表 1 のエントリに追加されたものです。 +

+
+
+
+
+

+The SHA256_N24, SHAKE_N32, and SHAKE_N24 in the parameter set names denote the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions defined in Section 2. +

+
+
+

+パラメータ セット名の SHA256_N24、SHAKE_N32、および SHAKE_N24 は、セクション 2 で定義された SHA-256/192、SHAKE256/256、および SHAKE256/192 ハッシュ関数を示します。 +

+
+
+
+
+

+Remember that the C message randomizer (which is included in the signature) has the same size (n bytes) as the hash output, and so it shrinks from 32 bytes to 24 bytes for the parameter sets that use either SHA-256/192 or SHAKE256/192. +

+
+
+

+C メッセージ ランダマイザー (署名に含まれる) のサイズはハッシュ出力と同じ (n バイト) であるため、SHA-256/192 または SHAKE256/192 を使用するパラメーター セットでは 32 バイトから 24 バイトに縮小されることに注意してください。 +

+
+
+
+
+
+4. Additional LMS Parameter Sets +
+
+
+
+4. 追加の LMS パラメータ セット +
+
+
+
+
+

+The table below defines several many-time signature parameters called Leighton-Micali Signature (LMS) parameters, using the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions: +

+
+
+

+以下の表は、SHA-256/192、SHAKE256/256、および SHAKE256/192 ハッシュ関数を使用して、Leighton-Micali Signature (LMS) パラメーターと呼ばれる複数の複数回署名パラメーターを定義しています。 +

+
+
+
+
+ 
+        +====================+==============+====+====+============+
+        | Parameter Set Name |      H       |  m |  h |     id     |
+        +====================+==============+====+====+============+
+        | LMS_SHA256_M24_H5  | SHA-256/192  | 24 |  5 | 0x0000000A |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHA256_M24_H10 | SHA-256/192  | 24 | 10 | 0x0000000B |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHA256_M24_H15 | SHA-256/192  | 24 | 15 | 0x0000000C |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHA256_M24_H20 | SHA-256/192  | 24 | 20 | 0x0000000D |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHA256_M24_H25 | SHA-256/192  | 24 | 25 | 0x0000000E |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHAKE_M32_H5   | SHAKE256/256 | 32 |  5 | 0x0000000F |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHAKE_M32_H10  | SHAKE256/256 | 32 | 10 | 0x00000010 |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHAKE_M32_H15  | SHAKE256/256 | 32 | 15 | 0x00000011 |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHAKE_M32_H20  | SHAKE256/256 | 32 | 20 | 0x00000012 |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHAKE_M32_H25  | SHAKE256/256 | 32 | 25 | 0x00000013 |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHAKE_M24_H5   | SHAKE256/192 | 24 |  5 | 0x00000014 |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHAKE_M24_H10  | SHAKE256/192 | 24 | 10 | 0x00000015 |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHAKE_M24_H15  | SHAKE256/192 | 24 | 15 | 0x00000016 |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHAKE_M24_H20  | SHAKE256/192 | 24 | 20 | 0x00000017 |
+        +--------------------+--------------+----+----+------------+
+        | LMS_SHAKE_M24_H25  | SHAKE256/192 | 24 | 25 | 0x00000018 |
+        +--------------------+--------------+----+----+------------+
+
+                                  Table 2
+
+
+
+
+
+

+Parameter Set Name: +

+
+
+

+パラメータセット名: +

+
+
+
+
+

+The human-readable name of the parameter set. +

+
+
+

+人間が判読できるパラメータ セットの名前。 +

+
+
+
+
+

+H: +

+
+
+

+ひ: +

+
+
+
+
+

+The second-preimage-resistant cryptographic hash function used within this parameter set. +

+
+
+

+このパラメータ セット内で使用される 2 番目のプリイメージ耐性のある暗号化ハッシュ関数。 +

+
+
+
+
+

+m: +

+
+
+

+メートル: +

+
+
+
+
+

+The size in bytes of the hash function output. +

+
+
+

+ハッシュ関数出力のバイト単位のサイズ。 +

+
+
+
+
+

+h: +

+
+
+

+h: +

+
+
+
+
+

+The height of the Merkle tree. +

+
+
+

+マークル ツリーの高さ。 +

+
+
+
+
+

+id: +

+
+
+

+id: +

+
+
+
+
+

+The IANA-defined identifier used to denote this specific parameter set, which appears in both public keys and signatures. +

+
+
+

+この特定のパラメータ セットを示すために使用される IANA 定義の識別子。公開鍵と署名の両方に表示されます。 +

+
+
+
+
+

+These values are additions to the entries in Table 2 of [RFC8554]. +

+
+
+

+これらの値は、[RFC8554] の表 2 のエントリに追加されたものです。 +

+
+
+
+
+

+The SHA256_M24, SHAKE_M32, and SHAKE_M24 in the parameter set names denote the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions defined in Section 2. +

+
+
+

+パラメータ セット名の SHA256_M24、SHAKE_M32、および SHAKE_M24 は、セクション 2 で定義された SHA-256/192、SHAKE256/256、および SHAKE256/192 ハッシュ関数を示します。 +

+
+
+
+
+
+5. Usage for These Additional Hash Functions within HSS +
+
+
+
+5. HSS 内でのこれらの追加ハッシュ関数の使用法 +
+
+
+
+
+

+To use the additional hash functions within HSS, one would use the appropriate LM-OTS id from Table 1 and the appropriate LMS id from Table 2 and use that additional hash function when computing the hashes for key generation, signature generation, and signature verification. +

+
+
+

+HSS 内で追加のハッシュ関数を使用するには、表 1 の適切な LM-OTS ID と表 2 の適切な LMS ID を使用し、キーの生成、署名の生成、および署名の検証のハッシュを計算するときにその追加のハッシュ関数を使用します。 +

+
+
+
+
+

+Note that the size of the I Merkle tree identifier remains 16 bytes, independent of what hash function is used. +

+
+
+

+I マークル ツリー識別子のサイズは、使用されるハッシュ関数に関係なく、16 バイトのままであることに注意してください。 +

+
+
+
+
+
+6. Parameter Set Selection +
+
+
+
+6. パラメータセットの選択 +
+
+
+
+
+

+This document, along with [RFC8554], defines four hash functions for use within HSS/LMS: SHA-256, SHA-256/192, SHAKE256/256, and SHAKE256/192. The main reason one would select a hash with a 192-bit output (either SHA-256/192 or SHAKE256/192) would be to reduce the signature size; this comes at the cost of reducing the security margin. However, the security should be sufficient for most uses. +

+
+
+

+この文書は、[RFC8554] とともに、HSS/LMS 内で使用する 4 つのハッシュ関数、SHA-256、SHA-256/192、SHAKE256/256、および SHAKE256/192 を定義します。192 ビット出力のハッシュ (SHA-256/192 または SHAKE256/192) を選択する主な理由は、署名のサイズを減らすためです。これには、セキュリティマージンが減少するという代償が伴います。ただし、セキュリティはほとんどの用途には十分です。 +

+
+
+
+
+

+In contrast, there is no security or signature size difference between the SHA-256-based parameter sets (SHA-256 or SHA-256/192) versus the SHAKE-based parameter sets (SHAKE256/256 or SHAKE256/192). The reason for selecting between the two would be based on practical considerations, for example, if the implementation happens to have an existing SHA-256 (or SHAKE) implementation or if one of the two happens to give better hashing performance on the platform. +

+
+
+

+対照的に、SHA-256 ベースのパラメータ セット (SHA-256 または SHA-256/192) と SHAKE ベースのパラメータ セット (SHAKE256/256 または SHAKE256/192) の間には、セキュリティや署名サイズの違いはありません。2 つのどちらかを選択する理由は、実装にたまたま既存の SHA-256 (または SHAKE) 実装があるかどうか、または 2 つのうちの 1 つがたまたまプラットフォーム上でより優れたハッシュ パフォーマンスを提供するかどうかなど、実際的な考慮事項に基づいています。 +

+
+
+
+
+
+7. Comparisons of 192-Bit and 256-Bit Parameter Sets +
+
+
+
+7. 192 ビットと 256 ビットのパラメータ セットの比較 +
+
+
+
+
+

+Switching to a 192-bit hash affects the signature size, the computation time, and the security strength. It significantly reduces the signature size and somewhat reduces the computation time, at the cost of security strength. See Section 8 for a discussion of the security strength. +

+
+
+

+192 ビット ハッシュに切り替えると、署名のサイズ、計算時間、セキュリティ強度に影響します。これにより、セキュリティ強度は犠牲になりますが、署名のサイズが大幅に縮小され、計算時間が若干短縮されます。セキュリティ強度の説明については、セクション 8 を参照してください。 +

+
+
+
+
+

+The impact on signature size and computation time is based on two effects: +

+
+
+

+署名のサイズと計算時間への影響は、次の 2 つの影響に基づいています。 +

+
+
+
+
+

+1. Each hash that appears in the signature is shorter. +

+
+
+

+1. 署名に含まれる各ハッシュは短くなります。 +

+
+
+
+
+

+2. We need fewer Winternitz chains (because LM-OTS signs a shorter value). +

+
+
+

+2. 必要な Winternitz チェーンの数は少なくなります (LM-OTS がより短い値に署名するため)。 +

+
+
+
+
+

+For signature length, both effects are relevant. The first is relevant because the signature consists of a series of hashes and each hash is shorter. The second is relevant because when we need fewer Winternitz chains, we need fewer hashes in each LM-OTS signature. +

+
+
+

+署名の長さについては、両方の効果が関係します。署名は一連のハッシュで構成され、各ハッシュは短いため、最初のものが重要です。2 つ目は、必要な Winternitz チェーンが少なくなると、各 LM-OTS 署名に必要なハッシュが少なくなるため、関連性があります。 +

+
+
+
+
+

+For computation time (for both signature generation and verification), effect 1 is irrelevant (we still need to perform essentially the same hash computation), but effect 2 still applies. For example, with W=8, SHA-256 requires 34 Winternitz chains per LM-OTS signature, but SHA-256/192 requires only 26. Since the vast majority of time (for both signature generation and verification) is spent computing these Winternitz chains, this reduction in the number of chains gives us some performance improvement. +

+
+
+

+計算時間 (署名の生成と検証の両方) に関しては、効果 1 は無関係です (本質的に同じハッシュ計算を実行する必要があります)、効果 2 は依然として適用されます。たとえば、W=8 の場合、SHA-256 では LM-OTS 署名ごとに 34 個の Winternitz チェーンが必要ですが、SHA-256/192 では 26 個しか必要ありません。大部分の時間 (署名の生成と検証の両方) がこれらの Winternitz チェーンの計算に費やされるため、このチェーン数の削減によりパフォーマンスがある程度向上します。 +

+
+
+
+
+

+The table below gives the space used by both the 256-bit and 192-bit parameter sets for a range of commonly used Winternitz parameters and tree heights: +

+
+
+

+以下の表は、一般的に使用される Winternitz パラメーターと木の高さの範囲について、256 ビットと 192 ビットの両方のパラメーター セットで使用されるスペースを示しています。 +

+
+
+
+
+ 
+              +=========+============+==============+==============+
+              | ParmSet | Winternitz | 256-bit hash | 192-bit hash |
+              +=========+============+==============+==============+
+              |    15   |     4      |     2672     |     1624     |
+              +---------+------------+--------------+--------------+
+              |    15   |     8      |     1616     |     1024     |
+              +---------+------------+--------------+--------------+
+              |    20   |     4      |     2832     |     1744     |
+              +---------+------------+--------------+--------------+
+              |    20   |     8      |     1776     |     1144     |
+              +---------+------------+--------------+--------------+
+              |  15/10  |     4      |     5236     |     3172     |
+              +---------+------------+--------------+--------------+
+              |  15/10  |     8      |     3124     |     1972     |
+              +---------+------------+--------------+--------------+
+              |  15/15  |     4      |     5396     |     3292     |
+              +---------+------------+--------------+--------------+
+              |  15/15  |     8      |     3284     |     2092     |
+              +---------+------------+--------------+--------------+
+              |  20/10  |     4      |     5396     |     3292     |
+              +---------+------------+--------------+--------------+
+              |  20/10  |     8      |     3284     |     2092     |
+              +---------+------------+--------------+--------------+
+              |  20/15  |     4      |     5556     |     3412     |
+              +---------+------------+--------------+--------------+
+              |  20/15  |     8      |     3444     |     2212     |
+              +---------+------------+--------------+--------------+
+
+                                     Table 3
+
+
+
+
+
+

+ParmSet: +

+
+
+

+パラメータセット: +

+
+
+
+
+

+The height of the Merkle tree(s), which is the parameter "h" from Table 2. Parameter sets listed as a single integer have L=1 and consist of a single Merkle tree of that height; parameter sets with L=2 are listed as x/y, with x being the height of the top-level Merkle tree and y being the bottom level. +

+
+
+

+マークル ツリーの高さ。表 2 のパラメータ「h」です。単一の整数としてリストされているパラメータ セットは L=1 を持ち、その高さの単一のマークル ツリーで構成されます。L=2 のパラメータ セットは x/y としてリストされます。x は最上位のマークル ツリーの高さ、y は最下位レベルです。 +

+
+
+
+
+

+Winternitz: +

+
+
+

+ウィンターニッツ: +

+
+
+
+
+

+The Winternitz parameter used, which is the parameter "w" from Table 1. For the tests that use multiple trees, this applies to all of them. +

+
+
+

+使用される Winternitz パラメーター。これは、表 1 のパラメーター「w」です。複数のツリーを使用するテストの場合、これはすべてのツリーに適用されます。 +

+
+
+
+
+

+256-bit hash: +

+
+
+

+256ビットハッシュ: +

+
+
+
+
+

+The size in bytes of a signature, assuming that a 256-bit hash is used in the signature (either SHA-256 or SHAKE256/256). +

+
+
+

+256 ビット ハッシュが署名 (SHA-256 または SHAKE256/256) で使用されると仮定した場合の、署名のバイト単位のサイズ。 +

+
+
+
+
+

+192-bit hash: +

+
+
+

+192ビットハッシュ: +

+
+
+
+
+

+The size in bytes of a signature, assuming that a 192-bit hash is used in the signature (either SHA-256/192 or SHAKE256/192). +

+
+
+

+192 ビット ハッシュが署名 (SHA-256/192 または SHAKE256/192) で使用されると仮定した場合の、署名のバイト単位のサイズ。 +

+
+
+
+
+

+An examination of the signature sizes shows that the 192-bit parameters consistently give a 35-40% reduction in the size of the signature in comparison with the 256-bit parameters. +

+
+
+

+署名のサイズを調べると、192 ビットのパラメータでは、256 ビットのパラメータと比較して署名のサイズが一貫して 35 ～ 40% 削減されることがわかります。 +

+
+
+
+
+

+For SHA-256/192, there is a smaller (circa 20%) reduction in the amount of computation required for a signature operation with a 192-bit hash, because fewer Winternitz chains would need to be computed. The SHAKE256/192 signatures may have either a faster or slower computation, depending on the implementation speed of SHAKE versus SHA-256 hashes. +

+
+
+

+SHA-256/192 の場合、計算する必要のある Winternitz チェーンの数が少なくなるため、192 ビット ハッシュでの署名操作に必要な計算量はより小さく (約 20%) 削減されます。SHAKE256/192 署名は、SHAKE ハッシュと SHA-256 ハッシュの実装速度に応じて、計算が高速になる場合もあれば、低速になる場合もあります。 +

+
+
+
+
+

+The SHAKE256/256-based parameter sets give no space advantage (or disadvantage) over the existing SHA-256-based parameter sets; any performance delta would depend solely on the implementation and whether they can generate SHAKE hashes faster than SHA-256 ones. +

+
+
+

+SHAKE256/256 ベースのパラメータ セットには、既存の SHA-256 ベースのパラメータ セットに比べてスペース上の利点 (または欠点) がありません。パフォーマンスの差は、実装と、SHA-256 ハッシュよりも高速に SHAKE ハッシュを生成できるかどうかのみに依存します。 +

+
+
+
+
+
+8. Security Considerations +
+
+
+
+8. セキュリティに関する考慮事項 +
+
+
+
+
+

+The strength of a signature that uses the SHA-256/192, SHAKE256/256, and SHAKE256/192 hash functions is based on the difficulty in finding preimages or second preimages to those hash functions. As shown in [Katz16], if we assume that the hash function can be modeled as a random oracle, then the security of the system is at least 8N-1 bits (where N is the size of the hash output in bytes); this gives us a security level of 255 bits for SHAKE256/256 and 191 bits for SHA-256/192 and SHAKE256/192). That is, the strength of SHA-256/192 and SHAKE256/192 can be expected to be equivalent to the strength of AES-192, while the strength of SHAKE256/256 is equivalent to the strength of AES-256. If AES-192 and AES-256 are quantum-resistant, then we expect SHA-256/192, SHAKE256/192, and SHAKE256/256 to also be. +

+
+
+

+SHA-256/192、SHAKE256/256、および SHAKE256/192 ハッシュ関数を使用する署名の強度は、それらのハッシュ関数に対するプリイメージまたは 2 番目のプリイメージを見つける難しさに基づいています。[Katz16] に示されているように、ハッシュ関数がランダム オラクルとしてモデル化できると仮定すると、システムのセキュリティは少なくとも 8N-1 ビットになります (N はバイト単位のハッシュ出力のサイズです)。これにより、SHAKE256/256 のセキュリティ レベルは 255 ビット、SHA-256/192 および SHAKE256/192 のセキュリティ レベルは 191 ビットになります)。つまり、SHA-256/192 および SHAKE256/192 の強度は AES-192 の強度と同等であることが期待でき、一方、SHAKE256/256 の強度は AES-256 の強度と同等であると考えられます。AES-192 と AES-256 が量子耐性がある場合、SHA-256/192、SHAKE256/192、および SHAKE256/256 も量子耐性があると予想されます。 +

+
+
+
+
+

+If we look at this in a different way, we see that the case of SHAKE256/256 is essentially the same as the existing SHA-256-based signatures; the difficultly of finding preimages and second preimages is essentially the same, and so they have (barring unexpected cryptographical advances) essentially the same level of security. +

+
+
+

+これを別の見方で見ると、SHAKE256/256 の場合は既存の SHA-256 ベースの署名と本質的に同じであることがわかります。プリイメージと 2 番目のプリイメージを見つけることの難しさは本質的に同じであるため、(予期しない暗号化の進歩がない限り) 本質的に同じレベルのセキュリティを備えています。 +

+
+
+
+
+

+The case of SHA-256/192 and SHAKE256/192 requires closer analysis. +

+
+
+

+SHA-256/192 および SHAKE256/192 の場合は、より詳細な分析が必要です。 +

+
+
+
+
+

+For a classical (non-quantum) computer, there is no known attack better than performing hashes of a large number of distinct preimages. Therefore, a successful attack has a high probability of requiring nearly 2^192 hash computations (for either SHA-256/192 or SHAKE256/192). These can be taken as the expected work effort and would appear to be completely infeasible in practice. +

+
+
+

+古典的な (非量子) コンピューターの場合、多数の個別のプリイメージのハッシュを実行することより優れた攻撃は知られていません。したがって、攻撃が成功すると、ほぼ 2^192 のハッシュ計算 (SHA-256/192 または SHAKE256/192 の場合) が必要になる可能性が高くなります。これらは予想される作業量とみなされる可能性があり、実際には完全に実行不可能であるように見えます。 +

+
+
+
+
+

+In theory, an attacker with a quantum computer could use Grover's algorithm [Grover96] to reduce the expected complexity to circa 2^96 hash computations (for N=24). On the other hand, implementing Grover's algorithm with this number of hash computations would require performing circa 2^96 hash computations in succession, which will take more time than is likely to be acceptable to any attacker. To speed this up, the attacker would need to run a number of instances of Grover's algorithm in parallel. This would necessarily increase the total work effort required, and to an extent, that makes it likely infeasible. This is because if we limit the time taken by Grover's algorithm to 2^t steps (for t <= 96), then to attack a hash preimage problem of 192 bits, it requires a total of 2^(192-t) hash computations, rather than the 2^(192/2) hash computations it would require if we did not limit the time taken. In other words, the hash preimage can be found in 2^t steps by using 2^(192-2t) quantum computers (for t <= 96), with one of the quantum computers finding the preimage. For example, if the adversary is willing to wait for 2^64 times the time taken by a hash computation (which is over 50 years if a quantum computer can compute a hash in 0.1 nanoseconds), this implies that a total of 2^(192-64) = 2^128 hash computations will need to be performed, on 2^64 (18 quintillion) separate quantum computers, each of which computes 2^64 hash evaluations. +

+
+
+

+理論的には、量子コンピューターを使用する攻撃者は、グローバーのアルゴリズム [Grover96] を使用して、予想される複雑さを約 2^96 ハッシュ計算 (N=24 の場合) に減らすことができます。一方、この数のハッシュ計算でグローバーのアルゴリズムを実装するには、約 2^96 のハッシュ計算を連続して実行する必要があり、攻撃者が許容できる以上に時間がかかります。これを高速化するには、攻撃者はグローバーのアルゴリズムの多数のインスタンスを並行して実行する必要があります。これにより必然的に必要な総作業量が増加するため、ある程度は実行不可能になる可能性があります。これは、Grover のアルゴリズムにかかる時間を 2^t ステップ (t <= 96) に制限すると、192 ビットのハッシュ プリイメージ問題を攻撃するには、かかる時間を制限しなかった場合に必要となる 2^(192/2) 回のハッシュ計算ではなく、合計 2^(192-t) 回のハッシュ計算が必要になるためです。言い換えれば、ハッシュ プリイメージは 2^(192-2t) 量子コンピューター (t <= 96) を使用して 2^t ステップで見つけることができ、量子コンピューターの 1 つがプリイメージを見つけます。たとえば、攻撃者がハッシュ計算にかかる時間の 2^64 倍待つことをいとわない場合 (量子コンピューターが 0.1 ナノ秒でハッシュを計算できる場合、これは 50 年以上に相当します)、これは、2^64 (18 京) 個の個別の量子に対して、合計 2^(192-64) = 2^128 回のハッシュ計算を実行する必要があることを意味します。コンピューター。それぞれが 2^64 ハッシュを計算します
評価。 +

+
+
+
+
+

+Hence, we expect that HSS/LMS based on these hash functions is secure against both classical and quantum computers, even though, in both cases, the expected work effort is less (for the N=24 case) than against either SHA-256 or SHAKE256/256. +

+
+
+

+したがって、これらのハッシュ関数に基づく HSS/LMS は、古典コンピューターと量子コンピューターの両方に対して安全であると予想されます。ただし、どちらの場合でも、予想される作業量は (N=24 の場合) SHA-256 または SHAKE256/256 よりも少なくなります。 +

+
+
+
+
+

+SHA-256 is subject to a length extension attack. In this attack, if the attacker is given the hash value of an unknown message (and the message length), then the attacker can compute the hash of the message appended with certain strings (even though the attacker does not know the contents of the initial part of the modified message). This would appear to be irrelevant to HSS for two reasons: +

+
+
+

+SHA-256 は長さ拡張攻撃の対象となります。この攻撃では、攻撃者に未知のメッセージのハッシュ値 (およびメッセージの長さ) が与えられた場合、攻撃者は、(攻撃者が変更されたメッセージの最初の部分の内容を知らなくても) 特定の文字列が追加されたメッセージのハッシュを計算できます。これは、次の 2 つの理由から HSS とは無関係であるように見えます。 +

+
+
+
+
+

+* For the initial message hash, the hash is entirely on public data. Hence, this attack is irrelevant, because the attacker could compute the hash of the message with appended data anyways. +

+
+
+

+* 最初のメッセージ ハッシュの場合、ハッシュは完全に公開データに基づいています。したがって、攻撃者はいずれにしてもデータが追加されたメッセージのハッシュを計算できるため、この攻撃は無関係です。 +

+
+
+
+
+

+* The rest of the hashes within HSS are fixed length. Hence, there is no opportunity to perform length extension attacks. +

+
+
+

+* HSS 内の残りのハッシュは固定長です。したがって、長さ拡張攻撃を実行する機会はありません。 +

+
+
+
+
+

+In addition, to perform a length extension attack on SHA-256/192, the attacker has to guess the 64 omitted bits (because the attack requires all 256 bits of the hash value); hence, that is even less of a concern than it is for the standard SHA-256. +

+
+
+

+さらに、SHA-256/192 に対して長さ拡張攻撃を実行するには、攻撃者は省略された 64 ビットを推測する必要があります (攻撃にはハッシュ値の 256 ビットすべてが必要であるため)。したがって、標準の SHA-256 よりもそれほど心配はありません。 +

+
+
+
+
+

+There is one corner case for which the security strength is reduced: if we need to assume that the signer will never deliberately generate a signature that is valid for two different messages. HSS uses randomized hashing when signing a message. That is, when a message is being presented to be signed, the signer generates a random value C and includes that in what is prepended to the message. Because the attacker cannot predict this value, it is infeasible for anyone other than the signer to find a generic collision. That is, practically speaking, a signature that is valid for two colliding messages is feasible only if the signer signed both messages. For this to happen, a signer (that is, the one with the private key and who picks the random C value) would have to break the collision resistance of the hash function to generate those two colliding messages. Note that this does not apply to someone who submits the messages for signing; only the signer could perform this. This would result in a signature that would be valid for two different selected messages. This is a nonstandard assumption for signature schemes and is usually not a concern, as we assume that the signer is trusted to generate signatures for any message. However, if the application needs to assume that it is infeasible for the signer to generate such a signature, then the security strength assumptions are reduced (128 bits for SHAKE256/256 and 96 bits for SHA-256/192 and SHAKE256/192). +

+
+
+

+セキュリティ強度が低下する特殊なケースが 1 つあります。それは、署名者が 2 つの異なるメッセージに対して有効な署名を意図的に生成しないと仮定する必要がある場合です。HSS は、メッセージに署名するときにランダム化されたハッシュを使用します。つまり、メッセージが署名のために提示されるときに、署名者はランダムな値 C を生成し、それをメッセージの先頭に追加するものに含めます。攻撃者はこの値を予測できないため、署名者以外の者が一般的な衝突を見つけることは不可能です。つまり、実際には、衝突する 2 つのメッセージに対して有効な署名は、署名者が両方のメッセージに署名した場合にのみ実現可能です。これを実現するには、署名者 (つまり、秘密鍵を持ち、ランダムな C 値を選択する署名者) がハッシュ関数の衝突耐性を破って、これら 2 つの衝突するメッセージを生成する必要があります。これは、署名のためにメッセージを送信する人には適用されないことに注意してください。これを実行できるのは署名者だけです。これにより、選択された 2 つの異なるメッセージに対して有効な署名が得られます。これは署名スキームの非標準的な仮定であり、署名者があらゆるメッセージの署名を生成することが信頼されていると仮定しているため、通常は問題になりません。ただし、署名者がそのような署名を生成することは実行不可能であるとアプリケーションが仮定する必要がある場合、セキュリティ強度の仮定は減らされます (SHAKE256/256 の場合は 128 ビット、SHA-256/192 および SHAKE256/192 の場合は 96 ビット)。 +

+
+
+
+
+

+Some cryptographers have raised the possibility of a multi-target attack (where the attacker has signatures from a large number of public keys and succeeds if they can generate a forgery against any one of those public keys). While no such method of attack has been proposed, the possibility cannot be excluded; if there are a large number of public keys, it might be prudent to consider the possibility of some security loss with N=24. If there are 2^K public keys, this security loss cannot be more than K bits of security. +

+
+
+

+一部の暗号学者は、マルチターゲット攻撃（攻撃者が多数の公開鍵からの署名を持っており、それらの公開鍵のいずれかに対する偽造を生成できれば成功する）の可能性を提起しています。そのような攻撃方法は提案されていませんが、可能性は排除できません。多数の公開キーがある場合、N=24 でセキュリティがある程度失われる可能性を考慮することが賢明かもしれません。2^K 個の公開キーがある場合、このセキュリティ損失は K ビットのセキュリティを超えることはできません。 +

+
+
+
+
+
+8.1. Note on the Version of SHAKE +
+
+
+
+8.1. SHAKEのバージョンについてのご注意 +
+
+
+
+
+

+[FIPS202] defines both SHAKE128 and SHAKE256. This specification selects SHAKE256, even though it is less efficient for large messages. The reason is that SHAKE128 has a low upper bound on the difficulty of finding preimages (due to the invertibility of its internal permutation), which would limit the strength of HSS/LMS (whose strength is based on the difficulty of finding preimages). Hence, we specify the use of SHAKE256, which has a considerably stronger preimage resistance. +

+
+
+

+[FIPS202] は SHAKE128 と SHAKE256 の両方を定義しています。この仕様では、大きなメッセージの場合は効率が低くなりますが、SHAKE256 が選択されます。その理由は、SHAKE128 には (内部順列の可逆性により) プリイメージを見つける難易度の上限が低く、HSS/LMS の強度 (その強度はプリイメージを見つける難易度に基づいています) が制限されるためです。したがって、プリイメージ耐性がかなり強い SHAKE256 の使用を指定します。 +

+
+
+
+
+
+9. IANA Considerations +
+
+
+
+9. IANAの考慮事項 +
+
+
+
+
+

+IANA has assigned the code points for the parameter sets in Section 3 in the "LM-OTS Signatures" registry and the parameter sets in Section 4 in the "Leighton-Micali Signatures (LMS)" registry. These assignments are included in [NIST_SP_800-208], but the IANA registrations only reference this document. +

+
+
+

+IANA は、「LM-OTS Signatures」レジストリのセクション 3 のパラメータ セットと、「Leighton-Micali Signatures (LMS)」レジストリのセクション 4 のパラメータ セットのコード ポイントを割り当てました。これらの割り当ては [NIST_SP_800-208] に含まれていますが、IANA 登録はこの文書のみを参照しています。 +

+
+
+
+
+
+10. References +
+
+
+
+10. 参考文献 +
+
+
+
+
+
+10.1. Normative References +
+
+
+
+10.1. 引用文献 +
+
+
+
+
+ 
+   [FIPS180]  NIST, "Secure Hash Standard", NIST FIPS 180-4,
+              DOI 10.6028/NIST.FIPS.180-4, August 2015,
+              <https://nvlpubs.nist.gov/nistpubs/FIPS/
+              NIST.FIPS.180-4.pdf>.
+
+
+
+
+
+ 
+   [FIPS202]  NIST, "SHA-3 Standard: Permutation-Based Hash and
+              Extendable-Output Functions", NIST FIPS 202,
+              DOI 10.6028/NIST.FIPS.202, August 2015,
+              <https://nvlpubs.nist.gov/nistpubs/FIPS/
+              NIST.FIPS.202.pdf>.
+
+
+
+
+
+ 
+   [RFC8554]  McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
+              Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554,
+              April 2019, <https://www.rfc-editor.org/info/rfc8554>.
+
+
+
+
+
+
+10.2. Informative References +
+
+
+
+10.2. 参考引用 +
+
+
+
+
+ 
+   [Grover96] Grover, L., "A fast quantum mechanical algorithm for
+              database search", Proceedings of the twenty-eighth annual
+              ACM symposium on Theory of Computing (STOC '96), pp.
+              212-219, DOI 10.1145/237814.237866, July 1996,
+              <https://doi.org/10.1145/237814.237866>.
+
+
+
+
+
+ 
+   [Katz16]   Katz, J., "Analysis of a Proposed Hash-Based Signature
+              Standard", Security Standardisation Research (SSR 2016),
+              Lecture Notes in Computer Science, vol. 10074, pp.
+              261-273, DOI 10.1007/978-3-319-49100-4_12, 2016,
+              <https://doi.org/10.1007/978-3-319-49100-4_12>.
+
+
+
+
+
+ 
+   [NIST_SP_800-208]
+              Cooper, D., Apon, D., Dang, Q., Davidson, M., Dworkin, M.,
+              and C. Miller, "Recommendation for Stateful Hash-Based
+              Signature Schemes", National Institute of Standards and
+              Technology, NIST SP 800-208, DOI 10.6028/NIST.SP.800-208,
+              October 2020, <https://doi.org/10.6028/NIST.SP.800-208>.
+
+
+
+
+
+
+Appendix A. Test Cases +
+
+
+
+付録A. テストケース +
+
+
+
+
+

+This appendix provides four test cases that can be used to verify or debug an implementation. This data is formatted with the name of the elements on the left and the value of the elements on the right, in hexadecimal. The concatenation of all of the values within a public key or signature produces that public key or signature, and values that do not fit within a single line are listed across successive lines. +

+
+
+

+この付録では、実装の検証またはデバッグに使用できる 4 つのテスト ケースを提供します。このデータは、左側に要素の名前、右側に要素の値を 16 進数で表示してフォーマットされています。公開キーまたは署名内のすべての値を連結すると、その公開キーまたは署名が生成され、1 行に収まらない値は連続した行にリストされます。 +

+
+
+
+
+
+A.1. Test Case 1 - SHA-256/192 +
+
+
+
+A.1. テストケース 1 - SHA-256/192 +
+
+
+
+
+ 
+   --------------------------------------------
+   (note: procedure in Appendix A of [RFC8554] is used)
+   SEED        000102030405060708090a0b0c0d0e0f
+               1011121314151617
+   I           202122232425262728292a2b2c2d2e2f
+   --------------------------------------------
+
+
+
+
+
+

+Figure 1: Private Key for SHA-256/192 +

+
+
+

+図 1: SHA-256/192 の秘密キー +

+
+
+
+
+ 
+   --------------------------------------------
+   HSS public key
+   levels      00000001
+   --------------------------------------------
+   LMS type    0000000a                         # LMS_SHA256_M24_H5
+   LM-OTS type 00000008                         # LMOTS_SHA256_N24_W8
+   I           202122232425262728292a2b2c2d2e2f
+   K           2c571450aed99cfb4f4ac285da148827
+               96618314508b12d2
+   --------------------------------------------
+
+
+
+
+
+

+Figure 2: Public Key for SHA-256/192 +

+
+
+

+図 2: SHA-256/192 の公開キー +

+
+
+
+
+ 
+   --------------------------------------------
+   Message     54657374206d65737361676520666f72  |Test message for|
+               205348413235362d3139320a          | SHA-256/192.|
+   --------------------------------------------
+
+
+
+
+
+

+Figure 3: Message for SHA-256/192 +

+
+
+

+図 3: SHA-256/192 のメッセージ +

+
+
+
+
+ 
+   --------------------------------------------
+   HSS signature
+   Nspk        00000000
+   sig[0]:
+   --------------------------------------------
+   LMS signature
+   q           00000005
+   --------------------------------------------
+   LM-OTS signature
+   LM-OTS type 00000008                         # LMOTS_SHA256_N24_W8
+   C           0b5040a18c1b5cabcbc85b047402ec62
+               94a30dd8da8fc3da
+   y[0]        e13b9f0875f09361dc77fcc4481ea463
+               c073716249719193
+   y[1]        614b835b4694c059f12d3aedd34f3db9
+               3f3580fb88743b8b
+   y[2]        3d0648c0537b7a50e433d7ea9d6672ff
+               fc5f42770feab4f9
+   y[3]        8eb3f3b23fd2061e4d0b38f832860ae7
+               6673ad1a1a52a900
+   y[4]        5dcf1bfb56fe16ff723627612f9a48f7
+               90f3c47a67f870b8
+   y[5]        1e919d99919c8db48168838cece0abfb
+               683da48b9209868b
+   y[6]        e8ec10c63d8bf80d36498dfc205dc45d
+               0dd870572d6d8f1d
+   y[7]        90177cf5137b8bbf7bcb67a46f86f26c
+               fa5a44cbcaa4e18d
+   y[8]        a099a98b0b3f96d5ac8ac375d8da2a7c
+               248004ba11d7ac77
+   y[9]        5b9218359cddab4cf8ccc6d54cb7e1b3
+               5a36ddc9265c0870
+   y[10]       63d2fc6742a7177876476a324b03295b
+               fed99f2eaf1f3897
+   y[11]       0583c1b2b616aad0f31cd7a4b1bb0a51
+               e477e94a01bbb4d6
+   y[12]       f8866e2528a159df3d6ce244d2b6518d
+               1f0212285a3c2d4a
+   y[13]       927054a1e1620b5b02aab0c8c10ed48a
+               e518ea73cba81fcf
+   y[14]       ff88bff461dac51e7ab4ca75f47a6259
+               d24820b9995792d1
+   y[15]       39f61ae2a8186ae4e3c9bfe0af2cc717
+               f424f41aa67f03fa
+   y[16]       edb0665115f2067a46843a4cbbd297d5
+               e83bc1aafc18d1d0
+   y[17]       3b3d894e8595a6526073f02ab0f08b99
+               fd9eb208b59ff631
+   y[18]       7e5545e6f9ad5f9c183abd043d5acd6e
+               b2dd4da3f02dbc31
+   y[19]       67b468720a4b8b92ddfe7960998bb7a0
+               ecf2a26a37598299
+   y[20]       413f7b2aecd39a30cec527b4d9710c44
+               73639022451f50d0
+   y[21]       1c0457125da0fa4429c07dad859c846c
+               bbd93ab5b91b01bc
+   y[22]       770b089cfede6f651e86dd7c15989c8b
+               5321dea9ca608c71
+   y[23]       fd862323072b827cee7a7e28e4e2b999
+               647233c3456944bb
+   y[24]       7aef9187c96b3f5b79fb98bc76c3574d
+               d06f0e95685e5b3a
+   y[25]       ef3a54c4155fe3ad817749629c30adbe
+               897c4f4454c86c49
+   --------------------------------------------
+   LMS type    0000000a                         # LMS_SHA256_M24_H5
+   path[0]     e9ca10eaa811b22ae07fb195e3590a33
+               4ea64209942fbae3
+   path[1]     38d19f152182c807d3c40b189d3fcbea
+               942f44682439b191
+   path[2]     332d33ae0b761a2a8f984b56b2ac2fd4
+               ab08223a69ed1f77
+   path[3]     19c7aa7e9eee96504b0e60c6bb5c942d
+               695f0493eb25f80a
+   path[4]     5871cffd131d0e04ffe5065bc7875e82
+               d34b40b69dd9f3c1
+
+
+
+
+
+

+Figure 4: Signature for SHA-256/192 +

+
+
+

+図 4: SHA-256/192 の署名 +

+
+
+
+
+
+A.2. Test Vector for SHAKE256/192 +
+
+
+
+A.2. SHAKE256/192のテストベクター +
+
+
+
+
+ 
+   --------------------------------------------
+   (note: procedure in Appendix A of [RFC8554] is used)
+   SEED        303132333435363738393a3b3c3d3e3f
+               4041424344454647
+   I           505152535455565758595a5b5c5d5e5f
+   --------------------------------------------
+
+
+
+
+
+

+Figure 5: Private Key for SHAKE256/192 +

+
+
+

+図 5: SHAKE256/192 の秘密鍵 +

+
+
+
+
+ 
+   ---------------------------------------------
+   HSS public key
+   levels      00000001
+   --------------------------------------------
+   LMS type    00000014                         # LMS_SHAKE_N24_H5
+   LM-OTS type 00000010                         # LMOTS_SHAKE_N24_W8
+   I           505152535455565758595a5b5c5d5e5f
+   K           db54a4509901051c01e26d9990e55034
+               7986da87924ff0b1
+   --------------------------------------------
+
+
+
+
+
+

+Figure 6: Public Key for SHAKE256/192 +

+
+
+

+図 6: SHAKE256/192 の公開鍵 +

+
+
+
+
+ 
+   --------------------------------------------
+   Message     54657374206d65737361676520666f72  |Test message for|
+               205348414b453235362d3139320a      | SHAKE256/192.|
+   --------------------------------------------
+
+
+
+
+
+

+Figure 7: Message for SHAKE256/192 +

+
+
+

+図 7: SHAKE256/192 のメッセージ +

+
+
+
+
+ 
+   --------------------------------------------
+   HSS signature
+   Nspk        00000000
+   sig[0]:
+   --------------------------------------------
+   LMS signature
+   q           00000006
+   --------------------------------------------
+   LM-OTS signature
+   LM-OTS type 00000010                         # LMOTS_SHAKE_N24_W8
+   C           84219da9ce9fffb16edb94527c6d1056
+               5587db28062deac4
+   y[0]        208e62fc4fbe9d85deb3c6bd2c01640a
+               ccb387d8a6093d68
+   y[1]        511234a6a1a50108091c034cb1777e02
+               b5df466149a66969
+   y[2]        a498e4200c0a0c1bf5d100cdb97d2dd4
+               0efd3cada278acc5
+   y[3]        a570071a043956112c6deebd1eb3a7b5
+               6f5f6791515a7b5f
+   y[4]        fddb0ec2d9094bfbc889ea15c3c7b9be
+               a953efb75ed648f5
+   y[5]        35b9acab66a2e9631e426e4e99b733ca
+               a6c55963929b77fe
+   y[6]        c54a7e703d8162e736875cb6a455d4a9
+               015c7a6d8fd5fe75
+   y[7]        e402b47036dc3770f4a1dd0a559cb478
+               c7fb1726005321be
+   y[8]        9d1ac2de94d731ee4ca79cff454c811f
+               46d11980909f047b
+   y[9]        2005e84b6e15378446b1ca691efe491e
+               a98acc9d3c0f785c
+   y[10]       aba5e2eb3c306811c240ba2280292382
+               7d582639304a1e97
+   y[11]       83ba5bc9d69d999a7db8f749770c3c04
+               a152856dc726d806
+   y[12]       7921465b61b3f847b13b2635a45379e5
+               adc6ff58a99b00e6
+   y[13]       0ac767f7f30175f9f7a140257e218be3
+               07954b1250c9b419
+   y[14]       02c4fa7c90d8a592945c66e86a76defc
+               b84500b55598a199
+   y[15]       0faaa10077c74c94895731585c8f900d
+               e1a1c675bd8b0c18
+   y[16]       0ebe2b5eb3ef8019ece3e1ea7223eb79
+               06a2042b6262b4aa
+   y[17]       25c4b8a05f205c8befeef11ceff12825
+               08d71bc2a8cfa0a9
+   y[18]       9f73f3e3a74bb4b3c0d8ca2abd0e1c2c
+               17dafe18b4ee2298
+   y[19]       e87bcfb1305b3c069e6d385569a4067e
+               d547486dd1a50d6f
+   y[20]       4a58aab96e2fa883a9a39e1bd45541ee
+               e94efc32faa9a94b
+   y[21]       e66dc8538b2dab05aee5efa6b3b2efb3
+               fd020fe789477a93
+   y[22]       afff9a3e636dbba864a5bffa3e28d13d
+               49bb597d94865bde
+   y[23]       88c4627f206ab2b465084d6b780666e9
+               52f8710efd748bd0
+   y[24]       f1ae8f1035087f5028f14affcc5fffe3
+               32121ae4f87ac5f1
+   y[25]       eac9062608c7d87708f1723f38b23237
+               a4edf4b49a5cd3d7
+   --------------------------------------------
+   LMS type    00000014                         # LMS_SHAKE_N24_H5
+   path[0]     dd4bdc8f928fb526f6fb7cdb944a7eba
+               a7fb05d995b5721a
+   path[1]     27096a5007d82f79d063acd434a04e97
+               f61552f7f81a9317
+   path[2]     b4ec7c87a5ed10c881928fc6ebce6dfc
+               e9daae9cc9dba690
+   path[3]     7ca9a9dd5f9f573704d5e6cf22a43b04
+               e64c1ffc7e1c442e
+   path[4]     cb495ba265f465c56291a902e62a461f
+               6dfda232457fad14
+
+
+
+
+
+

+Figure 8: Signature for SHAKE256/192 +

+
+
+

+図 8: SHAKE256/192 の署名 +

+
+
+
+
+
+A.3. Test Vector for SHA-256/256 +
+
+
+
+A.3. SHA-256/256 のテスト ベクトル +
+
+
+
+
+ 
+   --------------------------------------------
+   (note: procedure in Appendix A of [RFC8554] is used)
+   SEED        606162636465666768696a6b6c6d6e6f
+               707172737475767778797a7b7c7d7e7f
+   I           808182838485868788898a8b8c8d8e8f
+   --------------------------------------------
+
+
+
+
+
+

+Figure 9: Private Key for SHAKE256/256 +

+
+
+

+図 9: SHAKE256/256 の秘密鍵 +

+
+
+
+
+ 
+   --------------------------------------------
+   HSS public key
+   levels      00000001
+   --------------------------------------------
+   LMS type    0000000f                         # LMS_SHAKE_N32_H5
+   LM-OTS type 0000000c                         # LMOTS_SHAKE_N32_W8
+   I           808182838485868788898a8b8c8d8e8f
+   K           9bb7faee411cae806c16a466c3191a8b
+               65d0ac31932bbf0c2d07c7a4a36379fe
+   --------------------------------------------
+
+
+
+
+
+

+Figure 10: Public Key for SHAKE256/256 +

+
+
+

+図 10: SHAKE256/256 の公開鍵 +

+
+
+
+
+ 
+   --------------------------------------------
+   Message     54657374206d657361676520666f7220  |Test message for|
+               5348414b453235362d3235360a        |SHAKE256/256.|
+   --------------------------------------------
+
+
+
+
+
+

+Figure 11: Message for SHAKE256/256 +

+
+
+

+図 11: SHAKE256/256 のメッセージ +

+
+
+
+
+ 
+   --------------------------------------------
+   HSS signature
+   Nspk        00000000
+   sig[0]:
+   --------------------------------------------
+   LMS signature
+   q           00000007
+   --------------------------------------------
+   LM-OTS signature
+   LM-OTS type 0000000c                         # LMOTS_SHAKE_N32_W8
+   C           b82709f0f00e83759190996233d1ee4f
+               4ec50534473c02ffa145e8ca2874e32b
+   y[0]        16b228118c62b96c9c77678b33183730
+               debaade8fe607f05c6697bc971519a34
+   y[1]        1d69c00129680b67e75b3bd7d8aa5c8b
+               71f02669d177a2a0eea896dcd1660f16
+   y[2]        864b302ff321f9c4b8354408d0676050
+               4f768ebd4e545a9b0ac058c575078e6c
+   y[3]        1403160fb45450d61a9c8c81f6bd69bd
+               fa26a16e12a265baf79e9e233eb71af6
+   y[4]        34ecc66dc88e10c6e0142942d4843f70
+               a0242727bc5a2aabf7b0ec12a99090d8
+   y[5]        caeef21303f8ac58b9f200371dc9e41a
+               b956e1a3efed9d4bbb38975b46c28d5f
+   y[6]        5b3ed19d847bd0a737177263cbc1a226
+               2d40e80815ee149b6cce2714384c9b7f
+   y[7]        ceb3bbcbd25228dda8306536376f8793
+               ecadd6020265dab9075f64c773ef97d0
+   y[8]        7352919995b74404cc69a6f3b469445c
+               9286a6b2c9f6dc839be76618f053de76
+   y[9]        3da3571ef70f805c9cc54b8e501a98b9
+               8c70785eeb61737eced78b0e380ded4f
+   y[10]       769a9d422786def59700eef3278017ba
+               bbe5f9063b468ae0dd61d94f9f99d5cc
+   y[11]       36fbec4178d2bda3ad31e1644a2bcce2
+               08d72d50a7637851aa908b94dc437612
+   y[12]       0d5beab0fb805e1945c41834dd6085e6
+               db1a3aa78fcb59f62bde68236a10618c
+   y[13]       ff123abe64dae8dabb2e84ca705309c2
+               ab986d4f8326ba0642272cb3904eb96f
+   y[14]       6f5e3bb8813997881b6a33cac0714e4b
+               5e7a882ad87e141931f97d612b84e903
+   y[15]       e773139ae377f5ba19ac86198d485fca
+               97742568f6ff758120a89bf19059b8a6
+   y[16]       bfe2d86b12778164436ab2659ba86676
+               7fcc435584125fb7924201ee67b535da
+   y[17]       f72c5cb31f5a0b1d926324c26e67d4c3
+               836e301aa09bae8fb3f91f1622b1818c
+   y[18]       cf440f52ca9b5b9b99aba8a6754aae2b
+               967c4954fa85298ad9b1e74f27a46127
+   y[19]       c36131c8991f0cc2ba57a15d35c91cf8
+               bc48e8e20d625af4e85d8f9402ec44af
+   y[20]       bd4792b924b839332a64788a7701a300
+               94b9ec4b9f4b648f168bf457fbb3c959
+   y[21]       4fa87920b645e42aa2fecc9e21e000ca
+               7d3ff914e15c40a8bc533129a7fd3952
+   y[22]       9376430f355aaf96a0a13d13f2419141
+               b3cc25843e8c90d0e551a355dd90ad77
+   y[23]       0ea7255214ce11238605de2f000d2001
+               04d0c3a3e35ae64ea10a3eff37ac7e95
+   y[24]       49217cdf52f307172e2f6c7a2a4543e1
+               4314036525b1ad53eeaddf0e24b1f369
+   y[25]       14ed22483f2889f61e62b6fb78f5645b
+               dbb02c9e5bf97db7a0004e87c2a55399
+   y[26]       b61958786c97bd52fa199c27f6bb4d68
+               c4907933562755bfec5d4fb52f06c289
+   y[27]       d6e852cf6bc773ffd4c07ee2d6cc55f5
+               7edcfbc8e8692a49ad47a121fe3c1b16
+   y[28]       cab1cc285faf6793ffad7a8c341a49c5
+               d2dce7069e464cb90a00b2903648b23c
+   y[29]       81a68e21d748a7e7b1df8a593f3894b2
+               477e8316947ca725d141135202a9442e
+   y[30]       1db33bbd390d2c04401c39b253b78ce2
+               97b0e14755e46ec08a146d279c67af70
+   y[31]       de256890804d83d6ec5ca3286f1fca9c
+               72abf6ef868e7f6eb0fddda1b040ecec
+   y[32]       9bbc69e2fd8618e9db3bdb0af13dda06
+               c6617e95afa522d6a2552de15324d991
+   y[33]       19f55e9af11ae3d5614b564c642dbfec
+               6c644198ce80d2433ac8ee738f9d825e
+   --------------------------------------------
+   LMS type    0000000f                         # LMS_SHAKE_N32_H5
+   path[0]     71d585a35c3a908379f4072d070311db
+               5d65b242b714bc5a756ba5e228abfa0d
+   path[1]     1329978a05d5e815cf4d74c1e547ec4a
+               a3ca956ae927df8b29fb9fab3917a7a4
+   path[2]     ae61ba57e5342e9db12caf6f6dbc5253
+               de5268d4b0c4ce4ebe6852f012b162fc
+   path[3]     1c12b9ffc3bcb1d3ac8589777655e22c
+               d9b99ff1e4346fd0efeaa1da044692e7
+   path[4]     ad6bfc337db69849e54411df8920c228
+               a2b7762c11e4b1c49efb74486d3931ea
+
+
+
+
+
+

+Figure 12: Signature for SHAKE256/256 +

+
+
+

+図 12: SHAKE256/256 の署名 +

+
+
+
+
+
+A.4. Test Vector for SHA-256/192, W=4 +
+
+
+
+A.4. SHA-256/192 のテスト ベクトル、W=4 +
+
+
+
+
+ 
+   --------------------------------------------
+   (note: procedure in Appendix A of [RFC8554] is used)
+   SEED        202122232425262728292a2b2c2d2e2f
+               3031323334353637
+   I           404142434445464748494a4b4c4d4e4f
+   --------------------------------------------
+
+
+
+
+
+

+Figure 13: Private Key for SHA256/192 with W=4 +

+
+
+

+図 13: W=4 の SHA256/192 の秘密鍵 +

+
+
+
+
+ 
+   --------------------------------------------
+   HSS public key
+   levels      00000001
+   --------------------------------------------
+   LMS type    0000000d                         # LMS_SHA256_M24_H20
+   LM-OTS type 00000007                         # LMOTS_SHA256_N24_W4
+   I           404142434445464748494a4b4c4d4e4f
+   K           9c08a50d170406869892802ee4142fcd
+               eac990f110c2460c
+   --------------------------------------------
+
+
+
+
+
+

+Figure 14: Public Key for SHA256/192 with W=4 +

+
+
+

+図 14: W=4 の SHA256/192 の公開鍵 +

+
+
+
+
+ 
+   --------------------------------------------
+   Message     54657374206d65737361676520666f72  |Test message for|
+               205348413235362f31393220773d34    | SHA256/192 w=4|
+   --------------------------------------------
+
+
+
+
+
+

+Figure 15: Message for SHA256/192 with W=4 +

+
+
+

+図 15: W=4 の SHA256/192 のメッセージ +

+
+
+
+
+ 
+   --------------------------------------------
+   HSS signature
+   Nspk        00000000
+   sig[0]:
+   --------------------------------------------
+   LMS signature
+   q           00000064
+   --------------------------------------------
+   LM-OTS signature
+   LM-OTS type 00000007                         # LMOTS_SHA256_N24_W4
+   C          853fa6e1a65fef076acd2485505b93be
+              9aeb2641e3d3805c
+   y[0]       1887f26f4bcdb6ac0337b76fa5d66038
+              34287e010b20516f
+   y[1]       7c336df2134c0a981f1ec2bb7baee516
+              e91e67d3bd16c8d9
+   y[2]       45a7f2be4fd84a604ae3743efc609ee0
+              e69572e9c6d4a682
+   y[3]       50e877b75d3cae63e9d5c15a32bb3cd1
+              7045f6b3e195284f
+   y[4]       dd1ee3cfbe18f1cbd06ef3e7af34b184
+              4d42dac453115a45
+   y[5]       07ed525cec120d054b403c61a7e5034f
+              ac4be6ef5412d194
+   y[6]       d4b6bbc0ae6cd3fe9993d583ee06f403
+              0bc832efec24d1f7
+   y[7]       13f5088731b91a98491fa3adf1b322bc
+              e26df24c8415e3a4
+   y[8]       6bdfe07a6fd48e6d951515758cd64349
+              91098bf6949249fc
+   y[9]       a338ec235871dd564998d07d9b1b1b8d
+              644e657fee8039da
+   y[10]      8fe195d129faddb12d543b86b0ab8cf6
+              f26c121783f3b828
+   y[11]      d03f793b42909272f688e4ef6d46e82b
+              dd1a02b1ff86c3b7
+   y[12]      9920b2e6f19faf75c623242f1f2c549f
+              84fb2f4c3ffead31
+   y[13]      20d97baea507467bb2da79f132bbe15b
+              596fdfcb70983107
+   y[14]      ebca2597de9d55bd83bcae5c28a85259
+              dadb354859986e60
+   y[15]      c8afa0b10bd08a8f9ed9b1ede3377075
+              fe0ae36349f7d2ed
+   y[16]      7bfc9ece0d4cd6972059329419feaf3b
+              9a1045b6cfa4ae89
+   y[17]      b1cea8950aea4af870d1a3a3909ebc5a
+              3013d6deb927abc0
+   y[18]      f95093e83cb36a9c1d6f13add19268ac
+              7a0371f8335b0952
+   y[19]      a57fdb0141d55d937dd6ebb08fee8a5c
+              f426ac97d54ee7aa
+   y[20]      17e6c57be5e62a52a6b1b986730d3a3a
+              ad8a7d327ddf883e
+   y[21]      6bc7b636eb2a5c4f2a635ae5bada5418
+              d43dfedb69c0a020
+   y[22]      9334fac89d420d6ad5a2e1df95d26a1b
+              feb99a5e8455061b
+   y[23]      fdf2d6e8394caf8a4be699b8afa38e52
+              4d4053330af478f8
+   y[24]      5bf33d3ca3a35bc96987282bd513a8f6
+              a52db9ba36aa9088
+   y[25]      2b3bf573fa275449d8d49eb30bed2bb1
+              7a0ecc7d8a20807f
+   y[26]      2ea3dd37acd46c713cc2ac9d01a20a30
+              d6832eef86a1e26d
+   y[27]      1cad7761bf4130a6565572766026509d
+              eeddaf46b605452b
+   y[28]      218a4e137a7ce063b546a35c52510f0e
+              a2cac879192ec443
+   y[29]      e43b37c5ffa23da7a7fc254324a3de70
+              5c771794f10ea356
+   y[30]      e5a747e5146fd804a47719803c185b38
+              0e34b8dcc8269c2b
+   y[31]      073d86b2307cf90c6c3ef9271f2d53df
+              2579f0c4cfb632db
+   y[32]      37a9025965f70b4616673228e98644be
+              6576417b7a97f104
+   y[33]      350259e7f697408cdf8cf81a3e774162
+              6ccdb87ad8531264
+   y[34]      cb5ceb7c8c097cec505091a3ee3a826c
+              54f78169abc2e7d0
+   y[35]      a318dac10250ba940e51e79a3f572fb3
+              2bf442be6fd81267
+   y[36]      946e6387f9a8c705d945c653f2684655
+              e3fa6b9ee311d8a0
+   y[37]      91bef9898292fa272fb8761f066c23d8
+              7aa10d67871cc541
+   y[38]      9c843b796855c51ad1272e9264acd203
+              5a82b12c2ddbc85a
+   y[39]      dfcd7c22366a36495349391dbf000106
+              4b8f6b28365445d7
+   y[40]      33e48f1b058a6cb3e71bbb8df3e90406
+              299894f4ca682943
+   y[41]      ceeba410b33b07716ffc18d6eab75f2d
+              6372f1133605fa3c
+   y[42]      3ed66f2d8f7c5abe59e87d4500965e34
+              7523d73cb356c144
+   y[43]      827aaa22b1c72a15293c7400e02aaefc
+              f36f68a8246900e6
+   y[44]      e6228e7ad19d1450c23434f1e45043dc
+              2b6db57f20d8f5b3
+   y[45]      44d4162aa651333287cd8bf8fac41c78
+              d61fe2929209bfe2
+   y[46]      dc5a2f80205c043b22e540a29f0ea0a5
+              ff529e55bf1dfe42
+   y[47]      96fc4bb4ac2e875322ab115db479fe97
+              9d64f78409af4ec3
+   y[48]      ad3b758fff83af1b9c48e90ca39366f4
+              26c2fb921df55c72
+   y[49]      786a9217723945a1ac1a66af7def4f8b
+              367001732cce0e5b
+   y[50]      ac91ac9d603807f8bab105b46d315d4c
+              b88feb1c8686884b
+   --------------------------------------------
+   LMS type    0000000d                         # LMS_SHA256_M24_H20
+   path[0]    13d1a8ef00c5811c15c4d774fdcf7515
+              5315aff53ebdff8f
+   path[1]    b6a54f12c165963dd5690cc9842b0e21
+              90afc5443497584c
+   path[2]    832155599d00aced84bb3b59170396f7
+              db4fa84aa8577f76
+   path[3]    cf9367d6e99d3d5be3555d7156b004f2
+              002f505681b1ad22
+   path[4]    9b9b46a666672aa8ee662c3a0456a9ad
+              da7a44fbaca46789
+   path[5]    577dcd36dc5cdff34b864d0a32492a0a
+              cbcaa6c011748f20
+   path[6]    5b91ab2ab84f2333fb3e3b9acaecdac3
+              8b58aa5f32e718e2
+   path[7]    25631ed6674cccb8c119acbd4992ab31
+              30a6e912deec5983
+   path[8]    5ab52fbc549430f8b403e4a2a51cc7f4
+              6fc143d365763aa1
+   path[9]    708fd25bcd657a790e54718d97090624
+              2a3b8a97dff18e91
+   path[10]   a44c4ba818a8dd2d242251265b023b82
+              6077eb740f6682e6
+   path[11]   c4ada2b85a67988d406132c2ad899099
+              e44cfe610c3a5af7
+   path[12]   0b406224411a59597e5dda0f31cd16c9
+              14b67e96141661f0
+   path[13]   074f43eb02273481bc324ded26c64f23
+              88559d8c8bd0ef8b
+   path[14]   34ca4afebfac2a689b4246c264241488
+              dcf922350dc44f7b
+   path[15]   c09d57dc1126291b2318810e0f44801c
+              071e572fd032c780
+   path[16]   f44c9503a4c03c37417dc96422ba0849
+              c37956f9fd5d33ea
+   path[17]   4fcab84276effec652ca77d7d47ac93c
+              633d99e0a236f03d
+   path[18]   5587d1990ffaef737fced1f5cdd8f373
+              844e9f316aad41a0
+   path[19]   b12302639f83a2d74c9fe30d305a942b
+              c0c30352a5e44dfb
+
+
+
+
+
+

+Figure 16: Signature for SHA256/192 with W=4 +

+
+
+

+図 16: W=4 の SHA256/192 の署名 +

+
+
+
+
+
+Acknowledgements +
+
+
+
+謝辞 +
+
+
+
+
+

+We would like to thank Carsten Bormann, Russ Housley, Andrey Jivsov, Mallory Knodel, Virendra Kumar, Thomas Pornin, and Stanislav Smyshlyaev for their insightful and helpful reviews. +

+
+
+

+洞察力に富んだ有益なレビューをくださった Carsten Bormann、Russ Housley、Andrey Jivsov、Mallory Knodel、Virendra Kumar、Thomas Portin、Stanislav Smyshlyaev に感謝します。 +

+
+
+
+
+
+Authors' Addresses +
+
+
+
+著者の住所 +
+
+
+
+
+ 
+   Scott Fluhrer
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA
+   United States of America
+   Email: sfluhrer@cisco.com
+
+
+
+
+
+ 
+   Quynh Dang
+   NIST
+   100 Bureau Drive
+   Gaithersburg, MD
+   United States of America
+   Email: quynh.dang@nist.gov
+
+
+
+
+ + + diff --git a/html/rfc9861.html b/html/rfc9861.html new file mode 100644 index 000000000..24866c53d --- /dev/null +++ b/html/rfc9861.html @@ -0,0 +1,2748 @@ + + + + + + RFC 9861 - KangarooTwelve and TurboSHAKE 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Research Task Force (IRTF)                           B. Viguier
+Request for Comments: 9861                                 ABN AMRO Bank
+Category: Informational                                     D. Wong, Ed.
+ISSN: 2070-1721                                               zkSecurity
+                                                      G. Van Assche, Ed.
+                                                      STMicroelectronics
+                                                            Q. Dang, Ed.
+                                                                    NIST
+                                                          J. Daemen, Ed.
+                                                      Radboud University
+                                                            October 2025
+
+
+
+
+
+
+KangarooTwelve and TurboSHAKE +
+
+
+
+KangarooTwelve と TurboSHAKE +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document defines four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128, and KT256. +

+
+
+

+この文書では、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 という名前の、任意の長さの出力を持つハッシュ関数である 4 つの eXtendable-Output Function (XOF) を定義します。 +

+
+
+
+
+

+All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. +

+
+
+

+4 つの関数はすべて、効率的で安全なハッシュ プリミティブを提供し、最後の 2 つはスケーラブルな方法で実装の並列性を利用できます。 +

+
+
+
+
+

+This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in NIST FIPS 202 and is meant to serve as a stable reference and an implementation guide. +

+
+
+

+この文書は、Crypto Forum Research Group の成果物です。これは、NIST FIPS 202 の順列とスポンジ構造の定義に基づいて構築されており、安定したリファレンスおよび実装ガイドとして機能することを目的としています。 +

+
+
+
+
+
+Status of This Memo +
+
+
+
+本文書の位置付け +
+
+
+
+
+

+This document is not an Internet Standards Track specification; it is published for informational purposes. +

+
+
+

+この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。 +

+
+
+
+
+

+This document is a product of the Internet 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 Crypto Forum 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. +

+
+
+

+この文書は Internet Research Task Force (IRTF) の成果物です。IRTF は、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開には適していない可能性があります。この RFC は、インターネット研究タスクフォース (IRTF) の暗号フォーラム研究グループの合意を表しています。IRSG によって公開が承認された文書は、どのレベルのインターネット標準の候補でもありません。RFC 7841 のセクション 2 を参照してください。 +

+
+
+
+
+

+Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9861. +

+
+
+

+この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9861 で入手できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+Copyright (c) 2025 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+     1.1.  Conventions
+   2.  TurboSHAKE
+     2.1.  Interface
+     2.2.  Specifications
+   3.  KangarooTwelve: Tree Hashing over TurboSHAKE
+     3.1.  Interface
+     3.2.  Specification of KT128
+     3.3.  length_encode( x )
+     3.4.  Specification of KT256
+   4.  Message Authentication Codes
+   5.  Test Vectors
+   6.  IANA Considerations
+   7.  Security Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Appendix A.  Pseudocode
+     A.1.  Keccak-p[1600,n_r=12]
+     A.2.  TurboSHAKE128
+     A.3.  TurboSHAKE256
+     A.4.  KT128
+     A.5.  KT256
+   Authors' Addresses
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+This document defines the TurboSHAKE128, TurboSHAKE256 [TURBOSHAKE], KT128, and KT256 [KT] eXtendable-Output Functions (XOFs), i.e., hash function generalizations that can return an output of arbitrary length. Both TurboSHAKE128 and TurboSHAKE256 are based on a Keccak-p permutation specified in [FIPS202] and have a higher speed than the SHA-3 and SHAKE functions. +

+
+
+

+この文書は、TurboSHAKE128、TurboSHAKE256 [TURBOSHAKE]、KT128、および KT256 [KT] eXtendable-Output Functions (XOF)、つまり、任意の長さの出力を返すことができる一般化されたハッシュ関数を定義します。TurboSHAKE128 と TurboSHAKE256 はどちらも [FIPS202] で指定されている Keccak-p 順列に基づいており、SHA-3 および SHAKE 関数よりも高速です。 +

+
+
+
+
+

+TurboSHAKE is a sponge function family that makes use of Keccak-p[n_r=12,b=1600], a round-reduced version of the permutation used in SHA-3. Similarly to the SHAKE's security, it proposes two security strengths: 128 bits for TurboSHAKE128 and 256 bits for TurboSHAKE256. Halving the number of rounds compared to the original SHAKE functions makes TurboSHAKE roughly two times faster. +

+
+
+

+TurboSHAKE は、SHA-3 で使用される置換の丸め削減バージョンである Keccak-p[n_r=12,b=1600] を利用するスポンジ関数ファミリーです。SHAKE のセキュリティと同様に、TurboSHAKE128 の場合は 128 ビット、TurboSHAKE256 の場合は 256 ビットという 2 つのセキュリティ強度が提案されています。オリジナルの SHAKE 関数と比較してラウンド数が半分になるため、TurboSHAKE は約 2 倍高速になります。 +

+
+
+
+
+

+KangarooTwelve applies tree hashing on top of TurboSHAKE and comprises two functions, KT128 and KT256. Note that [KT] only defined KT128 under the name KangarooTwelve. KT256 is defined in this document. +

+
+
+

+KangarooTwelve は TurboSHAKE にツリー ハッシュを適用し、KT128 と KT256 の 2 つの関数で構成されます。[KT] は KT128 を KangarooTwelve という名前でのみ定義していることに注意してください。KT256 はこの文書で定義されています。 +

+
+
+
+
+

+The SHA-3 and SHAKE functions process data in a serial manner and are strongly limited in exploiting available parallelism in modern CPU architectures. Similar to ParallelHash [SP800-185], KangarooTwelve splits the input message into fragments. It then applies TurboSHAKE on each of them separately before applying TurboSHAKE again on the combination of the first fragment and the digests. More precisely, KT128 uses TurboSHAKE128 and KT256 uses TurboSHAKE256. They make use of Sakura coding for ensuring soundness of the tree hashing mode [SAKURA]. The use of TurboSHAKE in KangarooTwelve makes it faster than ParallelHash. +

+
+
+

+SHA-3 関数と SHAKE 関数はデータをシリアル方式で処理するため、最新の CPU アーキテクチャで利用可能な並列処理の活用には大きな制限があります。ParallelHash [SP800-185] と同様に、KangarooTwelve は入力メッセージをフラグメントに分割します。次に、それぞれに個別に TurboSHAKE を適用してから、最初のフラグメントとダイジェストの組み合わせに再度 TurboSHAKE を適用します。より正確には、KT128 は TurboSHAKE128 を使用し、KT256 は TurboSHAKE256 を使用します。ツリー ハッシュ モード [SAKURA] の健全性を確保するために、Sakura コーディングを利用します。KangarooTwelve で TurboSHAKE を使用すると、ParallelHash よりも高速になります。 +

+
+
+
+
+

+The security of TurboSHAKE128, TurboSHAKE256, KT128, and KT256 builds on the public scrutiny that Keccak has received since its publication [KECCAK_CRYPTANALYSIS] [TURBOSHAKE]. +

+
+
+

+TurboSHAKE128、TurboSHAKE256、KT128、および KT256 のセキュリティは、[KECCAK_CRYPTANALYSIS] [TURBOSHAKE] の公開以来 Keccak が受けてきた一般の監視に基づいています。 +

+
+
+
+
+

+With respect to functions defined in [FIPS202] and [SP800-185], TurboSHAKE128, TurboSHAKE256, KT128, and KT256 feature the following advantages: +

+
+
+

+[FIPS202] および [SP800-185] で定義されている関数に関して、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 には次の利点があります。 +

+
+
+
+
+

+* Unlike SHA3-224, SHA3-256, SHA3-384, and SHA3-512, the TurboSHAKE and KangarooTwelve functions have an extendable output. +

+
+
+

+* SHA3-224、SHA3-256、SHA3-384、SHA3-512 とは異なり、TurboSHAKE 関数と KangarooTwelve 関数には拡張可能な出力があります。 +

+
+
+
+
+

+* Unlike any functions in [FIPS202], and similar to functions in [SP800-185], KT128 and KT256 allow the use of a customization string. +

+
+
+

+* [FIPS202] の他の関数とは異なり、[SP800-185] の関数と同様に、KT128 および KT256 ではカスタマイズ文字列の使用が許可されています。 +

+
+
+
+
+

+* Unlike any functions in [FIPS202] and [SP800-185] except for ParallelHash, KT128 and KT256 exploit available parallelism. +

+
+
+

+* ParallelHash を除く [FIPS202] および [SP800-185] の関数とは異なり、KT128 および KT256 は利用可能な並列処理を利用します。 +

+
+
+
+
+

+* Unlike ParallelHash, KT128 and KT256 do not have overhead when processing short messages. +

+
+
+

+* ParallelHash とは異なり、KT128 と KT256 にはショート メッセージを処理する際のオーバーヘッドがありません。 +

+
+
+
+
+

+* The permutation in the TurboSHAKE functions has half the number of rounds compared to the one in the SHA-3 and SHAKE functions, making them faster than any function defined in [FIPS202]. The KangarooTwelve functions immediately benefit from the same speedup, improving over [FIPS202] and [SP800-185]. +

+
+
+

+* TurboSHAKE 関数の順列は、SHA-3 および SHAKE 関数の順列に比べてラウンド数が半分であるため、[FIPS202] で定義されているどの関数よりも高速になります。KangarooTwelve 関数は同じ高速化の恩恵をすぐに受けられ、[FIPS202] および [SP800-185] よりも改善されています。 +

+
+
+
+
+

+With respect to SHA-256, SHA-512, and other functions defined in [FIPS180], TurboSHAKE128, TurboSHAKE256, KT128, and KT256 feature the following advantages: +

+
+
+

+SHA-256、SHA-512、および [FIPS180] で定義されているその他の関数に関して、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 には次の利点があります。 +

+
+
+
+
+

+* Unlike any functions in [FIPS180], the TurboSHAKE and KangarooTwelve functions have an extendable output. +

+
+
+

+* [FIPS180] の他の関数とは異なり、TurboSHAKE 関数と KangarooTwelve 関数には拡張可能な出力があります。 +

+
+
+
+
+

+* The TurboSHAKE functions produce output at the same rate as they process input, whereas SHA-256 and SHA-512, when used in a mask generation function (MGF) construction, produce output half as fast as they process input. +

+
+
+

+* TurboSHAKE 関数は入力の処理と同じ速度で出力を生成しますが、SHA-256 および SHA-512 をマスク生成関数 (MGF) の構築で使用すると、入力の処理の半分の速度で出力を生成します。 +

+
+
+
+
+

+* Unlike the SHA-256 and SHA-512 functions, TurboSHAKE128, TurboSHAKE256, KT128, and KT256 do not suffer from the length extension weakness. +

+
+
+

+* SHA-256 および SHA-512 関数とは異なり、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 には長さ拡張の弱点がありません。 +

+
+
+
+
+

+* Unlike any functions in [FIPS180], TurboSHAKE128, TurboSHAKE256, KT128, and KT256 use a round function with algebraic degree 2, which makes them more suitable to masking techniques for protections against side-channel attacks. +

+
+
+

+* [FIPS180] の他の関数とは異なり、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 は代数次数 2 のラウンド関数を使用するため、サイドチャネル攻撃に対する保護のためのマスキング手法により適しています。 +

+
+
+
+
+

+This document represents the consensus of the Crypto Forum Research Group (CFRG) in the IRTF. It has been reviewed by two members of the Crypto Review Panel, as well as by several members of the CFRG. It is not an IETF product and is not a standard. +

+
+
+

+この文書は、IRTF の暗号フォーラム研究グループ (CFRG) の総意を表しています。これは、暗号レビューパネルの 2 人のメンバーと CFRG の数人のメンバーによってレビューされました。これは IETF 製品ではなく、標準でもありません。 +

+
+
+
+
+
+1.1. Conventions +
+
+
+
+1.1. 規約 +
+
+
+
+
+

+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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。 +

+
+
+
+
+

+The following notations are used throughout the document: +

+
+
+

+ドキュメント全体で次の表記が使用されます。 +

+
+
+
+
+

+* `...` denotes a string of bytes given in hexadecimal. For example, `0B 80`. +

+
+
+

+* 「...」は、16 進数で指定されたバイト列を示します。たとえば、「0B 80」です。 +

+
+
+
+
+

+* |s| denotes the length of a byte string `s`. For example, |`FF FF`| = 2. +

+
+
+

+* |s|はバイト列 `s` の長さを示します。たとえば、 |`FF FF`|= 2。 +

+
+
+
+
+

+* `00`^b denotes a byte string consisting of the concatenation of b bytes `00`. For example, `00`^7 = `00 00 00 00 00 00 00`. +

+
+
+

+* '００'＾ｂは、ｂバイトの'００'を連結したバイト列を表す。たとえば、`00`^7 = `00 00 00 00 00 00 00` となります。 +

+
+
+
+
+

+* `00`^0 denotes the empty byte string. +

+
+
+

+* `00`^0 は空のバイト列を表します。 +

+
+
+
+
+

+* a||b denotes the concatenation of two strings, a and b. For example, `10`||`F1` = `10 F1`. +

+
+
+

+* a||b は、2 つの文字列 a と b の連結を示します。たとえば、`10`||`F1` = `10 F1` となります。 +

+
+
+
+
+

+* s[n:m] denotes the selection of bytes from n (inclusive) to m (exclusive) of a string s. The indexing of a byte string starts at 0. For example, for s = `A5 C6 D7`, s[0:1] = `A5` and s[1:3] = `C6 D7`. +

+
+
+

+* s[n:m] は、文字列 s の n (両端を含む) から m (両端を含まない) までのバイトの選択を示します。バイト文字列のインデックスは 0 から始まります。たとえば、s = `A5 C6 D7`、s[0:1] = `A5`、および s[1:3] = `C6 D7` の場合。 +

+
+
+
+
+

+* s[n:] denotes the selection of bytes from n to the end of a string s. For example, for s = `A5 C6 D7`, s[0:] = `A5 C6 D7` and s[2:] = `D7`. +

+
+
+

+* s[n:] は、n から文字列 s の終わりまでのバイトの選択を示します。たとえば、s = `A5 C6 D7`、s[0:] = `A5 C6 D7`、および s[2:] = `D7` の場合。 +

+
+
+
+
+

+In the following, x and y are byte strings of equal length: +

+
+
+

+以下では、x と y は同じ長さのバイト文字列です。 +

+
+
+
+
+

+* x^=y denotes x takes the value x XOR y. +

+
+
+

+* x^=y は、x が値 x XOR y を取ることを示します。 +

+
+
+
+
+

+* x & y denotes x AND y. +

+
+
+

+* x & y は x AND y を表します。 +

+
+
+
+
+

+In the following, x and y are integers: +

+
+
+

+以下では、x と y は整数です。 +

+
+
+
+
+

+* x+=y denotes x takes the value x + y. +

+
+
+

+* x+=y は、x が値 x + y を取ることを示します。 +

+
+
+
+
+

+* x-=y denotes x takes the value x - y. +

+
+
+

+* x-=y は、x が値 x - y を取ることを示します。 +

+
+
+
+
+

+* x**y denotes the exponentiation of x by y. +

+
+
+

+* x**y は、x の y による累乗を表します。 +

+
+
+
+
+

+* x mod y denotes the remainder of the division of x by y. +

+
+
+

+* x mod y は、x を y で割った余りを表します。 +

+
+
+
+
+

+* x / y denotes the integer dividend of the division of x by y. +

+
+
+

+* x / y は、x を y で割った整数の被除数を示します。 +

+
+
+
+
+
+2. TurboSHAKE +
+
+
+
+2. ターボシェイク +
+
+
+
+
+
+2.1. Interface +
+
+
+
+2.1. インタフェース +
+
+
+
+
+

+TurboSHAKE is a family of eXtendable-Output Functions (XOFs). Internally, it makes use of the sponge construction, parameterized by two integers, the rate and the capacity, that sum to the permutation width (here, 1600 bits). The rate gives the number of bits processed or produced per call to the permutation, whereas the capacity determines the security level; see [FIPS202] for more details. This document focuses on only two instances, namely TurboSHAKE128 and TurboSHAKE256. (Note that the original definition includes a wider range of instances parameterized by their capacity [TURBOSHAKE].) +

+
+
+

+TurboSHAKE は、eXtendable-Output Functions (XOF) のファミリーです。内部的には、レートと容量の 2 つの整数でパラメータ化されたスポンジ構造を利用し、その合計が順列幅 (ここでは 1600 ビット) になります。レートは順列への呼び出しごとに処理または生成されるビット数を示しますが、容量はセキュリティ レベルを決定します。詳細については、[FIPS202] を参照してください。このドキュメントでは、TurboSHAKE128 と TurboSHAKE256 という 2 つのインスタンスのみに焦点を当てます。(元の定義には、容量 [TURBOSHAKE] によってパラメーター化された、より広範囲のインスタンスが含まれていることに注意してください。) +

+
+
+
+
+

+A TurboSHAKE instance takes a byte string M, an OPTIONAL byte D, and a positive integer L as input parameters, where: +

+
+
+

+TurboSHAKE インスタンスは、バイト文字列 M、オプションのバイト D、および正の整数 L を入力パラメータとして受け取ります。 +

+
+
+
+
+

+* M byte string is the message, +

+
+
+

+* M バイトの文字列がメッセージです。 +

+
+
+
+
+

+* D byte in the range [`01`, `02`, .. , `7F`] is an OPTIONAL domain separation byte, and +

+
+
+

+* [`01`, `02`, .. , `7F`] の範囲の D バイトはオプションのドメイン分離バイトであり、 +

+
+
+
+
+

+* L positive integer is the requested number of output bytes. +

+
+
+

+* L の正の整数は、要求された出力バイト数です。 +

+
+
+
+
+

+Conceptually, an XOF can be viewed as a hash function with an infinitely long output truncated to L bytes. This means that calling an XOF with the same input parameters but two different lengths yields outputs such that the shorter one is a prefix of the longer one. Specifically, if L1 < L2, then TurboSHAKE(M, D, L1) is the same as the first L1 bytes of TurboSHAKE(M, D, L2). +

+
+
+

+概念的には、XOF は、L バイトに切り詰められた無限に長い出力を持つハッシュ関数とみなすことができます。これは、同じ入力パラメータで 2 つの異なる長さを指定して XOF を呼び出すと、短い方が長い方のプレフィックスになるような出力が生成されることを意味します。具体的には、L1 < L2 の場合、TurboSHAKE(M, D, L1) は TurboSHAKE(M, D, L2) の最初の L1 バイトと同じになります。 +

+
+
+
+
+

+By default, the domain separation byte is `1F`. For an API that does not support a domain separation byte, D MUST be the `1F`. +

+
+
+

+デフォルトでは、ドメイン分離バイトは「1F」です。ドメイン分離バイトをサポートしない API の場合、D は `1F` でなければなりません。 +

+
+
+
+
+

+The TurboSHAKE instance produces output that is a hash of the (M, D) couple. If D is fixed, this becomes a hash of the message M. However, a protocol that requires a number of independent hash functions can choose different values for D to implement these. Specifically, for distinct values D1 and D2, TurboSHAKE(M, D1, L1) and TurboSHAKE(M, D2, L2) yield independent hashes of M. +

+
+
+

+TurboSHAKE インスタンスは、(M, D) カップルのハッシュである出力を生成します。D が固定されている場合、これはメッセージ M のハッシュになります。ただし、多数の独立したハッシュ関数を必要とするプロトコルでは、これらを実装するために D に異なる値を選択できます。具体的には、個別の値 D1 と D2 の場合、TurboSHAKE(M, D1, L1) と TurboSHAKE(M, D2, L2) は M の独立したハッシュを生成します。 +

+
+
+
+
+

+Note that an implementation MAY propose an incremental input interface where the input string M is given in pieces. If so, the output MUST be the same as if the function was called with M equal to the concatenation of the different pieces in the order they were given. Independently, an implementation MAY propose an incremental output interface where the output string is requested in pieces of given lengths. When the output is formed by concatenating the pieces in the requested order, it MUST be the same as if the function was called with L equal to the sum of the given lengths. +

+
+
+

+実装では、入力文字列 M が分割して与えられるインクリメンタル入力インターフェイスを提案してもよいことに注意してください。そうである場合、出力は、与えられた順序で異なる部分を連結したものに等しい M を指定して関数が呼び出された場合と同じでなければなりません (MUST)。独立して、実装は、出力文字列が指定された長さの断片で要求される増分出力インターフェイスを提案してもよい(MAY)。要求された順序で部分を連結することによって出力が形成される場合、それは、指定された長さの合計に等しい L で関数が呼び出された場合と同じでなければなりません (MUST)。 +

+
+
+
+
+
+2.2. Specifications +
+
+
+
+2.2. 仕様 +
+
+
+
+
+

+TurboSHAKE makes use of the permutation Keccak-p[1600,n_r=12], i.e., the permutation used in SHAKE and SHA-3 functions reduced to its last n_r=12 rounds as specified in FIPS 202; see Sections 3.3 and 3.4 of [FIPS202]. KP denotes this permutation. +

+
+
+

+TurboSHAKE は、順列 Keccak-p[1600,n_r=12] を利用します。つまり、FIPS 202 で指定されているように、SHAKE および SHA-3 関数で使用される順列が最後の n_r=12 ラウンドに縮小されます。[FIPS202] のセクション 3.3 および 3.4 を参照。KP はこの順列を示します。 +

+
+
+
+
+

+Similarly to SHAKE128, TurboSHAKE128 is a sponge function calling this permutation KP with a rate of 168 bytes or 1344 bits. It follows that TurboSHAKE128 has a capacity of 1600 - 1344 = 256 bits or 32 bytes. Respectively to SHAKE256, TurboSHAKE256 makes use of a rate of 136 bytes or 1088 bits and has a capacity of 512 bits or 64 bytes. +

+
+
+

+SHAKE128 と同様に、TurboSHAKE128 は、168 バイトまたは 1344 ビットのレートでこの順列 KP を呼び出すスポンジ関数です。したがって、TurboSHAKE128 の容量は 1600 - 1344 = 256 ビットまたは 32 バイトになります。SHAKE256 に対して、TurboSHAKE256 は 136 バイトまたは 1088 ビットのレートを利用し、512 ビットまたは 64 バイトの容量を持ちます。 +

+
+
+
+
+ 
+                            +---------------+===========+==========+
+                            |               | Rate      | Capacity |
+                            +===============+===========+==========+
+                            | TurboSHAKE128 | 168 Bytes | 32 Bytes |
+                            +===============+-----------+----------+
+                            | TurboSHAKE256 | 136 Bytes | 64 Bytes |
+                            +===============+-----------+----------+
+
+                                            Table 1
+
+
+
+
+
+

+We now describe the operations inside TurboSHAKE128. +

+
+
+

+TurboSHAKE128 内部の動作を説明します。 +

+
+
+
+
+

+* First, the input M' is formed by appending the domain separation byte D to the message M. +

+
+
+

+* まず、入力 M' は、ドメイン分離バイト D をメッセージ M に追加することによって形成されます。 +

+
+
+
+
+

+* If the length of M' is not a multiple of 168 bytes, then it is padded with zeros at the end to make it a multiple of 168 bytes. If M' is already a multiple of 168 bytes, then no padding is added. Then, a byte `80` is XORed to the last byte of the padded input M' and the resulting string is split into a sequence of 168-byte blocks. +

+
+
+

+* M' の長さが 168 バイトの倍数でない場合は、168 バイトの倍数にするために最後にゼロが埋め込まれます。M' がすでに 168 バイトの倍数である場合、パディングは追加されません。次に、バイト「80」がパディングされた入力 M' の最後のバイトと XOR 演算され、結果の文字列が 168 バイトのブロックのシーケンスに分割されます。 +

+
+
+
+
+

+* M' never has a length of 0 bytes due to the presence of the domain separation byte. +

+
+
+

+* ドメイン分離バイトが存在するため、M' の長さが 0 バイトになることはありません。 +

+
+
+
+
+

+* As defined by the sponge construction, the process operates on a state and consists of two phases: the absorbing phase, which processes the padded input M', and the squeezing phase, which produces the output. +

+
+
+

+* スポンジ構造で定義されているように、プロセスは状態に基づいて動作し、パッドされた入力 M' を処理する吸収フェーズと、出力を生成する絞りフェーズの 2 つのフェーズで構成されます。 +

+
+
+
+
+

+* In the absorbing phase, the state is initialized to all zero. The message blocks are XORed into the first 168 bytes of the state. Each block absorbed is followed with an application of KP to the state. +

+
+
+

+* 吸収フェーズでは、状態はすべて 0 に初期化されます。メッセージ ブロックは、状態の最初の 168 バイトに XOR 演算されます。吸収された各ブロックの後に、状態に KP が適用されます。 +

+
+
+
+
+

+* In the squeezing phase, the output is formed by taking the first 168 bytes of the state, applying KP to the state, and repeating as many times as is necessary. +

+
+
+

+* 圧縮フェーズでは、状態の最初の 168 バイトを取得し、その状態に KP を適用し、必要な回数だけ繰り返すことによって出力が形成されます。 +

+
+
+
+
+

+TurboSHAKE256 performs the same steps but makes use of 136-byte blocks with respect to the padding, absorbing, and squeezing phases. +

+
+
+

+TurboSHAKE256 は同じ手順を実行しますが、パディング、吸収、およびスクイージングのフェーズに関して 136 バイトのブロックを使用します。 +

+
+
+
+
+

+The definition of the TurboSHAKE functions equivalently implements the pad10*1 rule; see Section 5.1 of [FIPS202] for a definition of pad10*1. While M can be empty, the D byte is always present and is in the `01`-`7F` range. This last byte serves as domain separation and integrates the first bit of padding of the pad10*1 rule (hence, it cannot be `00`). Additionally, it must leave room for the second bit of padding (hence, it cannot have the most significant bit (MSB) set to 1), should it be the last byte of the block. For more details, refer to Section 6.1 of [KT] and Section 3 of [TURBOSHAKE]. +

+
+
+

+TurboSHAKE 関数の定義は、pad10*1 ルールを同等に実装します。Pad10*1 の定義については、[FIPS202] のセクション 5.1 を参照してください。M は空にすることもできますが、D バイトは常に存在し、「01」から「7F」の範囲内にあります。この最後のバイトはドメイン分離として機能し、pad10*1 ルールのパディングの最初のビットを統合します (したがって、「00」にすることはできません)。さらに、それがブロックの最後のバイトである場合、パディングの 2 番目のビット用の余地を残しておく必要があります (したがって、最上位ビット (MSB) を 1 に設定することはできません)。詳細については、[KT] のセクション 6.1 および [TURBOSHAKE] のセクション 3 を参照してください。 +

+
+
+
+
+

+The pseudocode versions of TurboSHAKE128 and TurboSHAKE256 are provided in Appendices A.2 and A.3, respectively. +

+
+
+

+TurboSHAKE128 と TurboSHAKE256 の擬似コード バージョンは、それぞれ付録 A.2 と A.3 に提供されています。 +

+
+
+
+
+
+3. KangarooTwelve: Tree Hashing over TurboSHAKE +
+
+
+
+3. KangarooTwelve: TurboSHAKE でのツリー ハッシュ +
+
+
+
+
+
+3.1. Interface +
+
+
+
+3.1. インタフェース +
+
+
+
+
+

+KangarooTwelve is a family of eXtendable-Output Functions (XOFs) consisting of the KT128 and KT256 instances. A KangarooTwelve instance takes two byte strings (M, C) and a positive integer L as input parameters, where: +

+
+
+

+KangarooTwelve は、KT128 インスタンスと KT256 インスタンスで構成される eXtendable-Output Function (XOF) ファミリです。KangarooTwelve インスタンスは、2 バイト文字列 (M、C) と正の整数 L を入力パラメータとして受け取ります。 +

+
+
+
+
+

+* M byte string is the message, +

+
+
+

+* M バイトの文字列がメッセージです。 +

+
+
+
+
+

+* C byte string is an OPTIONAL customization string, and +

+
+
+

+* C バイト文字列はオプションのカスタマイズ文字列であり、 +

+
+
+
+
+

+* L positive integer is the requested number of output bytes. +

+
+
+

+* L の正の整数は、要求された出力バイト数です。 +

+
+
+
+
+

+The customization string MAY serve as domain separation. It is typically a short string such as a name or an identifier (e.g., URI, Object Identifier (OID), etc.). It can serve the same purpose as TurboSHAKE's D input parameter (see Section 2.1) but with a larger range. +

+
+
+

+カスタマイズ文字列はドメイン分離として機能してもよい(MAY)。これは通常、名前や識別子 (URI、オブジェクト識別子 (OID) など) などの短い文字列です。TurboSHAKE の D 入力パラメータ (セクション 2.1 を参照) と同じ目的を果たすことができますが、範囲がより広くなります。 +

+
+
+
+
+

+By default, the customization string is the empty string. For an API that does not support a customization string parameter, C MUST be the empty string. +

+
+
+

+デフォルトでは、カスタマイズ文字列は空の文字列です。カスタマイズ文字列パラメータをサポートしない API の場合、C は空の文字列でなければなりません。 +

+
+
+
+
+

+Note that an implementation MAY propose an interface with the input and/or output provided incrementally, as specified in Section 2.1. +

+
+
+

+実装は、セクション 2.1 で指定されているように、段階的に提供される入力および/または出力とのインターフェイスを提案してもよいことに注意してください。 +

+
+
+
+
+
+3.2. Specification of KT128 +
+
+
+
+3.2. KT128の仕様 +
+
+
+
+
+

+On top of the sponge function TurboSHAKE128, KT128 uses a Sakura-compatible tree hash mode [SAKURA]. First, merge M and the OPTIONAL C to a single input string S in a reversible way. length_encode( |C| ) gives the length in bytes of C as a byte string. See Section 3.3. +

+
+
+

+KT128は、スポンジ機能TurboSHAKE128に加えて、さくら互換のツリーハッシュモード[SAKURA]を採用しています。まず、M と OPTIONAL C を単一の入力文字列 S に可逆的な方法でマージします。length_encode( |C| ) は、C のバイト長をバイト文字列として返します。セクション 3.3 を参照してください。 +

+
+
+
+
+ 
+       S = M || C || length_encode( |C| )
+
+
+
+
+
+

+Then, split S into n chunks of 8192 bytes. +

+
+
+

+次に、S を 8192 バイトの n 個のチャンクに分割します。 +

+
+
+
+
+ 
+       S = S_0 || .. || S_(n-1)
+       |S_0| = .. = |S_(n-2)| = 8192 bytes
+       |S_(n-1)| <= 8192 bytes
+
+
+
+
+
+

+From S_1 .. S_(n-1), compute the 32-byte chaining values CV_1 .. CV_(n-1). In order to be optimally efficient, this computation MAY exploit the parallelism available on the platform, such as single instruction, multiple data (SIMD) instructions. +

+
+
+

+S_1 .. S_(n-1) から、32 バイトの連鎖値 CV_1 .. CV_(n-1) を計算します。最適な効率を実現するために、この計算は、単一命令複数データ (SIMD) 命令など、プラットフォームで利用可能な並列処理を利用してもよい(MAY)。 +

+
+
+
+
+ 
+       CV_i = TurboSHAKE128( S_i, `0B`, 32 )
+
+
+
+
+
+

+Compute the final node: FinalNode. +

+
+
+

+最終ノード FinalNode を計算します。 +

+
+
+
+
+

+* If |S| <= 8192 bytes, FinalNode = S. +

+
+
+

+* |S| の場合<= 8192 バイト、FinalNode = S。 +

+
+
+
+
+

+* Otherwise, compute FinalNode as follows: +

+
+
+

+* それ以外の場合は、次のように FinalNode を計算します。 +

+
+
+
+
+ 
+       FinalNode = S_0 || `03 00 00 00 00 00 00 00`
+       FinalNode = FinalNode || CV_1
+                   ..
+       FinalNode = FinalNode || CV_(n-1)
+       FinalNode = FinalNode || length_encode(n-1)
+       FinalNode = FinalNode || `FF FF`
+
+
+
+
+
+

+Finally, the KT128 output is retrieved: +

+
+
+

+最後に、KT128 出力が取得されます。 +

+
+
+
+
+

+* If |S| <= 8192 bytes, from TurboSHAKE128( FinalNode, `07`, L ) +

+
+
+

+* |S| の場合<= 8192 バイト、TurboSHAKE128( FinalNode, `07`, L ) から +

+
+
+
+
+ 
+       KT128( M, C, L ) = TurboSHAKE128( FinalNode, `07`, L )
+
+
+
+
+
+

+* Otherwise, from TurboSHAKE128( FinalNode, `06`, L ) +

+
+
+

+* それ以外の場合、TurboSHAKE128( FinalNode, `06`, L ) から +

+
+
+
+
+ 
+       KT128( M, C, L ) = TurboSHAKE128( FinalNode, `06`, L )
+
+
+
+
+
+

+The following figure illustrates the computation flow of KT128 for |S| <= 8192 bytes: +

+
+
+

+次の図は、|S| に対する KT128 の計算フローを示しています。<= 8192 バイト: +

+
+
+
+
+ 
+       +--------------+  TurboSHAKE128(.., `07`, L)
+       |      S       |----------------------------->  output
+       +--------------+
+
+
+
+
+
+

+The following figure illustrates the computation flow of KT128 for |S| > 8192 bytes and where TurboSHAKE128 and length_encode( x ) are abbreviated as TSHK128 and l_e( x ), respectively: +

+
+
+

+次の図は、|S| に対する KT128 の計算フローを示しています。> 8192 バイトであり、TurboSHAKE128 と length_encode( x ) はそれぞれ TSHK128 と l_e( x ) と省略されます。 +

+
+
+
+
+ 
+                                     +--------------+
+                                     |     S_0      |
+                                     +--------------+
+                                           ||
+                                     +--------------+
+                                     | `03`||`00`^7 |
+                                     +--------------+
+                                           ||
+   +---------+  TSHK128(..,`0B`,32)  +--------------+
+   |   S_1   |---------------------->|     CV_1     |
+   +---------+                       +--------------+
+                                           ||
+   +---------+  TSHK128(..,`0B`,32)  +--------------+
+   |   S_2   |---------------------->|     CV_2     |
+   +---------+                       +--------------+
+                                           ||
+                  ..                       ..
+                                           ||
+   +---------+  TSHK128(..,`0B`,32)  +--------------+
+   | S_(n-1) |----------------------->|   CV_(n-1)  |
+   +---------+                       +--------------+
+                                           ||
+                                     +--------------+
+                                     |  l_e( n-1 )  |
+                                     +--------------+
+                                           ||
+                                     +--------------+
+                                     |   `FF FF`    |
+                                     +--------------+
+                                            | TSHK128(.., `06`, L)
+                                            +-------------------->  output
+
+
+
+
+
+

+A pseudocode version is provided in Appendix A.4. +

+
+
+

+疑似コードのバージョンは付録 A.4 に記載されています。 +

+
+
+
+
+

+The table below gathers the values of the domain separation bytes used by the tree hash mode: +

+
+
+

+以下の表は、ツリー ハッシュ モードで使用されるドメイン分離バイトの値をまとめたものです。 +

+
+
+
+
+ 
+                                          +==================+======+
+                                          | Type             | Byte |
+                                          +==================+======+
+                                          | SingleNode       | `07` |
+                                          +------------------+------+
+                                          | IntermediateNode | `0B` |
+                                          +------------------+------+
+                                          | FinalNode        | `06` |
+                                          +------------------+------+
+
+                                                    Table 2
+
+
+
+
+
+
+3.3. length_encode( x ) +
+
+
+
+3.3. length_encode( x ) +
+
+
+
+
+

+The function length_encode takes as inputs a non-negative integer x < 256**255 and outputs a string of bytes x_(n-1) || .. || x_0 || n where +

+
+
+

+関数 length_encode は、負でない整数 x < 256**255 を入力として受け取り、バイト文字列 x_(n-1) || を出力します。.. ||x_0 ||どこで +

+
+
+
+
+ 
+       x = sum of 256**i * x_i for i from 0 to n-1
+
+
+
+
+
+

+and where n is the smallest non-negative integer such that x < 256**n. n is also the length of x_(n-1) || .. || x_0. +

+
+
+

+ここで、n は、x < 256**n となる最小の非負の整数です。n は x_(n-1) の長さでもあります ||.. ||x_0。 +

+
+
+
+
+

+For example, length_encode(0) = `00`, length_encode(12) = `0C 01`, and length_encode(65538) = `01 00 02 03`. +

+
+
+

+たとえば、length_encode(0) = `00`、length_encode(12) = `0C 01`、および length_encode(65538) = `01 00 02 03` です。 +

+
+
+
+
+

+A pseudocode version is as follows, where { b } denotes the byte of numerical value b. +

+
+
+

+擬似コードのバージョンは次のとおりです。ここで、{ b } は数値 b のバイトを示します。 +

+
+
+
+
+ 
+     length_encode(x):
+       S = `00`^0
+
+       while x > 0
+           S = { x mod 256 } || S
+           x = x / 256
+
+       S = S || { |S| }
+
+       return S
+       end
+
+
+
+
+
+
+3.4. Specification of KT256 +
+
+
+
+3.4. KT256の仕様 +
+
+
+
+
+

+KT256 is specified exactly like KT128, with two differences: +

+
+
+

+KT256 は KT128 とまったく同じように指定されますが、次の 2 つの違いがあります。 +

+
+
+
+
+

+* All the calls to TurboSHAKE128 in KT128 are replaced with calls to TurboSHAKE256 in KT256. +

+
+
+

+* KT128 の TurboSHAKE128 への呼び出しはすべて、KT256 の TurboSHAKE256 への呼び出しに置き換えられます。 +

+
+
+
+
+

+* The chaining values CV_1 to CV_(n-1) are 64 bytes long in KT256 and are computed as follows: +

+
+
+

+* チェーン値 CV_1 から CV_(n-1) は、KT256 では 64 バイトの長さであり、次のように計算されます。 +

+
+
+
+
+ 
+       CV_i = TurboSHAKE256( S_i, `0B`, 64 )
+
+
+
+
+
+

+A pseudocode version is provided in Appendix A.5. +

+
+
+

+疑似コード バージョンは付録 A.5 に提供されています。 +

+
+
+
+
+
+4. Message Authentication Codes +
+
+
+
+4. メッセージ認証コード +
+
+
+
+
+

+Implementing a Message Authentication Code (MAC) with KT128 or KT256 MAY use a hash-then-MAC construction. This document defines and recommends a method called HopMAC: +

+
+
+

+KT128 または KT256 を使用したメッセージ認証コード (MAC) の実装では、hash-then-MAC 構造を使用してもよい(MAY)。この文書では、HopMAC と呼ばれる方法を定義し、推奨しています。 +

+
+
+
+
+ 
+       HopMAC128(Key, M, C, L) = KT128(Key, KT128(M, C, 32), L)
+       HopMAC256(Key, M, C, L) = KT256(Key, KT256(M, C, 64), L)
+
+
+
+
+
+

+Similarly to Hashed Message Authentication Code (HMAC), HopMAC consists of two calls: an inner call compressing the message M and the optional customization string C to a digest and an outer call computing the tag from the key and the digest. +

+
+
+

+ハッシュ メッセージ認証コード (HMAC) と同様に、HopMAC は 2 つの呼び出しで構成されます。1 つはメッセージ M とオプションのカスタマイズ文字列 C をダイジェストに圧縮する内部呼び出しで、もう 1 つはキーとダイジェストからタグを計算する外部呼び出しです。 +

+
+
+
+
+

+Unlike HMAC, the inner call to KangarooTwelve in HopMAC is keyless and does not require additional protection against side channel attacks (SCAs). Consequently, in an implementation that has to protect the HopMAC key against an SCA, only the outer call needs protection, and this amounts to a single execution of the underlying permutation (assuming the key length is at most 69 bytes). +

+
+
+

+HMAC とは異なり、HopMAC の KangarooTwelve への内部呼び出しはキーレスであり、サイド チャネル攻撃 (SCA) に対する追加の保護を必要としません。したがって、HopMAC キーを SCA から保護する必要がある実装では、保護が必要なのは外側の呼び出しのみであり、これは基礎となる置換の 1 回の実行に相当します (キーの長さが最大 69 バイトであると仮定)。 +

+
+
+
+
+

+In any case, TurboSHAKE128, TurboSHAKE256, KT128, and KT256 MAY be used to compute a MAC with the key reversibly prepended or appended to the input. For instance, one MAY compute a MAC on short messages simply calling KT128 with the key as the customization string, i.e., MAC = KT128(M, Key, L). +

+
+
+

+いずれの場合も、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 を使用して、入力の先頭または末尾に可逆的にキーを付加して MAC を計算できます。たとえば、カスタマイズ文字列としてキーを使用して KT128 を呼び出すだけで、ショート メッセージの MAC を計算できます (つまり、MAC = KT128(M, Key, L))。 +

+
+
+
+
+
+5. Test Vectors +
+
+
+
+5. テストベクター +
+
+
+
+
+

+Test vectors are based on the repetition of the pattern `00 01 02 .. F9 FA` with a specific length. ptn(n) defines a string by repeating the pattern `00 01 02 .. F9 FA` as many times as necessary and truncated to n bytes, for example: +

+
+
+

+テスト ベクトルは、特定の長さのパターン「00 01 02 .. F9 FA」の繰り返しに基づいています。ptn(n) は、パターン「00 01 02 .. F9 FA」を必要なだけ繰り返し、n バイトに切り詰めて文字列を定義します。次に例を示します。 +

+
+
+
+
+ 
+       Pattern for a length of 17 bytes:
+       ptn(17) =
+         `00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10`
+
+
+
+
+
+ 
+       Pattern for a length of 17**2 bytes:
+       ptn(17**2) =
+         `00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
+          10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
+          20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
+          30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
+          40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
+          50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
+          60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F
+          70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
+          80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F
+          90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F
+          A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF
+          B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF
+          C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF
+          D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF
+          E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF
+          F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA
+          00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
+          10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
+          20 21 22 23 24 25`
+
+
+
+
+
+ 
+     TurboSHAKE128(M=`00`^0, D=`1F`, 32):
+       `1E 41 5F 1C 59 83 AF F2 16 92 17 27 7D 17 BB 53
+        8C D9 45 A3 97 DD EC 54 1F 1C E4 1A F2 C1 B7 4C`
+
+     TurboSHAKE128(M=`00`^0, D=`1F`, 64):
+       `1E 41 5F 1C 59 83 AF F2 16 92 17 27 7D 17 BB 53
+        8C D9 45 A3 97 DD EC 54 1F 1C E4 1A F2 C1 B7 4C
+        3E 8C CA E2 A4 DA E5 6C 84 A0 4C 23 85 C0 3C 15
+        E8 19 3B DF 58 73 73 63 32 16 91 C0 54 62 C8 DF`
+
+     TurboSHAKE128(M=`00`^0, D=`1F`, 10032), last 32 bytes:
+       `A3 B9 B0 38 59 00 CE 76 1F 22 AE D5 48 E7 54 DA
+        10 A5 24 2D 62 E8 C6 58 E3 F3 A9 23 A7 55 56 07`
+
+     TurboSHAKE128(M=ptn(17**0 bytes), D=`1F`, 32):
+       `55 CE DD 6F 60 AF 7B B2 9A 40 42 AE 83 2E F3 F5
+        8D B7 29 9F 89 3E BB 92 47 24 7D 85 69 58 DA A9`
+
+     TurboSHAKE128(M=ptn(17**1 bytes), D=`1F`, 32):
+       `9C 97 D0 36 A3 BA C8 19 DB 70 ED E0 CA 55 4E C6
+        E4 C2 A1 A4 FF BF D9 EC 26 9C A6 A1 11 16 12 33`
+
+     TurboSHAKE128(M=ptn(17**2 bytes), D=`1F`, 32):
+       `96 C7 7C 27 9E 01 26 F7 FC 07 C9 B0 7F 5C DA E1
+        E0 BE 60 BD BE 10 62 00 40 E7 5D 72 23 A6 24 D2`
+
+     TurboSHAKE128(M=ptn(17**3 bytes), D=`1F`, 32):
+       `D4 97 6E B5 6B CF 11 85 20 58 2B 70 9F 73 E1 D6
+        85 3E 00 1F DA F8 0E 1B 13 E0 D0 59 9D 5F B3 72`
+
+     TurboSHAKE128(M=ptn(17**4 bytes), D=`1F`, 32):
+       `DA 67 C7 03 9E 98 BF 53 0C F7 A3 78 30 C6 66 4E
+        14 CB AB 7F 54 0F 58 40 3B 1B 82 95 13 18 EE 5C`
+
+     TurboSHAKE128(M=ptn(17**5 bytes), D=`1F`, 32):
+       `B9 7A 90 6F BF 83 EF 7C 81 25 17 AB F3 B2 D0 AE
+        A0 C4 F6 03 18 CE 11 CF 10 39 25 12 7F 59 EE CD`
+
+     TurboSHAKE128(M=ptn(17**6 bytes), D=`1F`, 32):
+       `35 CD 49 4A DE DE D2 F2 52 39 AF 09 A7 B8 EF 0C
+        4D 1C A4 FE 2D 1A C3 70 FA 63 21 6F E7 B4 C2 B1`
+
+     TurboSHAKE128(M=`FF FF FF`, D=`01`, 32):
+       `BF 32 3F 94 04 94 E8 8E E1 C5 40 FE 66 0B E8 A0
+        C9 3F 43 D1 5E C0 06 99 84 62 FA 99 4E ED 5D AB`
+
+     TurboSHAKE128(M=`FF`, D=`06`, 32):
+       `8E C9 C6 64 65 ED 0D 4A 6C 35 D1 35 06 71 8D 68
+        7A 25 CB 05 C7 4C CA 1E 42 50 1A BD 83 87 4A 67`
+
+     TurboSHAKE128(M=`FF FF FF`, D=`07`, 32):
+       `B6 58 57 60 01 CA D9 B1 E5 F3 99 A9 F7 77 23 BB
+        A0 54 58 04 2D 68 20 6F 72 52 68 2D BA 36 63 ED`
+
+     TurboSHAKE128(M=`FF FF FF FF FF FF FF`, D=`0B`, 32):
+       `8D EE AA 1A EC 47 CC EE 56 9F 65 9C 21 DF A8 E1
+        12 DB 3C EE 37 B1 81 78 B2 AC D8 05 B7 99 CC 37`
+
+     TurboSHAKE128(M=`FF`, D=`30`, 32):
+       `55 31 22 E2 13 5E 36 3C 32 92 BE D2 C6 42 1F A2
+        32 BA B0 3D AA 07 C7 D6 63 66 03 28 65 06 32 5B`
+
+     TurboSHAKE128(M=`FF FF FF`, D=`7F`, 32):
+       `16 27 4C C6 56 D4 4C EF D4 22 39 5D 0F 90 53 BD
+        A6 D2 8E 12 2A BA 15 C7 65 E5 AD 0E 6E AF 26 F9`
+
+
+
+
+
+ 
+     TurboSHAKE256(M=`00`^0, D=`1F`, 64):
+       `36 7A 32 9D AF EA 87 1C 78 02 EC 67 F9 05 AE 13
+        C5 76 95 DC 2C 66 63 C6 10 35 F5 9A 18 F8 E7 DB
+        11 ED C0 E1 2E 91 EA 60 EB 6B 32 DF 06 DD 7F 00
+        2F BA FA BB 6E 13 EC 1C C2 0D 99 55 47 60 0D B0`
+
+     TurboSHAKE256(M=`00`^0, D=`1F`, 10032), last 32 bytes:
+       `AB EF A1 16 30 C6 61 26 92 49 74 26 85 EC 08 2F
+        20 72 65 DC CF 2F 43 53 4E 9C 61 BA 0C 9D 1D 75`
+
+     TurboSHAKE256(M=ptn(17**0 bytes), D=`1F`, 64):
+       `3E 17 12 F9 28 F8 EA F1 05 46 32 B2 AA 0A 24 6E
+        D8 B0 C3 78 72 8F 60 BC 97 04 10 15 5C 28 82 0E
+        90 CC 90 D8 A3 00 6A A2 37 2C 5C 5E A1 76 B0 68
+        2B F2 2B AE 74 67 AC 94 F7 4D 43 D3 9B 04 82 E2`
+
+     TurboSHAKE256(M=ptn(17**1 bytes), D=`1F`, 64):
+       `B3 BA B0 30 0E 6A 19 1F BE 61 37 93 98 35 92 35
+        78 79 4E A5 48 43 F5 01 10 90 FA 2F 37 80 A9 E5
+        CB 22 C5 9D 78 B4 0A 0F BF F9 E6 72 C0 FB E0 97
+        0B D2 C8 45 09 1C 60 44 D6 87 05 4D A5 D8 E9 C7`
+
+     TurboSHAKE256(M=ptn(17**2 bytes), D=`1F`, 64):
+       `66 B8 10 DB 8E 90 78 04 24 C0 84 73 72 FD C9 57
+        10 88 2F DE 31 C6 DF 75 BE B9 D4 CD 93 05 CF CA
+        E3 5E 7B 83 E8 B7 E6 EB 4B 78 60 58 80 11 63 16
+        FE 2C 07 8A 09 B9 4A D7 B8 21 3C 0A 73 8B 65 C0`
+
+     TurboSHAKE256(M=ptn(17**3 bytes), D=`1F`, 64):
+       `C7 4E BC 91 9A 5B 3B 0D D1 22 81 85 BA 02 D2 9E
+        F4 42 D6 9D 3D 42 76 A9 3E FE 0B F9 A1 6A 7D C0
+        CD 4E AB AD AB 8C D7 A5 ED D9 66 95 F5 D3 60 AB
+        E0 9E 2C 65 11 A3 EC 39 7D A3 B7 6B 9E 16 74 FB`
+
+     TurboSHAKE256(M=ptn(17**4 bytes), D=`1F`, 64):
+       `02 CC 3A 88 97 E6 F4 F6 CC B6 FD 46 63 1B 1F 52
+        07 B6 6C 6D E9 C7 B5 5B 2D 1A 23 13 4A 17 0A FD
+        AC 23 4E AB A9 A7 7C FF 88 C1 F0 20 B7 37 24 61
+        8C 56 87 B3 62 C4 30 B2 48 CD 38 64 7F 84 8A 1D`
+
+     TurboSHAKE256(M=ptn(17**5 bytes), D=`1F`, 64):
+       `AD D5 3B 06 54 3E 58 4B 58 23 F6 26 99 6A EE 50
+        FE 45 ED 15 F2 02 43 A7 16 54 85 AC B4 AA 76 B4
+        FF DA 75 CE DF 6D 8C DC 95 C3 32 BD 56 F4 B9 86
+        B5 8B B1 7D 17 78 BF C1 B1 A9 75 45 CD F4 EC 9F`
+
+     TurboSHAKE256(M=ptn(17**6 bytes), D=`1F`, 64):
+       `9E 11 BC 59 C2 4E 73 99 3C 14 84 EC 66 35 8E F7
+        1D B7 4A EF D8 4E 12 3F 78 00 BA 9C 48 53 E0 2C
+        FE 70 1D 9E 6B B7 65 A3 04 F0 DC 34 A4 EE 3B A8
+        2C 41 0F 0D A7 0E 86 BF BD 90 EA 87 7C 2D 61 04`
+
+     TurboSHAKE256(M=`FF FF FF`, D=`01`, 64):
+       `D2 1C 6F BB F5 87 FA 22 82 F2 9A EA 62 01 75 FB
+        02 57 41 3A F7 8A 0B 1B 2A 87 41 9C E0 31 D9 33
+        AE 7A 4D 38 33 27 A8 A1 76 41 A3 4F 8A 1D 10 03
+        AD 7D A6 B7 2D BA 84 BB 62 FE F2 8F 62 F1 24 24`
+
+     TurboSHAKE256(M=`FF`, D=`06`, 64):
+       `73 8D 7B 4E 37 D1 8B 7F 22 AD 1B 53 13 E3 57 E3
+        DD 7D 07 05 6A 26 A3 03 C4 33 FA 35 33 45 52 80
+        F4 F5 A7 D4 F7 00 EF B4 37 FE 6D 28 14 05 E0 7B
+        E3 2A 0A 97 2E 22 E6 3A DC 1B 09 0D AE FE 00 4B`
+
+     TurboSHAKE256(M=`FF FF FF`, D=`07`, 64):
+       `18 B3 B5 B7 06 1C 2E 67 C1 75 3A 00 E6 AD 7E D7
+        BA 1C 90 6C F9 3E FB 70 92 EA F2 7F BE EB B7 55
+        AE 6E 29 24 93 C1 10 E4 8D 26 00 28 49 2B 8E 09
+        B5 50 06 12 B8 F2 57 89 85 DE D5 35 7D 00 EC 67`
+
+     TurboSHAKE256(M=`FF FF FF FF FF FF FF`, D=`0B`, 64):
+       `BB 36 76 49 51 EC 97 E9 D8 5F 7E E9 A6 7A 77 18
+        FC 00 5C F4 25 56 BE 79 CE 12 C0 BD E5 0E 57 36
+        D6 63 2B 0D 0D FB 20 2D 1B BB 8F FE 3D D7 4C B0
+        08 34 FA 75 6C B0 34 71 BA B1 3A 1E 2C 16 B3 C0`
+
+     TurboSHAKE256(M=`FF`, D=`30`, 64):
+       `F3 FE 12 87 3D 34 BC BB 2E 60 87 79 D6 B7 0E 7F
+        86 BE C7 E9 0B F1 13 CB D4 FD D0 C4 E2 F4 62 5E
+        14 8D D7 EE 1A 52 77 6C F7 7F 24 05 14 D9 CC FC
+        3B 5D DA B8 EE 25 5E 39 EE 38 90 72 96 2C 11 1A`
+
+     TurboSHAKE256(M=`FF FF FF`, D=`7F`, 64):
+       `AB E5 69 C1 F7 7E C3 40 F0 27 05 E7 D3 7C 9A B7
+        E1 55 51 6E 4A 6A 15 00 21 D7 0B 6F AC 0B B4 0C
+        06 9F 9A 98 28 A0 D5 75 CD 99 F9 BA E4 35 AB 1A
+        CF 7E D9 11 0B A9 7C E0 38 8D 07 4B AC 76 87 76`
+
+
+
+
+
+ 
+     KT128(M=`00`^0, C=`00`^0, 32):
+       `1A C2 D4 50 FC 3B 42 05 D1 9D A7 BF CA 1B 37 51
+        3C 08 03 57 7A C7 16 7F 06 FE 2C E1 F0 EF 39 E5`
+
+     KT128(M=`00`^0, C=`00`^0, 64):
+       `1A C2 D4 50 FC 3B 42 05 D1 9D A7 BF CA 1B 37 51
+        3C 08 03 57 7A C7 16 7F 06 FE 2C E1 F0 EF 39 E5
+        42 69 C0 56 B8 C8 2E 48 27 60 38 B6 D2 92 96 6C
+        C0 7A 3D 46 45 27 2E 31 FF 38 50 81 39 EB 0A 71`
+
+     KT128(M=`00`^0, C=`00`^0, 10032), last 32 bytes:
+       `E8 DC 56 36 42 F7 22 8C 84 68 4C 89 84 05 D3 A8
+        34 79 91 58 C0 79 B1 28 80 27 7A 1D 28 E2 FF 6D`
+
+     KT128(M=ptn(1 bytes), C=`00`^0, 32):
+       `2B DA 92 45 0E 8B 14 7F 8A 7C B6 29 E7 84 A0 58
+        EF CA 7C F7 D8 21 8E 02 D3 45 DF AA 65 24 4A 1F`
+
+     KT128(M=ptn(17 bytes), C=`00`^0, 32):
+       `6B F7 5F A2 23 91 98 DB 47 72 E3 64 78 F8 E1 9B
+        0F 37 12 05 F6 A9 A9 3A 27 3F 51 DF 37 12 28 88`
+
+     KT128(M=ptn(17**2 bytes), C=`00`^0, 32):
+       `0C 31 5E BC DE DB F6 14 26 DE 7D CF 8F B7 25 D1
+        E7 46 75 D7 F5 32 7A 50 67 F3 67 B1 08 EC B6 7C`
+
+     KT128(M=ptn(17**3 bytes), C=`00`^0, 32):
+       `CB 55 2E 2E C7 7D 99 10 70 1D 57 8B 45 7D DF 77
+        2C 12 E3 22 E4 EE 7F E4 17 F9 2C 75 8F 0D 59 D0`
+
+     KT128(M=ptn(17**4 bytes), C=`00`^0, 32):
+       `87 01 04 5E 22 20 53 45 FF 4D DA 05 55 5C BB 5C
+        3A F1 A7 71 C2 B8 9B AE F3 7D B4 3D 99 98 B9 FE`
+
+     KT128(M=ptn(17**5 bytes), C=`00`^0, 32):
+       `84 4D 61 09 33 B1 B9 96 3C BD EB 5A E3 B6 B0 5C
+        C7 CB D6 7C EE DF 88 3E B6 78 A0 A8 E0 37 16 82`
+
+     KT128(M=ptn(17**6 bytes), C=`00`^0, 32):
+       `3C 39 07 82 A8 A4 E8 9F A6 36 7F 72 FE AA F1 32
+        55 C8 D9 58 78 48 1D 3C D8 CE 85 F5 8E 88 0A F8`
+
+     KT128(`00`^0, C=ptn(1 bytes), 32):
+       `FA B6 58 DB 63 E9 4A 24 61 88 BF 7A F6 9A 13 30
+        45 F4 6E E9 84 C5 6E 3C 33 28 CA AF 1A A1 A5 83`
+
+     KT128(`FF`, C=ptn(41 bytes), 32):
+       `D8 48 C5 06 8C ED 73 6F 44 62 15 9B 98 67 FD 4C
+        20 B8 08 AC C3 D5 BC 48 E0 B0 6B A0 A3 76 2E C4`
+
+     KT128(`FF FF FF`, C=ptn(41**2 bytes), 32):
+       `C3 89 E5 00 9A E5 71 20 85 4C 2E 8C 64 67 0A C0
+        13 58 CF 4C 1B AF 89 44 7A 72 42 34 DC 7C ED 74`
+
+     KT128(`FF FF FF FF FF FF FF`, C=ptn(41**3 bytes), 32):
+       `75 D2 F8 6A 2E 64 45 66 72 6B 4F BC FC 56 57 B9
+        DB CF 07 0C 7B 0D CA 06 45 0A B2 91 D7 44 3B CF`
+
+     KT128(M=ptn(8191 bytes), C=`00`^0, 32):
+       `1B 57 76 36 F7 23 64 3E 99 0C C7 D6 A6 59 83 74
+        36 FD 6A 10 36 26 60 0E B8 30 1C D1 DB E5 53 D6`
+
+     KT128(M=ptn(8192 bytes), C=`00`^0, 32):
+       `48 F2 56 F6 77 2F 9E DF B6 A8 B6 61 EC 92 DC 93
+        B9 5E BD 05 A0 8A 17 B3 9A E3 49 08 70 C9 26 C3`
+
+     KT128(M=ptn(8192 bytes), C=ptn(8189 bytes), 32):
+       `3E D1 2F 70 FB 05 DD B5 86 89 51 0A B3 E4 D2 3C
+        6C 60 33 84 9A A0 1E 1D 8C 22 0A 29 7F ED CD 0B`
+
+     KT128(M=ptn(8192 bytes), C=ptn(8190 bytes), 32):
+       `6A 7C 1B 6A 5C D0 D8 C9 CA 94 3A 4A 21 6C C6 46
+        04 55 9A 2E A4 5F 78 57 0A 15 25 3D 67 BA 00 AE`
+
+
+
+
+
+ 
+     KT256(M=`00`^0, C=`00`^0, 64):
+       `B2 3D 2E 9C EA 9F 49 04 E0 2B EC 06 81 7F C1 0C
+        E3 8C E8 E9 3E F4 C8 9E 65 37 07 6A F8 64 64 04
+        E3 E8 B6 81 07 B8 83 3A 5D 30 49 0A A3 34 82 35
+        3F D4 AD C7 14 8E CB 78 28 55 00 3A AE BD E4 A9`
+
+     KT256(M=`00`^0, C=`00`^0, 128):
+       `B2 3D 2E 9C EA 9F 49 04 E0 2B EC 06 81 7F C1 0C
+        E3 8C E8 E9 3E F4 C8 9E 65 37 07 6A F8 64 64 04
+        E3 E8 B6 81 07 B8 83 3A 5D 30 49 0A A3 34 82 35
+        3F D4 AD C7 14 8E CB 78 28 55 00 3A AE BD E4 A9
+        B0 92 53 19 D8 EA 1E 12 1A 60 98 21 EC 19 EF EA
+        89 E6 D0 8D AE E1 66 2B 69 C8 40 28 9F 18 8B A8
+        60 F5 57 60 B6 1F 82 11 4C 03 0C 97 E5 17 84 49
+        60 8C CD 2C D2 D9 19 FC 78 29 FF 69 93 1A C4 D0`
+
+     KT256(M=`00`^0, C=`00`^0, 10064), last 64 bytes:
+       `AD 4A 1D 71 8C F9 50 50 67 09 A4 C3 33 96 13 9B
+        44 49 04 1F C7 9A 05 D6 8D A3 5F 1E 45 35 22 E0
+        56 C6 4F E9 49 58 E7 08 5F 29 64 88 82 59 B9 93
+        27 52 F3 CC D8 55 28 8E FE E5 FC BB 8B 56 30 69`
+
+     KT256(M=ptn(1 bytes), C=`00`^0, 64):
+       `0D 00 5A 19 40 85 36 02 17 12 8C F1 7F 91 E1 F7
+        13 14 EF A5 56 45 39 D4 44 91 2E 34 37 EF A1 7F
+        82 DB 6F 6F FE 76 E7 81 EA A0 68 BC E0 1F 2B BF
+        81 EA CB 98 3D 72 30 F2 FB 02 83 4A 21 B1 DD D0`
+
+     KT256(M=ptn(17 bytes), C=`00`^0, 64):
+       `1B A3 C0 2B 1F C5 14 47 4F 06 C8 97 99 78 A9 05
+        6C 84 83 F4 A1 B6 3D 0D CC EF E3 A2 8A 2F 32 3E
+        1C DC CA 40 EB F0 06 AC 76 EF 03 97 15 23 46 83
+        7B 12 77 D3 E7 FA A9 C9 65 3B 19 07 50 98 52 7B`
+
+     KT256(M=ptn(17**2 bytes), C=`00`^0, 64):
+       `DE 8C CB C6 3E 0F 13 3E BB 44 16 81 4D 4C 66 F6
+        91 BB F8 B6 A6 1E C0 A7 70 0F 83 6B 08 6C B0 29
+        D5 4F 12 AC 71 59 47 2C 72 DB 11 8C 35 B4 E6 AA
+        21 3C 65 62 CA AA 9D CC 51 89 59 E6 9B 10 F3 BA`
+
+     KT256(M=ptn(17**3 bytes), C=`00`^0, 64):
+       `64 7E FB 49 FE 9D 71 75 00 17 1B 41 E7 F1 1B D4
+        91 54 44 43 20 99 97 CE 1C 25 30 D1 5E B1 FF BB
+        59 89 35 EF 95 45 28 FF C1 52 B1 E4 D7 31 EE 26
+        83 68 06 74 36 5C D1 91 D5 62 BA E7 53 B8 4A A5`
+
+     KT256(M=ptn(17**4 bytes), C=`00`^0, 64):
+       `B0 62 75 D2 84 CD 1C F2 05 BC BE 57 DC CD 3E C1
+        FF 66 86 E3 ED 15 77 63 83 E1 F2 FA 3C 6A C8 F0
+        8B F8 A1 62 82 9D B1 A4 4B 2A 43 FF 83 DD 89 C3
+        CF 1C EB 61 ED E6 59 76 6D 5C CF 81 7A 62 BA 8D`
+
+     KT256(M=ptn(17**5 bytes), C=`00`^0, 64):
+       `94 73 83 1D 76 A4 C7 BF 77 AC E4 5B 59 F1 45 8B
+        16 73 D6 4B CD 87 7A 7C 66 B2 66 4A A6 DD 14 9E
+        60 EA B7 1B 5C 2B AB 85 8C 07 4D ED 81 DD CE 2B
+        40 22 B5 21 59 35 C0 D4 D1 9B F5 11 AE EB 07 72`
+
+     KT256(M=ptn(17**6 bytes), C=`00`^0, 64):
+       `06 52 B7 40 D7 8C 5E 1F 7C 8D CC 17 77 09 73 82
+        76 8B 7F F3 8F 9A 7A 20 F2 9F 41 3B B1 B3 04 5B
+        31 A5 57 8F 56 8F 91 1E 09 CF 44 74 6D A8 42 24
+        A5 26 6E 96 A4 A5 35 E8 71 32 4E 4F 9C 70 04 DA`
+
+     KT256(`00`^0, C=ptn(1 bytes), 64):
+       `92 80 F5 CC 39 B5 4A 5A 59 4E C6 3D E0 BB 99 37
+        1E 46 09 D4 4B F8 45 C2 F5 B8 C3 16 D7 2B 15 98
+        11 F7 48 F2 3E 3F AB BE 5C 32 26 EC 96 C6 21 86
+        DF 2D 33 E9 DF 74 C5 06 9C EE CB B4 DD 10 EF F6`
+
+     KT256(`FF`, C=ptn(41 bytes), 64):
+       `47 EF 96 DD 61 6F 20 09 37 AA 78 47 E3 4E C2 FE
+        AE 80 87 E3 76 1D C0 F8 C1 A1 54 F5 1D C9 CC F8
+        45 D7 AD BC E5 7F F6 4B 63 97 22 C6 A1 67 2E 3B
+        F5 37 2D 87 E0 0A FF 89 BE 97 24 07 56 99 88 53`
+
+     KT256(`FF FF FF`, C=ptn(41**2 bytes), 64):
+       `3B 48 66 7A 50 51 C5 96 6C 53 C5 D4 2B 95 DE 45
+        1E 05 58 4E 78 06 E2 FB 76 5E DA 95 90 74 17 2C
+        B4 38 A9 E9 1D DE 33 7C 98 E9 C4 1B ED 94 C4 E0
+        AE F4 31 D0 B6 4E F2 32 4F 79 32 CA A6 F5 49 69`
+
+     KT256(`FF FF FF FF FF FF FF`, C=ptn(41**3 bytes), 64):
+       `E0 91 1C C0 00 25 E1 54 08 31 E2 66 D9 4A DD 9B
+        98 71 21 42 B8 0D 26 29 E6 43 AA C4 EF AF 5A 3A
+        30 A8 8C BF 4A C2 A9 1A 24 32 74 30 54 FB CC 98
+        97 67 0E 86 BA 8C EC 2F C2 AC E9 C9 66 36 97 24`
+
+     KT256(M=ptn(8191 bytes), C=`00`^0, 64):
+       `30 81 43 4D 93 A4 10 8D 8D 8A 33 05 B8 96 82 CE
+        BE DC 7C A4 EA 8A 3C E8 69 FB B7 3C BE 4A 58 EE
+        F6 F2 4D E3 8F FC 17 05 14 C7 0E 7A B2 D0 1F 03
+        81 26 16 E8 63 D7 69 AF B3 75 31 93 BA 04 5B 20`
+
+     KT256(M=ptn(8192 bytes), C=`00`^0, 64):
+       `C6 EE 8E 2A D3 20 0C 01 8A C8 7A AA 03 1C DA C2
+        21 21 B4 12 D0 7D C6 E0 DC CB B5 34 23 74 7E 9A
+        1C 18 83 4D 99 DF 59 6C F0 CF 4B 8D FA FB 7B F0
+        2D 13 9D 0C 90 35 72 5A DC 1A 01 B7 23 0A 41 FA`
+
+     KT256(M=ptn(8192 bytes), C=ptn(8189 bytes), 64):
+       `74 E4 78 79 F1 0A 9C 5D 11 BD 2D A7 E1 94 FE 57
+        E8 63 78 BF 3C 3F 74 48 EF F3 C5 76 A0 F1 8C 5C
+        AA E0 99 99 79 51 20 90 A7 F3 48 AF 42 60 D4 DE
+        3C 37 F1 EC AF 8D 2C 2C 96 C1 D1 6C 64 B1 24 96`
+
+     KT256(M=ptn(8192 bytes), C=ptn(8190 bytes), 64):
+       `F4 B5 90 8B 92 9F FE 01 E0 F7 9E C2 F2 12 43 D4
+        1A 39 6B 2E 73 03 A6 AF 1D 63 99 CD 6C 7A 0A 2D
+        D7 C4 F6 07 E8 27 7F 9C 9B 1C B4 AB 9D DC 59 D4
+        B9 2D 1F C7 55 84 41 F1 83 2C 32 79 A4 24 1B 8B`
+
+
+
+
+
+
+6. IANA Considerations +
+
+
+
+6. IANAの考慮事項 +
+
+
+
+
+

+In the "Named Information Hash Algorithm Registry", k12-256 refers to the hash function obtained by evaluating KT128 on the input message with default C (the empty string) and L = 32 bytes (256 bits). Similarly, k12-512 refers to the hash function obtained by evaluating KT256 on the input message with default C (the empty string) and L = 64 bytes (512 bits). +

+
+
+

+「名前付き情報ハッシュ アルゴリズム レジストリ」では、k12-256 は、デフォルトの C (空の文字列) と L = 32 バイト (256 ビット) を使用して入力メッセージに対して KT128 を評価することによって得られるハッシュ関数を指します。同様に、k12-512 は、デフォルトの C (空の文字列) および L = 64 バイト (512 ビット) を使用して入力メッセージの KT256 を評価することによって取得されたハッシュ関数を指します。 +

+
+
+
+
+

+In the "COSE Algorithms" registry, IANA has added the following entries for TurboSHAKE and KangarooTwelve: +

+
+
+

+IANA は、「COSE Algorithms」レジストリに、TurboSHAKE および KangarooTwelve 用の次のエントリを追加しました。 +

+
+
+
+
+ 
+        +===============+=======+===================+==============+
+        | Name          | Value | Description       | Capabilities |
+        +===============+=======+===================+==============+
+        | TurboSHAKE128 | -261  | TurboSHAKE128 XOF | [kty]        |
+        +---------------+-------+-------------------+--------------+
+        | TurboSHAKE256 | -262  | TurboSHAKE256 XOF | [kty]        |
+        +---------------+-------+-------------------+--------------+
+        | KT128         | -263  | KT128 XOF         | [kty]        |
+        +---------------+-------+-------------------+--------------+
+        | KT256         | -264  | KT256 XOF         | [kty]        |
+        +---------------+-------+-------------------+--------------+
+
+                                  Table 3
+
+
+
+
+
+
+7. Security Considerations +
+
+
+
+7. セキュリティに関する考慮事項 +
+
+
+
+
+

+This document is meant to serve as a stable reference and an implementation guide for the KangarooTwelve and TurboSHAKE eXtendable-Output Functions. The security assurance of these functions relies on the cryptanalysis of reduced-round versions of Keccak, and they have the same claimed security strength as their corresponding SHAKE functions. +

+
+
+

+このドキュメントは、KangarooTwelve および TurboSHAKE eXtendable-Output 関数の安定したリファレンスおよび実装ガイドとして機能することを目的としています。これらの関数のセキュリティ保証は Keccak の縮小ラウンド バージョンの暗号解析に依存しており、対応する SHAKE 関数と同じセキュリティ強度が主張されています。 +

+
+
+
+
+ 
+                      +---------------+=============================+
+                      |               | Security Claim              |
+                      +===============+=============================+
+                      | TurboSHAKE128 | 128 bits (same as SHAKE128) |
+                      +===============+-----------------------------+
+                      | KT128         | 128 bits (same as SHAKE128) |
+                      +===============+-----------------------------+
+                      | TurboSHAKE256 | 256 bits (same as SHAKE256) |
+                      +===============+-----------------------------+
+                      | KT256         | 256 bits (same as SHAKE256) |
+                      +===============+-----------------------------+
+
+                                          Table 4
+
+
+
+
+
+

+To be more precise, KT128 is made of two layers: +

+
+
+

+より正確に言うと、KT128 は 2 つの層で構成されています。 +

+
+
+
+
+

+* The inner function TurboSHAKE128. The security assurance of this layer relies on cryptanalysis. The TurboSHAKE128 function is exactly Keccak[r=1344, c=256] (as in SHAKE128) reduced to 12 rounds. Any cryptanalysis of reduced-round Keccak is also cryptanalysis of reduced-round TurboSHAKE128 (provided the number of rounds attacked is not higher than 12). +

+
+
+

+* 内部関数 TurboSHAKE128。この層のセキュリティ保証は暗号解析に依存しています。TurboSHAKE128 関数は、正確に Keccak[r=1344, c=256] (SHAKE128 と同様) を 12 ラウンドに削減したものです。縮小ラウンド Keccak の暗号解析は、縮小ラウンド TurboSHAKE128 の暗号解析でもあります (攻撃ラウンド数が 12 を超えない場合)。 +

+
+
+
+
+

+* The tree hashing over TurboSHAKE128. This layer is a mode on top of TurboSHAKE128 that does not introduce any vulnerability thanks to the use of Sakura coding proven secure in [SAKURA]. +

+
+
+

+* TurboSHAKE128 をハッシュするツリー。このレイヤは、TurboSHAKE128 の上位にあるモードで、[SAKURA] で安全性が証明されたサクラ コーディングを使用しているため、脆弱性は発生しません。 +

+
+
+
+
+

+This reasoning is detailed and formalized in [KT]. +

+
+
+

+この推論は [KT] で詳しく説明され、形式化されています。 +

+
+
+
+
+

+KT256 is structured as KT128, except that it uses TurboSHAKE256 as the inner function. The TurboSHAKE256 function is exactly Keccak[r=1088, c=512] (as in SHAKE256) reduced to 12 rounds, and the same reasoning on cryptanalysis applies. +

+
+
+

+KT256 は、内部関数として TurboSHAKE256 を使用することを除いて、KT128 と同じ構造になっています。TurboSHAKE256 関数は、正確に Keccak[r=1088, c=512] (SHAKE256 と同様) を 12 ラウンドに削減したもので、暗号解析と同じ推論が適用されます。 +

+
+
+
+
+

+TurboSHAKE128 and KT128 aim at 128-bit security. To achieve 128-bit security strength, L, the chosen output length, MUST be large enough so that there are no generic attacks that violate 128-bit security. So for 128-bit (second) preimage security, the output should be at least 128 bits; for 128 bits of security against multi-target preimage attacks with T targets, the output should be at least 128+log_2(T) bits; and for 128-bit collision security, the output should be at least 256 bits. Furthermore, when the output length is at least 256 bits, TurboSHAKE128 and KT128 achieve NIST's post-quantum security level 2 [NISTPQ]. +

+
+
+

+TurboSHAKE128 と KT128 は 128 ビットのセキュリティを目指しています。128 ビットのセキュリティ強度を達成するには、128 ビットのセキュリティを侵害する一般的な攻撃が存在しないように、選択した出力長 L が十分に大きくなければなりません。したがって、128 ビット (2 番目) のプリイメージ セキュリティの場合、出力は少なくとも 128 ビットである必要があります。T 個のターゲットによるマルチターゲット プリイメージ攻撃に対する 128 ビットのセキュリティの場合、出力は少なくとも 128+log_2(T) ビットである必要があります。128 ビットの衝突セキュリティの場合、出力は少なくとも 256 ビットである必要があります。さらに、出力長が少なくとも 256 ビットの場合、TurboSHAKE128 と KT128 は NIST のポスト量子セキュリティ レベル 2 [NISTPQ] を達成します。 +

+
+
+
+
+

+Similarly, TurboSHAKE256 and KT256 aim at 256-bit security. To achieve 256-bit security strength, L, the chosen output length, MUST be large enough so that there are no generic attacks that violate 256-bit security. So for 256-bit (second) preimage security, the output should be at least 256 bits; for 256 bits of security against multi-target preimage attacks with T targets, the output should be at least 256+log_2(T) bits; and for 256-bit collision security, the output should be at least 512 bits. Furthermore, when the output length is at least 512 bits, TurboSHAKE256 and KT256 achieve NIST's post-quantum security level 5 [NISTPQ]. +

+
+
+

+同様に、TurboSHAKE256 と KT256 は 256 ビットのセキュリティを目指しています。256 ビットのセキュリティ強度を達成するには、選択した出力長である L は、256 ビットのセキュリティを侵害する一般的な攻撃が存在しないように十分な大きさでなければなりません。したがって、256 ビット (2 番目) のプリイメージ セキュリティの場合、出力は少なくとも 256 ビットである必要があります。T 個のターゲットによるマルチターゲット プリイメージ攻撃に対する 256 ビットのセキュリティの場合、出力は少なくとも 256+log_2(T) ビットである必要があります。256 ビットの衝突セキュリティの場合、出力は少なくとも 512 ビットである必要があります。さらに、出力長が少なくとも 512 ビットの場合、TurboSHAKE256 と KT256 は NIST のポスト量子セキュリティ レベル 5 [NISTPQ] を達成します。 +

+
+
+
+
+

+Unlike the SHA-256 and SHA-512 functions, TurboSHAKE128, TurboSHAKE256, KT128, and KT256 do not suffer from the length extension weakness and therefore do not require the use of the HMAC construction, for instance, when used for MAC computation [FIPS198]. Also, they can naturally be used as a key derivation function. The input must be an injective encoding of secret and diversification material, and the output can be taken as the derived key(s). The input does not need to be uniformly distributed, e.g., it can be a shared secret produced by the Diffie-Hellman or Elliptic Curve Diffie-Hellman (ECDH) protocol, but it needs to have sufficient min-entropy. +

+
+
+

+SHA-256 および SHA-512 関数とは異なり、TurboSHAKE128、TurboSHAKE256、KT128、および KT256 は長さ拡張の弱点に悩まされないため、たとえば MAC 計算に使用される場合に HMAC 構造を使用する必要がありません [FIPS198]。また、当然ながら鍵導出関数としても利用できます。入力は秘密および多様化マテリアルの単射エンコーディングである必要があり、出力は派生キーとして取得できます。入力は均一に分散される必要はなく、たとえば、Diffie-Hellman または Elliptic Curve Diffie-Hellman (ECDH) プロトコルによって生成された共有秘密でも構いませんが、十分な最小エントロピーが必要です。 +

+
+
+
+
+

+Lastly, as KT128 and KT256 use TurboSHAKE with three values for D, namely 0x06, 0x07, and 0x0B, protocols that use both KT128 and TurboSHAKE128 or both KT256 and TurboSHAKE256 SHOULD avoid using these three values for D. +

+
+
+

+最後に、KT128 と KT256 は D に 3 つの値、つまり 0x06、0x07、0x0B を指定して TurboSHAKE を使用するため、KT128 と TurboSHAKE128 の両方、または KT256 と TurboSHAKE256 の両方を使用するプロトコルは、D にこれら 3 つの値を使用することを避けるべきです(SHOULD)。 +

+
+
+
+
+
+8. References +
+
+
+
+8. 参考文献 +
+
+
+
+
+
+8.1. Normative References +
+
+
+
+8.1. 引用文献 +
+
+
+
+
+ 
+   [FIPS202]  NIST, "SHA-3 Standard: Permutation-Based Hash and
+              Extendable-Output Functions", NIST FIPS 202,
+              DOI 10.6028/NIST.FIPS.202, August 2015,
+              <https://nvlpubs.nist.gov/nistpubs/FIPS/
+              NIST.FIPS.202.pdf>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [SP800-185]
+              Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived
+              Functions: cSHAKE, KMAC, TupleHash and ParallelHash",
+              National Institute of Standards and Technology, NIST
+              SP 800-185, DOI 10.6028/NIST.SP.800-185, December 2016,
+              <https://doi.org/10.6028/NIST.SP.800-185>.
+
+
+
+
+
+
+8.2. Informative References +
+
+
+
+8.2. 参考引用 +
+
+
+
+
+ 
+   [FIPS180]  NIST, "Secure Hash Standard", NIST FIPS 180-4,
+              DOI 10.6028/NIST.FIPS.180-4, August 2015,
+              <https://nvlpubs.nist.gov/nistpubs/FIPS/
+              NIST.FIPS.180-4.pdf>.
+
+
+
+
+
+ 
+   [FIPS198]  NIST, "The Keyed-Hash Message Authentication Code (HMAC)",
+              NIST FIPS 198-1, DOI 10.6028/NIST.FIPS.198-1, July 2008,
+              <https://nvlpubs.nist.gov/nistpubs/FIPS/
+              NIST.FIPS.198-1.pdf>.
+
+
+
+
+
+ 
+   [KECCAK_CRYPTANALYSIS]
+              Keccak Team, "Summary of Third-party cryptanalysis of
+              Keccak", <https://www.keccak.team/third_party.html>.
+
+
+
+
+
+ 
+   [KT]       Bertoni, G., Daemen, J., Peeters, M., Van Assche, G., Van
+              Keer, R., and B. Viguier, "KangarooTwelve: Fast Hashing
+              Based on Keccak-p", Applied Cryptography and Network
+              Security (ACNS 2018), Lecture Notes in Computer Science,
+              vol. 10892, pp. 400-418, DOI 10.1007/978-3-319-93387-0_21,
+              June 2018, <https://link.springer.com/
+              chapter/10.1007/978-3-319-93387-0_21>.
+
+
+
+
+
+ 
+   [NISTPQ]   NIST, "Submission Requirements and Evaluation Criteria for
+              the Post-Quantum Cryptography Standardization Process",
+              <https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-
+              Cryptography/documents/call-for-proposals-final-dec-
+              2016.pdf>.
+
+
+
+
+
+ 
+   [SAKURA]   Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche,
+              "Sakura: a Flexible Coding for Tree Hashing", Applied
+              Cryptography and Network Security (ACNS 2014), Lecture
+              Notes in Computer Science, vol. 8479, pp. 217-234,
+              DOI 10.1007/978-3-319-07536-5_14, 2014,
+              <https://link.springer.com/
+              chapter/10.1007/978-3-319-07536-5_14>.
+
+
+
+
+
+ 
+   [TURBOSHAKE]
+              Bertoni, G., Daemen, J., Hoffert, S., Peeters, M., Van
+              Assche, G., Van Keer, R., and B. Viguier, "TurboSHAKE",
+              Cryptology ePrint Archive, Paper 2023/342, March 2023,
+              <http://eprint.iacr.org/2023/342>.
+
+
+
+
+
+ 
+   [XKCP]     "eXtended Keccak Code Package", commit 64404bee, December
+              2022, <https://github.com/XKCP/XKCP>.
+
+
+
+
+
+
+Appendix A. Pseudocode +
+
+
+
+付録A. 擬似コード +
+
+
+
+
+

+The subsections of this appendix contain pseudocode definitions of TurboSHAKE128, TurboSHAKE256, and KangarooTwelve. Standalone Python versions are also available in the Keccak Code Package [XKCP] and in [KT] +

+
+
+

+この付録のサブセクションには、TurboSHAKE128、TurboSHAKE256、および KangarooTwelve の疑似コード定義が含まれています。スタンドアロン Python バージョンは Keccak コード パッケージ [XKCP] および [KT] でも入手できます。 +

+
+
+
+
+
+A.1. Keccak-p[1600,n_r=12] +
+
+
+
+A.1. ケチャック-p[1600,n_r=12] +
+
+
+
+
+ 
+   KP(state):
+     RC[0]  = `8B 80 00 80 00 00 00 00`
+     RC[1]  = `8B 00 00 00 00 00 00 80`
+     RC[2]  = `89 80 00 00 00 00 00 80`
+     RC[3]  = `03 80 00 00 00 00 00 80`
+     RC[4]  = `02 80 00 00 00 00 00 80`
+     RC[5]  = `80 00 00 00 00 00 00 80`
+     RC[6]  = `0A 80 00 00 00 00 00 00`
+     RC[7]  = `0A 00 00 80 00 00 00 80`
+     RC[8]  = `81 80 00 80 00 00 00 80`
+     RC[9]  = `80 80 00 00 00 00 00 80`
+     RC[10] = `01 00 00 80 00 00 00 00`
+     RC[11] = `08 80 00 80 00 00 00 80`
+
+     for x from 0 to 4
+       for y from 0 to 4
+         lanes[x][y] = state[8*(x+5*y):8*(x+5*y)+8]
+
+     for round from 0 to 11
+       # theta
+       for x from 0 to 4
+         C[x] = lanes[x][0]
+         C[x] ^= lanes[x][1]
+         C[x] ^= lanes[x][2]
+         C[x] ^= lanes[x][3]
+         C[x] ^= lanes[x][4]
+       for x from 0 to 4
+         D[x] = C[(x+4) mod 5] ^ ROL64(C[(x+1) mod 5], 1)
+       for y from 0 to 4
+         for x from 0 to 4
+           lanes[x][y] = lanes[x][y]^D[x]
+
+       # rho and pi
+       (x, y) = (1, 0)
+       current = lanes[x][y]
+       for t from 0 to 23
+         (x, y) = (y, (2*x+3*y) mod 5)
+         (current, lanes[x][y]) =
+             (lanes[x][y], ROL64(current, (t+1)*(t+2)/2))
+
+       # chi
+       for y from 0 to 4
+         for x from 0 to 4
+           T[x] = lanes[x][y]
+         for x from 0 to 4
+           lanes[x][y] = T[x] ^((not T[(x+1) mod 5]) & T[(x+2) mod 5])
+
+       # iota
+       lanes[0][0] ^= RC[round]
+
+     state = `00`^0
+     for y from 0 to 4
+       for x from 0 to 4
+         state = state || lanes[x][y]
+
+     return state
+     end
+
+
+
+
+
+

+where ROL64(x, y) is a rotation of the 'x' 64-bit word toward the bits with higher indexes by 'y' positions. The 8-bytes byte string x is interpreted as a 64-bit word in little-endian format. +

+
+
+

+ここで、ROL64(x, y) は、「x」の 64 ビット ワードを、より高いインデックスを持つビットに向けて「y」位置だけ回転させたものです。8 バイトのバイト文字列 x は、リトル エンディアン形式の 64 ビット ワードとして解釈されます。 +

+
+
+
+
+
+A.2. TurboSHAKE128 +
+
+
+
+A.2. ターボシェイク128 +
+
+
+
+
+ 
+   TurboSHAKE128(message, separationByte, outputByteLen):
+     offset = 0
+     state = `00`^200
+     input = message || separationByte
+
+     # === Absorb complete blocks ===
+     while offset < |input| - 168
+         state ^= input[offset : offset + 168] || `00`^32
+         state = KP(state)
+         offset += 168
+
+     # === Absorb last block and treatment of padding ===
+     LastBlockLength = |input| - offset
+     state ^= input[offset:] || `00`^(200-LastBlockLength)
+     state ^= `00`^167 || `80` || `00`^32
+     state = KP(state)
+
+     # === Squeeze ===
+     output = `00`^0
+     while outputByteLen > 168
+         output = output || state[0:168]
+         outputByteLen -= 168
+         state = KP(state)
+
+     output = output || state[0:outputByteLen]
+
+     return output
+
+
+
+
+
+
+A.3. TurboSHAKE256 +
+
+
+
+A.3. ターボシェイク256 +
+
+
+
+
+ 
+   TurboSHAKE256(message, separationByte, outputByteLen):
+     offset = 0
+     state = `00`^200
+     input = message || separationByte
+
+     # === Absorb complete blocks ===
+     while offset < |input| - 136
+         state ^= input[offset : offset + 136] || `00`^64
+         state = KP(state)
+         offset += 136
+
+     # === Absorb last block and treatment of padding ===
+     LastBlockLength = |input| - offset
+     state ^= input[offset:] || `00`^(200-LastBlockLength)
+     state ^= `00`^135 || `80` || `00`^64
+     state = KP(state)
+
+     # === Squeeze ===
+     output = `00`^0
+     while outputByteLen > 136
+         output = output || state[0:136]
+         outputByteLen -= 136
+         state = KP(state)
+
+     output = output || state[0:outputByteLen]
+
+     return output
+
+
+
+
+
+
+A.4. KT128 +
+
+
+
+A.4. KT128 +
+
+
+
+
+ 
+   KT128(inputMessage, customString, outputByteLen):
+     S = inputMessage || customString
+     S = S || length_encode( |customString| )
+
+     if |S| <= 8192
+         return TurboSHAKE128(S, `07`, outputByteLen)
+     else
+         # === Kangaroo hopping ===
+         FinalNode = S[0:8192] || `03` || `00`^7
+         offset = 8192
+         numBlock = 0
+         while offset < |S|
+             blockSize = min( |S| - offset, 8192)
+             CV = TurboSHAKE128(S[offset : offset+blockSize], `0B`, 32)
+             FinalNode = FinalNode || CV
+             numBlock += 1
+             offset   += blockSize
+
+         FinalNode = FinalNode || length_encode( numBlock ) || `FF FF`
+
+         return TurboSHAKE128(FinalNode, `06`, outputByteLen)
+     end
+
+
+
+
+
+
+A.5. KT256 +
+
+
+
+A.5. KT256 +
+
+
+
+
+ 
+   KT256(inputMessage, customString, outputByteLen):
+     S = inputMessage || customString
+     S = S || length_encode( |customString| )
+
+     if |S| <= 8192
+         return TurboSHAKE256(S, `07`, outputByteLen)
+     else
+         # === Kangaroo hopping ===
+         FinalNode = S[0:8192] || `03` || `00`^7
+         offset = 8192
+         numBlock = 0
+         while offset < |S|
+             blockSize = min( |S| - offset, 8192)
+             CV = TurboSHAKE256(S[offset : offset+blockSize], `0B`, 64)
+             FinalNode = FinalNode || CV
+             numBlock += 1
+             offset   += blockSize
+
+         FinalNode = FinalNode || length_encode( numBlock ) || `FF FF`
+
+         return TurboSHAKE256(FinalNode, `06`, outputByteLen)
+     end
+
+
+
+
+
+
+Authors' Addresses +
+
+
+
+著者の住所 +
+
+
+
+
+ 
+   Benoît Viguier
+   ABN AMRO Bank
+   Groenelaan 2
+   Amstelveen
+   Netherlands
+   Email: cs.ru.nl@viguier.nl
+
+
+
+
+
+ 
+   David Wong (editor)
+   zkSecurity
+   Email: davidwong.crypto@gmail.com
+
+
+
+
+
+ 
+   Gilles Van Assche (editor)
+   STMicroelectronics
+   Email: gilles.vanassche@st.com
+
+
+
+
+
+ 
+   Quynh Dang (editor)
+   National Institute of Standards and Technology
+   Email: quynh.dang@nist.gov
+
+
+
+
+
+ 
+   Joan Daemen (editor)
+   Radboud University
+   Email: joan@cs.ru.nl
+
+
+
+
+ + + diff --git a/html/rfc9866.html b/html/rfc9866.html new file mode 100644 index 000000000..27e8fdd1c --- /dev/null +++ b/html/rfc9866.html @@ -0,0 +1,3043 @@ + + + + + + RFC 9866 - Root Node Failure Detector (RNFD): Fast Detection of Border Router Crashes in the Routing Protocol for Low-Power and Lossy Networks (RPL) 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)                       K. Iwanicki
+Request for Comments: 9866                          University of Warsaw
+Category: Standards Track                                   October 2025
+ISSN: 2070-1721
+
+
+
+
+
+
+ Root Node Failure Detector (RNFD): Fast Detection of Border Router Crashes in the Routing Protocol for Low-Power and Lossy Networks (RPL) +
+
+
+
+ルート ノード障害検出器 (RNFD): 低電力および損失の多いネットワーク (RPL) のルーティング プロトコルにおけるボーダー ルーターのクラッシュを迅速に検出 +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+By and large, correct operation of a network running the Routing Protocol for Low-Power and Lossy Networks (RPL) requires border routers to be up. In many applications, it is beneficial for the nodes to detect a failure of a border router as soon as possible to trigger fallback actions. This document specifies the Root Node Failure Detector (RNFD), an extension to RPL that expedites detection of border router crashes by having nodes collaboratively monitor the status of a given border router. The extension introduces an additional state at each node, a new type of RPL Control Message Option for synchronizing this state among different nodes, and the coordination algorithm itself. +

+
+
+

+一般に、低電力および損失の多いネットワーク用のルーティング プロトコル (RPL) を実行しているネットワークが正しく動作するには、境界ルーターが稼働している必要があります。多くのアプリケーションでは、ノードがボーダー ルーターの障害をできるだけ早く検出してフォールバック アクションをトリガーすることが有益です。この文書では、ノードが連携して特定の境界ルータのステータスを監視することで、境界ルータのクラッシュの検出を迅速化する RPL の拡張機能である、ルート ノード障害検出器 (RNFD) を指定します。この拡張機能では、各ノードでの追加の状態、異なるノード間でこの状態を同期するための新しいタイプの RPL 制御メッセージ オプション、および調整アルゴリズム自体が導入されます。 +

+
+
+
+
+
+Status of This Memo +
+
+
+
+本文書の位置付け +
+
+
+
+
+

+This is an Internet Standards Track document. +

+
+
+

+これはインターネット標準化トラックの文書です。 +

+
+
+
+
+

+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 Internet Standards is available in Section 2 of RFC 7841. +

+
+
+

+このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、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/rfc9866. +

+
+
+

+この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9866 で入手できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+Copyright (c) 2025 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+     1.1.  Effects of LBR Crashes
+     1.2.  Design Principles
+     1.3.  Other Solutions
+   2.  Terminology
+   3.  Overview
+     3.1.  Protocol State Machine
+     3.2.  Counters and Communication
+   4.  The RNFD Option
+     4.1.  General CFRC Requirements
+     4.2.  Format of the Option
+   5.  RPL Router Behavior
+     5.1.  Joining a DODAG Version and Changing the RNFD Role
+     5.2.  Detecting and Verifying Problems with the DODAG Root
+     5.3.  Disseminating Observations and Reaching Agreement
+     5.4.  DODAG Root's Behavior
+     5.5.  Activating and Deactivating the Protocol on Demand
+     5.6.  Processing CFRCs of Incompatible Lengths
+     5.7.  Summary of RNFD's Interactions with RPL
+     5.8.  Summary of RNFD's Constants
+   6.  Manageability Considerations
+     6.1.  Role Assignment and CFRC Size Adjustment
+     6.2.  Virtual DODAG Roots
+     6.3.  Monitoring
+   7.  Security Considerations
+   8.  IANA Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgements
+   Author's Address
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+RPL is an IPv6 routing protocol for Low-Power and Lossy Networks (LLNs) [RFC6550]. Such networks are usually constrained in device energy and channel capacity. They are formed largely of nodes that offer little processing power and memory, and links that are of variable qualities and support low data rates. Therefore, a significant challenge that a routing protocol for LLNs has to address is minimizing resource consumption without sacrificing reaction time to network changes. +

+
+
+

+RPL は、低電力および損失の多いネットワーク (LLN) 用の IPv6 ルーティング プロトコル [RFC6550] です。このようなネットワークは通常、デバイスのエネルギーとチャネル容量に制約があります。これらは主に、処理能力とメモリがほとんどないノードと、品質が変動し、低いデータ レートをサポートするリンクで構成されています。したがって、LLN のルーティング プロトコルが対処しなければならない重要な課題は、ネットワークの変更に対する反応時間を犠牲にすることなくリソースの消費を最小限に抑えることです。 +

+
+
+
+
+

+One of the main design principles adopted in RPL to minimize node resource consumption is delegating much of the responsibility for routing to LLN Border Routers (LBRs). A network is organized into Destination-Oriented Directed Acyclic Graphs (DODAGs), each corresponding to an LBR and having all its paths terminate at the LBR. To this end, every node is dynamically assigned a Rank representing its distance to a given LBR, measured in some metric, with the LBR having the minimal Rank, which reflects its role as the DODAG root. The Ranks allow each non-LBR node to select from among its neighbors (i.e., nodes to which the node has links) those that are closer to the LBR than the node itself (i.e., the node's parents in the graph). The resulting DODAG paths, consisting of the node-parent links, are utilized for routing packets upward to the LBR and outside the LLN. They are also used by nodes to periodically report their connectivity upward to the LBR, which allows for directing packets downward from the LBR to these nodes (e.g., by means of source routing [RFC6554]). All in all, not only do LBRs participate in routing, but they also drive the process of DODAG construction and maintenance underlying the protocol. +

+
+
+

+ノード リソースの消費を最小限に抑えるために RPL で採用されている主な設計原則の 1 つは、ルーティングの責任の多くを LLN ボーダー ルーター (LBR) に委任することです。ネットワークは、Destination-Oriented Directed Acyclic Graphs (DODAG) に編成され、各 DODAG は LBR に対応し、すべてのパスが LBR で終端します。この目的を達成するために、すべてのノードには、特定のメトリックで測定された特定の LBR までの距離を表すランクが動的に割り当てられます。LBR は、DODAG ルートとしての役割を反映する最小ランクを持ちます。ランクにより、各非 LBR ノードは、その隣接ノード (つまり、ノードがリンクを持つノード) の中から、ノード自体 (つまり、グラフ内のノードの親) よりも LBR に近いものを選択できます。結果として生じる DODAG パスは、ノードと親のリンクで構成され、LBR および LLN の外側へ上向きにパケットをルーティングするために利用されます。これらは、ノードが LBR に上向きの接続を定期的に報告するためにも使用され、これにより、LBR からこれらのノードにパケットを下向きに送信することが可能になります (たとえば、ソース ルーティング [RFC6554] によって)。全体として、LBR はルーティングに参加するだけでなく、プロトコルの基礎となる DODAG 構築および保守のプロセスも推進します。 +

+
+
+
+
+

+To play this central role, LBRs are expected to be more capable than regular LLN nodes. They are assumed not to be constrained in computing power, memory, and energy, which often entails a more involved hardware-software architecture and tethered power supply. However, this also makes them prone to failures, especially since it is often difficult to ensure a backup power supply for every LBR in large deployments. +

+
+
+

+この中心的な役割を果たすために、LBR には通常の LLN ノードよりも高い能力が期待されます。これらは、コンピューティング能力、メモリ、エネルギーの制約を受けないと想定されており、多くの場合、より複雑なハードウェア/ソフトウェア アーキテクチャと接続された電源が必要になります。ただし、特に大規模な導入ではすべての LBR にバックアップ電源を確保することが困難な場合が多いため、これにより障害が発生しやすくなります。 +

+
+
+
+
+
+1.1. Effects of LBR Crashes +
+
+
+
+1.1. LBR クラッシュの影響 +
+
+
+
+
+

+When an LBR crashes, or more generally, fails in a way that prevents other nodes in its DODAG from communicating with it, the nodes also lose the ability to communicate with other Internet hosts. In addition, a significant fraction of DODAG paths interconnecting the nodes become invalid, as they pass through the dead LBR. The others also degenerate as a result of DODAG repair attempts, which are bound to fail. In effect, routing inside the DODAG also becomes largely impossible. Consequently, it is desirable that an LBR crash be detected by the nodes fast, so that they can leave the broken DODAG and join another one or trigger additional application- or deployment-dependent fallback mechanisms, thereby minimizing the negative impact of the disconnection. +

+
+
+

+LBR がクラッシュすると、より一般的には、DODAG 内の他のノードが LBR と通信できなくなるような障害が発生すると、ノードは他のインターネット ホストと通信する能力も失います。さらに、ノードを相互接続する DODAG パスのかなりの部分が、デッド LBR を通過するため無効になります。他のものも DODAG 修復試行の結果として縮退しますが、失敗することは間違いありません。実際、DODAG 内のルーティングもほとんど不可能になります。したがって、LBR クラッシュがノードによって迅速に検出され、壊れた DODAG を離れて別の DODAG に参加したり、追加のアプリケーション依存またはデプロイメント依存のフォールバック メカニズムをトリガーしたりして、切断による悪影響を最小限に抑えることができることが望ましいです。 +

+
+
+
+
+

+Since all DODAG paths lead to the corresponding LBR, detecting its crash by a node entails dropping all parents and adopting an infinite Rank, which reflects the node's inability to reach the dead LBR. Depending on the deployment settings, the node can then remain in such a state, join a different DODAG, or even become the root of a floating DODAG. In any case, however, achieving this state for all nodes is slow, can generate heavy traffic, and is difficult to implement correctly [Iwanicki16] [Paszkowska19] [Ciolkosz19]. +

+
+
+

+すべての DODAG パスは対応する LBR につながるため、ノードによってそのクラッシュを検出するには、すべての親を削除し、ノードがデッド LBR に到達できないことを反映する無限ランクを採用する必要があります。デプロイメント設定に応じて、ノードはそのような状態を維持したり、別の DODAG に参加したり、フローティング DODAG のルートになることもあります。ただし、いずれの場合も、すべてのノードでこの状態を達成するには時間がかかり、大量のトラフィックが発生する可能性があり、正しく実装するのが困難です [Iwanicki16] [Paszkowska19] [Ciolkosz19]。 +

+
+
+
+
+

+To start with, tearing down all DODAG paths requires each of the dead LBR's neighbors to detect that its link with the LBR is no longer up. Otherwise, any of the neighbors unaware of this fact can keep advertising a finite Rank and can thus be other nodes' parent or ancestor in the DODAG; such nodes will incorrectly believe they have a valid path to the dead LBR. Detecting a crash of a link by a node normally happens when the node has observed a sufficient number of forwarding failures over the link. Therefore, considering the low-data-rate applications of LLNs, the period from the crash to the moment of eliminating the last link to the dead LBR from the DODAG may be long. Subsequently, learning by all nodes that none of their links can form any path leading to the dead LBR also adds latency, partly due to parent changes that the nodes independently perform in attempts to repair their broken paths locally. Since a non-LBR node has only local knowledge of the network, potentially inconsistent with that of other nodes, such parent changes often produce paths containing loops, which have to be broken before all nodes can conclude that no path to the dead LBR exists globally. Even with RPL's dedicated loop detection mechanisms [RFC6553], this also requires traffic and hence time. Finally, switching a parent or discovering a loop can also generate cascaded bursts of control traffic, owing to the adaptive Trickle algorithm for exchanging DODAG information [RFC6206]. Overall, the behavior of the network when handling an LBR crash is highly suboptimal, thereby not being in line with RPL's goals of minimizing resource consumption and reaction latencies. +

+
+
+

+まず、すべての DODAG パスを切断するには、停止した LBR の各隣接ノードが、その LBR とのリンクがもうアップしていないことを検出する必要があります。そうしないと、この事実に気づかない近隣ノードが有限のランクをアドバタイズし続ける可能性があり、DODAG 内の他のノードの親または祖先になる可能性があります。このようなノードは、デッド LBR への有効なパスがあると誤って信じてしまいます。ノードによるリンクのクラッシュの検出は、通常、ノードがリンク上で十分な数の転送障害を観察した場合に発生します。したがって、LLN の低データ レートのアプリケーションを考慮すると、クラッシュから、DODAG からデッド LBR への最後のリンクが削除されるまでの期間が長くなる可能性があります。その後、すべてのノードが、どのリンクもデッド LBR につながるパスを形成できないことを学習すると、遅延が増加します。これは、ノードが壊れたパスをローカルで修復しようとして独自に実行する親の変更が部分的に原因です。非 LBR ノードはネットワークについてローカルな情報しか持たず、他のノードの情報と矛盾する可能性があるため、このような親の変更によりループを含むパスが生成されることが多く、すべてのノードが無効な LBR へのパスがグローバルに存在しないと結論付ける前にループを解除する必要があります。RPL の専用ループ検出メカニズム [RFC6553] を使用しても、これにはトラフィックが必要となり、時間がかかります。最後に、DODAG 情報を交換するための適応トリクル アルゴリズム [RFC6206] により、親を切り替えるかループを発見すると、制御トラフィックのカスケード バーストが生成される可能性があります。全体として、LBR クラッシュを処理するときのネットワークの動作は非常に最適ではないため、リソース消費と反応遅延を最小限に抑えるという RPL の目標とは一致しません。 +

+
+
+
+
+
+1.2. Design Principles +
+
+
+
+1.2. 設計原則 +
+
+
+
+
+

+To address this issue, this document proposes an extension to RPL, dubbed the "Root Node Failure Detector (RNFD)". To minimize the time and traffic required to handle an LBR crash, the RNFD algorithm adopts the following design principles, derived directly from the previous observations: +

+
+
+

+この問題に対処するために、この文書では「Root Node Failure Detector (RNFD)」と呼ばれる RPL の拡張機能を提案します。LBR クラッシュの処理に必要な時間とトラフィックを最小限に抑えるために、RNFD アルゴリズムは、以前の観察から直接導き出された次の設計原則を採用しています。 +

+
+
+
+
+

+1. Explicitly coordinating LBR monitoring between nodes instead of relying only on the emergent behavior resulting from their independent operation. +

+
+
+

+1. ノードの独立した動作から生じる緊急の動作のみに依存するのではなく、ノード間の LBR 監視を明示的に調整します。 +

+
+
+
+
+

+2. Avoiding probing all links to the dead LBR so as to reduce the tail latency when eliminating these links from the DODAG. +

+
+
+

+2. DODAG からこれらのリンクを削除するときに、デッド LBR へのすべてのリンクをプローブすることを回避し、テール レイテンシを短縮します。 +

+
+
+
+
+

+3. Exploiting concurrency by prompting proactive checking for a possible LBR crash when some nodes suspect such a failure may have taken place, which aims to further reduce the overall latency. +

+
+
+

+3. 一部のノードで LBR クラッシュの可能性が疑われる場合に、そのような障害が発生した可能性があることを事前にチェックすることで同時実行性を利用し、全体的なレイテンシーをさらに短縮することを目的としています。 +

+
+
+
+
+

+4. Minimizing changes to RPL's existing algorithms by operating in parallel and largely independently (in the background) and by introducing few additional assumptions. +

+
+
+

+4. 並行してほぼ独立して (バックグラウンドで) 動作し、追加の仮定をいくつか導入することにより、RPL の既存のアルゴリズムへの変更を最小限に抑えます。 +

+
+
+
+
+

+While these principles do improve RPL's performance under a wide range of LBR crashes, their probabilistic nature precludes hard guarantees for all possible corner cases. In particular, in some scenarios, RNFD's operation may result in false negatives, but these situations are peculiar and will eventually be handled by RPL's own aforementioned mechanisms. Likewise, in some scenarios, notably involving highly unstable links, false positives may occur, but they can be alleviated as well. In any case, the principles also guarantee that RNFD can be deactivated at any time if needed, in which case RPL's operation is unaffected. +

+
+
+

+これらの原則は、広範囲の LBR クラッシュの下で RPL のパフォーマンスを向上させますが、その確率的な性質により、考えられるすべての例外的なケースに対する確実な保証は不可能です。特に、一部のシナリオでは、RNFD の操作により偽陰性が発生する可能性がありますが、これらの状況は特殊であり、最終的には RPL 独自の前述のメカニズムによって処理されます。同様に、一部のシナリオでは、特に非常に不安定なリンクが関係する場合、誤検知が発生する可能性がありますが、同様に軽減することができます。いずれの場合でも、この原則は、必要に応じていつでも RNFD を非アクティブ化できることも保証しており、その場合でも RPL の動作は影響を受けません。 +

+
+
+
+
+
+1.3. Other Solutions +
+
+
+
+1.3. その他のソリューション +
+
+
+
+
+

+Given the consequences of LBR failures, it is also worth considering other solutions to the problem. More specifically, power outages can be alleviated by provisioning redundant power sources or emergency batteries. Likewise, RPL's so-called virtual DODAG roots can help tolerate some failures of individual LBRs. +

+
+
+

+LBR 障害の影響を考慮すると、この問題に対する他の解決策を検討する価値もあります。具体的には、冗長電源や非常用バッテリーを設置することで停電を軽減できます。同様に、RPL のいわゆる仮想 DODAG ルートは、個々の LBR の一部の障害を許容するのに役立ちます。 +

+
+
+
+
+

+As mentioned previously, RNFD has been designed to be largely independent of those solutions; that is, rather than aiming to be their replacement, RNFD can complement them. In particular, the operation of RNFD with different variants of virtual DODAG roots is covered in Section 6.2. +

+
+
+

+前述したように、RNFD はこれらのソリューションからほとんど独立するように設計されています。つまり、RNFD はそれらの代替となることを目指すのではなく、それらを補完することができます。特に、仮想 DODAG ルートのさまざまなバリアントを使用した RNFD の操作については、セクション 6.2 で説明します。 +

+
+
+
+
+
+2. Terminology +
+
+
+
+2. 用語 +
+
+
+
+
+

+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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。 +

+
+
+
+
+

+The terminology used in this document is consistent with and incorporates that described in "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102], "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550], and "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams" [RFC6553]. Other terms used in LLNs can be found in "Terminology for Constrained-Node Networks" [RFC7228]. +

+
+
+

+この文書で使用される用語は、「低電力および損失の多いネットワークのルーティングで使用される用語」[RFC7102]、「RPL: 低電力および損失の多いネットワークのための IPv6 ルーティング プロトコル」[RFC6550]、および「データプレーン データグラムで RPL 情報を搬送するための低電力および損失の多いネットワーク用のルーティング プロトコル (RPL) オプション」と一致しており、それらを組み込んでいます。
[RFC6553]。LLN で使用されるその他の用語は、「Terminology for Constrained-Node Networks」[RFC7228] に記載されています。 +

+
+
+
+
+

+In particular, the following acronyms appear in the document: +

+
+
+

+特に、この文書には次の頭字語が使用されます。 +

+
+
+
+
+

+DIO: +

+
+
+

+DIO: +

+
+
+
+
+

+DODAG Information Object (a RPL message) +

+
+
+

+DODAG 情報オブジェクト (RPL メッセージ) +

+
+
+
+
+

+DIS: +

+
+
+

+DIS: +

+
+
+
+
+

+DODAG Information Solicitation (a RPL message) +

+
+
+

+DODAG 情報要請 (RPL メッセージ) +

+
+
+
+
+

+DODAG: +

+
+
+

+ドーダグ: +

+
+
+
+
+

+Destination-Oriented Directed Acyclic Graph +

+
+
+

+宛先指向の有向非巡回グラフ +

+
+
+
+
+

+LLN: +

+
+
+

+LLN: +

+
+
+
+
+

+Low-Power and Lossy Network +

+
+
+

+低電力で損失の多いネットワーク +

+
+
+
+
+

+LBR: +

+
+
+

+LBR: +

+
+
+
+
+

+LLN Border Router +

+
+
+

+LLN ボーダールーター +

+
+
+
+
+

+In addition, the document introduces the following concepts: +

+
+
+

+さらに、このドキュメントでは次の概念が紹介されています。 +

+
+
+
+
+

+Sentinel: +

+
+
+

+センチネル: +

+
+
+
+
+

+One of the two roles that a node can play in RNFD. For a given DODAG Version, a Sentinel node is a DODAG root's neighbor that monitors the DODAG root's status. There are normally multiple Sentinels for a DODAG root. However, being the DODAG root's neighbor need not imply being a Sentinel. +

+
+
+

+RNFD でノードが果たせる 2 つの役割の 1 つ。特定の DODAG バージョンの場合、Sentinel ノードは DODAG ルートのステータスを監視する DODAG ルートの近隣ノードです。通常、DODAG ルートには複数の Sentinel が存在します。ただし、DODAG ルートのネイバーであることは、センチネルであることを意味する必要はありません。 +

+
+
+
+
+

+Acceptor: +

+
+
+

+アクセプター: +

+
+
+
+
+

+The other of the two roles that a node can play in RNFD. For a given DODAG Version, an Acceptor node is a node that is not a Sentinel. +

+
+
+

+RNFD でノードが果たせる 2 つの役割のうちのもう 1 つ。特定の DODAG バージョンの場合、アクセプター ノードはセンチネルではないノードです。 +

+
+
+
+
+

+Locally Observed DODAG Root's State (LORS): +

+
+
+

+ローカルで観測された DODAG ルート状態 (LORS): +

+
+
+
+
+

+A node's local knowledge of the DODAG root's status, specifying in particular whether the DODAG root is up. +

+
+
+

+DODAG ルートのステータスに関するノードのローカル情報。特に、DODAG ルートが稼働しているかどうかを指定します。 +

+
+
+
+
+

+Conflict-Free Replicated Counter (CFRC): +

+
+
+

+競合のない複製カウンター (CFRC): +

+
+
+
+
+

+Conceptually represents a dynamic set whose cardinality can be estimated. It defines a partial order on its values and supports element addition and union. The union operation is order- and duplicate-insensitive, that is, idempotent, commutative, and associative. +

+
+
+

+カーディナリティを推定できる動的セットを概念的に表します。値の半順序を定義し、要素の追加と結合をサポートします。結合演算は順序や重複に影響されません。つまり、冪等、可換、結合です。 +

+
+
+
+
+
+3. Overview +
+
+
+
+3. 概要 +
+
+
+
+
+

+As mentioned previously, LBRs are DODAG roots in RPL; hence, a crash of an LBR is global in that it affects all nodes in the corresponding DODAG. Therefore, each node running RNFD for a given DODAG explicitly tracks the DODAG root's current condition, which is referred to as Locally Observed DODAG Root's State (LORS), and synchronizes its local knowledge with other nodes. +

+
+
+

+前述したように、LBR は RPL の DODAG ルートです。したがって、LBR のクラッシュは、対応する DODAG 内のすべてのノードに影響するという点でグローバルです。したがって、特定の DODAG に対して RNFD を実行している各ノードは、ローカルで観察された DODAG ルートの状態 (LORS) と呼ばれる DODAG ルートの現在の状態を明示的に追跡し、そのローカルな情報を他のノードと同期します。 +

+
+
+
+
+

+Since monitoring the condition of the DODAG root is performed by tracking the status of its links (i.e., whether they are up or down), it can only be done by the root's neighbors; other nodes must accept their observations. Consequently, depending on their roles, non-root nodes are divided in RNFD into two disjoint groups: Sentinels and Acceptors. A Sentinel node is a DODAG root's neighbor that monitors its link with the root. Thus, the DODAG root normally has multiple Sentinels, but being its neighbor need not imply being a Sentinel. An Acceptor node is a node that is not a Sentinel. Acceptors thus mainly collect and propagate Sentinels' observations. More information on Sentinel selection can be found in Section 6.1. +

+
+
+

+DODAG ルートの状態の監視は、そのリンクのステータス (つまり、アップかダウンか) を追跡することによって実行されるため、ルートの近隣者によってのみ実行できます。他のノードはその観察を受け入れる必要があります。その結果、RNFD では、その役割に応じて、ルート以外のノードが 2 つの独立したグループ (センチネルとアクセプター) に分割されます。Sentinel ノードは、ルートとのリンクを監視する DODAG ルートの近隣ノードです。したがって、DODAG ルートには通常複数の Sentinel がありますが、その近隣であることは Sentinel であることを意味する必要はありません。アクセプター ノードはセンチネルではないノードです。したがって、アクセプターは主にセンチネルの観察を収集し、広めます。Sentinel の選択の詳細については、セクション 6.1 を参照してください。 +

+
+
+
+
+
+3.1. Protocol State Machine +
+
+
+
+3.1. プロトコルステートマシン +
+
+
+
+
+

+The possible values of LORS and transitions between them are depicted in Figure 1. States "UP" and "GLOBALLY DOWN" can be attained by both Sentinels and Acceptors; states "SUSPECTED DOWN" and "LOCALLY DOWN" can be attained by Sentinels only. +

+
+
+

+LORS の可能な値とそれらの間の遷移を図 1 に示します。状態「UP」と「GLOBALLY DOWN」はセンチネルとアクセプターの両方で達成できます。「SUSPECTED DOWN」と「LOCALLY DOWN」はセンチネルのみが達成できると述べています。 +

+
+
+
+
+ 
+     +---------------------------------------------------------+
+     |                      |---------------------------+   3a |
+     |    +-----------------+---------+              3b |      |
+     |    | 2b              |         v                 v      v
+   +-+----+-+   1 +---------+-+     +-----------+     +-+------+-+
+   |   UP   +---->+ SUSPECTED +---->+  LOCALLY  +---->+ GLOBALLY |
+   |        +<----+    DOWN   | 2a  |    DOWN   | 3c  |   DOWN   |
+   +-+----+-+  4a +-----------+     +-+---------+     +-+--------+
+     ^    ^                           |                 |
+     |    |                        4b |                 |
+     |    +---------------------------+               5 |
+     +--------------------------------------------------+
+
+
+
+
+
+

+Figure 1: RNFD States and Transitions +

+
+
+

+図 1: RNFD の状態と遷移 +

+
+
+
+
+

+To begin with, when any node joins a DODAG Version, the DODAG root must appear alive, so the node initializes RNFD with its LORS equal to "UP". For a properly working DODAG root, the node remains in state "UP". +

+
+
+

+まず、いずれかのノードが DODAG バージョンに参加すると、DODAG ルートが生きているように見える必要があるため、ノードは LORS を「UP」に設定して RNFD を初期化します。DODAG ルートが適切に動作している場合、ノードは「UP」状態のままです。 +

+
+
+
+
+

+However, when a node acting as a Sentinel starts suspecting that the root may have crashed, it changes its LORS to "SUSPECTED DOWN" (transition 1 in Figure 1). The transition from "UP" to "SUSPECTED DOWN" can happen based on the node's observations at either the data plane (e.g., link-layer triggers about missing hop-by-hop acknowledgments for packets forwarded over the node's link to the root) or at the control plane (e.g., a significant growth in the number of Sentinels already suspecting the root to be dead). In state "SUSPECTED DOWN", the Sentinel node may verify its suspicion and/or inform other nodes about the suspicion. When this has been done, it changes its LORS to "LOCALLY DOWN" (transition 2a). In some cases, the verification need not be performed, and as an optimization, a direct transition from "UP" to "LOCALLY DOWN" (transition 2b) can be done instead. +

+
+
+

+ただし、Sentinel として機能するノードがルートがクラッシュした可能性があると疑い始めると、LORS を「SUSPECTED DOWN」に変更します (図 1 の遷移 1)。「UP」から「SUSPECTED DOWN」への遷移は、データ プレーン (例: ノードのリンクを介してルートに転送されたパケットのホップバイホップ確認応答の欠落に関するリンク層トリガー) またはコントロール プレーン (例: ルートが停止していると既に疑っているセンチネルの数の大幅な増加) でのノードの観察に基づいて発生する可能性があります。「SUSPECTED DOWN」状態では、Sentinel ノードはその疑いを検証し、および/またはその疑いについて他のノードに通知することができます。これが完了すると、LORS が「LOCALLY DOWN」に変更されます (遷移 2a)。場合によっては、検証を実行する必要がなく、最適化として、代わりに「UP」から「LOCALLY DOWN」への直接遷移 (遷移 2b) を実行できます。 +

+
+
+
+
+

+If a sufficient number of Sentinels have their LORS equal to "LOCALLY DOWN", all nodes (Sentinels and Acceptors) consent globally that the DODAG root must have crashed and set their LORS to "GLOBALLY DOWN", irrespective of the previous value (transitions 3a, 3b, and 3c). State "GLOBALLY DOWN" is terminal in that the only transition any node can perform from this to another state (transition 5) takes place when the node joins a new DODAG Version. When a node is in state "GLOBALLY DOWN", RNFD forces RPL to maintain an infinite Rank and no parent, thereby preventing routing packets upward in the DODAG. In other words, this state represents a situation in which all non-root nodes agree that the current DODAG Version is unusable; hence, to recover, the root has to give a proof of being alive by initiating a new DODAG Version. +

+
+
+

+十分な数の Sentinel の LORS が「LOCALLY DOWN」に等しい場合、すべてのノード (Sentinel と Acceptor) は、DODAG ルートがクラッシュし、以前の値に関係なく LORS を「GLOBALLY DOWN」に設定する必要があることにグローバルに同意します (遷移 3a、3b、および 3c)。「GLOBALLY DOWN」状態は、ノードが新しい DODAG バージョンに参加するときに、ノードが実行できる唯一の状態から別の状態への遷移 (遷移 5) が発生するという点で終端です。ノードが「GLOBALLY DOWN」状態にある場合、RNFD は RPL に無限ランクを維持させ、親を持たないよう強制するため、パケットが DODAG 内で上向きにルーティングされるのを防ぎます。言い換えれば、この状態は、ルート以外のすべてのノードが現在の DODAG バージョンが使用できないことに同意している状況を表します。したがって、回復するには、ルートが新しい DODAG バージョンを開始して生存の証明を提供する必要があります。 +

+
+
+
+
+

+In contrast, if a node (either a Sentinel or Acceptor) is in state "UP", RNFD does not influence RPL's packet forwarding; a node can route packets upward if it has a parent. The same is true for states "SUSPECTED DOWN" and "LOCALLY DOWN", attainable only by Sentinels. Finally, while in any of the two states, a Sentinel node may observe some activity of the DODAG root and hence decide that its suspicion is a mistake. In such a case, it returns to state "UP" (transitions 4a and 4b). +

+
+
+

+対照的に、ノード (センチネルまたはアクセプター) が状態「UP」にある場合、RNFD は RPL のパケット転送に影響を与えません。ノードに親がある場合、ノードはパケットを上向きにルーティングできます。「SUSPECTED DOWN」および「LOCALLY DOWN」状態についても同様であり、センチネルのみが到達できます。最後に、2 つの状態のいずれかにあるときに、Sentinel ノードが DODAG ルートのアクティビティを観察し、その疑いが間違いであると判断する可能性があります。このような場合には、状態「ＵＰ」に戻る（遷移４ａおよび４ｂ）。 +

+
+
+
+
+
+3.2. Counters and Communication +
+
+
+
+3.2. カウンターとコミュニケーション +
+
+
+
+
+

+To enable arriving at a global conclusion that the DODAG root has crashed (i.e., transiting to state "GLOBALLY DOWN"), all nodes count locally and synchronize among each other the number of Sentinels considering the root to be dead (i.e., those in state "LOCALLY DOWN"). This process employs structures referred to as Conflict-Free Replicated Counters (CFRCs). They are stored and modified independently by each node and are disseminated throughout the network in options added to RPL link-local control messages: DODAG Information Objects (DIOs) and DODAG Information Solicitations (DISs). Upon reception of such an option from its neighbor, a node merges the received counter with its local one, thereby obtaining a new content for its local counter. +

+
+
+

+DODAG ルートがクラッシュした (つまり、「GLOBALLY DOWN」状態に移行した) というグローバルな結論に達することを可能にするために、すべてのノードがローカルでカウントし、ルートが停止しているとみなされるセンチネル (つまり、「LOCALLY DOWN」状態にあるセンチネル) の数を相互に同期します。このプロセスでは、Conflict-Free Replicated Counters (CFRC) と呼ばれる構造が使用されます。これらは、各ノードによって個別に保存および変更され、RPL リンクローカル制御メッセージに追加されるオプションである DODAG Information Object (DIO) および DODAG Information Solicitations (DIS) でネットワーク全体に配布されます。近隣ノードからそのようなオプションを受信すると、ノードは受信したカウンタをローカルのカウンタとマージし、それによってローカル カウンタの新しい内容を取得します。 +

+
+
+
+
+

+The merging operation is idempotent, commutative, and associative. Moreover, all possible counter values are partially ordered. This enables ensuring eventual consistency of the counters across all nodes, irrespective of the particular sequence of merges, shape of the DODAG, or general network topology. In effect, as long as the network is connected, all nodes will be able to arrive at the same conclusion regarding the DODAG root, in particular when no two Sentinels have a direct link with each other. +

+
+
+

+マージ操作は冪等性、可換性、結合性があります。さらに、すべての可能なカウンタ値は部分的に順序付けされています。これにより、マージの特定のシーケンス、DODAG の形状、または一般的なネットワーク トポロジに関係なく、すべてのノードにわたるカウンターの最終的な一貫性を確保できます。実際、ネットワークが接続されている限り、特に 2 つの Sentinel が互いに直接リンクしていない場合、すべてのノードは DODAG ルートに関して同じ結論に達することができます。 +

+
+
+
+
+

+Each node in RNFD maintains two CFRCs for a DODAG: +

+
+
+

+RNFD の各ノードは、DODAG に対して 2 つの CFRC を維持します。 +

+
+
+
+
+

+PositiveCFRC: +

+
+
+

+ポジティブCFRC: +

+
+
+
+
+

+Counts Sentinels that consider or have previously considered the root node as alive in the current DODAG Version. +

+
+
+

+現在の DODAG バージョンでルート ノードが生きているとみなしている、または以前にみなしていたセンチネルをカウントします。 +

+
+
+
+
+

+NegativeCFRC: +

+
+
+

+ネガティブCFRC: +

+
+
+
+
+

+Counts Sentinels that consider or have previously considered the root node as dead in the current DODAG Version. +

+
+
+

+現在の DODAG バージョンでルート ノードが停止しているとみなしている、または以前にルート ノードが停止しているとみなしたセンチネルをカウントします。 +

+
+
+
+
+

+The PositiveCFRC is always greater than or equal to the NegativeCFRC in terms of the partial order defined for the counters. The difference between the value of the PositiveCFRC and the value of the NegativeCFRC is thus nonnegative and estimates the number of Sentinels that still consider the DODAG root node as alive. +

+
+
+

+PositiveCFRC は、カウンタに定義された半順序の点で常に NegativeCFRC 以上です。したがって、PositiveCFRC の値と NegativeCFRC の値の差は負ではなく、DODAG ルート ノードがまだ生きているとみなしているセンチネルの数を推定します。 +

+
+
+
+
+
+4. The RNFD Option +
+
+
+
+4. RNFD オプション +
+
+
+
+
+

+RNFD state synchronization between nodes takes place through the RNFD Option. It is a new type of RPL Control Message Option that is carried in link-local RPL control messages, notably DIOs and DISs. Its main task is allowing the receivers to merge their two CFRCs with the sender's CFRCs. +

+
+
+

+ノード間の RNFD 状態の同期は、RNFD オプションを通じて行われます。これは、リンクローカル RPL 制御メッセージ、特に DIO および DIS で伝送される新しいタイプの RPL 制御メッセージ オプションです。その主なタスクは、受信者が 2 つの CFRC を送信者の CFRC とマージできるようにすることです。 +

+
+
+
+
+
+4.1. General CFRC Requirements +
+
+
+
+4.1. CFRC の一般要件 +
+
+
+
+
+

+CFRCs in RNFD MUST support the following operations: +

+
+
+

+RNFD の CFRC は、次の操作をサポートしなければなりません。 +

+
+
+
+
+

+value(c) +

+
+
+

+値(c) +

+
+
+
+
+

+Returns a nonnegative integer value corresponding to the number of nodes counted by a given CFRC, c. +

+
+
+

+指定された CFRC によってカウントされたノードの数に対応する非負の整数値を返します。 c. +

+
+
+
+
+

+zero() +

+
+
+

+ゼロ（） +

+
+
+
+
+

+Returns a CFRC that counts no nodes, that is, has its value equal to 0. +

+
+
+

+ノードをカウントしない、つまり値が 0 に等しい CFRC を返します。 +

+
+
+
+
+

+self() +

+
+
+

+自己（） +

+
+
+
+
+

+Returns a CFRC that counts only the node executing the operation. +

+
+
+

+操作を実行しているノードのみをカウントする CFRC を返します。 +

+
+
+
+
+

+infinity() +

+
+
+

+無限大() +

+
+
+
+
+

+Returns a CFRC that counts all possible nodes and represents a special value, infinity. +

+
+
+

+考えられるすべてのノードをカウントし、特別な値である無限大を表す CFRC を返します。 +

+
+
+
+
+

+merge(c1, c2) +

+
+
+

+マージ(c1, c2) +

+
+
+
+
+

+Returns a CFRC that is a union of c1 and c2 (i.e., counts all nodes that are counted by either c1, c2, or both c1 and c2). +

+
+
+

+c1 と c2 の和集合である CFRC を返します (つまり、c1、c2、または c1 と c2 の両方によってカウントされるすべてのノードをカウントします)。 +

+
+
+
+
+

+compare(c1, c2) +

+
+
+

+比較(c1, c2) +

+
+
+
+
+

+Returns the result of comparing c1 to c2. +

+
+
+

+c1 と c2 を比較した結果を返します。 +

+
+
+
+
+

+saturated(c) +

+
+
+

+飽和(c) +

+
+
+
+
+

+Returns TRUE if a given CFRC, c, is saturated (i.e., no more new nodes should be counted by it); returns FALSE otherwise. +

+
+
+

+指定された CFRC c が飽和している (つまり、これ以上新しいノードをカウントする必要がない) 場合は TRUE を返します。それ以外の場合は FALSE を返します。 +

+
+
+
+
+

+The partial ordering of CFRCs implies that the result of compare(c1, c2) can be either: +

+
+
+

+CFRC の部分的な順序付けは、compare(c1, c2) の結果が次のいずれかになることを意味します。 +

+
+
+
+
+

+* smaller, if c1 is ordered before c2 (i.e., c2 counts all nodes that c1 counts and at least one node that c1 does not count); +

+
+
+

+* c1 が c2 より前に順序付けされている場合 (つまり、c2 は、c1 がカウントするすべてのノードと、c1 がカウントしない少なくとも 1 つのノードをカウントします) の場合は小さくなります。 +

+
+
+
+
+

+* greater, if c1 is ordered after c2 (i.e., c1 counts all nodes that c2 counts and at least one node that c2 does not count); +

+
+
+

+* c1 が c2 の後に順序付けされている場合は大きくなります (つまり、c1 は、c2 がカウントするすべてのノードと、c2 がカウントしない少なくとも 1 つのノードをカウントします)。 +

+
+
+
+
+

+* equal, if c1 and c2 are the same (i.e., they count the same nodes); or +

+
+
+

+* c1 と c2 が同じ (つまり、同じノードを数える) 場合は等しい。または +

+
+
+
+
+

+* incomparable, otherwise. +

+
+
+

+* そうでなければ、比類のないもの。 +

+
+
+
+
+

+In particular, zero() is smaller than all other values, and infinity() is greater than any other value. +

+
+
+

+特に、zero() は他のすべての値より小さく、infinity() は他のどの値よりも大きくなります。 +

+
+
+
+
+

+The properties of merging can be formalized as follows for any c1, c2, and c3: +

+
+
+

+マージのプロパティは、c1、c2、および c3 について次のように形式化できます。 +

+
+
+
+
+

+* idempotence: c1 = merge(c1, c1); +

+
+
+

+* べき等: c1 = merge(c1, c1); +

+
+
+
+
+

+* commutativity: merge(c1, c2) = merge(c2, c1); and +

+
+
+

+* 可換性: マージ(c1, c2) = マージ(c2, c1);そして +

+
+
+
+
+

+* associativity: merge(c1, merge(c2, c3)) = merge(merge(c1, c2), c3). +

+
+
+

+* 結合性: マージ(c1, マージ(c2, c3)) = マージ(マージ(c1, c2), c3)。 +

+
+
+
+
+

+In particular, merge(c, zero()) always equals c, while merge(c, infinity()) always equals infinity(). +

+
+
+

+特に、merge(c, zero()) は常に c と等しくなりますが、merge(c, infinity()) は常に infinity() と等しくなります。 +

+
+
+
+
+

+There are many algorithmic structures that can provide the aforementioned properties of CFRC. Although in principle RNFD does not rely on any specific one, the option adopts so-called linear counting [Whang90]. +

+
+
+

+前述の CFRC の特性を提供できるアルゴリズム構造は数多くあります。原則として RNFD は特定のものに依存しませんが、このオプションはいわゆる線形カウンティングを採用しています [Whang90]。 +

+
+
+
+
+
+4.2. Format of the Option +
+
+
+
+4.2. オプションの形式 +
+
+
+
+
+

+The format of the RNFD Option conforms to the generic format of RPL Control Message Options (see Section 6.7.1 of [RFC6550]): +

+
+
+

+RNFD オプションの形式は、RPL 制御メッセージ オプションの一般的な形式に準拠しています ([RFC6550] のセクション 6.7.1 を参照)。 +

+
+
+
+
+ 
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |  Type = 0x0E  | Option Length |                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+     |                                                               |
+     +                                                               +
+     |               PosCFRC, NegCFRC (Variable Length*)             |
+     .                                                               .
+     .                                                               .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+

+Figure 2: Format of the RNFD Option +

+
+
+

+図 2: RNFD オプションのフォーマット +

+
+
+
+
+

+The "*" denotes that, if present, the fields have equal lengths. +

+
+
+

+「*」は、存在する場合、フィールドの長さが等しいことを示します。 +

+
+
+
+
+

+Option Type: +

+
+
+

+オプションの種類: +

+
+
+
+
+

+0x0E +

+
+
+

+0x0E +

+
+
+
+
+

+Option Length: +

+
+
+

+オプションの長さ: +

+
+
+
+
+

+8-bit unsigned integer. Denotes the length of the option in octets, excluding the Option Type and Option Length fields. Its value MUST be even. A value of 0 denotes that RNFD is disabled in the current DODAG Version. +

+
+
+

+8 ビットの符号なし整数。「オプション タイプ」フィールドと「オプション長」フィールドを除く、オプションの長さをオクテット単位で示します。その値は偶数でなければなりません。値 0 は、RNFD が現在の DODAG バージョンで無効になっていることを示します。 +

+
+
+
+
+

+PosCFRC, NegCFRC: +

+
+
+

+PosCFRC、NegCFRC: +

+
+
+
+
+

+Two variable-length, octet-aligned bit arrays carrying the sender's PositiveCFRC and NegativeCFRC, respectively. +

+
+
+

+送信者の PositiveCFRC と NegativeCFRC をそれぞれ伝送する 2 つの可変長の、オクテットに位置合わせされたビット配列。 +

+
+
+
+
+

+The length of the arrays constituting the PosCFRC and NegCFRC fields is the same and is derived from Option Length as follows. The value of Option Length is divided by 2 to obtain the number of octets each of the two arrays occupies. The resulting number of octets is multiplied by 8, which yields an upper bound on the number of bits in each array. As the actual bit length of each of the arrays, the largest prime number less than the upper bound is assumed. For example, if the value of Option Length is 16, then each array occupies 8 octets, and its actual bit length is 61, as this is the largest prime number less than 64. +

+
+
+

+PosCFRC フィールドと NegCFRC フィールドを構成する配列の長さは同じであり、次のように Option Length から導出されます。Option Length の値を 2 で割ると、2 つの配列がそれぞれ占有するオクテット数が得られます。結果のオクテット数は 8 倍され、各配列のビット数の上限が決まります。各配列の実際のビット長としては、上限値以下の最大の素数を仮定する。たとえば、オプションの長さの値が 16 の場合、各配列は 8 オクテットを占有し、実際のビット長は 61 になります。これは、64 未満の最大の素数であるためです。 +

+
+
+
+
+

+Furthermore, for any bit equal to 1 in the NegCFRC, the bit with the same index MUST also be equal to 1 in the PosCFRC. Any unused bits (i.e., the bits beyond the actual bit length of each of the arrays) MUST be equal to 0. Finally, if PosCFRC has all its bits equal to 1, then NegCFRC MUST also have all its bits equal to 1. +

+
+
+

+さらに、NegCFRC で 1 に等しいビットについては、同じインデックスを持つビットも PosCFRC で 1 に等しくなければなりません (MUST)。未使用のビット (つまり、各配列の実際のビット長を超えるビット) は 0 に等しくなければなりません (MUST)。 最後に、PosCFRC のすべてのビットが 1 に等しい場合、NegCFRC もすべてのビットが 1 に等しくなければなりません (MUST)。 +

+
+
+
+
+

+The CFRC operations are defined for such bit arrays of a given length as follows: +

+
+
+

+CFRC 演算は、指定された長さのビット配列に対して次のように定義されます。 +

+
+
+
+
+

+value(c) +

+
+
+

+値(c) +

+
+
+
+
+

+Returns the smallest integer value not less than -LT*ln(L0/LT), where ln() is the natural logarithm function, L0 is the number of bits equal to 0 in the array corresponding to c, and LT is the bit length of the array. +

+
+
+

+-LT*ln(L0/LT) 以上の最小の整数値を返します。ここで、ln() は自然対数関数、L0 は c に対応する配列内の 0 に等しいビット数、LT は配列のビット長です。 +

+
+
+
+
+

+zero() +

+
+
+

+ゼロ（） +

+
+
+
+
+

+Returns an array with all bits equal to 0. +

+
+
+

+すべてのビットが 0 に等しい配列を返します。 +

+
+
+
+
+

+self() +

+
+
+

+自己（） +

+
+
+
+
+

+Returns an array with a single bit, selected uniformly at random, equal to 1. +

+
+
+

+均一にランダムに選択された 1 に等しい単一ビットの配列を返します。 +

+
+
+
+
+

+infinity() +

+
+
+

+無限大() +

+
+
+
+
+

+Returns an array with all bits equal to 1. +

+
+
+

+すべてのビットが 1 に等しい配列を返します。 +

+
+
+
+
+

+merge(c1, c2) +

+
+
+

+マージ(c1, c2) +

+
+
+
+
+

+Returns a bit array that constitutes a bitwise OR of c1 and c2. That is, a bit in the resulting array is equal to 0 only if the same bit is equal to 0 in both c1 and c2. +

+
+
+

+c1 と c2 のビット単位の OR を構成するビット配列を返します。つまり、結果の配列内のビットが 0 になるのは、c1 と c2 の両方で同じビットが 0 に等しい場合のみです。 +

+
+
+
+
+

+compare(c1, c2) +

+
+
+

+比較(c1, c2) +

+
+
+
+
+

+Returns: +

+
+
+

+戻り値: +

+
+
+
+
+

+* equal, if each bit of c1 is equal to the corresponding bit of c2; +

+
+
+

+* c1 の各ビットが c2 の対応するビットと等しい場合は等しい。 +

+
+
+
+
+

+* less, if c1 and c2 are not equal, and for each bit equal to 1 in c1, the corresponding bit in c2 is also equal to 1; +

+
+
+

+* 以下、c1 と c2 が等しくなく、c1 の各ビットが 1 に等しい場合、c2 の対応するビットも 1 に等しくなります。 +

+
+
+
+
+

+* greater, if c1 and c2 are not equal, and for each bit equal to 1 in c2, the corresponding bit in c1 is also equal to 1; or +

+
+
+

+* より大きい場合、c1 と c2 が等しくなく、c2 の各ビットが 1 に等しい場合、c1 の対応するビットも 1 に等しくなります。または +

+
+
+
+
+

+* incomparable, otherwise. +

+
+
+

+* そうでなければ、比類のないもの。 +

+
+
+
+
+

+saturated(c) +

+
+
+

+飽和(c) +

+
+
+
+
+

+Returns TRUE if more than RNFD_CFRC_SATURATION_THRESHOLD of the bits in c are equal to 1; returns FALSE otherwise. +

+
+
+

+c のビットのうち RNFD_CFRC_SATURATION_THRESHOLD を超えるビットが 1 に等しい場合は TRUE を返します。それ以外の場合は FALSE を返します。 +

+
+
+
+
+
+5. RPL Router Behavior +
+
+
+
+5. RPL ルーターの動作 +
+
+
+
+
+

+Although RNFD operates largely independently of RPL, it does need to interact with RPL and the overall protocol stack. These interactions are described next and can be realized, for instance, by means of event triggers. +

+
+
+

+RNFD は主に RPL とは独立して動作しますが、RPL およびプロトコル スタック全体と対話する必要があります。これらの対話については次に説明しますが、たとえばイベント トリガーによって実現できます。 +

+
+
+
+
+
+5.1. Joining a DODAG Version and Changing the RNFD Role +
+
+
+
+5.1. DODAG バージョンへの参加と RNFD ロールの変更 +
+
+
+
+
+

+Whenever RPL is running at a node and joins a DODAG Version, RNFD (if active) MUST assume the role of Acceptor for the node. Accordingly, it MUST set its LORS to "UP" and its PositiveCFRC and NegativeCFRC to zero(). +

+
+
+

+RPL がノードで実行され、DODAG バージョンに参加するときは常に、RNFD (アクティブな場合) がノードのアクセプターの役割を引き受けなければなりません (MUST)。したがって、LORS を「UP」に設定し、PositiveCFRC と NegativeCFRC を zero() に設定しなければなりません。 +

+
+
+
+
+

+The role may then change between Acceptor and Sentinel at any time. However, while a switch from Sentinel to Acceptor has no preconditions, in order for a switch from Acceptor to Sentinel to be possible, _all_ of the following conditions MUST hold: +

+
+
+

+その後、役割はいつでもアクセプターとセンチネルの間で変更される可能性があります。ただし、Sentinel から Acceptor への切り替えには前提条件がありませんが、Acceptor から Sentinel への切り替えを可能にするためには、次の条件のすべてが満たされなければなりません。 +

+
+
+
+
+

+1. LORS is "UP"; +

+
+
+

+1. LORS は「アップ」です。 +

+
+
+
+
+

+2. saturated(PositiveCFRC) is FALSE; +

+
+
+

+2. 飽和(PositiveCFRC) は FALSE です。 +

+
+
+
+
+

+3. a neighbor entry for the DODAG root is present in RPL's DODAG parent set; and +

+
+
+

+3. DODAG ルートの隣接エントリが RPL の DODAG 親セットに存在します。そして +

+
+
+
+
+

+4. the neighbor is considered reachable via its link-local IPv6 address. +

+
+
+

+4. 近隣ノードは、そのリンクローカル IPv6 アドレスを介して到達可能であるとみなされます。 +

+
+
+
+
+

+A role change also requires appropriate updates to LORS and CFRCs, so that the node is properly accounted for. More specifically, when changing its role from Acceptor to Sentinel, the node MUST add itself to its PositiveCFRC as follows. It MUST generate a new CFRC value, selfc = self(), and it MUST replace its PositiveCFRC, denoted oldpc, with newpc = merge(oldpc, selfc). In contrast, the effects of a switch from Sentinel to Acceptor vary depending on the node's value of LORS before the switch: +

+
+
+

+ロールの変更には、ノードが適切に考慮されるように、LORS と CFRC に対する適切な更新も必要です。より具体的には、その役割をアクセプターからセンチネルに変更するとき、ノードは次のように自身をその PositiveCFRC に追加しなければなりません (MUST)。新しい CFRC 値 selfc = self() を生成しなければならず、oldpc で示される PositiveCFRC を newpc = merge(oldpc, selfc) に置き換えなければなりません。対照的に、Sentinel から Acceptor への切り替えの効果は、切り替え前のノードの LORS の値に応じて異なります。 +

+
+
+
+
+

+* For "GLOBALLY DOWN", the node MUST NOT modify its LORS, PositiveCFRC, and NegativeCFRC. +

+
+
+

+* 「GLOBALLY DOWN」の場合、ノードは LORS、PositiveCFRC、および NegativeCFRC を変更してはなりません (MUST NOT)。 +

+
+
+
+
+

+* For "LOCALLY DOWN", the node MUST set its LORS to "UP" but MUST NOT modify its PositiveCFRC and NegativeCFRC. +

+
+
+

+* 「LOCALLY DOWN」の場合、ノードは LORS を「UP」に設定しなければなりませんが、PositiveCFRC と NegativeCFRC を変更してはなりません。 +

+
+
+
+
+

+* For "UP" and "SUSPECTED DOWN", the node MUST set its LORS to "UP" and MUST NOT modify its PositiveCFRC, but the node MUST add itself to NegativeCFRC, by replacing its NegativeCFRC, denoted oldnc, with newnc = merge(oldnc, selfc), where selfc is the counter generated with self() when the node last added itself to its PositiveCFRC. +

+
+
+

+* 「UP」および「SUSPECTED DOWN」の場合、ノードは LORS を「UP」に設定しなければならず、PositiveCFRC を変更してはなりません。ただし、ノードは、oldnc で示される NegativeCFRC を newnc = merge(oldnc, selfc) に置き換えることによって、自身を NegativeCFRC に追加しなければなりません。ここで、selfc は、ノードが最後に自身を PositiveCFRC に追加したときに self() で生成されたカウンターです。 +

+
+
+
+
+
+5.2. Detecting and Verifying Problems with the DODAG Root +
+
+
+
+5.2. DODAG ルートの問題の検出と検証 +
+
+
+
+
+

+Only nodes that are Sentinels take an active part in detecting crashes of the DODAG root; Acceptors just disseminate their observations, reflected in the CFRCs. +

+
+
+

+Sentinel であるノードのみが、DODAG ルートのクラッシュの検出に積極的に関与します。受け入れ者は、CFRC に反映された観察結果を広めるだけです。 +

+
+
+
+
+

+The DODAG root monitoring SHOULD be based on both internal inputs, notably the values of CFRCs and LORS, and external inputs, such as triggers from RPL and other protocols. External input monitoring SHOULD be performed preferably in a reactive fashion, also independently of RPL, and at both the data plane and control plane. In particular, it is RECOMMENDED that RNFD be directly notified of events relevant to the routing adjacency maintenance mechanisms on which RPL relies, such as Layer 2 (L2) triggers [RFC5184] or the Neighbor Unreachability Detection [RFC4861] mechanism. In addition, depending on the underlying protocol stack, there may be other potential sources of such events, for instance, neighbor communication overhearing. In any case, only events concerning the DODAG root need to be monitored. For example, RNFD can conclude that there may be problems with the DODAG root if it observes a lack of multiple consecutive L2 acknowledgments for packets transmitted by the node via the link to the DODAG root. Internally, in turn, it is RECOMMENDED that RNFD take action whenever there is a change to its local CFRCs, so that a node can have a chance to participate in detecting potential problems even when normally it would not exchange packets over the link with the DODAG root during some period. In particular, RNFD SHOULD conclude that there may be problems with the DODAG root when the fraction value(NegativeCFRC)/value(PositiveCFRC) has grown by at least RNFD_SUSPICION_GROWTH_THRESHOLD since the node last set its LORS to "UP". +

+
+
+

+DODAG ルート監視は、内部入力、特に CFRC と LORS の値と、RPL や他のプロトコルからのトリガーなどの外部入力の両方に基づくべきです(SHOULD)。外部入力モニタリングは、RPL とは独立して、データ プレーンとコントロール プレーンの両方で事後対応的に実行することが望ましいです (SHOULD)。特に、レイヤ 2 (L2) トリガー [RFC5184] や近隣到達不能検出 [RFC4861] メカニズムなど、RPL が依存するルーティング隣接関係維持メカニズムに関連するイベントを RNFD に直接通知することが推奨されます。さらに、基礎となるプロトコル スタックによっては、近隣通信の傍聴など、このようなイベントの潜在的な原因が他にも存在する可能性があります。いずれの場合も、DODAG ルートに関するイベントのみを監視する必要があります。たとえば、RNFD は、ノードによって DODAG ルートへのリンクを介して送信されたパケットに対する複数の連続した L2 確認応答の欠如を観察した場合、DODAG ルートに問題がある可能性があると結論付けることができます。内部的には、ローカル CFRC に変更があるたびに RNFD がアクションを起こすことが推奨されます。これにより、ノードは、通常は一定期間 DODAG ルートとのリンク上でパケットを交換しない場合でも、潜在的な問題の検出に参加する機会を得ることができます。特に、RNFD は、ノードが最後に LORS を「UP」に設定してから、端数の値 (NegativeCFRC)/値 (PositiveCFRC) が少なくとも RNFD_SUSPICION_GROWTH_THRESHOLD だけ増加した場合、DODAG ルートに問題がある可能性があると結論付ける必要があります (SHOULD)。 +

+
+
+
+
+

+Whenever, having its LORS set to "UP", RNFD concludes (based on either external or internal inputs) that there may be problems with the link with the DODAG root, it MUST set its LORS either to "SUSPECTED DOWN" or, as an optimization, to "LOCALLY DOWN". +

+
+
+

+LORS が「UP」に設定されている場合、RNFD は、DODAG ルートとのリンクに問題がある可能性があると (外部入力または内部入力に基づいて) 結論付けるたびに、LORS を「SUSPECTED DOWN」、または最適化として「LOCALLY DOWN」に設定しなければなりません。 +

+
+
+
+
+

+The "SUSPECTED DOWN" value of LORS is temporary: its aim is to give RNFD an additional opportunity to verify whether the link with the DODAG root is indeed down. Depending on the outcome of such verification, RNFD MUST set its LORS to either "UP", if the link has been confirmed not to be down, or "LOCALLY DOWN", otherwise. The verification can be performed, for example, by transmitting RPL DIS or ICMPv6 Echo Request messages to the DODAG root's link-local IPv6 address and expecting replies confirming that the root is up and reachable through the link. Care should be taken not to overload the DODAG root with traffic due to simultaneous probes, for instance, random backoffs can be employed to this end. It is RECOMMENDED that the "SUSPECTED DOWN" value of LORS be attained and verification take place if RNFD's conclusion on the state of the DODAG root is based only on indirect observations, for example, the aforementioned growth of the CFRC values. In contrast, for direct observations, such as missing L2 acknowledgments, the verification MAY be skipped, with the node's LORS effectively changing from "UP" directly to "LOCALLY DOWN". +

+
+
+

+LORS の「SUSPECTED DOWN」値は一時的なものです。その目的は、RNFD に DODAG ルートとのリンクが実際にダウンしているかどうかを確認する追加の機会を与えることです。そのような検証の結果に応じて、RNFD はリンクがダウンしていないことが確認された場合は LORS を「UP」に設定し、そうでない場合は「LOCALLY DOWN」に設定しなければなりません。検証は、たとえば、RPL DIS または ICMPv6 Echo Request メッセージを DODAG ルートのリンクローカル IPv6 アドレスに送信し、ルートが稼働中でリンク経由で到達可能であることを確認する応答を期待することによって実行できます。同時プローブにより DODAG ルートにトラフィックが過負荷にならないように注意する必要があります。たとえば、この目的のためにランダム バックオフを使用できます。DODAG ルートの状態に関する RNFD の結論が間接的な観察、たとえば、前述の CFRC 値の増加のみに基づいている場合、LORS の「SUSPECTED DOWN」値に達し、検証が行われることが推奨されます。対照的に、L2 確認応答の欠落などの直接観察の場合、ノードの LORS が事実上「UP」から直接「LOCALLY DOWN」に変更されるため、検証がスキップされてもよい(MAY)。 +

+
+
+
+
+

+For consistency with RPL, when detecting potential problems with the DODAG root, RNFD also must make use of RPL's independent knowledge. More specifically, a node MUST switch its LORS from "UP" or "SUSPECTED DOWN" directly to "LOCALLY DOWN" if a neighbor entry for the DODAG root is removed from RPL's DODAG parent set or the neighbor ceases to be considered reachable via its link-local IPv6 address. +

+
+
+

+RPL との一貫性を保つために、DODAG ルートの潜在的な問題を検出する場合、RNFD は RPL の独立した知識も利用する必要があります。より具体的には、DODAG ルートの隣接エントリが RPL の DODAG 親セットから削除された場合、または隣接ノードがそのリンクローカル IPv6 アドレス経由で到達可能であると見なされなくなった場合、ノードはその LORS を「UP」または「SUSPECTED DOWN」から「LOCALLY DOWN」に直接切り替えなければなりません (MUST)。 +

+
+
+
+
+

+Finally, while having its LORS already equal to "LOCALLY DOWN", a node may make an observation confirming that its link with the DODAG root is actually up. In such a case, it SHOULD set its LORS back to "UP" but MUST NOT do this before conditions 2-4 in Section 5.1, which are necessary for a node to change its role from Acceptor to Sentinel, all hold. +

+
+
+

+最後に、LORS がすでに「LOCALLY DOWN」に等しい場合、ノードは、DODAG ルートとのリンクが実際にアップしていることを確認する観察を行うことができます。このような場合、LORS を「UP」に戻す必要があります (SHOULD) が、ノードがその役割をアクセプターからセンチネルに変更するために必要なセクション 5.1 の条件 2 ～ 4 がすべて成立する前にこれを行ってはなりません (MUST NOT)。 +

+
+
+
+
+

+To appropriately account for the node's observations on the state of the DODAG root, the aforementioned LORS transitions are accompanied by changes to the node's local CFRCs as follows. Transitions between "UP" and "SUSPECTED DOWN" do not affect either of the two CFRCs. In contrast, during a switch from "UP" or "SUSPECTED DOWN" to "LOCALLY DOWN", the node MUST add itself to its NegativeCFRC, as explained previously. By symmetry, if there is a transition from "LOCALLY DOWN" to "UP", the node MUST add itself to its PositiveCFRC, as explained previously. +

+
+
+

+DODAG ルートの状態に関するノードの観察を適切に説明するために、前述の LORS 遷移には、次のようにノードのローカル CFRC への変更が伴います。「UP」と「SUSPECTED DOWN」の間の遷移は、2 つの CFRC のどちらにも影響しません。対照的に、「UP」または「SUSPECTED DOWN」から「LOCALLY DOWN」への切り替え中は、前に説明したように、ノードは自身を NegativeCFRC に追加しなければなりません (MUST)。対称性により、「LOCALLY DOWN」から「UP」への遷移がある場合、前に説明したように、ノードは自身を PositiveCFRC に追加しなければなりません (MUST)。 +

+
+
+
+
+

+Such changes to a node's local CFRCs, if performed repeatedly due to incorrect decisions regarding the status of the node's link with the DODAG root, may lead to those CFRCs becoming saturated. An implementation should thus try to minimize false-positive transitions from "UP" and "SUSPECTED DOWN" to "LOCALLY DOWN". The exact approach depends on the specific solutions employed for assessing the state of a link. For instance, one can utilize additional mechanisms for increasing the confidence of individual decisions, such as during the aforementioned verification in the "SUSPECTED DOWN" state, or can limit the number of transitions per node, possibly in an adaptive fashion. +

+
+
+

+DODAG ルートとのノードのリンクのステータスに関する誤った決定により、ノードのローカル CFRC に対するこのような変更が繰り返し実行されると、それらの CFRC が飽和状態になる可能性があります。したがって、実装では、「UP」および「SUSPECTED DOWN」から「LOCALLY DOWN」への誤検知遷移を最小限に抑えるように努める必要があります。正確なアプローチは、リンクの状態を評価するために採用される特定のソリューションによって異なります。たとえば、前述の「SUSPECTED DOWN」状態での検証中など、個々の決定の信頼性を高めるための追加メカニズムを利用したり、場合によっては適応的な方法でノードごとの遷移数を制限したりできます。 +

+
+
+
+
+
+5.3. Disseminating Observations and Reaching Agreement +
+
+
+
+5.3. 観察結果を広めて合意に達する +
+
+
+
+
+

+Nodes disseminate their observations by exchanging CFRCs in the RNFD Options embedded in link-local RPL control messages, notably DIOs and DISs. When processing such a received option, a node (acting as a Sentinel or Acceptor) MUST update its PositiveCFRC and NegativeCFRC to newpc = merge(oldpc, recvpc) and newnc = merge(oldnc, recvnc), respectively. Here, oldpc and oldnc are the values of the node's PositiveCFRC and NegativeCFRC before the update, while recvpc and recvnc are the received values of option fields PosCFRC and NegCFRC, respectively. +

+
+
+

+ノードは、リンクローカル RPL 制御メッセージ (特に DIO と DIS) に埋め込まれた RNFD オプションの CFRC を交換することによって、観測結果を広めます。このような受信したオプションを処理するとき、ノード (センチネルまたはアクセプターとして機能する) は、その PositiveCFRC と NegativeCFRC をそれぞれ newpc = merge(oldpc, recvpc) と newnc = merge(oldnc, recvnc) に更新しなければなりません (MUST)。ここで、oldpc と oldnc は更新前のノードの PositiveCFRC と NegativeCFRC の値であり、recvpc と recvnc はそれぞれオプション フィールド PosCFRC と NegCFRC の受信値です。 +

+
+
+
+
+

+In effect, the node's value of the fraction value(NegativeCFRC)/value(PositiveCFRC) may change. If the fraction reaches at least RNFD_CONSENSUS_THRESHOLD (with value(PositiveCFRC) being greater than zero), then the node consents on the DODAG root being down. Accordingly, it MUST change its LORS to "GLOBALLY DOWN" and set its PositiveCFRC and NegativeCFRC both to infinity(). +

+
+
+

+実際には、ノードの分数値 (NegativeCFRC)/値 (PositiveCFRC) の値が変更される可能性があります。この割合が少なくとも RNFD_CONSENSUS_THRESHOLD (value(PositiveCFRC) がゼロより大きい場合) に達すると、ノードは DODAG ルートがダウンしていることに同意します。したがって、LORS を「GLOBALLY DOWN」に変更し、PositiveCFRC と NegativeCFRC の両方を infinity() に設定しなければなりません。 +

+
+
+
+
+

+The "GLOBALLY DOWN" value of LORS is terminal; the node MUST NOT change it and MUST NOT modify its CFRCs until it joins a new DODAG Version. With this value of LORS, RNFD at the node MUST also prevent RPL from having any DODAG parent and advertising any Rank other than INFINITE_RANK. +

+
+
+

+LORS の「GLOBALLY DOWN」値は最終的なものです。ノードは新しい DODAG バージョンに参加するまで、それを変更してはならず、CFRC を変更してはなりません。LORS のこの値により、ノードの RNFD は、RPL が DODAG 親を持ち、INFINITE_RANK 以外のランクをアドバタイズすることも防止しなければなりません (MUST)。 +

+
+
+
+
+

+Since the RNFD Option is embedded, among others, in RPL DIO control messages, updates to a node's CFRCs may affect the sending schedule of these messages, which is driven by the DIO Trickle timer [RFC6206]. It is RECOMMENDED to use a dedicated Trickle timer for RNFD that is different from RPL's original DIO Trickle timer. In such a setting, whenever the dedicated timer fires and no DIO message containing the RNFD Option has been sent to the link-local all-RPL-nodes multicast IPv6 address since the previous firing, the node sends a DIO message containing the RNFD Option to the address. The minimal and maximal interval sizes of the dedicated timer SHOULD NOT be smaller than those of RPL's original DIO Trickle timer. In contrast, in the absence of the dedicated Trickle timer for RNFD, an implementation SHOULD ensure that the RNFD Option is present in multicast DIO messages sufficiently often to quickly propagate changes to the node's CFRCs and, notably, as soon as possible after a reset of the timer triggered by RNFD. In the remainder of this document, we will refer to the Trickle timer utilized by RNFD (either the dedicated one or RPL's original one, depending on the implementation) simply as "Trickle timer". In particular, a node MUST reset its Trickle timer when it changes its LORS to "GLOBALLY DOWN", so that information about the detected crash of the DODAG root is disseminated in the DODAG fast. Likewise, a node SHOULD reset its Trickle timer when any of its local CFRCs change significantly. +

+
+
+

+RNFD オプションは特に RPL DIO 制御メッセージに埋め込まれているため、ノードの CFRC の更新は、DIO Trickle タイマー [RFC6206] によって駆動されるこれらのメッセージの送信スケジュールに影響を与える可能性があります。RPL のオリジナルの DIO トリクル タイマーとは異なる、RNFD 専用のトリクル タイマーを使用することをお勧めします。このような設定では、専用タイマーが起動し、前回の起動以降、RNFD オプションを含む DIO メッセージがリンクローカルの全 RPL ノードのマルチキャスト IPv6 アドレスに送信されていない場合、ノードは RNFD オプションを含む DIO メッセージをそのアドレスに送信します。専用タイマーの最小間隔サイズと最大間隔サイズは、RPL のオリジナルの DIO Trickle タイマーの間隔サイズより小さくてはいけません (SHOULD NOT)。対照的に、RNFD 専用の Trickle タイマーが存在しない場合、実装では、変更をノードの CFRC に迅速に伝播するのに十分な頻度で、特に RNFD によってトリガーされたタイマーのリセット後できるだけ早く、RNFD オプションがマルチキャスト DIO メッセージに存在することを保証する必要があります (SHOULD)。このドキュメントの残りの部分では、RNFD によって利用されるトリクル タイマー (実装に応じて、専用のものまたは RPL のオリジナルのもの) を単に「トリクル タイマー」と呼びます。特に、ノードは LORS を「GLOBALLY DOWN」に変更するときにトリクル タイマーをリセットし、DODAG ルートの検出されたクラッシュに関する情報が DODAG ファストで広められるようにしなければなりません。同様に、ノードは、ローカル CFRC のいずれかが大幅に変化したときに、その Trickle タイマーをリセットする必要があります (SHOULD)。 +

+
+
+
+
+
+5.4. DODAG Root's Behavior +
+
+
+
+5.4. DODAG ルートの動作 +
+
+
+
+
+

+The DODAG root node MUST assume the role of Acceptor in RNFD and MUST NOT ever switch this role. It MUST also monitor its LORS and local CFRCs, so that it can react to various events. +

+
+
+

+DODAG ルート ノードは、RNFD でのアクセプターの役割を引き受けなければならず、この役割を決して切り替えてはなりません。また、さまざまなイベントに対応できるように、LORS とローカル CFRC を監視しなければなりません。 +

+
+
+
+
+

+To start with, the DODAG root MUST generate a new DODAG Version, thereby restarting the protocol, if it changes its LORS to "GLOBALLY DOWN", which may happen when the root has restarted after a crash or the nodes have falsely detected its crash. It MAY also generate a new DODAG Version if the fraction value(NegativeCFRC)/value(PositiveCFRC) approaches RNFD_CONSENSUS_THRESHOLD, so as to avoid potential interruptions to routing. +

+
+
+

+まず、DODAG ルートは、LORS を「GLOBALLY DOWN」に変更する場合、新しい DODAG バージョンを生成し、それによってプロトコルを再起動しなければなりません。これは、ルートがクラッシュ後に再起動した場合、またはノードがクラッシュを誤って検出した場合に発生する可能性があります。また、ルーティングの潜在的な中断を避けるために、小数値 (NegativeCFRC)/値 (PositiveCFRC) が RNFD_CONSENSUS_THRESHOLD に近づいた場合、新しい DODAG バージョンを生成してもよい (MAY)。 +

+
+
+
+
+

+Furthermore, the DODAG root SHOULD either generate a new DODAG Version or increase the bit length of its CFRCs if saturated(PositiveCFRC) becomes TRUE. This is a self-regulation mechanism that helps adjust the CFRCs to a potentially large number of Sentinels (see Section 6.1). +

+
+
+

+さらに、DODAG ルートは、saturated(PositiveCFRC) が TRUE になった場合、新しい DODAG バージョンを生成するか、その CFRC のビット長を増やす必要があります (SHOULD)。これは、潜在的に多数のセンチネルに合わせて CFRC を調整するのに役立つ自己調整メカニズムです (セクション 6.1 を参照)。 +

+
+
+
+
+

+In general, issuing a new DODAG Version effectively restarts RNFD. Thus, the DODAG root MAY also perform this operation in other situations. +

+
+
+

+一般に、新しい DODAG バージョンを発行すると、実質的に RNFD が再起動されます。したがって、DODAG ルートは他の状況でもこの操作を実行してもよい(MAY)。 +

+
+
+
+
+
+5.5. Activating and Deactivating the Protocol on Demand +
+
+
+
+5.5. オンデマンドでのプロトコルのアクティブ化と非アクティブ化 +
+
+
+
+
+

+RNFD can be activated and deactivated on demand, once per DODAG Version. The particular policies for activating and deactivating the protocol are outside the scope of this document. However, the activation and deactivation MUST be done at the DODAG root node; other nodes MUST comply. +

+
+
+

+RNFD は、DODAG バージョンごとに 1 回、オンデマンドでアクティブ化および非アクティブ化できます。プロトコルをアクティブ化および非アクティブ化するための特定のポリシーは、このドキュメントの範囲外です。ただし、アクティブ化と非アクティブ化は DODAG ルート ノードで行う必要があります。他のノードも従わなければなりません。 +

+
+
+
+
+

+More specifically, when a non-root node joins a DODAG Version, RNFD at the node is initially inactive. The node MUST NOT activate the protocol unless it receives for this DODAG Version a valid RNFD Option containing some CFRCs, that is, having its Option Length field positive. In particular, if the option accompanies the message that causes the node to join the DODAG Version, the protocol MUST be active from the moment of the joining. RNFD then remains active at the node until it is explicitly deactivated or the node joins a new DODAG Version. An explicit deactivation MUST take place when the node receives an RNFD Option for the DODAG Version with no CFRCs, that is, having its Option Length field equal to zero. When explicitly deactivated, RNFD MUST NOT be reactivated unless the node joins a new DODAG Version. In particular, when the first RNFD Option received by the node has its Option Length field equal to zero, the protocol MUST remain deactivated for the entire time the node belongs to the current DODAG Version. +

+
+
+

+より具体的には、非ルート ノードが DODAG バージョンに参加すると、ノードの RNFD は最初は非アクティブになります。ノードは、この DODAG バージョンに対して、いくつかの CFRC を含む有効な RNFD オプション、つまり、オプション長フィールドが正のものを受信しない限り、プロトコルをアクティブにしてはなりません (MUST NOT)。特に、オプションがノードを DODAG バージョンに参加させるメッセージを伴う場合、プロトコルは参加の瞬間からアクティブでなければなりません (MUST)。RNFD は、明示的に非アクティブ化されるか、ノードが新しい DODAG バージョンに参加するまで、ノードでアクティブなままになります。ノードが CFRC のない DODAG バージョンの RNFD オプションを受信したとき、つまりオプション長フィールドがゼロに等しいとき、明示的な非アクティブ化が行われなければなりません (MUST)。明示的に非アクティブ化された場合、ノードが新しい DODAG バージョンに参加しない限り、RNFD を再アクティブ化してはなりません (MUST NOT)。特に、ノードが受信した最初の RNFD オプションのオプション長フィールドが 0 に等しい場合、そのノードが現在の DODAG バージョンに属している間、プロトコルは非アクティブのままでなければなりません (MUST)。 +

+
+
+
+
+

+When RNFD at a node is initially inactive for a DODAG Version, the node MUST NOT attach any RNFD Option to the messages it sends (in particular, because it may not know the desired CFRC length; see Section 5.6). When the protocol has been explicitly deactivated, the node MAY also decide not to attach the option to its outgoing messages. However, it is RECOMMENDED that it send a sufficient number of messages with the option to the link-local all-RPL-nodes multicast IPv6 address to allow its neighbors to learn that RNFD has been deactivated in the current DODAG Version. In particular, it MAY reset its Trickle timer to this end but MAY also use some reactive mechanisms. For example, it might reply with a unicast DIO or DIS containing the RNFD Option with no CFRCs to a message from a neighbor that contains the option with some CFRCs, as such a neighbor appears not to have learned about the deactivation of RNFD. +

+
+
+

+ノードの RNFD が最初に DODAG バージョンに対して非アクティブである場合、ノードは送信するメッセージに RNFD オプションを付加してはなりません (特に、必要な CFRC 長がわからない可能性があるため、セクション 5.6 を参照)。プロトコルが明示的に非アクティブ化されている場合、ノードは発信メッセージにオプションを付加しないことを決定してもよい(MAY)。ただし、現在の DODAG バージョンで RNFD が非アクティブ化されていることを近隣のルータが認識できるように、リンク ローカルの全 RPL ノードのマルチキャスト IPv6 アドレスにオプション付きで十分な数のメッセージを送信することが推奨されます。特に、この目的のために Trickle タイマーをリセットしてもよい (MAY) が、いくつかの反応メカニズムを使用してもよい (MAY)。たとえば、一部の CFRC を含むオプションを含むネイバーからのメッセージに対して、CFRC を含まない RNFD オプションを含むユニキャスト DIO または DIS で応答する可能性があります。これは、そのようなネイバーが RNFD の非アクティブ化について学習していないように見えるためです。 +

+
+
+
+
+
+5.6. Processing CFRCs of Incompatible Lengths +
+
+
+
+5.6. 互換性のない長さの CFRC の処理 +
+
+
+
+
+

+The merge() and compare() operations on CFRCs require both arguments to be compatible, that is, to have the same bit length. However, the processing rules for the RNFD Option (see Section 4.2) do not necessitate this. This fact is made use of not only in the mechanisms for activating and deactivating the protocol (see Section 5.5), but also in mechanisms for dynamic adjustments of CFRCs, which aim to enable deployment-specific policies (see Section 6.1). A node thus must be prepared to receive the RNFD Option with fields PosCFRC and NegCFRC of a different bit length than the node's own PositiveCFRC and NegativeCFRC. Assuming that it has RNFD active and that fields PosCFRC and NegCFRC in the option have a positive length, the node MUST react as follows. +

+
+
+

+CFRC の merge() および Compare() 操作では、両方の引数に互換性があること、つまり同じビット長であることが必要です。ただし、RNFD オプションの処理規則 (セクション 4.2 を参照) ではこれは必要ありません。この事実は、プロトコルをアクティブ化および非アクティブ化するメカニズム (セクション 5.5 を参照) だけでなく、展開固有のポリシーを有効にすることを目的とした CFRC の動的調整のメカニズム (セクション 6.1 を参照) でも利用されます。したがって、ノードは、ノード自身の PositiveCFRC および NegativeCFRC とは異なるビット長のフィールド PosCFRC および NegCFRC を含む RNFD オプションを受信できるように準備する必要があります。RNFD がアクティブであり、オプションの PosCFRC フィールドと NegCFRC フィールドが正の長さを持っていると仮定すると、ノードは次のように反応しなければなりません (MUST)。 +

+
+
+
+
+

+If the bit length of fields PosCFRC and NegCFRC is the same as that of the node's local PositiveCFRC and NegativeCFRC, then the node MUST perform the merges, as detailed previously (see Section 5.3). +

+
+
+

+フィールド PosCFRC および NegCFRC のビット長がノードのローカル PositiveCFRC および NegativeCFRC のビット長と同じである場合、ノードは以前に詳述したようにマージを実行しなければなりません (セクション 5.3 を参照)。 +

+
+
+
+
+

+If the bit length of fields PosCFRC and NegCFRC is smaller than that of the node's local PositiveCFRC and NegativeCFRC, then the node MUST ignore the option and MAY reset its Trickle timer. +

+
+
+

+フィールド PosCFRC および NegCFRC のビット長がノードのローカル PositiveCFRC および NegativeCFRC のビット長より小さい場合、ノードはオプションを無視しなければならず (MUST)、トリクル タイマーをリセットしてもよい (MAY)。 +

+
+
+
+
+

+If the bit length of fields PosCFRC and NegCFRC is greater than that of the node's local PositiveCFRC and NegativeCFRC, then the node MUST extend the bit length of its local CFRCs to be equal to that in the option and set the CFRCs as follows: +

+
+
+

+フィールド PosCFRC および NegCFRC のビット長がノードのローカル PositiveCFRC および NegativeCFRC のビット長より大きい場合、ノードはローカル CFRC のビット長をオプションのビット長と等しくなるように拡張し、CFRC を次のように設定しなければなりません。 +

+
+
+
+
+

+* If the node's LORS is "GLOBALLY DOWN", then both of its local CFRCs MUST be set to infinity(). +

+
+
+

+* ノードの LORS が「GLOBALLY DOWN」の場合、そのローカル CFRC の両方を infinity() に設定しなければなりません。 +

+
+
+
+
+

+* Otherwise, they both MUST be set to zero(), and the node MUST account for itself in so initialized CFRCs. More specifically, if the node is a Sentinel, then it MUST add itself to its PositiveCFRC, as detailed previously. In addition, if its LORS is "LOCALLY DOWN", then it MUST also add itself to its NegativeCFRC, as explained previously. Finally, the node MUST perform merges of its local CFRCs and the ones received in the option (see Section 5.3) and MAY reset its Trickle timer. +

+
+
+

+* それ以外の場合、それらは両方とも zero() に設定されなければならず、ノードはそのように初期化された CFRC 内でそれ自体を考慮しなければなりません。より具体的には、ノードが Sentinel の場合、前に説明したように、ノード自体を PositiveCFRC に追加しなければなりません (MUST)。さらに、LORS が「LOCALLY DOWN」の場合は、前に説明したように、自身を NegativeCFRC に追加しなければなりません。最後に、ノードはローカル CFRC とオプション (セクション 5.3 を参照) で受信した CFRC のマージを実行しなければならず (MUST)、トリクル タイマーをリセットしてもよい (MAY)。 +

+
+
+
+
+

+In contrast, if the node is unable to extend its local CFRCs, for example, because it lacks resources, then it MUST stop participating in RNFD. That is, until it joins a new DODAG Version, it MUST NOT send the RNFD Option and MUST ignore this option in received messages. +

+
+
+

+対照的に、ノードがリソース不足などの理由でローカル CFRC を拡張できない場合は、RNFD への参加を停止しなければなりません。つまり、新しい DODAG バージョンに参加するまで、RNFD オプションを送信してはならず、受信メッセージ内のこのオプションを無視しなければなりません (MUST)。 +

+
+
+
+
+

+A DODAG root node can be requested to increase the bit length of its CFRCs externally, as part of the management policies (see Section 6.1). If it cannot fulfill such a request, then it MUST NOT stop participating in RNFD and SHOULD return an error to the requester instead. Otherwise, since it is always an Acceptor, the above rules require it to extend both CFRCs to the requested length and to set them both to either zero() or infinity(), depending on whether its LORS is different from or equal to "GLOBALLY DOWN", respectively. In the latter case, given the earlier rules governing the root's behavior upon reaching the "GLOBALLY DOWN" state (cf. Section 5.4), the root is also bound to eventually set its CFRCs to zero() and, in addition, generate a new DODAG Version and change its LORS back to "UP". Therefore, these two steps can be optimized into one, meaning that effectively, irrespective of its LORS, when increasing the bit length of its CFRCs in response to an external request, the root also sets the CFRCs to zero(). +

+
+
+

+DODAG ルート ノードは、管理ポリシーの一環として、外部から CFRC のビット長を増やすように要求できます (セクション 6.1 を参照)。そのような要求を満たすことができない場合、RNFD への参加を停止してはならず、代わりに要求者にエラーを返す必要があります (SHOULD)。それ以外の場合、常にアクセプターであるため、上記のルールでは、両方の CFRC を要求された長さまで拡張し、LORS が「GLOBALLY DOWN」と異なるか等しいかに応じて両方を zero() または infinity() に設定する必要があります。後者の場合、「GLOBALLY DOWN」状態に達したときのルートの動作を管理する以前のルール (セクション 5.4 を参照) を考慮すると、ルートは最終的に CFRC を zero() に設定し、さらに新しい DODAG バージョンを生成して LORS を「UP」に戻すことになります。したがって、これらの 2 つのステップは 1 つに最適化できます。つまり、LORS に関係なく、外部要求に応じて CFRC のビット長を増やすときに、ルートは CFRC を zero() に設定することになります。 +

+
+
+
+
+
+5.7. Summary of RNFD's Interactions with RPL +
+
+
+
+5.7. RNFD と RPL との関係の概要 +
+
+
+
+
+

+In summary, RNFD interacts with RPL in the following manner: +

+
+
+

+要約すると、RNFD は次の方法で RPL と対話します。 +

+
+
+
+
+

+* While having its LORS equal to "GLOBALLY DOWN", RNFD prevents RPL from routing packets and advertising upward routes in the corresponding DODAG (see Section 5.3). +

+
+
+

+* LORS を「GLOBALLY DOWN」に設定している間、RNFD は、RPL がパケットをルーティングし、対応する DODAG 内で上向きルートをアドバタイズすることを防ぎます (セクション 5.3 を参照)。 +

+
+
+
+
+

+* In some scenarios, RNFD triggers RPL to issue a new DODAG Version (see Section 5.4). +

+
+
+

+* 一部のシナリオでは、RNFD が RPL をトリガーして新しい DODAG バージョンを発行します (セクション 5.4 を参照)。 +

+
+
+
+
+

+* Depending on the implementation, RNFD may cause RPL's DIO Trickle timer resets (see Sections 5.3, 5.5, and 5.6). +

+
+
+

+* 実装によっては、RNFD が RPL の DIO Trickle タイマー リセットを引き起こす可能性があります (セクション 5.3、5.5、および 5.6 を参照)。 +

+
+
+
+
+

+* RNFD monitors events relevant to routing adjacency maintenance as well as those affecting RPL's DODAG parent set (see Sections 5.1 and 5.2). +

+
+
+

+* RNFD は、ルーティング隣接関係の維持に関連するイベントと、RPL の DODAG 親セットに影響を与えるイベントを監視します (セクション 5.1 および 5.2 を参照)。 +

+
+
+
+
+

+* Using RNFD entails embedding the RNFD Option into link-local RPL control messages (see Section 4.2). +

+
+
+

+* RNFD を使用するには、RNFD オプションをリンクローカル RPL 制御メッセージに埋め込む必要があります (セクション 4.2 を参照)。 +

+
+
+
+
+
+5.8. Summary of RNFD's Constants +
+
+
+
+5.8. RNFDの定数の概要 +
+
+
+
+
+

+The following is a summary of RNFD's constants: +

+
+
+

+以下は RNFD の定数の概要です。 +

+
+
+
+
+

+RNFD_CONSENSUS_THRESHOLD: +

+
+
+

+RNFD_CONSENSUS_THRESHOLD: +

+
+
+
+
+

+A threshold concerning the value of the fraction value(NegativeCFRC)/value(PositiveCFRC). If the value at a Sentinel or Acceptor node reaches the threshold, then the node's LORS is set to "GLOBALLY DOWN", which implies that consensus has been reached on the DODAG root node being down (see Section 5.3). The default value of the threshold is 0.51, which indicates that a majority of Sentinels must consider the root to be down to reach the consensus. In general, when the value is higher, the detection period is longer, but the risk of false positives is lower. +

+
+
+

+端数値(NegativeCFRC)/値(PositiveCFRC)の値に関する閾値。Sentinel または Acceptor ノードの値がしきい値に達すると、ノードの LORS は「GLOBALLY DOWN」に設定されます。これは、DODAG ルート ノードがダウンしていることについて合意が得られたことを意味します (セクション 5.3 を参照)。しきい値のデフォルト値は 0.51 で、これは、コンセンサスに達するには、大多数の Sentinel がルートがダウンしていると見なす必要があることを示します。一般に、値が高いほど検出期間は長くなりますが、誤検知のリスクは低くなります。 +

+
+
+
+
+

+RNFD_SUSPICION_GROWTH_THRESHOLD: +

+
+
+

+RNFD_SUSPICION_GROWTH_THRESHOLD: +

+
+
+
+
+

+A threshold concerning the value of the fraction value(NegativeCFRC)/value(PositiveCFRC). If the value at a Sentinel node grows at least by this threshold since the time the node's LORS was last set to "UP", then the node's LORS is set to "SUSPECTED DOWN" or "LOCALLY DOWN", which implies that the node starts suspecting or assumes a crash of the DODAG root (see Section 5.2). When the value is higher, the duration of detecting true crashes is longer, but the risk of increased traffic due to verifying false suspicions is lower. The default value of the threshold is 0.12, which in sparse networks (up to 8 neighbors per node) triggers a suspicion at a Sentinel node after just one other Sentinel starts considering the root as dead, while being gradually more conservative in denser networks. +

+
+
+

+端数値(NegativeCFRC)/値(PositiveCFRC)の値に関する閾値。ノードの LORS が最後に「UP」に設定されてから、Sentinel ノードの値が少なくともこのしきい値だけ増加した場合、ノードの LORS は「SUSPECTED DOWN」または「LOCALLY DOWN」に設定されます。これは、ノードが DODAG ルートのクラッシュを疑うか、または想定し始めることを意味します (セクション 5.2 を参照)。値が大きいほど、本当のクラッシュを検出するまでの時間は長くなりますが、誤った疑いの検証によってトラフィックが増加するリスクは低くなります。しきい値のデフォルト値は 0.12 で、疎なネットワーク (ノードごとに最大 8 つの隣接ノード) では、他の 1 つの Sentinel がルートをデッドとみなし始めると、Sentinel ノードで疑わしい値がトリガーされますが、高密度のネットワークでは徐々に保守的になります。 +

+
+
+
+
+

+RNFD_CFRC_SATURATION_THRESHOLD: +

+
+
+

+RNFD_CFRC_SATURATION_THRESHOLD: +

+
+
+
+
+

+A threshold concerning the percentage of bits set to 1 in a CFRC, c. If the percentage for c is equal to or greater than this threshold, then saturated(c) returns TRUE, which hints the DODAG root to generate a new DODAG Version or increase the bit length of the CFRCs (see Section 5.4). The default value of the threshold is 0.63. When the value is higher, the probability of bit collisions is higher, and the results of function value(c) may thus be more erratic. +

+
+
+

+ＣＦＲＣにおいて１に設定されるビットのパーセンテージに関する閾値、 ｃ．c のパーセンテージがこのしきい値以上の場合、saturated(c) は TRUE を返し、DODAG ルートに新しい DODAG バージョンを生成するか、CFRC のビット長を増やすよう示唆します (セクション 5.4 を参照)。しきい値のデフォルト値は 0.63 です。値が大きいほど、ビット衝突の確率が高くなるため、関数 value(c) の結果がより不安定になる可能性があります。 +

+
+
+
+
+

+The means of configuring the constants at individual nodes are outside the scope of this document. +

+
+
+

+個々のノードで定数を設定する方法は、このドキュメントの範囲外です。 +

+
+
+
+
+
+6. Manageability Considerations +
+
+
+
+6. 管理性に関する考慮事項 +
+
+
+
+
+

+RNFD is largely self-managed, with the exception of protocol activation and deactivation, as well as node role assignment and the related CFRC size adjustment, for which only the aforementioned mechanisms are defined, so as to enable adopting deployment-specific policies. This section discusses the manageability issues. +

+
+
+

+RNFD は、プロトコルのアクティブ化と非アクティブ化、ノードの役割の割り当て、および関連する CFRC サイズの調整を除いて、大部分が自己管理されます。これらについては、展開固有のポリシーの採用を可能にするために、前述のメカニズムのみが定義されています。このセクションでは、管理性の問題について説明します。 +

+
+
+
+
+
+6.1. Role Assignment and CFRC Size Adjustment +
+
+
+
+6.1. 役割の割り当てと CFRC サイズの調整 +
+
+
+
+
+

+One approach to node role and CFRC size selection is to manually designate specific nodes as Sentinels in RNFD, assuming that they will have chances to satisfy the necessary conditions for attaining this role (see Section 5.1), and to fix the CFRC bit length to accommodate these nodes. +

+
+
+

+ノードの役割と CFRC サイズの選択に対する 1 つのアプローチは、特定のノードがこの役割を達成するために必要な条件を満たす機会があると仮定して (セクション 5.1 を参照)、特定のノードを RNFD のセンチネルとして手動で指定し、これらのノードに対応するために CFRC ビット長を固定することです。 +

+
+
+
+
+

+Another approach is to automate the selection process. In principle, any node satisfying the necessary conditions for becoming a Sentinel (see Section 5.1) can attain this role. However, in networks where the DODAG root node has many neighbors, this approach may lead to saturated(PositiveCFRC) quickly becoming TRUE, which may degrade RNFD's performance without additional measures. This issue can be handled with a probabilistic solution: if PositiveCFRC becomes saturated with little or no increase in NegativeCFRC, then a new DODAG Version can be issued, and a node satisfying the necessary conditions can become a Sentinel in this version only with probability 1/2. This process can be continued with the probability being halved in each new DODAG Version until PositiveCFRC is no longer quickly saturated. Another solution is to increase, potentially multiple times, the bit length of the CFRCs by the DODAG root if PositiveCFRC becomes saturated with little or no growth in NegativeCFRC. This does not require issuing a new DODAG Version but lengthens the RNFD Option. In this way, a sufficient bit length can be dynamically discovered, or the root can conclude that a given bit length is excessive for (some) nodes and resort to the previous solution. Increasing the bit length can be done, for instance, by doubling it, respecting the condition that it has to be a prime number (see Section 4.2). +

+
+
+

+もう 1 つのアプローチは、選択プロセスを自動化することです。原則として、センチネルになるために必要な条件 (セクション 5.1 を参照) を満たすノードは、この役割を達成できます。ただし、DODAG ルート ノードに多くの隣接ノードがあるネットワークでは、このアプローチでは飽和(PositiveCFRC) がすぐに TRUE になり、追加の対策がなければ RNFD のパフォーマンスが低下する可能性があります。この問題は確率論的な解決策で処理できます。つまり、NegativeCFRC がほとんどまたはまったく増加せずに PositiveCFRC が飽和状態になった場合、新しい DODAG バージョンを発行することができ、必要な条件を満たすノードはこのバージョンで確率 1/2 でのみ Sentinel になることができます。このプロセスは、PositiveCFRC が急速に飽和しなくなるまで、新しい DODAG バージョンごとに確率を半分にして継続できます。もう 1 つの解決策は、PositiveCFRC が飽和し、NegativeCFRC がほとんどまたはまったく増加しない場合に、DODAG ルートによって CFRC のビット長をおそらく複数倍に増やすことです。これには新しい DODAG バージョンを発行する必要はありませんが、RNFD オプションが長くなります。このようにして、十分なビット長を動的に見つけることができます。あるいは、ルートは、特定のビット長が (一部の) ノードにとって過剰であると結論付け、前の解決策に頼ることもできます。ビット長を増やすには、たとえば、ビット長が素数である必要があるという条件を考慮してビット長を 2 倍にすることができます (セクション 4.2 を参照)。 +

+
+
+
+
+

+In either of the solutions, Sentinel nodes should preferably be stable themselves and have stable links to the DODAG root. Otherwise, they may often exhibit LORS transitions between "UP" and "LOCALLY DOWN" or switches between Acceptor and Sentinel roles, which gradually saturates CFRCs. As a mitigation, the number of such transitions and switches per node MAY be limited; however, having Sentinels be stable SHOULD be preferred. +

+
+
+

+どちらのソリューションでも、Sentinel ノード自体が安定しており、DODAG ルートへの安定したリンクを持つことが望ましいです。それ以外の場合は、「UP」と「LOCALLY DOWN」の間で LORS 遷移が発生したり、アクセプターとセンチネルの役割が切り替わったりすることが多く、これにより CFRC が徐々に飽和状態になります。緩和策として、ノードごとのそのような遷移とスイッチの数を制限してもよい(MAY)。ただし、Sentinel を安定させることが好ましいはずです。 +

+
+
+
+
+
+6.2. Virtual DODAG Roots +
+
+
+
+6.2. 仮想 DODAG ルート +
+
+
+
+
+

+RPL allows a DODAG to have a so-called "virtual root", that is, a collection of nodes coordinating to act as a single root of the DODAG. The details of the coordination process are left open in [RFC6550], but from RNFD's perspective, two possible realizations are worth consideration: +

+
+
+

+RPL を使用すると、DODAG はいわゆる「仮想ルート」、つまり、DODAG の単一のルートとして機能するように調整するノードの集合を持つことができます。調整プロセスの詳細は [RFC6550] で未公開のままですが、RNFD の観点からは、次の 2 つの実現可能性を検討する価値があります。 +

+
+
+
+
+

+* Just a single (primary) node of the nodes comprising the virtual root acts as the actual root of the DODAG. Only when this node fails does another (backup) node take over. As a result, at any time, at most one of the nodes comprising the virtual root is the actual root. +

+
+
+

+* 仮想ルートを構成するノードのうちの 1 つの (プライマリ) ノードだけが、DODAG の実際のルートとして機能します。このノードに障害が発生した場合にのみ、別の (バックアップ) ノードが引き継ぎます。その結果、いつでも、仮想ルートを構成するノードのうち最大 1 つが実際のルートになります。 +

+
+
+
+
+

+* More than one of the nodes comprising the virtual root act as actual roots of the DODAG, all advertising the same Rank in the DODAG. When some of the nodes fail, the other nodes may or may not react in any specific way. In other words, at any time, more than one node can be the actual root. +

+
+
+

+* 仮想ルートを構成する複数のノードが DODAG の実際のルートとして機能し、すべて DODAG 内の同じランクをアドバタイズします。一部のノードに障害が発生した場合、他のノードは特定の方法で反応する場合もあれば、反応しない場合もあります。言い換えれば、いつでも複数のノードが実際のルートになる可能性があります。 +

+
+
+
+
+

+In the first realization, RNFD's operation is largely unaffected. The necessary conditions for a node to become a Sentinel (Section 5.1) guarantee that only the current primary root node is monitored by the protocol. This SHOULD be taken into account in the policies for node role assignment, CFRC size selection, and, possibly, the setting of the three thresholds (Section 5.8). Moreover, when a new primary has been elected, a new DODAG Version MUST be issued to avoid polluting CFRCs with observations on the previous primary. +

+
+
+

+最初の実現では、RNFD の動作はほとんど影響を受けません。ノードが Sentinel になるための必要条件 (セクション 5.1) により、現在のプライマリ ルート ノードのみがプロトコルによって監視されることが保証されます。これは、ノードの役割の割り当て、CFRC サイズの選択、および場合によっては 3 つのしきい値の設定 (セクション 5.8) のポリシーで考慮されるべきです (SHOULD)。さらに、新しい予備選挙が選出された場合、以前の予備選挙に関する観察結果によって CFRC が汚染されるのを避けるために、新しい DODAG バージョンを発行しなければなりません (MUST)。 +

+
+
+
+
+

+In the second realization, the fact that the virtual root consists of multiple nodes is transparent to RNFD. Therefore, employing RNFD in such a setting can be beneficial only if the nodes comprising the virtual root may suffer from correlated crashes, for instance, due to global power outages. +

+
+
+

+2 番目の実現では、仮想ルートが複数のノードで構成されているという事実は、RNFD に対して透過的です。したがって、このような設定で RNFD を採用することは、仮想ルートを構成するノードが、たとえば世界規模の停電によって相関クラッシュに見舞われる可能性がある場合にのみ有益となり得ます。 +

+
+
+
+
+
+6.3. Monitoring +
+
+
+
+6.3. 監視 +
+
+
+
+
+

+For monitoring the operation of RNFD, its implementation SHOULD provide the following information about a node: +

+
+
+

+RNFD の動作を監視するために、その実装はノードに関する次の情報を提供する必要があります (SHOULD)。 +

+
+
+
+
+

+* whether the protocol is active, and +

+
+
+

+* プロトコルがアクティブかどうか、および +

+
+
+
+
+

+* whether LORS is "GLOBALLY DOWN". +

+
+
+

+* LORS が「世界的にダウン」しているかどうか。 +

+
+
+
+
+

+This information MUST be accompanied by the monitoring parameters defined by RPL [RFC6550], including at least the DODAG Version Number and the Rank. To offer even finer-grained visibility into RNFD's state at the node, the implementation MAY also provide: +

+
+
+

+この情報には、少なくとも DODAG バージョン番号とランクを含む、RPL [RFC6550] で定義された監視パラメータが伴わなければなりません (MUST)。ノードでの RNFD の状態に対するさらにきめ細かい可視性を提供するために、実装は以下を提供してもよい (MAY)。 +

+
+
+
+
+

+* the assigned role (i.e., Sentinel or Acceptor), +

+
+
+

+* 割り当てられた役割 (つまり、センチネルまたはアクセプター)、 +

+
+
+
+
+

+* the exact value of LORS (i.e., "UP", "SUSPECTED DOWN", "LOCALLY DOWN", or "GLOBALLY DOWN"), +

+
+
+

+* LORS の正確な値 (つまり、「UP」、「SUSPECTED DOWN」、「LOCALLY DOWN」、または「GLOBALLY DOWN」)、 +

+
+
+
+
+

+* the two CFRCs (i.e., PositiveCFRC and NegativeCFRC), and +

+
+
+

+* 2 つの CFRC (つまり、ポジティブ CFRC とネガティブ CFRC)、および +

+
+
+
+
+

+* the constants listed in Section 5.8. +

+
+
+

+* セクション 5.8 にリストされている定数。 +

+
+
+
+
+
+7. Security Considerations +
+
+
+
+7. セキュリティに関する考慮事項 +
+
+
+
+
+

+RNFD is an extension to RPL and thus is vulnerable to and benefits from the security issues and solutions described in [RFC6550] and [RFC7416]. Its specification in this document does not introduce new traffic patterns or new messages, for which specific mitigation techniques would be required beyond what can already be adopted for RPL. +

+
+
+

+RNFD は RPL の拡張であるため、[RFC6550] および [RFC7416] で説明されているセキュリティ問題と解決策に対して脆弱ですが、その恩恵を受けます。このドキュメントの仕様では、RPL に既に採用されているものを超えた特定の緩和手法が必要となる新しいトラフィック パターンや新しいメッセージは導入されていません。 +

+
+
+
+
+

+In particular, RNFD depends on information exchanged in the RNFD Option. If the contents of this option were compromised, then failure misdetection may occur. One possibility is that the DODAG root may be falsely detected as crashed, which would result in an inability of the nodes to route packets, at least until a new DODAG Version is issued by the root. Another possibility is that a crash of the DODAG root may not be detected by RNFD, in which case RPL would have to rely on its own mechanisms. Moreover, compromising the contents of the RNFD Option may also lead to increased DIO traffic due to Trickle timer resets. Consequently, RNFD deployments are RECOMMENDED to use RPL security mechanisms if there is a risk that control information might be modified or spoofed. +

+
+
+

+特に、RNFD は RNFD オプションで交換される情報に依存します。このオプションの内容が侵害された場合、障害の誤検出が発生する可能性があります。可能性の 1 つは、DODAG ルートがクラッシュしていると誤って検出される可能性であり、その結果、少なくともルートによって新しい DODAG バージョンが発行されるまで、ノードはパケットをルーティングできなくなります。もう 1 つの可能性としては、DODAG ルートのクラッシュが RNFD によって検出されない可能性があり、その場合、RPL は独自のメカニズムに依存する必要があります。さらに、RNFD オプションの内容が侵害されると、トリクル タイマーのリセットにより DIO トラフィックが増加する可能性もあります。したがって、制御情報が変更またはなりすましされるリスクがある場合、RNFD 導入では RPL セキュリティ メカニズムを使用することが推奨されます。 +

+
+
+
+
+

+In this context, two features of RNFD are worth highlighting. First, unless all neighbors of a DODAG root are compromised, a false positive can always be detected by the root based on its local CFRCs. If the frequency of such false positives becomes problematic, RNFD can be disabled altogether, for instance, until the problem has been diagnosed. This procedure can be largely automated at LBRs. Second, some types of false negatives can also be detected this way. Those that do pass undetected are likely not to have major negative consequences on RPL apart from the lack of improvement to its performance upon a DODAG root's crash, at least if RPL's other components are not attacked as well. +

+
+
+

+これに関連して、RNFD の 2 つの機能は強調する価値があります。まず、DODAG ルートの近隣すべてが侵害されない限り、ルートはローカル CFRC に基づいて誤検知を常に検出できます。このような誤検知の頻度が問題になる場合は、たとえば、問題が診断されるまで RNFD を完全に無効にすることができます。この手順は、LBR で大部分が自動化できます。第 2 に、一部のタイプの偽陰性もこの方法で検出できます。検出されずに通過するコンポーネントは、少なくとも RPL の他のコンポーネントが同様に攻撃されない限り、DODAG ルートのクラッシュ時にパフォーマンスが改善されないことを除けば、RPL に大きな悪影響を与えることはないと考えられます。 +

+
+
+
+
+
+8. IANA Considerations +
+
+
+
+8. IANAの考慮事項 +
+
+
+
+
+

+IANA has allocated the following value in the "RPL Control Message Options" registry within the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group (https://www.iana.org/assignments/rpl). +

+
+
+

+IANA は、「Routing Protocol for Low Power and Lossy Networks (RPL)」レジストリ グループ (https://www.iana.org/assignments/rpl) 内の「RPL Control Message Options」レジストリに次の値を割り当てました。 +

+
+
+
+
+ 
+                                  +=======+=============+===========+
+                                  | Value | Meaning     | Reference |
+                                  +=======+=============+===========+
+                                  | 0x0E  | RNFD Option | RFC 9866  |
+                                  +-------+-------------+-----------+
+
+                                                Table 1
+
+
+
+
+
+
+9. References +
+
+
+
+9. 参考文献 +
+
+
+
+
+
+9.1. Normative References +
+
+
+
+9.1. 引用文献 +
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
+              "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
+              March 2011, <https://www.rfc-editor.org/info/rfc6206>.
+
+
+
+
+
+ 
+   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
+              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
+              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
+              Low-Power and Lossy Networks", RFC 6550,
+              DOI 10.17487/RFC6550, March 2012,
+              <https://www.rfc-editor.org/info/rfc6550>.
+
+
+
+
+
+ 
+   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
+              Power and Lossy Networks (RPL) Option for Carrying RPL
+              Information in Data-Plane Datagrams", RFC 6553,
+              DOI 10.17487/RFC6553, March 2012,
+              <https://www.rfc-editor.org/info/rfc6553>.
+
+
+
+
+
+ 
+   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
+              Routing Header for Source Routes with the Routing Protocol
+              for Low-Power and Lossy Networks (RPL)", RFC 6554,
+              DOI 10.17487/RFC6554, March 2012,
+              <https://www.rfc-editor.org/info/rfc6554>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+
+9.2. Informative References +
+
+
+
+9.2. 参考引用 +
+
+
+
+
+ 
+   [Ciolkosz19]
+              Ciolkosz, P., "Integration of the RNFD Algorithm for
+              Border Router Failure Detection with the RPL Standard for
+              Routing IPv6 Packets", Master's Thesis, University of
+              Warsaw, 2019.
+
+
+
+
+
+ 
+   [Iwanicki16]
+              Iwanicki, K., "RNFD: Routing-Layer Detection of DODAG
+              (Root) Node Failures in Low-Power Wireless Networks", 2016
+              15th ACM/IEEE International Conference on Information
+              Processing in Sensor Networks (IPSN), pp. 1-12,
+              DOI 10.1109/IPSN.2016.7460720, 2016,
+              <https://doi.org/10.1109/IPSN.2016.7460720>.
+
+
+
+
+
+ 
+   [Paszkowska19]
+              Paszkowska, A. and K. Iwanicki, "Failure Handling in RPL
+              Implementations: An Experimental Qualitative Study",
+              Mission-Oriented Sensor Networks and Systems: Art and
+              Science, Springer International Publishing, pp. 49-95,
+              DOI 10.1007/978-3-319-91146-5_3, 2019,
+              <https://doi.org/10.1007/978-3-319-91146-5_3>.
+
+
+
+
+
+ 
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              DOI 10.17487/RFC4861, September 2007,
+              <https://www.rfc-editor.org/info/rfc4861>.
+
+
+
+
+
+ 
+   [RFC5184]  Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
+              Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
+              (L3)-Driven Fast Handover", RFC 5184,
+              DOI 10.17487/RFC5184, May 2008,
+              <https://www.rfc-editor.org/info/rfc5184>.
+
+
+
+
+
+ 
+   [RFC7102]  Vasseur, JP., "Terms Used in Routing for Low-Power and
+              Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
+              2014, <https://www.rfc-editor.org/info/rfc7102>.
+
+
+
+
+
+ 
+   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
+              Constrained-Node Networks", RFC 7228,
+              DOI 10.17487/RFC7228, May 2014,
+              <https://www.rfc-editor.org/info/rfc7228>.
+
+
+
+
+
+ 
+   [RFC7416]  Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
+              and M. Richardson, Ed., "A Security Threat Analysis for
+              the Routing Protocol for Low-Power and Lossy Networks
+              (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
+              <https://www.rfc-editor.org/info/rfc7416>.
+
+
+
+
+
+ 
+   [Whang90]  Whang, K.-Y., Vander-Zanden, B.T., and H.M. Taylor, "A
+              Linear-time Probabilistic Counting Algorithm for Database
+              Applications", ACM Transactions on Database Systems
+              (TODS), vol. 15, no. 2, pp. 208-229,
+              DOI 10.1145/78922.78925, 1990,
+              <https://doi.org/10.1145/78922.78925>.
+
+
+
+
+
+
+Acknowledgements +
+
+
+
+謝辞 +
+
+
+
+
+

+The author would like to acknowledge Piotr Ciolkosz and Agnieszka Paszkowska. Agnieszka contributed to deeper understanding and formally proving various aspects of RPL's behavior upon an LBR crash. Piotr developed a prototype implementation of RNFD dedicated for RPL to verify earlier performance claims. +

+
+
+

+著者は、ピョートル・チョルコシュとアグニエシュカ・パスコウスカに感謝したいと思います。アグニエシュカは、LBR 墜落時の RPL の動作のさまざまな側面についての理解を深め、正式に証明することに貢献しました。Piotr は、以前のパフォーマンス主張を検証するために、RPL 専用の RNFD のプロトタイプ実装を開発しました。 +

+
+
+
+
+
+Author's Address +
+
+
+
+著者の連絡先 +
+
+
+
+
+ 
+   Konrad Iwanicki
+   University of Warsaw
+   Banacha 2
+   02-097 Warszawa
+   Poland
+   Phone: +48 22 55 44 428
+   Email: iwanicki@mimuw.edu.pl
+
+
+
+
+ + + diff --git a/html/rfc9869.html b/html/rfc9869.html new file mode 100644 index 000000000..48ea2660e --- /dev/null +++ b/html/rfc9869.html @@ -0,0 +1,1570 @@ + + + + + + RFC 9869 - Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)                      G. Fairhurst
+Request for Comments: 9869                                      T. Jones
+Category: Standards Track                         University of Aberdeen
+ISSN: 2070-1721                                             October 2025
+
+
+
+
+
+
+Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options +
+
+
+
+UDP オプションのデータグラム パケット化層パス MTU 検出 (DPLPMTUD) +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document specifies how a UDP Options sender implements Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) as a robust method for Path MTU Discovery (PMTUD). This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across a network path. It also provides a way to allow the application to periodically verify the current Maximum Packet Size (MPS) supported by a path and to update this when required. +

+
+
+

+この文書では、UDP オプションの送信者が、Path MTU Discovery (PMTUD) の堅牢な方法として Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) を実装する方法を指定します。この方法では、UDP オプションのパケット化層を使用します。これにより、アプリケーションはネットワーク パス経由で送信できる最大サイズのデータグラムを検出できるようになります。また、アプリケーションがパスでサポートされている現在の最大パケット サイズ (MPS) を定期的に確認し、必要に応じてこれを更新できるようにする方法も提供します。 +

+
+
+
+
+
+Status of This Memo +
+
+
+
+本文書の位置付け +
+
+
+
+
+

+This is an Internet Standards Track document. +

+
+
+

+これはインターネット標準化トラックの文書です。 +

+
+
+
+
+

+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 Internet Standards is available in Section 2 of RFC 7841. +

+
+
+

+このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、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/rfc9869. +

+
+
+

+この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9869 で入手できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+Copyright (c) 2025 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+   2.  Terminology
+   3.  DPLPMTUD for UDP Options
+     3.1.  Packet Formats
+     3.2.  Sending Probe Packets with the Request Option
+     3.3.  Receiving UDP Options Probe Packets and Sending the RES
+           Option
+   4.  DPLPMTUD Sender Procedures for UDP Options
+     4.1.  Confirmation of Connectivity Across a Path
+     4.2.  Sending Probe Packets to Increase the PLPMTU
+     4.3.  Validating the Path with UDP Options
+     4.4.  Probe Packets That Do Not Include Application Data
+     4.5.  Probe Packets That Include Application Data
+   5.  Receiving Events from the Network
+     5.1.  Changes in the Path
+     5.2.  Validation of PTB Messages
+   6.  Examples with Different Receiver Behaviors
+   7.  IANA Considerations
+   8.  Security Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+The User Datagram Protocol (UDP) [RFC0768] offers a minimal transport service on top of IP and is frequently used as a substrate for other protocols. Section 3.2 of UDP Guidelines [RFC8085] recommends that applications implement some form of Path MTU Discovery (PMTUD) to avoid the generation of IP fragments: +

+
+
+

+ユーザー データグラム プロトコル (UDP) [RFC0768] は、IP 上で最小限のトランスポート サービスを提供し、他のプロトコルの基盤として頻繁に使用されます。UDP ガイドライン [RFC8085] のセクション 3.2 では、IP フラグメントの生成を回避するために、アプリケーションが何らかの形式の Path MTU Discovery (PMTUD) を実装することを推奨しています。 +

+
+
+
+
+

+Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself [RFC1191] [RFC1981] [RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation. +

+
+
+

+したがって、アプリケーションは、IP 層によって提供されるパス MTU 情報を使用するか、Path MTU Discovery (PMTUD) 自体 [RFC1191] [RFC1981] [RFC4821] を実装して、宛先へのパスが断片化せずに希望のメッセージ サイズをサポートするかどうかを決定する必要があります (SHOULD)。 +

+
+
+
+
+

+The UDP API [RFC8304] offers calls for applications to receive ICMP Packet Too Big (PTB) messages and to control the maximum size of datagrams that are sent, but it does not offer any automated mechanisms for an application to discover the MPS supported by a path. Upper Layer protocols, which include applications, can implement mechanisms for PMTUD above the UDP API. +

+
+
+

+UDP API [RFC8304] は、アプリケーションが ICMP Packet Too Big (PTB) メッセージを受信し、送信されるデータグラムの最大サイズを制御するための呼び出しを提供しますが、アプリケーションがパスでサポートされている MPS を検出するための自動メカニズムは提供しません。アプリケーションを含む上位層プロトコルは、UDP API の上に PMTUD のメカニズムを実装できます。 +

+
+
+
+
+

+Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] describes a method for a bidirectional Packetization Layer (PL) to search for the largest Packetization Layer PMTU (PLPMTU) supported on a path. DPLPMTUD [RFC8899] specifies this support for datagram transports. PLPMTUD and DPLPMTUD gain robustness by using a probing mechanism that does not solely rely on ICMP PTB messages and works on paths that drop ICMP PTB messages. +

+
+
+

+パケット化層パス MTU 検出 (PLPMTUD) [RFC4821] は、双方向パケット化層 (PL) がパス上でサポートされる最大のパケット化層 PMTU (PLPMTU) を検索する方法を説明しています。DPLPMTUD [RFC8899] は、データグラムトランスポートに対するこのサポートを指定しています。PLPMTUD および DPLPMTUD は、ICMP PTB メッセージのみに依存せず、ICMP PTB メッセージをドロップするパス上で動作するプローブ メカニズムを使用することで堅牢性を実現します。 +

+
+
+
+
+

+UDP Options [RFC9868] supplies functionality that can be used to implement DPLPMTUD within the transport service or in an Upper Layer protocol (including an application) that uses UDP Options. This document specifies how DPLPMTUD using UDP Options is implemented (Section 6.1 of [RFC8899]) and requires support to be enabled at both the sender and receiver. +

+
+
+

+UDP オプション [RFC9868] は、トランスポート サービス内、または UDP オプションを使用する上位層プロトコル (アプリケーションを含む) 内で DPLPMTUD を実装するために使用できる機能を提供します。この文書は、UDP オプションを使用した DPLPMTUD がどのように実装されるかを指定し ([RFC8899] のセクション 6.1)、送信者と受信者の両方でサポートを有効にする必要があります。 +

+
+
+
+
+

+Implementing DPLPMTUD within the transport service above UDP Options avoids the need for each Upper Layer protocol to implement the DPLPMTUD method. It provides a standard method for applications to discover the current MPS for a path and to detect when this changes. It can be used with Equal-Cost Multipath (ECMP) routing and/or multihoming. If multipath or multihoming is supported, a state machine is needed for each path. +

+
+
+

+UDP オプション上のトランスポート サービス内に DPLPMTUD を実装すると、各上位層プロトコルで DPLPMTUD メソッドを実装する必要がなくなります。これは、アプリケーションがパスの現在の MPS を検出し、これがいつ変更されたかを検出するための標準的な方法を提供します。Equal-Cost Multipath (ECMP) ルーティングやマルチホーミングと併用できます。マルチパスまたはマルチホーミングがサポートされている場合は、パスごとにステート マシンが必要です。 +

+
+
+
+
+

+DPLPMTUD is not specified for multicast. The method requires explicit acknowledgement of probe packets provided by UDP Options, which is primarily intended for unicast use (see Section 23 of [RFC9868]). +

+
+
+

+DPLPMTUD はマルチキャストに指定されていません。この方法は、主にユニキャストでの使用を目的とした UDP オプションによって提供されるプローブ パケットの明示的な確認応答を必要とします ([RFC9868] のセクション 23 を参照)。 +

+
+
+
+
+
+2. Terminology +
+
+
+
+2. 用語 +
+
+
+
+
+

+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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。 +

+
+
+
+
+

+This document uses the terms defined for DPLPMTUD (Sections 2 and 5 of [RFC8899]). +

+
+
+

+この文書では、DPLPMTUD ([RFC8899] のセクション 2 および 5) に対して定義された用語を使用します。 +

+
+
+
+
+
+3. DPLPMTUD for UDP Options +
+
+
+
+3. UDP オプションの DPLPMTUD +
+
+
+
+
+

+A UDP Options sender implementing DPLPMTUD uses the method specified in [RFC8899]. In this specification, DPLPMTUD is realized using a pair of UDP Options: the Request (REQ) Option and the Response (RES) Option (Section 11.7 of [RFC9868]). The method also uses the End of Options List (EOL) Option (Section 11.1 of [RFC9868]) to introduce padding to set the size of a probe packet. +

+
+
+

+DPLPMTUD を実装する UDP オプション送信側は、[RFC8899] で指定されたメソッドを使用します。この仕様では、DPLPMTUD は、一対の UDP オプション、つまり要求 (REQ) オプションと応答 (RES) オプションを使用して実現されます ([RFC9868] のセクション 11.7)。このメソッドはまた、オプション リストの終わり (EOL) オプション ([RFC9868] のセクション 11.1) を使用して、プローブ パケットのサイズを設定するためのパディングを導入します。 +

+
+
+
+
+

+Use of DPLPMTUD MUST be explicitly enabled by the application, for instance, once an application has established connectivity and is ready to exchange data with the remote Upper Layer protocol. Similarly, a DPLPMTUD receiver MUST NOT respond to a UDP REQ Option until DPLPMTUD has been enabled. This is to help protect from misuse of the mechanism for other forms of probing. +

+
+
+

+たとえば、アプリケーションが接続を確立し、リモートの上位層プロトコルとデータを交換する準備ができたら、DPLPMTUD の使用をアプリケーションによって明示的に有効にする必要があります。同様に、DPLPMTUD 受信者は、DPLPMTUD が有効になるまで、UDP REQ オプションに応答してはなりません (MUST NOT)。これは、他の形式のプローブのメカニズムの悪用を防ぐために役立ちます。 +

+
+
+
+
+

+Probe packets consume network capacity and incur endpoint processing (Section 4.1 of [RFC8899]). Implementations ought to send a probe packet with a UDP REQ Option only when required by their local DPLPMTUD state machine, i.e., when confirming the base PMTU for the path, probing to increase the PLPMTU, or confirming the current PLPMTU. +

+
+
+

+プローブ パケットはネットワーク容量を消費し、エンドポイント処理が発生します ([RFC8899] のセクション 4.1)。実装では、ローカルの DPLPMTUD ステート マシンで必要な場合、つまり、パスのベース PMTU を確認する場合、PLPMTU を増やすためにプローブする場合、または現在の PLPMTU を確認する場合にのみ、UDP REQ オプションを含むプローブ パケットを送信する必要があります。 +

+
+
+
+
+

+DPLPMTUD can be implemented over UDP Options in two ways: +

+
+
+

+DPLPMTUD は、次の 2 つの方法で UDP オプション上に実装できます。 +

+
+
+
+
+

+* Implementation within the UDP transport service. +

+
+
+

+* UDP トランスポート サービス内での実装。 +

+
+
+
+
+

+* Implementation in an Upper Layer protocol (or application) that uses UDP Options. +

+
+
+

+* UDP オプションを使用する上位層プロトコル (またはアプリケーション) での実装。 +

+
+
+
+
+

+When DPLPMTUD is implemented within the UDP transport service, the DPLPMTUD state machine is responsible for sending probe packets to determine a PLPMTU, as described in this document. This determines an MPS, the largest size of application data block that can be sent across a network path using a single datagram. The Upper Layer protocol is responsible for deciding when a session enables DPLPMTUD. +

+
+
+

+DPLPMTUD が UDP トランスポート サービス内に実装されている場合、DPLPMTUD ステート マシンは、このドキュメントで説明されているように、プローブ パケットを送信して PLPMTU を決定する役割を果たします。これにより、単一のデータグラムを使用してネットワーク パスを介して送信できるアプリケーション データ ブロックの最大サイズである MPS が決まります。上位層プロトコルは、セッションで DPLPMTUD をいつ有効にするかを決定します。 +

+
+
+
+
+

+The discovered PLPMTU can be used to either: +

+
+
+

+検出された PLPMTU は次のいずれかに使用できます。 +

+
+
+
+
+

+* set the maximum datagram size for the current path or +

+
+
+

+* 現在のパスの最大データグラム サイズを設定するか、 +

+
+
+
+
+

+* set the maximum fragment size when a sender uses the UDP Fragmentation Option to divide a datagram into multiple UDP fragments for transmission. The size of each UDP fragment is then less than or equal to the size of the discovered largest IP packet that can be received across the current path. +

+
+
+

+* 送信者が UDP フラグメンテーション オプションを使用してデータグラムを複数の UDP フラグメントに分割して送信する場合の最大フラグメント サイズを設定します。各 UDP フラグメントのサイズは、現在のパスを介して受信できる、検出された最大の IP パケットのサイズ以下になります。 +

+
+
+
+
+

+The figure below shows an implementation of DPLPMTUD within the UDP transport service. It illustrates key interactions between the layers. This design requires an API primitive to allow the application to control whether the DPLPMTUD state machine is enabled for a specific UDP port. By default, this API MUST disable DPLPMTUD processing. +

+
+
+

+次の図は、UDP トランスポート サービス内での DPLPMTUD の実装を示しています。これは、レイヤー間の重要な相互作用を示しています。この設計には、アプリケーションが特定の UDP ポートに対して DPLPMTUD ステート マシンを有効にするかどうかを制御できるようにする API プリミティブが必要です。デフォルトでは、この API は DPLPMTUD 処理を無効にしなければなりません。 +

+
+
+
+
+ 
+   +--------------------------------+
+   |      Upper Layer Protocol      |
+   |         or Application         |
+   +---------------------------+----+
+       ^                       | Messages (with UDP Options)
+       | receive         send  v Primitives for MPS, Min_PMTU, etc.
+   +---+----------------------------+
+   | DPLPMTUD State Machine         |
+   |   Maximum Packet Size (MPS)    |
+   |   PLPMTU, Probed-Size, Min_PMTU|
+   |   Token Values & Probes, etc.  |
+   +---------------------------+----+
+       ^                       | Messages (with UDP Options)
+       |                       |   Send/Receive: Probes with Options
+       | receive         send  v   Events: ICMP, Interface MTU, etc.
+   +---+----------------------------+
+   | UDP Options Transport          |
+   +---------------------------+----+
+       ^                       | Datagrams (with UDP Options)
+       |                       |   Fragmented Datagrams with UDP Options
+       | receive         send  v   Events: ICMP, Interface MTU, etc.
+
+
+
+
+
+

+Note: UDP allows an Upper Layer protocol to send datagrams with or without payload data (with or without UDP Options). These are delivered across the network to the remote Upper Layer. When DPLPMTUD is implemented within the UDP transport service, probe packets that include a REQ or RES UDP Option can be sent with no UDP payload. In this case, these probe packets were not generated by a sending application; therefore, the corresponding received datagrams are not delivered to the remote application. +

+
+
+

+注: UDP を使用すると、上位層プロトコルでペイロード データの有無にかかわらず (UDP オプションの有無にかかわらず) データグラムを送信できます。これらは、ネットワークを介してリモートの上位層に配信されます。DPLPMTUD が UDP トランスポート サービス内に実装されている場合、REQ または RES UDP オプションを含むプローブ パケットは、UDP ペイロードなしで送信できます。この場合、これらのプローブ パケットは送信アプリケーションによって生成されたものではありません。したがって、対応する受信データグラムはリモート アプリケーションに配信されません。 +

+
+
+
+
+

+When DPLPMTUD is instead implemented by an Upper Layer protocol, the format and content of probe packets are determined by the Upper Layer protocol. This design is also permitted to use the REQ and RES Options provided by UDP Options. +

+
+
+

+代わりに DPLPMTUD が上位層プロトコルによって実装される場合、プローブ パケットの形式と内容は上位層プロトコルによって決定されます。このデザインでは、UDP オプションによって提供される REQ および RES オプションの使用も許可されます。 +

+
+
+
+
+

+If DPLPMTUD is active at more than one layer, then the values of the tokens used in REQ Options need to be coordinated with any values used for other DPLPMTUD probe packets to ensure that each probe packet can be identified by a unique token. When configurable, a configuration ought to avoid performing such discovery both within UDP Options and also by an Upper Layer protocol that sends and receives probe packets via UDP Options. Section 6.1 of [RFC8899] recommends that: "An application SHOULD avoid using DPLPMTUD when the underlying transport system provides this capability." +

+
+
+

+DPLPMTUD が複数のレイヤーでアクティブである場合、REQ オプションで使用されるトークンの値は、他の DPLPMTUD プローブ パケットに使用される値と調整して、各プローブ パケットが一意のトークンで識別できるようにする必要があります。構成可能な場合、構成では、UDP オプション内で、また UDP オプションを介してプローブ パケットを送受信する上位層プロトコルによっても、そのような検出を実行することを回避する必要があります。[RFC8899] のセクション 6.1 では、「基盤となるトランスポート システムがこの機能を提供する場合、アプリケーションは DPLPMTUD の使用を避けるべきです (SHOULD)」と推奨しています。 +

+
+
+
+
+
+3.1. Packet Formats +
+
+
+
+3.1. パケットフォーマット +
+
+
+
+
+

+The UDP Options used in this document are described in [RFC9868] and are used in the following ways: +

+
+
+

+この文書で使用される UDP オプションは [RFC9868] で説明されており、次の方法で使用されます。 +

+
+
+
+
+

+* The REQ Option is set by a sending PL to solicit a response from a remote receiver. A four-byte (four-octet) token identifies each request. +

+
+
+

+* REQ オプションは、リモート受信者からの応答を要求するために送信側 PL によって設定されます。4 バイト (4 オクテット) のトークンが各リクエストを識別します。 +

+
+
+
+
+

+* A sending PL can use the EOL Option together with a minimum datagram length to pad probe packets. +

+
+
+

+* 送信側 PL は、EOL オプションを最小データグラム長とともに使用して、プローブ パケットをパディングできます。 +

+
+
+
+
+

+* The RES Option is sent by a UDP Options receiver in response to a previously received REQ Option. Each RES Option echoes the last received four-byte token. +

+
+
+

+* RES オプションは、以前に受信した REQ オプションに応答して UDP オプション受信機によって送信されます。各 RES オプションは、最後に受信した 4 バイトのトークンをエコーします。 +

+
+
+
+
+

+* If a UDP Options endpoint creates and sends a datagram with a RES Option solely as response to a received REQ Option, the responder MUST limit the rate of these responses (e.g., limiting each pair of ports to send 1 per measured RTT or 1 per second). This rate limit is to mitigate the DoS vector without significantly impacting the operation of DPLPMTUD. An example in Section 6 describes a case where this might be used. +

+
+
+

+* UDP オプションのエンドポイントが、受信した REQ オプションへの応答としてのみ RES オプションを含むデータグラムを作成して送信する場合、応答側はこれらの応答のレートを制限しなければなりません (たとえば、ポートの各ペアが測定された RTT ごとに 1 つ、または 1 秒あたり 1 つ送信するように制限する)。このレート制限は、DPLPMTUD の動作に大きな影響を与えることなく、DoS ベクトルを軽減することを目的としています。セクション 6 の例では、これが使用されるケースについて説明します。 +

+
+
+
+
+

+* Reception of a RES Option by the REQ sender confirms that a specific probe packet has been received by the remote UDP Options receiver. +

+
+
+

+* REQ 送信者による RES オプションの受信により、特定のプローブ パケットがリモート UDP オプション受信者によって受信されたことが確認されます。 +

+
+
+
+
+

+The token allows a UDP Options sender to distinguish between acknowledgements for initial probe packets and acknowledgements confirming receipt of subsequent probe packets (e.g., travelling along alternate paths with a larger RTT). Each probe packet MUST be uniquely identifiable by the UDP Options sender within the Maximum Segment Lifetime (MSL) [RFC8085]. The UDP Options sender MUST NOT reuse a token value within the MSL. A four-byte value for the token field provides sufficient space for multiple unique probe packets to be made within the MSL. Since UDP Options operates over UDP, the token values only need to be unique for the specific 5-tuple over which it is operating. +

+
+
+

+このトークンにより、UDP オプションの送信者は、最初のプローブ パケットに対する確認応答と、後続のプローブ パケットの受信を確認する確認応答 (たとえば、より大きな RTT で代替パスに沿って移動する) を区別できるようになります。各プローブ パケットは、最大セグメント ライフタイム (MSL) [RFC8085] 内で UDP オプション送信者によって一意に識別可能でなければなりません (MUST)。UDP オプションの送信者は、MSL 内のトークン値を再利用してはなりません (MUST NOT)。トークン フィールドの 4 バイト値は、MSL 内で作成される複数の一意のプローブ パケットに十分なスペースを提供します。UDP オプションは UDP 上で動作するため、トークン値は、動作している特定の 5 タプルに対して一意である必要があるだけです。 +

+
+
+
+
+

+The value of the four-byte token field SHOULD be initialized to a randomized value to enhance protection from off-path attacks, as described in Section 5.1 of [RFC8085]. +

+
+
+

+[RFC8085]のセクション5.1で説明されているように、オフパス攻撃からの保護を強化するために、4バイトのトークンフィールドの値はランダム化された値に初期化されるべきです(SHOULD)。 +

+
+
+
+
+
+3.2. Sending Probe Packets with the Request Option +
+
+
+
+3.2. リクエスト オプションを使用したプローブ パケットの送信 +
+
+
+
+
+

+DPLPMTUD relies upon sending a probe packet with a specific size. Each probe packet includes the UDP Options area containing a REQ Option and any other required options concluded with an EOL Option (Section 11.1 of [RFC9868]), followed by any padding needed to inflate to the required probe size. +

+
+
+

+DPLPMTUD は、特定のサイズのプローブ パケットの送信に依存します。各プローブ パケットには、REQ オプションと、EOL オプション ([RFC9868] のセクション 11.1) で終了するその他の必要なオプションを含む UDP オプション領域が含まれており、その後に必要なプローブ サイズに拡張するために必要なパディングが続きます。 +

+
+
+
+
+

+A probe packet can therefore be up to the maximum size supported by the local interface (i.e., the Interface MTU). Item 2 in Section 3 of [RFC8899] requires the network interface below DPLPMTUD to provide a way to transmit a probe packet that is larger than the current PLPMTU. The size of this probe packet MUST NOT be constrained by the maximum PMTU set by network layer mechanisms (such as discovered by PMTUD [RFC1191][RFC8201] or the PMTU size held in the IP-layer cache), as noted in item 2 in Section 3 of [RFC8899]). +

+
+
+

+したがって、プローブ パケットは、ローカル インターフェイスでサポートされる最大サイズ (つまり、インターフェイス MTU) にすることができます。[RFC8899] のセクション 3 の項目 2 では、現在の PLPMTU より大きいプローブ パケットを送信する方法を提供するために、DPLPMTUD の下のネットワーク インターフェイスが必要です。このプローブパケットのサイズは、ネットワーク層メカニズムによって設定された最大 PMTU ([RFC8899] のセクション 3 の項目 2 に記載されているように、PMTUD [RFC1191][RFC8201] によって発見されたものや IP 層キャッシュに保持されている PMTU サイズなど) によって制限されてはなりません (MUST NOT)。 +

+
+
+
+
+

+UDP datagrams used as DPLPMTUD probe packets, as described in this document, MUST NOT be fragmented at the UDP or IP layer. Therefore, Section 3 of [RFC8899] requires: "In IPv4, a probe packet MUST be sent with the Don't Fragment (DF) bit set in the IP header and without network layer endpoint fragmentation." +

+
+
+

+この文書で説明されているように、DPLPMTUD プローブ パケットとして使用される UDP データグラムは、UDP 層または IP 層で断片化してはなりません (MUST NOT)。したがって、[RFC8899] のセクション 3 では、「IPv4 では、プローブ パケットは、IP ヘッダーに Don't Fragment (DF) ビットを設定して、ネットワーク層のエンドポイント フラグメンテーションを行わずに送信しなければなりません (MUST)」と規定しています。 +

+
+
+
+
+
+3.3. Receiving UDP Options Probe Packets and Sending the RES Option +
+
+
+
+3.3. UDP オプション プローブ パケットの受信と RES オプションの送信 +
+
+
+
+
+

+When DPLPMTUD is enabled, a UDP Options receiver responds by sending a UDP datagram with the RES Option when it receives a UDP Options datagram with the REQ Option. +

+
+
+

+DPLPMTUD が有効な場合、UDP オプション受信側は、REQ オプション付きの UDP オプション データグラムを受信すると、RES オプション付きの UDP データグラムを送信して応答します。 +

+
+
+
+
+

+The operation of DPLPMTUD can depend on the support at the remote UDP Options endpoint, the way in which DPLPMTUD is implemented, and in some cases, the application data that is exchanged over the UDP transport service. When UDP Options is not supported by the remote receiver, DPLPMTUD will be unable to confirm the path or to discover the PLPMTU. This will result in the minimum configured PLPMTU (MIN_PLPMTU). More explanation of usage is provided in Section 6. +

+
+
+

+DPLPMTUD の動作は、リモート UDP オプション エンドポイントでのサポート、DPLPMTUD の実装方法、および場合によっては UDP トランスポート サービス経由で交換されるアプリケーション データに依存します。UDP オプションがリモート受信側でサポートされていない場合、DPLPMTUD はパスを確認したり、PLPMTU を検出したりできません。これにより、最小構成 PLPMTU (MIN_PLPMTU) が得られます。使用法の詳細についてはセクション 6 で説明します。 +

+
+
+
+
+

+Note: A receiver that only responds when there is a datagram queued for transmission by the Upper Layer could potentially receive multiple datagrams with a REQ Option before it can respond. When sent, the RES Option will only acknowledge the latest received token value. A sender would then conclude that any earlier REQ Options were not successfully received. However, DPLPMTUD does not usually result in sending more than one probe packet per timeout interval, and a delay in responding will already have been treated as a failed probe attempt. Therefore, this does not significantly impact performance, although a more prompt response would have resulted in DPLPMTUD recording reception of all probe packets. +

+
+
+

+注: 上位層による送信のためにキューに入れられたデータグラムがある場合にのみ応答する受信機は、応答する前に REQ オプションを使用して複数のデータグラムを受信する可能性があります。送信時に、RES オプションは最後に受信したトークン値のみを確認します。その後、送信者は、以前の REQ オプションは正常に受信されなかったと結論付けます。ただし、DPLPMTUD では通常、タイムアウト間隔ごとに複数のプローブ パケットが送信されることはなく、応答の遅延はすでにプローブ試行の失敗として扱われています。したがって、これはパフォーマンスに大きな影響を与えませんが、より迅速な応答により、DPLPMTUD はすべてのプローブ パケットの受信を記録することになります。 +

+
+
+
+
+
+4. DPLPMTUD Sender Procedures for UDP Options +
+
+
+
+4. UDP オプションの DPLPMTUD 送信者手順 +
+
+
+
+
+

+DPLPMTUD utilizes three types of probe. These are described in the following sections: +

+
+
+

+DPLPMTUD は 3 種類のプローブを利用します。これらについては、次のセクションで説明します。 +

+
+
+
+
+

+* Probes to confirm the path can support the BASE_PLPMTU (Section 5.1.4 of [RFC8899]). +

+
+
+

+* パスが BASE_PLPMTU をサポートできることを確認するためのプローブ ([RFC8899] のセクション 5.1.4)。 +

+
+
+
+
+

+* Probes to detect whether the path can support a larger PLPMTU. +

+
+
+

+* パスがより大きな PLPMTU をサポートできるかどうかを検出するためのプローブ。 +

+
+
+
+
+

+* Probes to validate that the path supports the current PLPMTU. +

+
+
+

+* パスが現在の PLPMTU をサポートしていることを検証するためのプローブ。 +

+
+
+
+
+
+4.1. Confirmation of Connectivity Across a Path +
+
+
+
+4.1. パス間の接続の確認 +
+
+
+
+
+

+The DPLPMTUD method requires a PL to confirm connectivity over the path (Section 5.1.4 of [RFC8899]), but UDP itself does not offer a mechanism for this. +

+
+
+

+DPLPMTUD メソッドでは、PL がパス上の接続を確認する必要があります ([RFC8899] のセクション 5.1.4) が、UDP 自体はこれのためのメカニズムを提供しません。 +

+
+
+
+
+

+UDP Options can provide this required functionality. A UDP Options sender implementing this specification MUST elicit a positive confirmation of connectivity for the path by sending a probe packet padded to size BASE_PLPMTU. This confirmation probe MUST include the REQ UDP Option to elicit a response from the remote DPLPMTUD. Reception of a datagram with the corresponding RES Option confirms the reception of a packet of the probed size that has successfully traversed the path to the receiver. This also confirms that the remote endpoint supports the RES Option. +

+
+
+

+UDP オプションは、この必要な機能を提供できます。この仕様を実装する UDP オプション送信者は、サイズ BASE_PLPMTU にパディングされたプローブ パケットを送信することによって、パスの接続性の肯定的な確認を引き出しなければなりません (MUST)。この確認プローブには、リモート DPLPMTUD からの応答を引き出すための REQ UDP オプションが含まれなければなりません (MUST)。対応する RES オプションを使用してデータグラムを受信すると、受信者へのパスを正常に通過した、調査されたサイズのパケットの受信が確認されます。これにより、リモート エンドポイントが RES オプションをサポートしていることも確認されます。 +

+
+
+
+
+
+4.2. Sending Probe Packets to Increase the PLPMTU +
+
+
+
+4.2. PLPMTU を増やすためのプローブ パケットの送信 +
+
+
+
+
+

+From time to time, DPLPMTUD enters the SEARCHING state, described in Section 5.2 of [RFC8899], (e.g., after expiry of the PMTU_RAISE_TIMER) to detect whether the current path can support a larger PLPMTU. When the remote endpoint advertises a UDP Maximum Datagram Size (MDS) Option (see Section 11.5 of [RFC9868]), this value MAY be used as a hint to initialize this search to increase the PLPMTU. +

+
+
+

+時折、DPLPMTUD は [RFC8899] のセクション 5.2 で説明されている SEARCHING 状態に入り (例: PMTU_RAISE_TIMER の期限切れ後)、現在のパスがより大きな PLPMTU をサポートできるかどうかを検出します。リモートエンドポイントが UDP 最大データグラムサイズ (MDS) オプション ([RFC9868] のセクション 11.5 を参照) をアドバタイズする場合、この値は、PLPMTU を増やすためにこの検索を初期化するためのヒントとして使用されてもよい(MAY)。 +

+
+
+
+
+

+Probe packets seeking to increase the PLPMTU SHOULD NOT carry application data (see "Probing using padding data" in Section 4.1 of [RFC8899]), since they will be lost whenever their size exceeds the actual PMTU. [RFC8899] requires a probe packet to elicit a positive acknowledgement that the path has delivered a datagram of the specific probed size; therefore, a probe packet MUST include the REQ Option when using transport options for UDP [RFC9868]. +

+
+
+

+PLPMTU を増加しようとするプローブ パケットは、サイズが実際の PMTU を超えるたびに失われるため、アプリケーション データを伝送すべきではありません ([RFC8899] のセクション 4.1 の「パディング データを使用したプローブ」を参照)。[RFC8899] では、パスが特定のプローブされたサイズのデータグラムを配信したという肯定的な確認応答を引き出すためにプローブ パケットを要求しています。したがって、UDP [RFC9868] のトランスポート オプションを使用する場合、プローブ パケットには REQ オプションが含まれなければなりません (MUST)。 +

+
+
+
+
+

+At the receiver, a received probe packet that does not carry application data does not form a part of the end-to-end transport data and is not delivered to the Upper Layer protocol (i.e., application or protocol layered above UDP). A zero-length payload notification could still be delivered to the application (see Section 5 of [RFC8085]), although Section 18 of [RFC9868] discusses the implications when using UDP Options. +

+
+
+

+受信側では、アプリケーション データを伝送しない受信プローブ パケットは、エンドツーエンドのトランスポート データの一部を形成せず、上位層プロトコル (つまり、UDP の上層にあるアプリケーションまたはプロトコル) に配信されません。[RFC9868] のセクション 18 では、UDP オプションを使用する場合の影響について説明していますが、長さゼロのペイロード通知は依然としてアプリケーションに配信される可能性があります ([RFC8085] のセクション 5 を参照)。 +

+
+
+
+
+
+4.3. Validating the Path with UDP Options +
+
+
+
+4.3. UDP オプションを使用したパスの検証 +
+
+
+
+
+

+A PL using DPLPMTUD MUST validate that a path continues to support the PLPMTU discovered in a previous search for a suitable PLPMTU value, as defined in Section 6.1.4 of [RFC8899]. This validation sends probe packets in the DPLPMTUD SEARCH_COMPLETE state (Section 5.2 of [RFC8899]) to detect black-holing of data (Section 4.3 of [RFC8899] defines a DPLPMTUD black hole). +

+
+
+

+DPLPMTUD を使用する PL は、[RFC8899] のセクション 6.1.4 で定義されているように、適切な PLPMTU 値の以前の検索で発見された PLPMTU をパスが引き続きサポートしていることを検証しなければなりません (MUST)。この検証は、データのブラックホールを検出するために DPLPMTUD SEARCH_COMPLETE 状態 ([RFC8899] のセクション 5.2) でプローブ パケットを送信します ([RFC8899] のセクション 4.3 は DPLPMTUD ブラック ホールを定義しています)。 +

+
+
+
+
+

+Path validation can be implemented within UDP Options by generating a probe packet of size PLPMTU, which MUST include a REQ Option to elicit a positive confirmation that the path has delivered this probe packet. A probe packet used to validate the path MAY use either "Probing using padding data" to construct a probe packet that does not carry any application data or "Probing using application data and padding data"; see Section 4.1 of [RFC8899]. When using "Probing using padding data", the UDP Options API does not indicate receipt of the zero-length probe packet (see Section 6 of [RFC9868]). +

+
+
+

+パス検証は、サイズ PLPMTU のプローブ パケットを生成することで UDP オプション内で実装できます。これには、パスがこのプローブ パケットを配信したという肯定的な確認を引き出すための REQ オプションが含まれなければなりません。パスの検証に使用されるプローブ パケットは、アプリケーション データを運ばないプローブ パケットを構築するために「パディング データを使用したプローブ」、または「アプリケーション データとパディング データを使用したプローブ」のいずれかを使用してもよい(MAY)。[RFC8899] のセクション 4.1 を参照してください。「パディングデータを使用したプローブ」を使用する場合、UDP オプション API は長さゼロのプローブパケットの受信を示しません ([RFC9868] のセクション 6 を参照)。 +

+
+
+
+
+
+4.4. Probe Packets That Do Not Include Application Data +
+
+
+
+4.4. アプリケーション データを含まないパケットの調査 +
+
+
+
+
+

+A simple implementation of the method might be designed to only use probe packets in a UDP datagram that includes no application data. The size of each probe packet is padded to the required probe size including the REQ Option. This implements "Probing using padding data" (Section 4.1 of [RFC8899]) and avoids having to retransmit application data when a probe fails. This could be achieved by setting a minimum datagram length, such that the options list ends in EOL (Section 11.1 of [RFC9868]) with any additional space zero-filled as needed (see Section 15 of [RFC9868]). In this use, the probe packets do not form a part of the end-to-end transport data and a receiver does not deliver them to the Upper Layer protocol. +

+
+
+

+このメソッドの単純な実装は、アプリケーション データを含まない UDP データグラム内のプローブ パケットのみを使用するように設計される場合があります。各プローブ パケットのサイズは、REQ オプションを含む必要なプローブ サイズにパディングされます。これにより、「パディング データを使用したプローブ」([RFC8899] のセクション 4.1) が実装され、プローブが失敗した場合にアプリケーション データを再送信する必要がなくなります。これは、オプションリストが EOL ([RFC9868] のセクション 11.1) で終了し、必要に応じて追加のスペースにゼロが埋められるように、データグラムの最小長を設定することで実現できます ([RFC9868] のセクション 15 を参照)。この使用法では、プローブ パケットはエンドツーエンドのトランスポート データの一部を形成せず、受信機はそれらを上位層プロトコルに配信しません。 +

+
+
+
+
+
+4.5. Probe Packets That Include Application Data +
+
+
+
+4.5. アプリケーション データを含むパケットの調査 +
+
+
+
+
+

+An implementation always uses the format in Section 4.4 when DPLPMTUD searches to increase the PLPMTU. +

+
+
+

+DPLPMTUD が PLPMTU を増やすために検索する場合、実装では常にセクション 4.4 の形式が使用されます。 +

+
+
+
+
+

+An alternative format is permitted for a probe packet that is used to confirm the connectivity or to validate the path. These probe packets MAY carry application data. (UDP payload data is permitted because these probe packets perform black-hole detection and will therefore usually have a higher probability of successful transmission, similar to other packets sent by the Upper Layer protocol.) Section 4.1 of [RFC8899] provides a discussion of the merits and demerits of including application data. For example, this reduces the need to send additional datagrams. +

+
+
+

+接続性の確認またはパスの検証に使用されるプローブ パケットには、代替フォーマットが許可されています。これらのプローブ パケットはアプリケーション データを伝送してもよい(MAY)。(UDP ペイロード データが許可されるのは、これらのプローブ パケットがブラック ホール検出を実行するため、通常、上位層プロトコルによって送信される他のパケットと同様に、送信が成功する確率が高くなります。) [RFC8899] のセクション 4.1 では、アプリケーション データを含めることの長所と短所について説明しています。たとえば、これにより追加のデータグラムを送信する必要性が減ります。 +

+
+
+
+
+

+This type of probe packet MAY use a control message format defined by the Upper Layer protocol, provided that the message does not need to be delivered reliably. The REQ Option MUST be included when the sending Upper Layer protocol performs DPLPMTUD. The DPLPMTUD method tracks the transmission of probe packets (using the REQ Option token). +

+
+
+

+このタイプのプローブ パケットは、メッセージを確実に配信する必要がない場合、上位層プロトコルで定義された制御メッセージ フォーマットを使用してもよい(MAY)。REQ オプションは、送信側上位層プロトコルが DPLPMTUD を実行するときに含める必要があります。DPLPMTUD メソッドは、(REQ オプション トークンを使用して) プローブ パケットの送信を追跡します。 +

+
+
+
+
+

+A receiver that responds to DPLPMTUD MUST process the REQ Option and include the corresponding RES Option with an Upper Layer protocol message that it returns to the requester (examples of receiver processing are provided in Section 6). +

+
+
+

+DPLPMTUD に応答する受信者は、REQ オプションを処理し、要求者に返す上位層プロトコル メッセージに対応する RES オプションを含めなければなりません (受信者の処理の例はセクション 6 で提供されます)。 +

+
+
+
+
+

+Probe packets that use this format form a part of the end-to-end transport data and can be used to manage the PLPMTU in just one direction or can be used for both directions. +

+
+
+

+この形式を使用するプローブ パケットは、エンドツーエンドのトランスポート データの一部を形成し、一方向のみで PLPMTU を管理するために使用することも、両方向に使用することもできます。 +

+
+
+
+
+
+5. Receiving Events from the Network +
+
+
+
+5. ネットワークからのイベントの受信 +
+
+
+
+
+

+This specification does not rely upon reception of events from the network, but an implementation can utilize these events when they are provided. +

+
+
+

+この仕様はネットワークからのイベントの受信には依存しませんが、実装ではこれらのイベントが提供されたときにそれを利用できます。 +

+
+
+
+
+
+5.1. Changes in the Path +
+
+
+
+5.1. パスの変更 +
+
+
+
+
+

+A change in the path or the loss of a probe packet can result in DPLPMTUD updating the PLPMTU. DPLPMTUD [RFC8899] recommends that methods are robust to path changes that could have occurred since the path characteristics were last confirmed and to the possibility of inconsistent path information being received. For example, a notification that a path has changed could trigger path validation to provide black-hole protection (Section 4.3 of [RFC8899]). +

+
+
+

+パスの変更またはプローブ パケットの損失により、DPLPMTUD が PLPMTU を更新する可能性があります。DPLPMTUD [RFC8899] は、パス特性が最後に確認されてから発生した可能性のあるパス変更や、受信される一貫性のないパス情報の可能性に対して、方法が堅牢であることを推奨しています。たとえば、パスが変更されたという通知は、ブラックホール保護を提供するためにパスの検証をトリガーできます ([RFC8899] のセクション 4.3)。 +

+
+
+
+
+

+An Upper Layer protocol could trigger DPLPMTUD to validate the path when it observes a high packet loss rate (or a repeated protocol timeout) [RFC8899]. +

+
+
+

+上位層プロトコルは、高いパケット損失率 (またはプロトコル タイムアウトの繰り返し) [RFC8899] を観察した場合に、DPLPMTUD をトリガーしてパスを検証する可能性があります。 +

+
+
+
+
+

+Section 3 of [RFC8899] requires any methods designed to share the PLPMTU between PLs (such as updating the IP cache PMTU for an interface/destination) to be robust to the wide variety of underlying network forwarding behaviors. For example, an implementation could avoid sharing PMTU information that could potentially relate to packets sent with the same address over a different interface. +

+
+
+

+[RFC8899] のセクション 3 では、基盤となるさまざまなネットワーク転送動作に対して堅牢であるために、PL 間で PLPMTU を共有するように設計された方法 (インターフェイス/宛先の IP キャッシュ PMTU の更新など) を要求しています。たとえば、実装では、異なるインターフェイスを介して同じアドレスで送信されたパケットに関連する可能性がある PMTU 情報の共有を回避できます。 +

+
+
+
+
+
+5.2. Validation of PTB Messages +
+
+
+
+5.2. PTB メッセージの検証 +
+
+
+
+
+

+Support for receiving ICMP PTB messages is OPTIONAL for DPLPMTUD. A UDP Options sender can therefore ignore received ICMP PTB messages. +

+
+
+

+ICMP PTB メッセージの受信のサポートは、DPLPMTUD ではオプションです。したがって、UDP オプションの送信者は、受信した ICMP PTB メッセージを無視できます。 +

+
+
+
+
+

+Before processing an ICMP PTB message, the DPLPMTUD method needs to perform two checks to ensure that the message was received in response to a sent probe packet: +

+
+
+

+ICMP PTB メッセージを処理する前に、DPLPMTUD メソッドは 2 つのチェックを実行して、送信されたプローブ パケットに対する応答としてメッセージが受信されたことを確認する必要があります。 +

+
+
+
+
+

+* DPLPMTUD first utilizes the quoted information in each PTB message. The receiver MUST validate the protocol information in the quoted packet carried in an ICMP PTB message payload to validate the message originated from the sending node (see Section 4.6.1 of [RFC8899]). +

+
+
+

+* DPLPMTUD は、まず各 PTB メッセージ内で引用された情報を利用します。受信者は、送信ノードから発信されたメッセージを検証するために、ICMP PTB メッセージ ペイロードで運ばれる引用パケット内のプロトコル情報を検証しなければなりません ([RFC8899] のセクション 4.6.1 を参照)。 +

+
+
+
+
+

+* The receiver SHOULD utilize information that is not simple for an off-path attacker to determine (see Section 4.6.1 of [RFC8899]). Specifically, a UDP Options receiver SHOULD confirm that the token contained in the UDP REQ Option of the quoted packet has a value that corresponds to a probe packet that was recently sent by the current endpoint. +

+
+
+

+* 受信者は、オフパス攻撃者にとって判断が容易ではない情報を利用すべきである(SHOULD)([RFC8899]のセクション4.6.1を参照)。具体的には、UDP オプション受信者は、引用されたパケットの UDP REQ オプションに含まれるトークンが、現在のエンドポイントによって最近送信されたプローブ パケットに対応する値を持つことを確認する必要があります (SHOULD)。 +

+
+
+
+
+

+An implementation unable to support this validation MUST ignore received ICMP PTB messages. +

+
+
+

+この検証をサポートできない実装は、受信した ICMP PTB メッセージを無視しなければなりません (MUST)。 +

+
+
+
+
+
+6. Examples with Different Receiver Behaviors +
+
+
+
+6. さまざまな受信機の動作の例 +
+
+
+
+
+

+When enabled, a DPLPMTUD endpoint that implements UDP Options normally responds with a UDP datagram with a RES Option when requested by a sender. +

+
+
+

+有効にすると、UDP オプションを実装する DPLPMTUD エンドポイントは、通常、送信者から要求されたときに、RES オプションを含む UDP データグラムで応答します。 +

+
+
+
+
+

+The following examples describe various possible receiver behaviors: +

+
+
+

+次の例は、考えられるさまざまな受信機の動作を説明しています。 +

+
+
+
+
+

+* No DPLPMTUD receiver support: One case is when a sender supports this specification, but no RES Option is received from the remote endpoint. In this example, the method is unable to discover the PLPMTU. This will result in using the MIN_PLPMTU. Such a remote endpoint might be not configured to process UDP Options or might not return a datagram with a RES Option for some other reason (e.g., packet loss, insufficient space to include the option, filtering on the path, etc.). +

+
+
+

+* DPLPMTUD 受信側サポートなし: 1 つのケースは、送信側がこの仕様をサポートしているが、リモート エンドポイントから RES オプションを受信しない場合です。この例では、メソッドは PLPMTU を検出できません。これにより、MIN_PLPMTU が使用されます。このようなリモート エンドポイントは、UDP オプションを処理するように構成されていない可能性や、他の理由 (例: パケット損失、オプションを含めるスペースの不足、パス上のフィルタリングなど) により RES オプションを含むデータグラムを返さない可能性があります。 +

+
+
+
+
+

+* DPLPMTUD receiver uses application datagrams: In a second case, both the sender and receiver support DPLPMTUD using the specification, and the receiver only returns a RES Option with the next UDP datagram that is sent to the requester. Therefore, reception of a REQ Option does not systematically trigger a response. This allows DPLPMTUD to operate when there is a flow of datagrams in both directions, provided there is periodic feedback (e.g., one acknowledgement packet per RTT). It requires the PLPMTU at the receiver to be sufficiently large enough that the RES Option can be included in the feedback packets that are sent in the return direction. This method avoids opportunities to misuse the method as a DoS attack. However, when there is a low rate of transmission (or no datagrams are sent) in the return direction, this will prevent prompt delivery of the RES Option. At the DPLPMTUD sender, this results in probe packets failing to be acknowledged in time and could result in a smaller PLPMTU than is actually supported by the path or in using the MIN_PLPMTU. +

+
+
+

+* DPLPMTUD 受信者はアプリケーション データグラムを使用します。2 番目のケースでは、送信者と受信者の両方が仕様を使用して DPLPMTUD をサポートし、受信者はリクエスターに送信される次の UDP データグラムとともに RES オプションのみを返します。したがって、REQ オプションの受信は体系的に応答をトリガーしません。これにより、定期的なフィードバック (例: RTT ごとに 1 つの確認パケット) がある場合、両方向のデータグラム フローがある場合に DPLPMTUD が動作できるようになります。戻り方向に送信されるフィードバック パケットに RES オプションを含めることができるように、受信側の PLPMTU が十分に大きいことが必要です。この方法により、この方法が DoS 攻撃として悪用される機会が回避されます。ただし、戻り方向の送信速度が低い (またはデータグラムが送信されない) 場合、RES オプションの迅速な配信が妨げられます。これにより、DPLPMTUD 送信側でプローブ パケットが時間内に確認応答されなくなり、パスまたは MIN_PLPMTU の使用で実際にサポートされるよりも PLPMTU が小さくなる可能性があります。 +

+
+
+
+
+

+* Unidirectional transfer: Another case is where an application only transfers data in one direction (or predominantly in one direction). In this case, the wait at the receiver for a datagram to be queued before returning a RES Option could easily result in a probe timeout at the DPLPMTUD sender. In this case, DPLPMTUD could allow exchanging datagrams without a payload (as discussed in earlier sections) to return the RES Option. +

+
+
+

+* 単方向転送: アプリケーションがデータを一方向のみ (または主に一方向) に転送するもう 1 つのケースがあります。この場合、RES オプションを返す前にデータグラムがキューに入れられるまで受信側で待機すると、DPLPMTUD 送信側でプローブ タイムアウトが簡単に発生する可能性があります。この場合、DPLPMTUD により、(前のセクションで説明したように) ペイロードなしでデータグラムを交換して RES オプションを返すことができます。 +

+
+
+
+
+

+* DPLPMTUD receiver permitted to send responses in UDP datagrams with no payload: A DPLPMTUD receiver can generate a datagram (e.g., with zero payload data) solely to return a RES Option (e.g., sent when no other datagrams are queued for transmission). This would allow an endpoint to probe the set of UDP ports that have been configured with support for this specification using a DPLPMTUD probe packet. Although this results in some additional traffic overhead, it has the advantage that it can ensure timely progress of DPLPMTUD. Section 3.1 specifies: "If a UDP Options endpoint creates and sends a datagram with a RES Option solely as response to a received REQ Option, the responder MUST limit the rate of these responses (e.g., limiting each pair of ports to send 1 per measured RTT or 1 per second)". This rate limit is to mitigate the DoS vector, without significantly impacting the operation of DPLPMTUD. +

+
+
+

+* DPLPMTUD 受信機は、ペイロードのない UDP データグラムで応答を送信することを許可されています: DPLPMTUD 受信機は、RES オプションを返すためだけにデータグラム (たとえば、ペイロード データがゼロ) を生成できます (たとえば、他のデータグラムが送信のためにキューに入れられていないときに送信されます)。これにより、エンドポイントは、DPLPMTUD プローブ パケットを使用して、この仕様をサポートするように構成された UDP ポートのセットをプローブできるようになります。これにより、追加のトラフィック オーバーヘッドが発生しますが、DPLPMTUD をタイムリーに進行させることができるという利点があります。セクション 3.1 では、「UDP オプションのエンドポイントが、受信した REQ オプションへの応答としてのみ RES オプションを含むデータグラムを作成して送信する場合、レスポンダーはこれらの応答のレートを制限しなければなりません (例: 測定された RTT ごとに 1 つ、または 1 秒あたり 1 つ送信するようにポートの各ペアを制限する)」と規定されています。このレート制限は、DPLPMTUD の動作に大きな影響を与えることなく、DoS ベクトルを軽減することを目的としています。 +

+
+
+
+
+
+7. IANA Considerations +
+
+
+
+7. IANAの考慮事項 +
+
+
+
+
+

+This document has no IANA actions. +

+
+
+

+この文書には IANA のアクションはありません。 +

+
+
+
+
+
+8. Security Considerations +
+
+
+
+8. セキュリティに関する考慮事項 +
+
+
+
+
+

+The security considerations for using UDP Options are described in [RFC9868]. The method does not change the integrity protection offered by the UDP Options method. +

+
+
+

+UDP オプションを使用する場合のセキュリティに関する考慮事項は、[RFC9868] で説明されています。このメソッドは、UDP オプション メソッドによって提供される整合性保護を変更しません。 +

+
+
+
+
+

+The security considerations for using DPLPMTUD are described in [RFC8899]. On-path attackers could maliciously drop or modify probe packets to seek to decrease the PMTU or to maliciously modify probe packets in an attempt to black-hole traffic. +

+
+
+

+DPLPMTUD を使用する場合のセキュリティに関する考慮事項は [RFC8899] で説明されています。パス上の攻撃者は、PMTU を減少させようとしてプローブ パケットを悪意を持ってドロップまたは変更したり、トラフィックをブラックホール化するためにプローブ パケットを悪意を持って変更したりする可能性があります。 +

+
+
+
+
+

+The specification recommends that the token value in the REQ Option is initialized to a randomized value. This is to enhance protection from off-path attacks. If a subsequent probe packet uses a token value that is easily derived from the initial value (e.g., incrementing the value), a misbehaving on-path observer could then determine the token values used for subsequent probe packets from that sender, even if these probe packets are not transiting via the observer. This would allow probe packets to be forged, with an impact similar to other on-path attacks against probe packets. This attack could be mitigated by using an unpredictable token value for each probe packet. +

+
+
+

+仕様では、REQ オプションのトークン値をランダムな値に初期化することが推奨されています。これは、オフパス攻撃からの保護を強化するためです。後続のプローブ パケットが初期値から容易に導出されるトークン値を使用する場合 (値をインクリメントするなど)、不正な動作を行うオンパス オブザーバーは、たとえこれらのプローブ パケットがオブザーバーを経由していない場合でも、その送信者からの後続のプローブ パケットに使用されるトークン値を決定する可能性があります。これにより、プローブ パケットが偽造される可能性があり、プローブ パケットに対する他のパス上の攻撃と同様の影響が生じます。この攻撃は、各プローブ パケットに予測不可能なトークン値を使用することで軽減できる可能性があります。 +

+
+
+
+
+

+The method does not change the ICMP PTB message validation method described by DPLPMTUD: A UDP Options sender that utilizes ICMP PTB messages received to a probe packet MUST use the quoted packet to validate the UDP port information in combination with the token contained in the UDP Option before processing the packet using the DPLPMTUD method. +

+
+
+

+このメソッドは、DPLPMTUD で説明されている ICMP PTB メッセージ検証メソッドを変更しません。プローブ パケットに対して受信した ICMP PTB メッセージを利用する UDP オプション送信者は、DPLPMTUD メソッドを使用してパケットを処理する前に、引用符付きパケットを使用して、UDP オプションに含まれるトークンと組み合わせて UDP ポート情報を検証しなければなりません (MUST)。 +

+
+
+
+
+

+Upper Layer protocols or applications that employ encryption ought to perform DPLPMTUD at a layer above UDP Options and not enable UDP Options support for DPLPMTUD. This allows the application to control when DPLPMTUD is used to control the additional traffic that this generates. This also ensures that DPLPMTUD probe packets are encrypted. +

+
+
+

+暗号化を使用する上位層のプロトコルまたはアプリケーションは、UDP オプションより上の層で DPLPMTUD を実行する必要があり、DPLPMTUD に対する UDP オプションのサポートを有効にしないでください。これにより、アプリケーションは、生成される追加トラフィックを制御するために DPLPMTUD を使用するタイミングを制御できるようになります。これにより、DPLPMTUD プローブ パケットが確実に暗号化されます。 +

+
+
+
+
+
+9. References +
+
+
+
+9. 参考文献 +
+
+
+
+
+
+9.1. Normative References +
+
+
+
+9.1. 引用文献 +
+
+
+
+
+ 
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              DOI 10.17487/RFC0768, August 1980,
+              <https://www.rfc-editor.org/info/rfc768>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC8899]  Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
+              Völker, "Packetization Layer Path MTU Discovery for
+              Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
+              September 2020, <https://www.rfc-editor.org/info/rfc8899>.
+
+
+
+
+
+ 
+   [RFC9868]  Touch, J. and C. Heard, Ed., "Transport Options for UDP",
+              RFC 9868, DOI 10.17487/RFC9868, October 2025,
+              <https://www.rfc-editor.org/info/rfc9868>.
+
+
+
+
+
+
+9.2. Informative References +
+
+
+
+9.2. 参考引用 +
+
+
+
+
+ 
+   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+              DOI 10.17487/RFC1191, November 1990,
+              <https://www.rfc-editor.org/info/rfc1191>.
+
+
+
+
+
+ 
+   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
+              <https://www.rfc-editor.org/info/rfc4821>.
+
+
+
+
+
+ 
+   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
+              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
+              March 2017, <https://www.rfc-editor.org/info/rfc8085>.
+
+
+
+
+
+ 
+   [RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
+              "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
+              DOI 10.17487/RFC8201, July 2017,
+              <https://www.rfc-editor.org/info/rfc8201>.
+
+
+
+
+
+ 
+   [RFC8304]  Fairhurst, G. and T. Jones, "Transport Features of the
+              User Datagram Protocol (UDP) and Lightweight UDP (UDP-
+              Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,
+              <https://www.rfc-editor.org/info/rfc8304>.
+
+
+
+
+
+
+Acknowledgements +
+
+
+
+謝辞 +
+
+
+
+
+

+Gorry Fairhurst and Tom Jones are supported by funding provided by the University of Aberdeen. The authors would like to thank Magnus Westerlund and Mohamed Boucadair for their detailed comments and also other people who contributed to completing this document. +

+
+
+

+ゴリー・フェアハーストとトム・ジョーンズは、アバディーン大学から提供された資金によってサポートされています。著者らは、詳細なコメントを寄せてくれた Magnus Westerlund と Mohamed Boucadair、そしてこの文書の完成に貢献した他の人々に感謝の意を表します。 +

+
+
+
+
+
+Authors' Addresses +
+
+
+
+著者の住所 +
+
+
+
+
+ 
+   Godred Fairhurst
+   University of Aberdeen
+   School of Engineering
+   Fraser Noble Building
+   Aberdeen
+   AB24 3UE
+   United Kingdom
+   Email: gorry@erg.abdn.ac.uk
+
+
+
+
+
+ 
+   Tom Jones
+   University of Aberdeen
+   School of Engineering
+   Fraser Noble Building
+   Aberdeen
+   AB24 3UE
+   United Kingdom
+   Email: tom@erg.abdn.ac.uk
+
+
+
+
+ + + diff --git a/html/rfc9870.html b/html/rfc9870.html new file mode 100644 index 000000000..33819314f --- /dev/null +++ b/html/rfc9870.html @@ -0,0 +1,2224 @@ + + + + + + RFC 9870 - Export of UDP Options Information in IP Flow Information Export (IPFIX) 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)                      M. Boucadair
+Request for Comments: 9870                                        Orange
+Category: Standards Track                                     T. Reddy.K
+ISSN: 2070-1721                                                    Nokia
+                                                            October 2025
+
+
+
+
+
+
+Export of UDP Options Information in IP Flow Information Export (IPFIX) +
+
+
+
+IP フロー情報エクスポート (IPFIX) での UDP オプション情報のエクスポート +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP Options. +

+
+
+

+この文書では、UDP オプションの新しい IP フロー情報エクスポート (IPFIX) 情報要素を指定します。 +

+
+
+
+
+
+Status of This Memo +
+
+
+
+本文書の位置付け +
+
+
+
+
+

+This is an Internet Standards Track document. +

+
+
+

+これはインターネット標準化トラックの文書です。 +

+
+
+
+
+

+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 Internet Standards is available in Section 2 of RFC 7841. +

+
+
+

+このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、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/rfc9870. +

+
+
+

+この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9870 で入手できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+Copyright (c) 2025 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+   2.  Conventions and Definitions
+   3.  UDP Options at a Glance
+   4.  New UDP IPFIX Information Elements
+     4.1.  udpSafeOptions
+     4.2.  udpUnsafeOptions
+     4.3.  udpExID
+     4.4.  udpSafeExIDList
+     4.5.  udpUnsafeExIDList
+   5.  Examples
+     5.1.  Reduced-Size Encoding
+     5.2.  SAFE Experimental Option
+     5.3.  ExIDs and Reduced-Size Encoding
+   6.  Security Considerations
+   7.  IANA Considerations
+     7.1.  IPFIX Information Elements
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+IP Flow Information Export (IPFIX) [RFC7011] is a protocol that is widely deployed in networks for traffic management purposes (Section 2 of [RFC6632]). The protocol specifies the encoding of a set of basic data types and how the various Information Elements (IEs) are transmitted. In order to support the export of new Flow-related measurement data, new IEs can be defined and registered in a dedicated IANA registry [IANA-IPFIX] for interoperability. +

+
+
+

+IP フロー情報エクスポート (IPFIX) [RFC7011] は、トラフィック管理の目的でネットワークに広く導入されているプロトコルです ([RFC6632] のセクション 2)。このプロトコルは、一連の基本データ型のエンコーディングと、さまざまな情報要素 (IE) の送信方法を指定します。新しいフロー関連の測定データのエクスポートをサポートするために、新しい IE を定義し、相互運用性を確保する専用の IANA レジストリ [IANA-IPFIX] に登録できます。 +

+
+
+
+
+

+This document specifies new IPFIX Information Elements for UDP Options (Section 4). A brief overview of UDP Options is provided in Section 3. +

+
+
+

+この文書では、UDP オプションの新しい IPFIX 情報要素を指定します (セクション 4)。UDP オプションの簡単な概要はセクション 3 で説明されています。 +

+
+
+
+
+

+The IE specified in Section 4.1 uses the new abstract data type ("unsigned256") defined in [RFC9740]. +

+
+
+

+セクション 4.1 で規定されている IE は、[RFC9740] で定義されている新しい抽象データ型 ("unsigned256") を使用します。 +

+
+
+
+
+

+Transport (including MTU) considerations are discussed in Section 10 of [RFC7011]. +

+
+
+

+トランスポート (MTU を含む) に関する考慮事項は、[RFC7011] のセクション 10 で説明されています。 +

+
+
+
+
+

+Examples to illustrate the use of the new IPFIX Information Elements are provided in Section 5. +

+
+
+

+新しい IPFIX 情報要素の使用例をセクション 5 に示します。 +

+
+
+
+
+
+2. Conventions and Definitions +
+
+
+
+2. 規則と定義 +
+
+
+
+
+

+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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。 +

+
+
+
+
+

+This document uses the IPFIX-specific terminology (e.g., Flow) defined in Section 2 of [RFC7011]. As in the base IPFIX specification [RFC7011], these IPFIX-specific terms have the first letter of a word capitalized. +

+
+
+

+この文書では、[RFC7011] のセクション 2 で定義されている IPFIX 固有の用語 (例: フロー) を使用します。基本 IPFIX 仕様 [RFC7011] と同様、これらの IPFIX 固有の用語では、単語の最初の文字が大文字になります。 +

+
+
+
+
+

+The document adheres to the naming conventions for Information Elements per Section 2.3 of [RFC7012]. +

+
+
+

+この文書は、[RFC7012] のセクション 2.3 に基づく情報要素の命名規則に準拠しています。 +

+
+
+
+
+

+Also, this document uses the terms defined in Section 3 of [RFC9868], especially "datagram" and "surplus area". +

+
+
+

+また、この文書では、[RFC9868] のセクション 3 で定義されている用語、特に「データグラム」と「余剰領域」を使用します。 +

+
+
+
+
+
+3. UDP Options at a Glance +
+
+
+
+3. UDP オプションの概要 +
+
+
+
+
+

+UDP [RFC0768] does not support an extension mechanism similar to the options supported by other transport protocols, such as TCP [RFC9293], Stream Control Transmission Protocol (SCTP) [RFC9260], or Datagram Congestion Control Protocol (DCCP) [RFC4340]. Such a mechanism can be useful for various applications, e.g., to discover a path MTU or share timestamps. To fill that void, [RFC9868] extends UDP with a mechanism to insert extensions in datagrams. To do so, and unlike the conventional approach that relies upon transport headers, [RFC9868] uses trailers. Concretely, UDP Options are placed in the surplus area (that is, the area of an IP payload that follows a UDP packet). See Figure 1. An example of the use of UDP Options for Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) is described in [RFC9869]. +

+
+
+

+UDP [RFC0768] は、TCP [RFC9293]、ストリーム制御伝送プロトコル (SCTP) [RFC9260]、またはデータグラム輻輳制御プロトコル (DCCP) [RFC4340] などの他のトランスポート プロトコルでサポートされるオプションと同様の拡張メカニズムをサポートしません。このようなメカニズムは、パス MTU の検出やタイムスタンプの共有など、さまざまなアプリケーションに役立ちます。この空白を埋めるために、[RFC9868] はデータグラムに拡張機能を挿入するメカニズムを使用して UDP を拡張します。そうするために、トランスポートヘッダーに依存する従来のアプローチとは異なり、[RFC9868] はトレーラーを使用します。具体的には、ＵＤＰオプションは余剰領域（ＵＤＰパケットに続くＩＰペイロードの領域）に配置される。図 1 を参照してください。データグラム パケット化層パス MTU 検出のための UDP オプション (DPLPMTUD) の使用例は、[RFC9869] で説明されています。 +

+
+
+
+
+ 
+                             IP transport payload
+                <------------------------------------------------->
+      +--------+---------+----------------------+------------------+
+      | IP Hdr | UDP Hdr |     UDP user data    |   surplus area   |
+      +--------+---------+----------------------+------------------+
+                <------------------------------>
+                           UDP Length
+
+
+
+
+
+

+Figure 1: Surplus Area +

+
+
+

+図 1: 余剰領域 +

+
+
+
+
+

+Sections 4.1 and 4.2 introduce new IEs to export the observed UDP Options. +

+
+
+

+セクション 4.1 と 4.2 では、観察された UDP オプションをエクスポートするための新しい IE を紹介します。 +

+
+
+
+
+

+UDP Options are unambiguously identified by means of a 1-byte field, called "Kind". +

+
+
+

+UDP オプションは、「Kind」と呼ばれる 1 バイトのフィールドによって明確に識別されます。 +

+
+
+
+
+

+Options indicated by Kind values in the range 0-191 are called SAFE Options. Such options can be silently ignored by legacy receivers because they do not alter the UDP user data (Section 11 of [RFC9868]). SAFE Options are exported using the IE defined in Section 4.1. +

+
+
+

+0 ～ 191 の範囲の Kind 値で示されるオプションは SAFE オプションと呼ばれます。このようなオプションは、UDP ユーザーデータを変更しないため、レガシー受信機では黙って無視できます ([RFC9868] のセクション 11)。SAFE オプションは、セクション 4.1 で定義された IE を使用してエクスポートされます。 +

+
+
+
+
+

+Options indicated by Kind values in the range 192-255 are called UNSAFE Options. Such options are not safe for legacy receivers to ignore because they alter the UDP user data (Section 12 of [RFC9868]). UNSAFE Options are exported using the IE defined in Section 4.2. +

+
+
+

+192 ～ 255 の範囲の Kind 値で示されるオプションは、UNSAFE オプションと呼ばれます。このようなオプションは、UDP ユーザーデータを変更するため、レガシー受信機にとって無視するのは安全ではありません ([RFC9868] のセクション 12)。UNSAFE オプションは、セクション 4.2 で定義された IE を使用してエクスポートされます。 +

+
+
+
+
+

+UDP Options occur per-packet within a Flow and can be inserted at any time in the Flow. +

+
+
+

+UDP オプションはフロー内のパケットごとに発生し、フロー内でいつでも挿入できます。 +

+
+
+
+
+

+[RFC9868] reserves two options for experiments: the Experimental (EXP, Kind=127) Option for SAFE Options and the UNSAFE Experimental (UEXP, Kind=254) Option. For both options, Experiment Identifiers (ExIDs) are used to differentiate concurrent use of these options. Known ExIDs are expected to be registered within IANA. Section 4.4 specifies a new IPFIX IE to export observed ExIDs in the EXP Options. Also, Section 4.5 specifies a new IPFIX IE to export observed ExIDs in the UEXP Options. Only 16-bit ExIDs are supported in [RFC9868]. +

+
+
+

+[RFC9868] は実験用に 2 つのオプションを予約しています。SAFE オプションの実験 (EXP、Kind=127) オプションと UNSAFE 実験 (UEXP、Kind=254) オプションです。どちらのオプションでも、実験識別子 (ExID) を使用して、これらのオプションの同時使用を区別します。既知の ExID は IANA 内に登録されることが期待されます。セクション 4.4 では、EXP オプションで監視された ExID をエクスポートするための新しい IPFIX IE を指定しています。また、セクション 4.5 では、UEXP オプションで監視された ExID をエクスポートするための新しい IPFIX IE を指定しています。[RFC9868] では 16 ビット ExID のみがサポートされています。 +

+
+
+
+
+

+This document does not intend to elaborate operational guidance/ implications of UDP Options. The document focuses exclusively on exporting observed UDP Options in datagrams. +

+
+
+

+この文書は、UDP オプションの運用上のガイダンスや影響について詳しく説明することを目的としたものではありません。このドキュメントでは、データグラム内の監視された UDP オプションのエクスポートのみに焦点を当てています。 +

+
+
+
+
+
+4. New UDP IPFIX Information Elements +
+
+
+
+4. 新しい UDP IPFIX 情報要素 +
+
+
+
+
+

+Given the Kind structure of SAFE and UNSAFE UDP Options, using one single IE that would multiplex both types of options will limit the benefits of reduced-size encoding in the presence of UNSAFE Options. For example, at least 24 octets would be needed to report mandatory SAFE Options that are observed in a Flow. In order to use less bits to report observed UDP Options, distinct IEs are thus defined to report SAFE (Section 4.1) and UNSAFE (Section 4.2) UDP Options. As further detailed in Section 5.1, only one octet is needed to report mandatory SAFE Options. +

+
+
+

+SAFE および UNSAFE UDP オプションの Kind 構造を考慮すると、両方のタイプのオプションを多重化する 1 つの IE を使用すると、UNSAFE オプションが存在する場合のサイズ縮小エンコードの利点が制限されます。たとえば、フロー内で観察される必須の SAFE オプションを報告するには、少なくとも 24 オクテットが必要になります。観測された UDP オプションをレポートするために使用するビットを少なくするために、SAFE (セクション 4.1) および UNSAFE (セクション 4.2) の UDP オプションをレポートするために別個の IE が定義されます。セクション 5.1 で詳しく説明するように、必須の SAFE オプションを報告するために必要なオクテットは 1 つだけです。 +

+
+
+
+
+
+4.1. udpSafeOptions +
+
+
+
+4.1. udpSafeオプション +
+
+
+
+
+

+Name: +

+
+
+

+名前： +

+
+
+
+
+

+udpSafeOptions +

+
+
+

+udpSafeオプション +

+
+
+
+
+

+ElementID: +

+
+
+

+要素ID: +

+
+
+
+
+

+525 +

+
+
+

+525 +

+
+
+
+
+

+Description: +

+
+
+

+説明： +

+
+
+
+
+

+Observed SAFE UDP Options in a Flow. The information is encoded in a set of bit fields. +

+
+
+

+フロー内で観察された SAFE UDP オプション。情報は一連のビットフィールドにエンコードされます。 +

+
+
+
+
+

+Options are mapped to bits according to their option numbers. UDP Option Kind 0 corresponds to the least significant bit in the udpSafeOptions IE, while Kind 191 corresponds to the 65th most significant bit of the IE. The bit is set to 1 if the corresponding SAFE UDP Option is observed at least once in the Flow. The bit is set to 0 if the option is never observed in the Flow. The 64 most significant bits MUST be set to 0. +

+
+
+

+オプションは、オプション番号に従ってビットにマッピングされます。UDP オプション Kind 0 は udpSafeOptions IE の最下位ビットに対応し、Kind 191 は IE の 65 番目の最上位ビットに対応します。対応する SAFE UDP オプションがフロー内で少なくとも 1 回観察されると、このビットは 1 に設定されます。オプションがフロー内で観察されない場合、ビットは 0 に設定されます。最上位 64 ビットは 0 に設定しなければなりません。 +

+
+
+
+
+

+The reduced-size encoding per Section 6.2 of [RFC7011] is followed whenever fewer octets are needed to report observed SAFE UDP Options. For example, if only option Kinds <= 31 are observed, then the value of the udpSafeOptions IE can be encoded as unsigned32, or if only option Kinds <= 63 are observed, then the value of the udpSafeOptions IE can be encoded as unsigned64. +

+
+
+

+観測された SAFE UDP オプションを報告するために必要なオクテットが少ない場合は常に、[RFC7011] のセクション 6.2 に従った縮小サイズのエンコーディングが適用されます。たとえば、オプション Kinds <= 31 のみが観察される場合、udpSafeOptions IE の値は unsigned32 としてエンコードでき、オプション Kinds <= 63 のみが観察される場合、udpSafeOptions IE の値は unsigned64 としてエンコードできます。 +

+
+
+
+
+

+The presence of udpSafeExIDList is an indication that the SAFE Experimental Option is observed in a Flow. The presence of udpSafeExIDList takes precedence over setting the corresponding bit in the udpSafeOptions IE for the same Flow. In order to optimize the use of the reduced-size encoding in the presence of udpSafeExIDList IE, the Exporter MUST NOT set the EXP flag of the udpSafeOptions IE that is reported for the same Flow to 1. +

+
+
+

+udpSafeExIDList の存在は、SAFE 実験的オプションがフロー内で観察されていることを示します。udpSafeExIDList の存在は、同じフローの udpSafeOptions IE の対応するビットの設定よりも優先されます。udpSafeExIDList IE の存在下で縮小サイズのエンコーディングの使用を最適化するために、エクスポーターは、同じフローについて報告される udpSafeOptions IE の EXP フラグを 1 に設定してはなりません。 +

+
+
+
+
+

+Abstract Data Type: +

+
+
+

+抽象データ型: +

+
+
+
+
+

+unsigned256 +

+
+
+

+署名なし256 +

+
+
+
+
+

+Data Type Semantics: +

+
+
+

+データ型のセマンティクス: +

+
+
+
+
+

+flags +

+
+
+

+フラグ +

+
+
+
+
+

+Additional Information: +

+
+
+

+追加情報： +

+
+
+
+
+

+See the "UDP Option Kind Numbers" registry at [UDP_OPTIONS]. +

+
+
+

+[UDP_OPTIONS] の「UDP オプションの種類番号」レジストリを参照してください。 +

+
+
+
+
+

+See [RFC9868] for more details about UDP Options. +

+
+
+

+UDP オプションの詳細については、[RFC9868] を参照してください。 +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+RFC 9870 +

+
+
+

+RFC 9870 +

+
+
+
+
+
+4.2. udpUnsafeOptions +
+
+
+
+4.2. udpUnsafeオプション +
+
+
+
+
+

+Name: +

+
+
+

+名前： +

+
+
+
+
+

+udpUnsafeOptions +

+
+
+

+udpUnsafeオプション +

+
+
+
+
+

+ElementID: +

+
+
+

+要素ID: +

+
+
+
+
+

+526 +

+
+
+

+526 +

+
+
+
+
+

+Description: +

+
+
+

+説明： +

+
+
+
+
+

+Observed UNSAFE UDP Options in a Flow. The information is encoded in a set of bit fields. +

+
+
+

+フロー内で検出された安全でない UDP オプション。情報は一連のビットフィールドにエンコードされます。 +

+
+
+
+
+

+Options are mapped to bits according to their option numbers. UDP Option Kind 192 corresponds to the least significant bit in the udpUnsafeOptions IE, while Kind 255 corresponds to the most significant bit of the IE. The bit is set to 1 if the corresponding UNSAFE UDP Option is observed at least once in the Flow. The bit is set to 0 if the option is never observed in the Flow. +

+
+
+

+オプションは、オプション番号に従ってビットにマッピングされます。UDP オプションの種類 192 は udpUnsafeOptions IE の最下位ビットに対応し、種類 255 は IE の最上位ビットに対応します。対応する UNSAFE UDP オプションがフロー内で少なくとも 1 回検出された場合、このビットは 1 に設定されます。オプションがフロー内で観察されない場合、ビットは 0 に設定されます。 +

+
+
+
+
+

+The reduced-size encoding per Section 6.2 of [RFC7011] is followed whenever fewer octets are needed to report observed UNSAFE UDP Options. +

+
+
+

+観察された UNSAFE UDP オプションを報告するためにより少ないオクテットが必要な場合は常に、[RFC7011] のセクション 6.2 に従った縮小サイズのエンコーディングが適用されます。 +

+
+
+
+
+

+The presence of udpUnsafeExIDList is an indication that the UNSAFE Experimental Option is observed in a Flow. The presence of udpUnsafeExIDList takes precedence over setting the corresponding bit in the udpUnsafeOptions IE for the same Flow. In order to optimize the use of the reduced-size encoding in the presence of udpUnsafeExIDList IE, the Exporter MUST NOT set the UEXP flag of the udpUnsafeOptions IE that is reported for the same Flow to 1. +

+
+
+

+udpUnsafeExIDList の存在は、UNSAFE 実験的オプションがフロー内で観察されていることを示します。udpUnsafeExIDList の存在は、同じフローの udpUnsafeOptions IE 内の対応するビットの設定よりも優先されます。udpUnsafeExIDList IE の存在下で縮小サイズのエンコーディングの使用を最適化するために、エクスポーターは、同じフローについて報告される udpUnsafeOptions IE の UEXP フラグを 1 に設定してはなりません (MUST NOT)。 +

+
+
+
+
+

+Abstract Data Type: +

+
+
+

+抽象データ型: +

+
+
+
+
+

+unsigned64 +

+
+
+

+署名なし64 +

+
+
+
+
+

+Data Type Semantics: +

+
+
+

+データ型のセマンティクス: +

+
+
+
+
+

+flags +

+
+
+

+フラグ +

+
+
+
+
+

+Additional Information: +

+
+
+

+追加情報： +

+
+
+
+
+

+See the "UDP Option Kind Numbers" registry at [UDP_OPTIONS]. +

+
+
+

+[UDP_OPTIONS] の「UDP オプションの種類番号」レジストリを参照してください。 +

+
+
+
+
+

+See [RFC9868] for more details about UDP Options. +

+
+
+

+UDP オプションの詳細については、[RFC9868] を参照してください。 +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+RFC 9870 +

+
+
+

+RFC 9870 +

+
+
+
+
+
+4.3. udpExID +
+
+
+
+4.3. udpExID +
+
+
+
+
+

+Name: +

+
+
+

+名前： +

+
+
+
+
+

+udpExID +

+
+
+

+udpExID +

+
+
+
+
+

+ElementID: +

+
+
+

+要素ID: +

+
+
+
+
+

+527 +

+
+
+

+527 +

+
+
+
+
+

+Description: +

+
+
+

+説明： +

+
+
+
+
+

+Observed ExID in an Experimental (EXP, Kind=127) Option or an UNSAFE Experimental (UEXP, Kind=254) Option. +

+
+
+

+実験的 (EXP、Kind=127) オプションまたは UNSAFE 実験的 (UEXP、Kind=254) オプションで観察された ExID。 +

+
+
+
+
+

+A basicList of udpExID is used to report udpSafeExIDList and udpUnsafeExIDList values. +

+
+
+

+udpExID の BasicList は、udpSafeExIDList および udpUnsafeExIDList の値を報告するために使用されます。 +

+
+
+
+
+

+Abstract Data Type: +

+
+
+

+抽象データ型: +

+
+
+
+
+

+unsigned16 +

+
+
+

+署名なし16 +

+
+
+
+
+

+Data Type Semantics: +

+
+
+

+データ型のセマンティクス: +

+
+
+
+
+

+identifier +

+
+
+

+識別子 +

+
+
+
+
+

+Additional Information: +

+
+
+

+追加情報： +

+
+
+
+
+

+See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry at [UDP_ExIDs]. +

+
+
+

+[UDP_ExIDs] の「TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)」レジストリを参照してください。 +

+
+
+
+
+

+See [RFC9868] for more details about ExIDs. +

+
+
+

+ExID の詳細については、[RFC9868] を参照してください。 +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+RFC 9870 +

+
+
+

+RFC 9870 +

+
+
+
+
+
+4.4. udpSafeExIDList +
+
+
+
+4.4. udpSafeExIDList +
+
+
+
+
+

+Name: +

+
+
+

+名前： +

+
+
+
+
+

+udpSafeExIDList +

+
+
+

+udpSafeExIDList +

+
+
+
+
+

+ElementID: +

+
+
+

+要素ID: +

+
+
+
+
+

+528 +

+
+
+

+528 +

+
+
+
+
+

+Description: +

+
+
+

+説明： +

+
+
+
+
+

+Observed ExIDs in the Experimental (EXP, Kind=127) Option. +

+
+
+

+実験的 (EXP、Kind=127) オプションで観察された ExID。 +

+
+
+
+
+

+A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an EXP Option. +

+
+
+

+udpExID 情報要素の BasicList。各 udpExID 情報要素は、EXP オプションで観察される ExID を保持します。 +

+
+
+
+
+

+Abstract Data Type: +

+
+
+

+抽象データ型: +

+
+
+
+
+

+basicList +

+
+
+

+基本リスト +

+
+
+
+
+

+Data Type Semantics: +

+
+
+

+データ型のセマンティクス: +

+
+
+
+
+

+list +

+
+
+

+リスト +

+
+
+
+
+

+Additional Information: +

+
+
+

+追加情報： +

+
+
+
+
+

+See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry at [UDP_ExIDs]. +

+
+
+

+[UDP_ExIDs] の「TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)」レジストリを参照してください。 +

+
+
+
+
+

+See [RFC9868] for more details about ExIDs. +

+
+
+

+ExID の詳細については、[RFC9868] を参照してください。 +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+RFC 9870 +

+
+
+

+RFC 9870 +

+
+
+
+
+
+4.5. udpUnsafeExIDList +
+
+
+
+4.5. udpUnsafeExIDList +
+
+
+
+
+

+Name: +

+
+
+

+名前： +

+
+
+
+
+

+udpUnsafeExIDList +

+
+
+

+udpUnsafeExIDList +

+
+
+
+
+

+ElementID: +

+
+
+

+要素ID: +

+
+
+
+
+

+529 +

+
+
+

+529 +

+
+
+
+
+

+Description: +

+
+
+

+説明： +

+
+
+
+
+

+Observed ExIDs in the UNSAFE Experimental (UEXP, Kind=254) Option. +

+
+
+

+UNSAFE Experimental (UEXP、Kind=254) オプションで観察された ExID。 +

+
+
+
+
+

+A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an UEXP Option. +

+
+
+

+udpExID 情報要素の BasicList。各 udpExID 情報要素は、UEXP オプションで観察される ExID を保持します。 +

+
+
+
+
+

+Abstract Data Type: +

+
+
+

+抽象データ型: +

+
+
+
+
+

+basicList +

+
+
+

+基本リスト +

+
+
+
+
+

+Data Type Semantics: +

+
+
+

+データ型のセマンティクス: +

+
+
+
+
+

+list +

+
+
+

+リスト +

+
+
+
+
+

+Additional Information: +

+
+
+

+追加情報： +

+
+
+
+
+

+See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry at [UDP_ExIDs]. +

+
+
+

+[UDP_ExIDs] の「TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)」レジストリを参照してください。 +

+
+
+
+
+

+See [RFC9868] for more details about ExIDs. +

+
+
+

+ExID の詳細については、[RFC9868] を参照してください。 +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+RFC 9870 +

+
+
+

+RFC 9870 +

+
+
+
+
+
+5. Examples +
+
+
+
+5. 例 +
+
+
+
+
+
+5.1. Reduced-Size Encoding +
+
+
+
+5.1. 縮小サイズのエンコーディング +
+
+
+
+
+

+Given the UDP Kind allocation in Section 10 of [RFC9868] and the option mapping defined in Section 4.1 of this document, fewer octets are likely to be used for Flows with mandatory UDP Options. +

+
+
+

+[RFC9868] のセクション 10 の UDP Kind 割り当てと、この文書のセクション 4.1 で定義されているオプション マッピングを考慮すると、必須の UDP オプションを持つフローに使用されるオクテットは少なくなる可能性があります。 +

+
+
+
+
+

+Figure 2 shows an example of the Kind/bit mappings in the udpSafeOptions IE for a Flow in which End of Options List (EOL, Kind=0) and Additional Payload Checksum (APC, Kind=2) Options are observed. Only the bits that corresponds to EOL and APC Options are set to 1. +

+
+
+

+図 2 は、オプション リストの終わり (EOL、Kind=0) および追加のペイロード チェックサム (APC、Kind=2) オプションが観察されるフローの udpSafeOptions IE の Kind/ビット マッピングの例を示しています。EOL および APC オプションに対応するビットのみが 1 に設定されます。 +

+
+
+
+
+ 
+       MSB                                                       LSB
+                            1                          25
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 ... 8 9 0 1 2 3 4 5
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+
+       |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|   |0|0|0|0|0|1|0|1|
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+-+
+
+
+
+
+
+

+Figure 2: An Example of udpSafeOptions IE with EOL and APC Options +

+
+
+

+図 2: EOL および APC オプションを使用した udpSafeOptions IE の例 +

+
+
+
+
+

+One octet is sufficient to report these observed options because the leading zeros are dropped per the reduced-size encoding guidance. Concretely, the reported udpSafeOptions IE will be set to 0x05 (Figure 3). +

+
+
+

+サイズ縮小エンコードのガイダンスに従って先頭のゼロが削除されるため、これらの観察されたオプションを報告するには 1 オクテットで十分です。具体的には、報告された udpSafeOptions IE は 0x05 に設定されます (図 3)。 +

+
+
+
+
+ 
+                             MSB           LSB
+                              0 1 2 3 4 5 6 7
+                             +-+-+-+-+-+-+-+-+
+                             |0|0|0|0|0|1|0|1|
+                             +-+-+-+-+-+-+-+-+
+
+
+
+
+
+

+Figure 3: An Example of the Wire udpSafeOptions IE Value with EOL and APC Options +

+
+
+

+図 3: EOL および APC オプションを使用したワイヤ udpSafeOptions IE 値の例 +

+
+
+
+
+
+5.2. SAFE Experimental Option +
+
+
+
+5.2. SAFE 実験的オプション +
+
+
+
+
+

+Let us now consider a UDP Flow in which SAFE Experimental Options are observed. If a udpSafeOptions IE is exported for this Flow, then that IE will have the EXP bit set to 1 (Figure 4). This example does not make any assumption about the presence of other UDP Options ("X" can be set to 0 or 1). +

+
+
+

+次に、SAFE 実験的オプションが観察される UDP フローを考えてみましょう。udpSafeOptions IE がこのフローに対してエクスポートされる場合、その IE の EXP ビットは 1 に設定されます (図 4)。この例では、他の UDP オプションの存在については何も想定していません (「X」は 0 または 1 に設定できます)。 +

+
+
+
+
+ 
+        MSB                                                     LSB
+                          12                          25
+         0 1 2 3 ... 7 8 9 0 1 2 3 4 5 6 7 8 9 ... 8 9 0 1 2 3 4 5
+        +-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+
+        |X|X|X|X|   |X|X|X|X|X|X|X|X|X|X|X|1|X|X|   |X|X|X|X|X|X|X|
+        +-+-+-+-+...+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+
+
+
+
+
+
+

+Figure 4: An Example of udpSafeOptions with EXP Option +

+
+
+

+図 4: EXP オプションを使用した udpSafeOptions の例 +

+
+
+
+
+
+5.3. ExIDs and Reduced-Size Encoding +
+
+
+
+5.3. ExID と縮小サイズのエンコーディング +
+
+
+
+
+

+Now assume that EOL, APC, EXP, and UEXP Options are observed in a Flow. Let us also consider that the observed SAFE Experimental Options have ExIDs set to 0x9858 and 0xE2D4 and UNSAFE Experimental Options have ExIDs set to 0xC3D9 and 0x1234. Figure 5 shows an excerpt of the Data Set encoding with a focus on SAFE Experimental Options that have ExIDs. The fields are defined in [RFC6313]. +

+
+
+

+ここで、EOL、APC、EXP、および UEXP オプションがフローで観察されると仮定します。また、観察された SAFE 実験的オプションの ExID は 0x9858 および 0xE2D4 に設定されており、UNSAFE 実験的オプションの ExID は 0xC3D9 および 0x1234 に設定されていることも考えてみましょう。図 5 は、ExID を持つ SAFE Experimental Options に焦点を当てたデータ セット エンコーディングの抜粋を示しています。フィールドは [RFC6313] で定義されています。 +

+
+
+
+
+ 
+      MSB                                                          LSB
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     :                           ...                                 :
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |      255      |        List Length = 9        |semantic=allof |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |           udpExID = 527       |         Field Length = 2      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | SAFE ExID =  0x9858           | SAFE ExID = 0xE2D4            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |      255      |        List Length = 9        |semantic=allof |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |           udpExID = 527       |         Field Length = 2      |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | UNSAFE ExID =  0xC3D9         | UNSAFE ExID =  0x1234         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     :                           ...                                 :
+
+
+
+
+
+

+Figure 5: Example of UDP Experimental Option ExID IEs +

+
+
+

+図 5: UDP 実験的オプション ExID IE の例 +

+
+
+
+
+

+Following the guidance in Section 4.1, the reported udpSafeOptions IE will be set to 0x05 even in the presence of EXP Options. +

+
+
+

+セクション 4.1 のガイダンスに従って、報告される udpSafeOptions IE は、EXP オプションが存在する場合でも 0x05 に設定されます。 +

+
+
+
+
+
+6. Security Considerations +
+
+
+
+6. セキュリティに関する考慮事項 +
+
+
+
+
+

+This document does not introduce new security considerations other than those already discussed in Section 11 of [RFC7011] and Section 8 of [RFC7012]. +

+
+
+

+この文書は、[RFC7011] のセクション 11 および [RFC7012] のセクション 8 で既に説明されているもの以外の、新しいセキュリティに関する考慮事項を紹介しません。 +

+
+
+
+
+

+The reader may refer to Section 24 of [RFC9868] for the security considerations related to UDP Options. +

+
+
+

+UDP オプションに関連するセキュリティ上の考慮事項については、[RFC9868] のセクション 24 を参照してください。 +

+
+
+
+
+
+7. IANA Considerations +
+
+
+
+7. IANAの考慮事項 +
+
+
+
+
+
+7.1. IPFIX Information Elements +
+
+
+
+7.1. IPFIX 情報要素 +
+
+
+
+
+

+IANA has added the following new IEs to the "IPFIX Information Elements" registry under the "IP Flow Information Export (IPFIX) Entities" registry group [IANA-IPFIX]: +

+
+
+

+IANA は、「IP フロー情報エクスポート (IPFIX) エンティティ」レジストリ グループ [IANA-IPFIX] の下の「IPFIX 情報要素」レジストリに次の新しい IE を追加しました。 +

+
+
+
+
+ 
+        +===========+===================+=========================+
+        | ElementID | Name              | Reference               |
+        +===========+===================+=========================+
+        | 525       | udpSafeOptions    | Section 4.1 of RFC 9870 |
+        +-----------+-------------------+-------------------------+
+        | 526       | udpUnsafeOptions  | Section 4.2 of RFC 9870 |
+        +-----------+-------------------+-------------------------+
+        | 527       | udpExID           | Section 4.3 of RFC 9870 |
+        +-----------+-------------------+-------------------------+
+        | 528       | udpSafeExIDList   | Section 4.4 of RFC 9870 |
+        +-----------+-------------------+-------------------------+
+        | 529       | udpUnsafeExIDList | Section 4.5 of RFC 9870 |
+        +-----------+-------------------+-------------------------+
+
+
+
+
+
+

+Table 1: New IPFIX Information Elements +

+
+
+

+表 1: 新しい IPFIX 情報要素 +

+
+
+
+
+

+udpSafeOptions uses the abstract data type ("unsigned256") defined in [RFC9740]. +

+
+
+

+udpSafeOptions は、[RFC9740] で定義されている抽象データ型 ("unsigned256") を使用します。 +

+
+
+
+
+
+8. References +
+
+
+
+8. 参考文献 +
+
+
+
+
+
+8.1. Normative References +
+
+
+
+8.1. 引用文献 +
+
+
+
+
+ 
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              DOI 10.17487/RFC0768, August 1980,
+              <https://www.rfc-editor.org/info/rfc768>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
+              "Export of Structured Data in IP Flow Information Export
+              (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011,
+              <https://www.rfc-editor.org/info/rfc6313>.
+
+
+
+
+
+ 
+   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
+              "Specification of the IP Flow Information Export (IPFIX)
+              Protocol for the Exchange of Flow Information", STD 77,
+              RFC 7011, DOI 10.17487/RFC7011, September 2013,
+              <https://www.rfc-editor.org/info/rfc7011>.
+
+
+
+
+
+ 
+   [RFC7012]  Claise, B., Ed. and B. Trammell, Ed., "Information Model
+              for IP Flow Information Export (IPFIX)", RFC 7012,
+              DOI 10.17487/RFC7012, September 2013,
+              <https://www.rfc-editor.org/info/rfc7012>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC9740]  Boucadair, M. and B. Claise, "New IPFIX Information
+              Elements for TCP Options and IPv6 Extension Headers",
+              RFC 9740, DOI 10.17487/RFC9740, March 2025,
+              <https://www.rfc-editor.org/info/rfc9740>.
+
+
+
+
+
+ 
+   [RFC9868]  Touch, J. and C. Heard, Ed., "Transport Options for UDP",
+              RFC 9868, DOI 10.17487/RFC9868, October 2025,
+              <https://www.rfc-editor.org/info/rfc9868>.
+
+
+
+
+
+
+8.2. Informative References +
+
+
+
+8.2. 参考引用 +
+
+
+
+
+ 
+   [IANA-IPFIX]
+              IANA, "IP Flow Information Export (IPFIX) Entities",
+              <https://www.iana.org/assignments/ipfix>.
+
+
+
+
+
+ 
+   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
+              Congestion Control Protocol (DCCP)", RFC 4340,
+              DOI 10.17487/RFC4340, March 2006,
+              <https://www.rfc-editor.org/info/rfc4340>.
+
+
+
+
+
+ 
+   [RFC6632]  Ersue, M., Ed. and B. Claise, "An Overview of the IETF
+              Network Management Standards", RFC 6632,
+              DOI 10.17487/RFC6632, June 2012,
+              <https://www.rfc-editor.org/info/rfc6632>.
+
+
+
+
+
+ 
+   [RFC9260]  Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
+              Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
+              June 2022, <https://www.rfc-editor.org/info/rfc9260>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC9869]  Fairhurst, G. and T. Jones, "Datagram Packetization Layer
+              Path MTU Discovery (DPLPMTUD) for UDP Options", RFC 9869,
+              DOI 10.17487/RFC9869, October 2025,
+              <https://www.rfc-editor.org/info/rfc9869>.
+
+
+
+
+
+ 
+   [UDP_ExIDs]
+              IANA, "TCP/UDP Experimental Option Experiment Identifiers
+              (TCP/UDP ExIDs)", <https://www.iana.org/assignments/udp>.
+
+
+
+
+
+ 
+   [UDP_OPTIONS]
+              IANA, "UDP Option Kind Numbers",
+              <https://www.iana.org/assignments/udp>.
+
+
+
+
+
+
+Acknowledgments +
+
+
+
+謝辞 +
+
+
+
+
+

+Thanks to Benoît Claise for the discussion on the ordering of IPFIX IEs. Thanks to Paul Aitken for the review and comments. +

+
+
+

+IPFIX IE の順序について議論してくれた Benoit Claise に感謝します。レビューとコメントをくださった Paul Aitken に感謝します。 +

+
+
+
+
+

+Thanks to Tommy Pauly for the TSVART review, Joe Touch for the INTDIR review, Robert Sparks for the GENART review, Watson Ladd for the SECDIR review, and Jouni Korhonen for the OPSDIR review. +

+
+
+

+TSVART レビューの Tommy Pauly、INTDIR レビューの Joe Touch、GENART レビューの Robert Sparks、SECDIR レビューの Watson Ladd、OPSDIR レビューの Jouni Korhonen に感謝します。 +

+
+
+
+
+

+Thanks to Thomas Graf for the shepherd review. +

+
+
+

+羊飼いのレビューを書いてくれた Thomas Graf に感謝します。 +

+
+
+
+
+

+Thanks to Mahesh Jethanandani for the AD review. +

+
+
+

+AD レビューを投稿してくださった Mahesh Jethanandani に感謝します。 +

+
+
+
+
+

+Thanks to Éric Vyncke, Roman Danyliw, and Zahed Sarker for the IESG review. +

+
+
+

+IESG のレビューに協力してくれた Éric Vyncke、Roman Danyliw、Zahed Sarker に感謝します。 +

+
+
+
+
+
+Authors' Addresses +
+
+
+
+著者の住所 +
+
+
+
+
+ 
+   Mohamed Boucadair
+   Orange
+   35000 Rennes
+   France
+   Email: mohamed.boucadair@orange.com
+
+
+
+
+
+ 
+   Tirumaleswar Reddy.K
+   Nokia
+   India
+   Email: kondtir@gmail.com
+
+
+
+
+ + + diff --git a/html/rfc9883.html b/html/rfc9883.html new file mode 100644 index 000000000..7ea2cf8ef --- /dev/null +++ b/html/rfc9883.html @@ -0,0 +1,1735 @@ + + + + + + RFC 9883 - An Attribute for Statement of Possession of a Private Key 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)                        R. Housley
+Request for Comments: 9883                                Vigil Security
+Category: Standards Track                                   October 2025
+ISSN: 2070-1721
+
+
+
+
+
+
+An Attribute for Statement of Possession of a Private Key +
+
+
+
+秘密鍵の所有を宣言するための属性 +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate. +

+
+
+

+この文書は、証明書サブジェクトによる秘密キーの所有を宣言するための属性を指定します。X.509 証明書の登録の一環として、認証局 (CA) は通常、認証される公開キーに対応する秘密キーをサブジェクトが所有しているという証明を要求します。場合によっては、CA が証明書サブジェクトからの署名付きステートメントを受け入れる場合があります。たとえば、証明書サブジェクトが署名とキーの確立に別個の証明書を必要とする場合、同じサブジェクトに対して以前に発行された署名証明書で検証できるステートメントは、その後のキー確立証明書の発行には適切である可能性があります。 +

+
+
+
+
+
+Status of This Memo +
+
+
+
+本文書の位置付け +
+
+
+
+
+

+This is an Internet Standards Track document. +

+
+
+

+これはインターネット標準化トラックの文書です。 +

+
+
+
+
+

+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 Internet Standards is available in Section 2 of RFC 7841. +

+
+
+

+このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、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/rfc9883. +

+
+
+

+この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9883 で入手できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+Copyright (c) 2025 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+     1.1.  ASN.1
+     1.2.  Terminology
+   2.  Overview
+   3.  Attribute for Statement of Possession of a Private Key
+   4.  Conventions for PKCS#10
+   5.  Conventions for CRMF
+   6.  Security Considerations
+   7.  IANA Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Appendix A.  ASN.1 Module
+   Appendix B.  Example Use of the privateKeyPossessionStatement
+           Attribute
+   Acknowledgements
+   Author's Address
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+This document specifies an attribute for a statement of possession of a private key by a certificate subject. X.509 certificate [RFC5280] enrollment often depends on PKCS#10 [RFC2986] or the Certificate Request Message Format (CRMF) [RFC4211]. As part of enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. Alternatively, a CA may accept a signed statement from the certificate subject claiming knowledge of that private key. When a certificate subject needs separate certificates for signature and key establishment, a signed statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate. +

+
+
+

+この文書は、証明書サブジェクトによる秘密キーの所有を宣言するための属性を指定します。X.509 証明書 [RFC5280] の登録は、多くの場合、PKCS#10 [RFC2986] または証明書要求メッセージ形式 (CRMF) [RFC4211] に依存します。登録の一環として、認証局 (CA) は通常、認証対象の公開キーに対応する秘密キーをサブジェクトが所有しているという証明を要求します。あるいは、CA は、その秘密鍵の知識を主張する証明書主体からの署名付きステートメントを受け入れることもできます。証明書サブジェクトが署名と鍵の確立に別個の証明書を必要とする場合、同じサブジェクトに対して以前に発行された署名証明書で検証できる署名付きステートメントは、その後の鍵確立証明書の発行に適している可能性があります。 +

+
+
+
+
+

+For example, a subject may need a signature certificate that contains an ML-DSA (Module-Lattice-Based Digital Signature Algorithm) public key and a key establishment certificate that contains an ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) public key. For another example, a subject may need a signature certificate that contains an ECDSA (Elliptic Curve Digital Signature Algorithm) public key and a key establishment certificate that contains an ECDH (Elliptic Curve Diffie-Hellman) public key. +

+
+
+

+たとえば、サブジェクトは、ML-DSA (モジュール格子ベースのデジタル署名アルゴリズム) 公開キーを含む署名証明書と、ML-KEM (モジュール格子ベースのキーカプセル化メカニズム) 公開キーを含むキー確立証明書を必要とする場合があります。別の例として、サブジェクトは、ECDSA (楕円曲線デジタル署名アルゴリズム) 公開鍵を含む署名証明書と、ECDH (楕円曲線ディフィーヘルマン) 公開鍵を含む鍵確立証明書を必要とする場合があります。 +

+
+
+
+
+

+A statement of possession may be used in lieu of the usual proof-of-possession mechanisms. The statement is simply a signed assertion that the requestor of a key establishment certificate has possession of the key establishment private key and that statement is signed using a signature private key that was previously shown to be in the possession of the same certificate subject. If allowed by the Certificate Policy [RFC3647], the CA is permitted to accept this statement in lieu of proof that the requestor has possession of the private key, such as [RFC6955]. +

+
+
+

+通常の所有証明メカニズムの代わりに所有声明が使用される場合があります。このステートメントは、キー確立証明書の要求者がキー確立秘密キーを所有しており、そのステートメントは、同じ証明書サブジェクトが所有していることが以前に示されている署名秘密キーを使用して署名されているという署名付きアサーションにすぎません。証明書ポリシー [RFC3647] で許可されている場合、CA は、[RFC6955] など、要求者が秘密鍵を所有していることを証明する代わりに、このステートメントを受け入れることが許可されます。 +

+
+
+
+
+

+Note that [RFC6955] offers some algorithms that provide proof of possession for Diffie-Hellman private keys; however, these algorithms are not suitable for use with PKCS#10 [RFC2986]. In addition, the algorithms in [RFC6955] do not support key encapsulation mechanism algorithms, such as ML-KEM. The attribute specified in this document, on the other hand, is suitable for use with both PKCS#10 and the CRMF [RFC4211]. +

+
+
+

+[RFC6955] は、Diffie-Hellman 秘密鍵の所有証明を提供するいくつかのアルゴリズムを提供していることに注意してください。ただし、これらのアルゴリズムは PKCS#10 [RFC2986] での使用には適していません。さらに、[RFC6955] のアルゴリズムは、ML-KEM などの鍵カプセル化メカニズムのアルゴリズムをサポートしていません。一方、この文書で指定された属性は、PKCS#10 と CRMF [RFC4211] の両方での使用に適しています。 +

+
+
+
+
+
+1.1. ASN.1 +
+
+
+
+1.1. ASN.1 +
+
+
+
+
+

+The attribute defined in this document is generated using ASN.1 [X680], using the Distinguished Encoding Rules (DER) [X690]. +

+
+
+

+この文書で定義される属性は、ASN.1 [X680]、Distinguished Encoding Rules (DER) [X690] を使用して生成されます。 +

+
+
+
+
+
+1.2. Terminology +
+
+
+
+1.2. 用語 +
+
+
+
+
+

+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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。 +

+
+
+
+
+
+2. Overview +
+
+
+
+2. 概要 +
+
+
+
+
+

+When using the attribute defined in this document to make a statement about the possession of the key establishment private key, the process to obtain two certificates with PKCS#10 is as follows: +

+
+
+

+この文書で定義されている属性を使用して鍵確立秘密鍵の所有についてステートメントを作成する場合、PKCS#10 で 2 つの証明書を取得するプロセスは次のとおりです。 +

+
+
+
+
+

+1. The subject generates the signature key pair. +

+
+
+

+1. サブジェクトは署名鍵ペアを生成します。 +

+
+
+
+
+

+2. The subject composes a PKCS#10 Certificate Signing Request (CSR) in the usual manner. It includes a signature that is produced with the private key from step 1. +

+
+
+

+2. サブジェクトは通常の方法で PKCS#10 証明書署名要求 (CSR) を作成します。これには、手順 1 の秘密キーを使用して生成された署名が含まれています。 +

+
+
+
+
+

+3. The subject sends the CSR to the CA, and it gets back a signature certificate. The signature certificate includes a key usage of digitalSignature, nonRepudiation, or both (see Section 4.2.1.3 of [RFC5280]). +

+
+
+

+3. サブジェクトは CSR を CA に送信し、CA は署名証明書を返します。署名証明書には、digitalSignature、nonRepudiation、またはその両方の鍵の使用法が含まれています（[RFC5280] のセクション 4.2.1.3 を参照）。 +

+
+
+
+
+

+4. The subject generates the key establishment key pair. +

+
+
+

+4. サブジェクトは鍵確立鍵ペアを生成します。 +

+
+
+
+
+

+5. The subject composes a PKCS#10 CSR containing the key establishment public key. The CSR attributes include the attribute specified in Section 3 of this document. The subject name matches the one from step 3. The CSR includes a signature that is produced with the private key from step 1. +

+
+
+

+5. サブジェクトは、鍵確立公開鍵を含む PKCS#10 CSR を作成します。CSR 属性には、この文書のセクション 3 で指定された属性が含まれます。サブジェクト名はステップ 3 の名前と一致します。CSR には、ステップ 1 の秘密キーを使用して生成された署名が含まれています。 +

+
+
+
+
+

+6. The subject sends the CSR to the CA, and it gets back a key establishment certificate. The key establishment certificate includes a key usage of keyEncipherment or keyAgreement (see Section 4.2.1.3 of [RFC5280]). +

+
+
+

+6. サブジェクトは CSR を CA に送信し、CA はキー確立証明書を返します。鍵確立証明書には、keyEncipherment または keyAgreement の鍵使用法が含まれます ([RFC5280] のセクション 4.2.1.3 を参照)。 +

+
+
+
+
+

+In general, the issuer of the key establishment certificate will be the same as the issuer of the signature certificate. If the issuers of the two certificates will be different, then the certificate policy of the issuer of the key establishment certificate MUST explain the procedure that is used to verify the subject and subject alternative names. +

+
+
+

+一般に、鍵確立証明書の発行者は署名証明書の発行者と同じになります。2 つの証明書の発行者が異なる場合、鍵確立証明書の発行者の証明書ポリシーで、サブジェクトとサブジェクトの代替名の検証に使用される手順を説明しなければなりません (MUST)。 +

+
+
+
+
+
+3. Attribute for Statement of Possession of a Private Key +
+
+
+
+3. 秘密鍵の所有を宣言するための属性 +
+
+
+
+
+

+The attribute for statement of possession of a private key is included in a certificate request to make the following statement: +

+
+
+

+秘密キーの所有に関するステートメントの属性は、次のステートメントを作成するために証明書リクエストに含まれています。 +

+
+
+
+
+

+ The subject of the signature certificate that is used to validate the signature on this certificate request states, without providing proof, that it has possession of the private key that corresponds to the public key in the certificate request. +

+
+
+

+この証明書要求の署名を検証するために使用される署名証明書の件名は、証明を提供することなく、証明書要求の公開キーに対応する秘密キーを所有していると述べています。 +

+
+
+
+
+

+The CA MUST perform certification path validation for the signature certificate as specified in Section 6 of [RFC5280]. If the certification path is not valid, then the CA MUST reject the request for the key establishment certificate. +

+
+
+

+CA は、[RFC5280] のセクション 6 に規定されているように、署名証明書の証明書パス検証を実行しなければなりません (MUST)。認証パスが有効でない場合、CA は鍵確立証明書の要求を拒否しなければなりません (MUST)。 +

+
+
+
+
+

+The CA MUST validate the signature on the certificate request using the public key from the signature certificate. If the signature is not valid, then the CA MUST reject the certificate request. +

+
+
+

+CA は、署名証明書の公開鍵を使用して、証明書リクエストの署名を検証しなければなりません (MUST)。署名が有効でない場合、CA は証明書要求を拒否しなければなりません (MUST)。 +

+
+
+
+
+

+The subject in the signature certificate SHOULD be the same as the subject name in the certificate request. If they are different, the certificate policy MUST describe how the CA can determine that the two subject names identify the same entity. If the CA is unable to determine that the two subject names identify the same entity, then the CA MUST reject the certificate request. +

+
+
+

+署名証明書のサブジェクトは、証明書リクエストのサブジェクト名と同じである必要があります (SHOULD)。それらが異なる場合、証明書ポリシーは、CA が 2 つのサブジェクト名が同じエンティティを識別していることをどのように判断できるかを記述しなければなりません (MUST)。CA が 2 つのサブジェクト名が同じエンティティを識別していると判断できない場合、CA は証明書要求を拒否しなければなりません (MUST)。 +

+
+
+
+
+

+If subject alternative names are present in the certificate request, they SHOULD match subject alternative names in the signature certificate. If they are different, the certificate policy MUST describe how the CA can determine that the two subject alternative names identify the same entity. If the CA is unable to determine that each of subject alternative names identifies the same entity as is named in the signature certificate, then the CA MUST reject the certificate request. +

+
+
+

+証明書リクエストにサブジェクト代替名が存在する場合、それらは署名証明書内のサブジェクト代替名と一致する必要があります(SHOULD)。それらが異なる場合、証明書ポリシーは、CA が 2 つのサブジェクト代替名が同じエンティティを識別していることをどのように判断できるかを記述しなければなりません (MUST)。CA が、各サブジェクト代替名が署名証明書で指定されているのと同じエンティティを識別していると判断できない場合、CA は証明書要求を拒否しなければなりません (MUST)。 +

+
+
+
+
+

+When the CA rejects a certificate request for any of the reasons listed above, the CA should provide information to the requestor about the reason for the rejection to aid with diagnostic efforts. Likewise, the CA should log the rejection events. +

+
+
+

+CA が上記のいずれかの理由で証明書要求を拒否した場合、CA は診断作業を支援するために、拒否の理由に関する情報を要求者に提供する必要があります。同様に、CA は拒否イベントをログに記録する必要があります。 +

+
+
+
+
+

+The attribute for statement of possession of a private key has the following structure: +

+
+
+

+秘密鍵の所有を宣言するための属性は次の構造になっています。 +

+
+
+
+
+ 
+      id-at-statementOfPossession OBJECT IDENTIFIER ::=
+        { 1 3 6 1 4 1 22112 2 1 }
+
+      privateKeyPossessionStatement ATTRIBUTE ::= {
+        TYPE PrivateKeyPossessionStatement
+        IDENTIFIED BY id-at-statementOfPossession }
+
+      PrivateKeyPossessionStatement ::= SEQUENCE {
+        signer  IssuerAndSerialNumber,
+        cert    Certificate OPTIONAL }
+
+
+
+
+
+

+The components of the PrivateKeyStatement SEQUENCE have the following semantics: +

+
+
+

+PrivateKeyStatement SEQUENCE のコンポーネントには次のセマンティクスがあります。 +

+
+
+
+
+

+signer: +

+
+
+

+署名者: +

+
+
+
+
+

+The issuer name and certificate serial number of the signature certificate. +

+
+
+

+署名証明書の発行者名と証明書のシリアル番号。 +

+
+
+
+
+

+cert: +

+
+
+

+証明書: +

+
+
+
+
+

+The signature certificate. If the issuer of the key establishment certificate will be the same as the issuer of the signature certificate, then this component MAY be omitted. When the signature certificate is omitted, the signer is assuming that the CA has a mechanism to obtain all valid certificates that it issued. +

+
+
+

+署名証明書。鍵確立証明書の発行者が署名証明書の発行者と同じである場合、このコンポーネントは省略してもよい(MAY)。署名証明書が省略された場合、署名者は、CA が発行したすべての有効な証明書を取得するメカニズムを備えていると想定します。 +

+
+
+
+
+
+4. Conventions for PKCS#10 +
+
+
+
+4. PKCS#10 の規則 +
+
+
+
+
+

+This section specifies the conventions for using the attribute for statement of possession of a private key with PKCS#10 [RFC2986] when requesting a key establishment certificate. +

+
+
+

+このセクションでは、鍵確立証明書を要求する際に、PKCS#10 [RFC2986] で秘密鍵の所有を宣言するための属性を使用するための規則を指定します。 +

+
+
+
+
+

+The PKCS#10 CertificationRequest always has three components, as follows: +

+
+
+

+PKCS#10 CertificationRequest には、次の 3 つのコンポーネントが常に含まれます。 +

+
+
+
+
+

+certificationRequestInfo: +

+
+
+

+認証要求情報: +

+
+
+
+
+

+The subject name SHOULD be the same as the subject name in the signature certificate, the subjectPKInfo MUST contain the public key for the key establishment algorithm, and the attributes MUST include privateKeyPossessionStatement attribute as specified in Section 3 of this document. +

+
+
+

+サブジェクト名は署名証明書のサブジェクト名と同じである必要があり (SHOULD)、subjectPKInfo には鍵確立アルゴリズムの公開鍵が含まれなければならず、属性にはこの文書のセクション 3 で指定されている privateKeyPossessionStatement 属性が含まれなければなりません (MUST)。 +

+
+
+
+
+

+signatureAlgorithm: +

+
+
+

+署名アルゴリズム: +

+
+
+
+
+

+The signature algorithm MUST be one that can be validated with the public key in the signature certificate. +

+
+
+

+署名アルゴリズムは、署名証明書内の公開キーを使用して検証できるものでなければなりません。 +

+
+
+
+
+

+signature: +

+
+
+

+サイン： +

+
+
+
+
+

+The signature over certificationRequestInfo MUST validate with the public key in the signature certificate, and certification path validation for the signature certificate MUST be successful as specified in Section 6 of [RFC5280]. +

+
+
+

+[RFC5280] のセクション 6 に規定されているように、certificationRequestInfo に対する署名は署名証明書内の公開鍵を使用して検証しなければならず (MUST)、署名証明書の証明書パスの検証は成功しなければなりません (MUST)。 +

+
+
+
+
+
+5. Conventions for CRMF +
+
+
+
+5. CRMF の規約 +
+
+
+
+
+

+This section specifies the conventions for using the attribute for statement of possession of a private key with the CRMF [RFC4211] when requesting a key establishment certificate. +

+
+
+

+このセクションでは、鍵確立証明書を要求する際に、CRMF [RFC4211] で秘密鍵の所有を宣言するための属性を使用するための規則を指定します。 +

+
+
+
+
+

+The following ASN.1 types are defined for use with CRMF. They have exactly the same semantics and syntax as the attribute discussed above, but they offer a similar naming convention to the Registration Controls in [RFC4211]. +

+
+
+

+次の ASN.1 タイプは、CRMF で使用するために定義されています。これらは、上で説明した属性とまったく同じセマンティクスと構文を持ちますが、[RFC4211] の登録コントロールと同様の命名規則を提供します。 +

+
+
+
+
+ 
+     regCtrl-privateKeyPossessionStatement ATTRIBUTE ::=
+       privateKeyPossessionStatement
+
+     id-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=
+       id-at-statementOfPossession
+
+
+
+
+
+

+The CRMF CertificationRequest always has three components, as follows: +

+
+
+

+CRMF CertificationRequest には、次の 3 つのコンポーネントが常に含まれます。 +

+
+
+
+
+

+certReq: +

+
+
+

+証明書要求: +

+
+
+
+
+

+The certTemplate MUST include the subject and the publicKey components. The same subject name SHOULD match the subject name in the signature certificate, and publicKey MUST contain the public key for the key establishment algorithm. +

+
+
+

+certTemplate には、件名と publicKey コンポーネントが含まれなければなりません。同じサブジェクト名が署名証明書内のサブジェクト名と一致する必要があり (SHOULD)、publicKey には鍵確立アルゴリズムの公開鍵が含まれなければなりません (MUST)。 +

+
+
+
+
+

+popo: +

+
+
+

+ポポ: +

+
+
+
+
+

+The ProofOfPossession MUST use the signature CHOICE, the poposkInput MUST be present, POPOSigningKeyInput.authInfo MUST use the sender CHOICE, the sender SHOULD be set to the subject name that appears in the signature certificate, the publicKey MUST contain a copy of the public key from the certTemplate, the algorithmIdentifier MUST identify a signature algorithm that can be validated with the public key in the signature certificate, the signature over the poposkInput MUST validate with the public key in the signature certificate, and certification path validation for the signature certificate MUST be successful as specified in Section 6 of [RFC5280]. +

+
+
+

+ProofOfPossession は署名 CHOICE を使用しなければならず、poposkInput が存在しなければならず、POPOSigningKeyInput.authInfo は送信者 CHOICE を使用しなければならず、送信者は署名証明書に表示されるサブジェクト名に設定される必要があり、publicKey には certTemplate からの公開鍵のコピーが含まれなければならず、algorithmIdentifier は署名証明書内の公開鍵で検証できる署名アルゴリズムを識別しなければなりません。署名終了
PoposkInput は、署名証明書内の公開鍵を使用して検証しなければならず (MUST)、[RFC5280] のセクション 6 に規定されているように、署名証明書の証明書パスの検証が成功しなければなりません (MUST)。 +

+
+
+
+
+

+regInfo: +

+
+
+

+登録情報: +

+
+
+
+
+

+The attributes MUST include the privateKeyPossessionStatement attribute as specified in Section 3 of this document. +

+
+
+

+このドキュメントのセクション 3 で指定されているように、属性には privateKeyPossessionStatement 属性を含める必要があります。 +

+
+
+
+
+
+6. Security Considerations +
+
+
+
+6. セキュリティに関する考慮事項 +
+
+
+
+
+

+The privateKeyPossessionStatement attribute MUST NOT be used to obtain a signature certificate. Performing proof of possession of the signature private key is easily accomplished by signing the certificate request. +

+
+
+

+privateKeyPossessionStatement 属性を署名証明書の取得に使用してはなりません (MUST NOT)。署名秘密キーの所有証明は、証明書要求に署名することで簡単に実行できます。 +

+
+
+
+
+

+The subject is signing the privateKeyPossessionStatement attribute to tell the CA that it has possession of the key establishment private key. This is being done instead of providing technical proof of possession. If the subject has lost control of the signature private key, then the signed privateKeyPossessionStatement attribute could be generated by some other party. Timely revocation of the compromised signature certificate is the only protection against such loss of control. +

+
+
+

+サブジェクトは、privateKeyPossessionStatement 属性に署名して、キー確立秘密キーを所有していることを CA に伝えます。これは、所有の技術的証拠を提供する代わりに行われます。サブジェクトが署名秘密キーの制御を失った場合、署名された privateKeyPossessionStatement 属性が他の当事者によって生成される可能性があります。侵害された署名証明書を適時に取り消すことが、このような制御の喪失を防ぐ唯一の方法です。 +

+
+
+
+
+

+If the CA revokes a compromised signature certificate, then the CA SHOULD also revoke all key establishment certificates that were obtained with privateKeyPossessionStatement attributes signed by that compromised signature certificate. +

+
+
+

+CA が侵害された署名証明書を取り消す場合、CA は、その侵害された署名証明書によって署名された privateKeyPossessionStatement 属性を使用して取得されたすべての鍵確立証明書も取り消す必要があります (SHOULD)。 +

+
+
+
+
+

+The signature key pair and the key establishment key pair are expected to have roughly the same security strength. To ensure that the signature on the statement is not the weakest part of the certificate enrollment, the signature key pair SHOULD be at least as strong as the key establishment key pair. +

+
+
+

+署名キー ペアとキー確立キー ペアは、ほぼ同じセキュリティ強度を持つことが期待されます。ステートメントの署名が証明書登録の最も弱い部分にならないようにするには、署名キー ペアは少なくともキー確立キー ペアと同じくらい強力である必要があります (SHOULD)。 +

+
+
+
+
+

+If a CA allows a subject in the key establishment certificate to be different than the subject name in the signature certificate, then certificate policy MUST describe how to determine that the two subject names identify the same entity. Likewise, if a CA allows subject alternative names in the key establishment certificate that are not present in the signature certificate, then certificate policy MUST describe how to determine that the subject alternative names identify the same entity as is named in the signature certificate. +

+
+
+

+CA が鍵確立証明書のサブジェクトが署名証明書のサブジェクト名と異なることを許可する場合、証明書ポリシーは、2 つのサブジェクト名が同じエンティティを識別することを判断する方法を記述しなければなりません (MUST)。同様に、CA が署名証明書に存在しないサブジェクト代替名を鍵確立証明書で許可する場合、証明書ポリシーは、サブジェクト代替名が署名証明書に指定されているものと同じエンティティを識別することを決定する方法を記述しなければなりません (MUST)。 +

+
+
+
+
+
+7. IANA Considerations +
+
+
+
+7. IANAの考慮事項 +
+
+
+
+
+

+For the ASN.1 Module in Appendix A of this document, IANA has assigned an object identifier (OID) for the module identifier (118) with a Description of "id-mod-private-key-possession-stmt-2025" in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). +

+
+
+

+この文書の付録 A の ASN.1 モジュールについて、IANA は、「SMI Security for PKIX Module Identifier」レジストリ (1.3.6.1.5.5.7.0) 内の「id-mod-private-key-possession-stmt-2025」の説明を持つモジュール識別子 (118) にオブジェクト識別子 (OID) を割り当てました。 +

+
+
+
+
+
+8. References +
+
+
+
+8. 参考文献 +
+
+
+
+
+
+8.1. Normative References +
+
+
+
+8.1. 引用文献 +
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
+              Request Syntax Specification Version 1.7", RFC 2986,
+              DOI 10.17487/RFC2986, November 2000,
+              <https://www.rfc-editor.org/info/rfc2986>.
+
+
+
+
+
+ 
+   [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure
+              Certificate Request Message Format (CRMF)", RFC 4211,
+              DOI 10.17487/RFC4211, September 2005,
+              <https://www.rfc-editor.org/info/rfc4211>.
+
+
+
+
+
+ 
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+
+
+
+
+ 
+   [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
+              Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
+              DOI 10.17487/RFC5912, June 2010,
+              <https://www.rfc-editor.org/info/rfc5912>.
+
+
+
+
+
+ 
+   [RFC6268]  Schaad, J. and S. Turner, "Additional New ASN.1 Modules
+              for the Cryptographic Message Syntax (CMS) and the Public
+              Key Infrastructure Using X.509 (PKIX)", RFC 6268,
+              DOI 10.17487/RFC6268, July 2011,
+              <https://www.rfc-editor.org/info/rfc6268>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [X680]     ITU-T, "Information technology -- Abstract Syntax Notation
+              One (ASN.1): Specification of basic notation", ITU-T
+              Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
+              <https://www.itu.int/rec/T-REC-X.680>.
+
+
+
+
+
+ 
+   [X690]     ITU-T, "Information technology -- ASN.1 encoding rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
+              February 2021, <https://www.itu.int/rec/T-REC-X.690>.
+
+
+
+
+
+
+8.2. Informative References +
+
+
+
+8.2. 参考引用 +
+
+
+
+
+ 
+   [RFC3647]  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
+              Wu, "Internet X.509 Public Key Infrastructure Certificate
+              Policy and Certification Practices Framework", RFC 3647,
+              DOI 10.17487/RFC3647, November 2003,
+              <https://www.rfc-editor.org/info/rfc3647>.
+
+
+
+
+
+ 
+   [RFC6955]  Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
+              of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
+              May 2013, <https://www.rfc-editor.org/info/rfc6955>.
+
+
+
+
+
+
+Appendix A. ASN.1 Module +
+
+
+
+付録A. ASN.1モジュール +
+
+
+
+
+

+This ASN.1 Module uses the conventions established by [RFC5912] and [RFC6268]. +

+
+
+

+この ASN.1 モジュールは、[RFC5912] および [RFC6268] によって確立された規則を使用します。 +

+
+
+
+
+ 
+   PrivateKeyPossessionStatement-2025
+     { iso(1) identified-organization(3) dod(6) internet(1)
+       security(5) mechanisms(5) pkix(7) id-mod(0)
+       id-mod-private-key-possession-stmt-2025(118) }
+
+   DEFINITIONS IMPLICIT TAGS ::= BEGIN
+
+   EXPORTS ALL;
+
+   IMPORTS
+     ATTRIBUTE
+     FROM PKIX-CommonTypes-2009 -- in [RFC5912]
+       { iso(1) identified-organization(3) dod(6) internet(1)
+         security(5) mechanisms(5) pkix(7) id-mod(0)
+         id-mod-pkixCommon-02(57) }
+
+     Certificate
+     FROM PKIX1Explicit-2009 -- in [RFC5912]
+       { iso(1) identified-organization(3) dod(6) internet(1)
+         security(5) mechanisms(5) pkix(7) id-mod(0)
+         id-mod-pkix1-explicit-02(51) }
+
+     IssuerAndSerialNumber
+     FROM CryptographicMessageSyntax-2010 -- [RFC6268]
+       { iso(1) member-body(2) us(840) rsadsi(113549)
+          pkcs(1) pkcs-9(9) smime(16) modules(0)
+          id-mod-cms-2009(58) } ;
+
+   --
+   -- Private Key Possession Statement Attribute
+   --
+
+   id-at-statementOfPossession OBJECT IDENTIFIER ::=
+     { 1 3 6 1 4 1 22112 2 1 }
+
+   privateKeyPossessionStatement ATTRIBUTE ::= {
+     TYPE PrivateKeyPossessionStatement
+     IDENTIFIED BY id-at-statementOfPossession }
+
+   PrivateKeyPossessionStatement ::= SEQUENCE {
+     signer  IssuerAndSerialNumber,
+     cert    Certificate OPTIONAL }
+
+   --
+   -- Registration Control Support
+   --
+
+   RegControlSet ATTRIBUTE ::=
+     { regCtrl-privateKeyPossessionStatement, ... }
+
+   regCtrl-privateKeyPossessionStatement ATTRIBUTE ::=
+     privateKeyPossessionStatement
+
+   id-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=
+     id-at-statementOfPossession
+
+   END
+
+
+
+
+
+
+Appendix B. Example Use of the privateKeyPossessionStatement Attribute +
+
+
+
+付録B. privateKeyPossessionStatement 属性の使用例 +
+
+
+
+
+

+In this example, the self-signed certificate for the CA is as follows: +

+
+
+

+この例では、CA の自己署名証明書は次のとおりです。 +

+
+
+
+
+ 
+   -----BEGIN CERTIFICATE-----
+   MIIB7DCCAXKgAwIBAgIUL149AUxHunELBZMELEQm+isgKCQwCgYIKoZIzj0EAwMw
+   NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh
+   LmV4YW1wbGUwHhcNMjUwMTAzMjAyNzA5WhcNMzUwMTAzMjAyNzA5WjA3MQswCQYD
+   VQQGEwJVUzETMBEGA1UEChMKRXhhbXBsZSBDQTETMBEGA1UEAxMKY2EuZXhhbXBs
+   ZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABDxZdB/Glcxdk1p6Jf1j5en6QfliY9OS
+   fjZbtje/w6M58PN8Sb3VFln1rPdvD17UXeazSG9Hr/Dq3enbsHHO0pPntcFOgb8n
+   r8R8LUGhxRzjlxkaEJN+pa6Nf7qk49JDeaM/MD0wDwYDVR0TAQH/BAUwAwEB/zAL
+   BgNVHQ8EBAMCAgQwHQYDVR0OBBYEFD6YvLLv3DQbvnGS0qP6bbzyZkCqMAoGCCqG
+   SM49BAMDA2gAMGUCMGfb61IigoJ3QDnlsRdoktREHe0Dpm6DKw3qOyLL6A0cFK9Z
+   g8m11xIwvptlran52gIxAK1VrOjzRsFiHRptO+gFXstTXnQkKBb2/3WQz2SqcIS/
+   BWEp+siJ19OXOlz6APDB7w==
+   -----END CERTIFICATE-----
+
+
+
+
+
+

+Alice generates her ECDSA signature key pair. Then, Alice composes a PKCS#10 Certificate Signing Request (CSR) in the usual manner as specified in [RFC2986]. The CSR includes a signature that is produced with her ECDSA private key. The CSR is as follows: +

+
+
+

+アリスは ECDSA 署名鍵ペアを生成します。次に、アリスは [RFC2986] で指定されている通常の方法で PKCS#10 証明書署名要求 (CSR) を作成します。CSR には、彼女の ECDSA 秘密キーを使用して生成された署名が含まれています。CSRは以下の通りです。 +

+
+
+
+
+ 
+   -----BEGIN CERTIFICATE REQUEST-----
+   MIIBhTCCAQsCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH
+   EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB2MBAGByqGSM49AgEGBSuBBAAiA2IA
+   BIAc+6lXN1MIM/82QeWNb55H0zr+lVgWVeF0bf4jzxCb5MCjVaM0eFEvcjXMV5p4
+   kzqiJTHC0V2JAoqYMX/DMFIcwZ7xP9uQd9ep6KZ+RXut211L8+W1QI1QJSDNxANR
+   saBQME4GCSqGSIb3DQEJDjFBMD8wDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCB4Aw
+   IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wCgYIKoZIzj0EAwMD
+   aAAwZQIwPa2rOCe60edAF43C/t57IW8liyy+69FE04hMAFgw3Ga+nR+8zDuUsVLw
+   xXGAHtcDAjEA6LbvNkZjo6j2z5xRIjrHzEbGgiV4MF4xtnpfSSRI4dB0zT52bWkj
+   TZsuS1YWIkjt
+   -----END CERTIFICATE REQUEST-----
+
+
+
+
+
+

+The CA issues a signature certificate to Alice: +

+
+
+

+CA は、アリスに署名証明書を発行します。 +

+
+
+
+
+ 
+   -----BEGIN CERTIFICATE-----
+   MIICJzCCAa6gAwIBAgIUf3Sj/ANs4hR4XFlhTm+N8kxHqHkwCgYIKoZIzj0EAwMw
+   NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh
+   LmV4YW1wbGUwHhcNMjUwMTA5MTcwMzQ4WhcNMjYwMTA5MTcwMzQ4WjA8MQswCQYD
+   VQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT
+   BUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEgBz7qVc3Uwgz/zZB5Y1vnkfT
+   Ov6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxXmniTOqIlMcLRXYkCipgxf8MwUhzB
+   nvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3EA1Gxo3YwdDAMBgNVHRMBAf8EAjAA
+   MAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A0f7tCzkQEZgYzH3NcM2L05IwHwYD
+   VR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJmQKowFwYDVR0gBBAwDjAMBgpghkgB
+   ZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/Uypd7BaVnUjB36UtX9m5ZmPi78y5
+   1RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIwRJ6U91048NAb3nicHcrGFf1UYrhb
+   DlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u
+   -----END CERTIFICATE-----
+
+
+
+
+
+

+Alice generates her ECDH key establishment key pair. Then, Alice composes a PKCS#10 CSR. The CSR attributes include the privateKeyPossessionStatement attribute, which points to her ECDSA signature certificate. The CSR includes her ECDH public key and a signature that is produced with her ECDSA private key. The CSR is as follows: +

+
+
+

+アリスは、ECDH 鍵確立鍵ペアを生成します。次に、アリスは PKCS#10 CSR を作成します。CSR 属性には、ECDSA 署名証明書を指す privateKeyPossessionStatement 属性が含まれます。CSR には、彼女の ECDH 公開キーと、ECDSA 秘密キーを使用して生成された署名が含まれています。CSRは以下の通りです。 +

+
+
+
+
+ 
+   -----BEGIN CERTIFICATE REQUEST-----
+   MIIEMTCCA7gCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH
+   EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB0MA4GBSuBBAEMBgUrgQQAIgNiAAQB
+   RyQTH+cq1s5F94uFqFe7l1LqGdEC8Tm+e5VYBCfKAC8MJySQMj1GixEEXL+1Wjtg
+   23XvnJouCDoxSpDCSMqf3kvp5+naM37uxa3ZYgD6DPY3me5EZvyZPvSRJTFl/Bag
+   ggL9MGcGCSqGSIb3DQEJDjFaMFgwDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCAwgw
+   IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wFwYDVR0gBBAwDjAM
+   BgpghkgBZQMCATAwMIICkAYKKwYBBAGBrGACATGCAoAwggJ8ME8wNzELMAkGA1UE
+   BhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUC
+   FH90o/wDbOIUeFxZYU5vjfJMR6h5MIICJzCCAa6gAwIBAgIUf3Sj/ANs4hR4XFlh
+   Tm+N8kxHqHkwCgYIKoZIzj0EAwMwNzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4
+   YW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUwHhcNMjUwMTA5MTcwMzQ4WhcN
+   MjYwMTA5MTcwMzQ4WjA8MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNV
+   BAcTB0hlcm5kb24xDjAMBgNVBAMTBUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACID
+   YgAEgBz7qVc3Uwgz/zZB5Y1vnkfTOv6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxX
+   mniTOqIlMcLRXYkCipgxf8MwUhzBnvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3E
+   A1Gxo3YwdDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A
+   0f7tCzkQEZgYzH3NcM2L05IwHwYDVR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJm
+   QKowFwYDVR0gBBAwDjAMBgpghkgBZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/
+   Uypd7BaVnUjB36UtX9m5ZmPi78y51RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIw
+   RJ6U91048NAb3nicHcrGFf1UYrhbDlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u
+   MAoGCCqGSM49BAMDA2cAMGQCL2TNHPULWcCS2DqZCCiQeSwx2JPLMI14Vi977bzy
+   rImq5p0H3Bel6fAS8BnQ00WNAjEAhHDAlcbRuHhqdW6mOgDd5kWEGGqgixIuvEEc
+   fVbnNCEyEE4n0mQ99PHURnXoHwqF
+   -----END CERTIFICATE REQUEST-----
+
+
+
+
+
+

+The CSR decodes to the following: +

+
+
+

+CSR は次のようにデコードされます。 +

+
+
+
+
+ 
+      0 1073: SEQUENCE {
+      4  952:  SEQUENCE {
+      8    1:   INTEGER 0
+     11   60:   SEQUENCE {
+     13   11:    SET {
+     15    9:     SEQUENCE {
+     17    3:      OBJECT IDENTIFIER countryName (2 5 4 6)
+     22    2:      PrintableString 'US'
+            :       }
+            :      }
+     26   11:    SET {
+     28    9:     SEQUENCE {
+     30    3:      OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
+     35    2:      PrintableString 'VA'
+            :       }
+            :      }
+     39   16:    SET {
+     41   14:     SEQUENCE {
+     43    3:      OBJECT IDENTIFIER localityName (2 5 4 7)
+     48    7:      PrintableString 'Herndon'
+            :       }
+            :      }
+     57   14:    SET {
+     59   12:     SEQUENCE {
+     61    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
+     66    5:      PrintableString 'Alice'
+            :       }
+            :      }
+            :     }
+     73  116:   SEQUENCE {
+     75   14:    SEQUENCE {
+     77    5:     OBJECT IDENTIFIER ECDH (1 3 132 1 12)
+     84    5:     OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
+            :      }
+     91   98:    BIT STRING
+            :     04 01 47 24 13 1F E7 2A D6 CE 45 F7 8B 85 A8 57
+            :     BB 97 52 EA 19 D1 02 F1 39 BE 7B 95 58 04 27 CA
+            :     00 2F 0C 27 24 90 32 3D 46 8B 11 04 5C BF B5 5A
+            :     3B 60 DB 75 EF 9C 9A 2E 08 3A 31 4A 90 C2 48 CA
+            :     9F DE 4B E9 E7 E9 DA 33 7E EE C5 AD D9 62 00 FA
+            :     0C F6 37 99 EE 44 66 FC 99 3E F4 91 25 31 65 FC
+            :     16
+            :     }
+    191  765:   [0] {
+    195  103:    SEQUENCE {
+    197    9:     OBJECT IDENTIFIER
+            :      extensionRequest (1 2 840 113549 1 9 14)
+    208   90:     SET {
+    210   88:      SEQUENCE {
+    212   12:       SEQUENCE {
+    214    3:        OBJECT IDENTIFIER
+            :         basicConstraints (2 5 29 19)
+    219    1:        BOOLEAN TRUE
+    222    2:        OCTET STRING, encapsulates {
+    224    0:         SEQUENCE {}
+            :          }
+            :         }
+    226   11:       SEQUENCE {
+    228    3:        OBJECT IDENTIFIER keyUsage (2 5 29 15)
+    233    4:        OCTET STRING, encapsulates {
+    235    2:         BIT STRING 3 unused bits
+            :          '10000'B (bit 4)
+            :          }
+            :         }
+    239   34:       SEQUENCE {
+    241    3:        OBJECT IDENTIFIER subjectAltName (2 5 29 17)
+    246   27:        OCTET STRING, encapsulates {
+    248   25:         SEQUENCE {
+    250   23:          [1] 'alice@email.example.com'
+            :           }
+            :          }
+            :         }
+    275   23:       SEQUENCE {
+    277    3:        OBJECT IDENTIFIER
+            :         certificatePolicies (2 5 29 32)
+    282   16:        OCTET STRING, encapsulates {
+    284   14:         SEQUENCE {
+    286   12:          SEQUENCE {
+    288   10:           OBJECT IDENTIFIER
+            :            testCertPolicy (2 16 840 1 101 3 2 1 48 48)
+            :            }
+            :           }
+            :          }
+            :         }
+            :        }
+            :       }
+            :      }
+    300  656:    SEQUENCE {
+    304   10:     OBJECT IDENTIFIER
+            :      statementOfPossession (1 3 6 1 4 1 22112 2 1)
+    316  640:     SET {
+    320  636:      SEQUENCE {
+    324   79:       SEQUENCE {
+    326   55:        SEQUENCE {
+    328   11:         SET {
+    330    9:          SEQUENCE {
+    332    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
+    337    2:           PrintableString 'US'
+            :            }
+            :           }
+    341   19:         SET {
+    343   17:          SEQUENCE {
+    345    3:           OBJECT IDENTIFIER
+            :            organizationName (2 5 4 10)
+    350   10:           PrintableString 'Example CA'
+            :            }
+            :           }
+    362   19:         SET {
+    364   17:          SEQUENCE {
+    366    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
+    371   10:           PrintableString 'ca.example'
+            :            }
+            :           }
+            :          }
+    383   20:        INTEGER
+            :      7F 74 A3 FC 03 6C E2 14 78 5C 59 61 4E 6F 8D F2
+            :      4C 47 A8 79
+            :         }
+    405  551:       SEQUENCE {
+    409  430:        SEQUENCE {
+    413    3:         [0] {
+    415    1:          INTEGER 2
+            :           }
+    418   20:         INTEGER
+            :      7F 74 A3 FC 03 6C E2 14 78 5C 59 61 4E 6F 8D F2
+            :      4C 47 A8 79
+    440   10:         SEQUENCE {
+    442    8:          OBJECT IDENTIFIER
+            :           ecdsaWithSHA384 (1 2 840 10045 4 3 3)
+            :           }
+    452   55:         SEQUENCE {
+    454   11:          SET {
+    456    9:           SEQUENCE {
+    458    3:            OBJECT IDENTIFIER
+            :             countryName (2 5 4 6)
+    463    2:            PrintableString 'US'
+            :             }
+            :            }
+    467   19:          SET {
+    469   17:           SEQUENCE {
+    471    3:            OBJECT IDENTIFIER
+            :             organizationName (2 5 4 10)
+    476   10:            PrintableString 'Example CA'
+            :             }
+            :            }
+    488   19:          SET {
+    490   17:           SEQUENCE {
+    492    3:            OBJECT IDENTIFIER
+            :             commonName (2 5 4 3)
+    497   10:            PrintableString 'ca.example'
+            :             }
+            :            }
+            :           }
+    509   30:         SEQUENCE {
+    511   13:          UTCTime 09/01/2025 17:03:48 GMT
+    526   13:          UTCTime 09/01/2026 17:03:48 GMT
+            :           }
+    541   60:         SEQUENCE {
+    543   11:          SET {
+    545    9:           SEQUENCE {
+    547    3:            OBJECT IDENTIFIER
+            :             countryName (2 5 4 6)
+    552    2:            PrintableString 'US'
+            :             }
+            :            }
+    556   11:          SET {
+    558    9:           SEQUENCE {
+    560    3:            OBJECT IDENTIFIER
+            :             stateOrProvinceName (2 5 4 8)
+    565    2:            PrintableString 'VA'
+            :             }
+            :            }
+    569   16:          SET {
+    571   14:           SEQUENCE {
+    573    3:            OBJECT IDENTIFIER
+            :             localityName (2 5 4 7)
+    578    7:            PrintableString 'Herndon'
+            :             }
+            :            }
+    587   14:          SET {
+    589   12:           SEQUENCE {
+    591    3:            OBJECT IDENTIFIER
+            :             commonName (2 5 4 3)
+    596    5:            PrintableString 'Alice'
+            :             }
+            :            }
+            :           }
+    603  118:         SEQUENCE {
+    605   16:          SEQUENCE {
+    607    7:           OBJECT IDENTIFIER
+            :            ecPublicKey (1 2 840 10045 2 1)
+    616    5:           OBJECT IDENTIFIER
+            :            secp384r1 (1 3 132 0 34)
+            :            }
+    623   98:          BIT STRING
+            :      04 80 1C FB A9 57 37 53 08 33 FF 36 41 E5 8D 6F
+            :      9E 47 D3 3A FE 95 58 16 55 E1 74 6D FE 23 CF 10
+            :      9B E4 C0 A3 55 A3 34 78 51 2F 72 35 CC 57 9A 78
+            :      93 3A A2 25 31 C2 D1 5D 89 02 8A 98 31 7F C3 30
+            :      52 1C C1 9E F1 3F DB 90 77 D7 A9 E8 A6 7E 45 7B
+            :      AD DB 5D 4B F3 E5 B5 40 8D 50 25 20 CD C4 03 51
+            :      B1
+            :           }
+    723  118:         [3] {
+    725  116:          SEQUENCE {
+    727   12:           SEQUENCE {
+    729    3:            OBJECT IDENTIFIER
+            :             basicConstraints (2 5 29 19)
+    734    1:            BOOLEAN TRUE
+    737    2:            OCTET STRING, encapsulates {
+    739    0:             SEQUENCE {}
+            :              }
+            :             }
+    741   11:           SEQUENCE {
+    743    3:            OBJECT IDENTIFIER
+            :             keyUsage (2 5 29 15)
+    748    4:            OCTET STRING, encapsulates {
+    750    2:             BIT STRING 7 unused bits
+            :              '1'B (bit 0)
+            :              }
+            :             }
+    754   29:           SEQUENCE {
+    756    3:            OBJECT IDENTIFIER
+            :             subjectKeyIdentifier (2 5 29 14)
+    761   22:            OCTET STRING, encapsulates {
+    763   20:             OCTET STRING
+            :      23 1D 00 D1 FE ED 0B 39 10 11 98 18 CC 7D CD 70
+            :      CD 8B D3 92
+            :              }
+            :             }
+    785   31:           SEQUENCE {
+    787    3:            OBJECT IDENTIFIER
+            :             authorityKeyIdentifier (2 5 29 35)
+    792   24:            OCTET STRING, encapsulates {
+    794   22:             SEQUENCE {
+    796   20:              [0]
+            :      3E 98 BC B2 EF DC 34 1B BE 71 92 D2 A3 FA 6D BC
+            :      F2 66 40 AA
+            :               }
+            :              }
+            :             }
+    818   23:           SEQUENCE {
+    820    3:            OBJECT IDENTIFIER
+            :             certificatePolicies (2 5 29 32)
+    825   16:            OCTET STRING, encapsulates {
+    827   14:             SEQUENCE {
+    829   12:              SEQUENCE {
+    831   10:               OBJECT IDENTIFIER
+            :                testCertPolicy (2 16 840 1 101 3 2 1 48 48)
+            :                }
+            :               }
+            :              }
+            :             }
+            :            }
+            :           }
+            :          }
+    843   10:        SEQUENCE {
+    845    8:         OBJECT IDENTIFIER
+            :          ecdsaWithSHA384 (1 2 840 10045 4 3 3)
+            :          }
+    855  103:        BIT STRING, encapsulates {
+    858  100:         SEQUENCE {
+    860   48:          INTEGER
+            :      6B BF 53 2A 5D EC 16 95 9D 48 C1 DF A5 2D 5F D9
+            :      B9 66 63 E2 EF CC B9 D5 10 3C 5A 16 CE BF 42 90
+            :      56 B7 18 B6 3E 2A 39 D8 8C 54 A0 5C A1 57 1E C8
+    910   48:          INTEGER
+            :      44 9E 94 F7 5D 38 F0 D0 1B DE 78 9C 1D CA C6 15
+            :      FD 54 62 B8 5B 0E 5C AD 2B 8B 42 6B 91 C1 C4 3F
+            :      EA 02 0C B8 FD E5 33 03 93 59 C1 56 8B 2B BF 2E
+            :           }
+            :          }
+            :         }
+            :        }
+            :       }
+            :      }
+            :     }
+            :    }
+    960   10:  SEQUENCE {
+    962    8:   OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
+            :    }
+    972  103:  BIT STRING, encapsulates {
+    975  100:   SEQUENCE {
+    977   47:    INTEGER
+            :     64 CD 1C F5 0B 59 C0 92 D8 3A 99 08 28 90 79 2C
+            :     31 D8 93 CB 30 8D 78 56 2F 7B ED BC F2 AC 89 AA
+            :     E6 9D 07 DC 17 A5 E9 F0 12 F0 19 D0 D3 45 8D
+   1026   49:    INTEGER
+            :     00 84 70 C0 95 C6 D1 B8 78 6A 75 6E A6 3A 00 DD
+            :     E6 45 84 18 6A A0 8B 12 2E BC 41 1C 7D 56 E7 34
+            :     21 32 10 4E 27 D2 64 3D F4 F1 D4 46 75 E8 1F 0A
+            :     85
+            :     }
+            :    }
+            :   }
+
+
+
+
+
+

+The CA issues a key establishment certificate to Alice: +

+
+
+

+CA は鍵確立証明書をアリスに発行します。 +

+
+
+
+
+ 
+   -----BEGIN CERTIFICATE-----
+   MIICJTCCAaygAwIBAgIUf3Sj/ANs4hR4XFlhTm+N8kxHqHowCgYIKoZIzj0EAwMw
+   NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh
+   LmV4YW1wbGUwHhcNMjUwMTA5MTcwNTAwWhcNMjYwMTA5MTcwNTAwWjA8MQswCQYD
+   VQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT
+   BUFsaWNlMHQwDgYFK4EEAQwGBSuBBAAiA2IABAFHJBMf5yrWzkX3i4WoV7uXUuoZ
+   0QLxOb57lVgEJ8oALwwnJJAyPUaLEQRcv7VaO2Dbde+cmi4IOjFKkMJIyp/eS+nn
+   6dozfu7FrdliAPoM9jeZ7kRm/Jk+9JElMWX8FqN2MHQwDAYDVR0TAQH/BAIwADAL
+   BgNVHQ8EBAMCAwgwHQYDVR0OBBYEFAnLfJvnEUcvLXaPUDZMZlQ/zZ3WMB8GA1Ud
+   IwQYMBaAFD6YvLLv3DQbvnGS0qP6bbzyZkCqMBcGA1UdIAQQMA4wDAYKYIZIAWUD
+   AgEwMDAKBggqhkjOPQQDAwNnADBkAjARQ5LuV6yz8A5DZCll1S/gfxZ+QSJl/pKc
+   cTL6Sdr1IS18U/zY8VUJeB2H0nBamLwCMBRQ6sEWpNoeeR8Bonpoot/zYD2luQ1V
+   2jevmYsnBihKF0debgfhGvh8WIgBR69DZg==
+   -----END CERTIFICATE-----
+
+
+
+
+
+
+Acknowledgements +
+
+
+
+謝辞 +
+
+
+
+
+

+Thanks to Sean Turner, Joe Mandel, Mike StJohns, Mike Ounsworth, John Gray, Carl Wallace, Corey Bonnell, Hani Ezzadeen, Deb Cooley, Mohamed Boucadair, and Bron Gondwana for their constructive comments. +

+
+
+

+Sean Turner、Joe Mandel、Mike StJohns、Mike Ounsworth、John Gray、Carl Wallace、Corey Bonnell、Hani Ezzadeen、Deb Cooley、Mohamed Boucadair、Bron Gondwana の建設的なコメントに感謝します。 +

+
+
+
+
+
+Author's Address +
+
+
+
+著者の連絡先 +
+
+
+
+
+ 
+   Russ Housley
+   Vigil Security, LLC
+   Herndon, VA
+   United States of America
+   Email: housley@vigilsec.com
+
+
+
+
+ + +