Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 9986 InkBridge Networks
Category: Experimental M. Jethanandani
ISSN: 2070-1721 Arrcus
S. Agarwal
Arrcus, Inc.
A. Mishra
Aalyria Technologies
J. Haas
HPE
June 2026
This document describes a Bidirectional Forwarding Detection (BFD) Optimized Authentication Mode known as Meticulous Keyed ISAAC Authentication. This mode can be used to authenticate some BFD packets with less CPU time cost than using MD5 or SHA-1 with the trade-off of decreased security. This mechanism cannot be used to signal state changes, but it can be used to maintain a session in the Up state.
このドキュメントでは、Meticulous Keyed ISAAC Authentication として知られる双方向転送検出 (BFD) 最適化認証モードについて説明します。このモードを使用すると、セキュリティが低下する代わりに、MD5 または SHA-1 を使用するよりも少ない CPU 時間コストで一部の BFD パケットを認証できます。このメカニズムは、状態変化を通知するために使用することはできませんが、セッションを Up 状態に維持するために使用できます。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書は Internet Standards Track 仕様ではありません。試験、実験実装、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネット コミュニティ向けの実験プロトコルを定義します。このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。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/rfc9986.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9986 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Meticulous Keying
1.2. Requirements Language
2. Experimental Extensions to RFC 5880
3. Architecture of the Auth Type Method
3.1. Rationale for ISAAC and Operational Overview
4. Meticulous Keyed ISAAC Authentication Types
4.1. Meticulous Keyed ISAAC Authentication, ISAAC Format
4.2. Meticulous Keyed ISAAC Authentication, MD5 Format
4.3. Meticulous Keyed ISAAC Authentication, SHA-1 Format
5. New State Variables for Meticulous Keyed ISAAC Authentications
6. Procedures for BFD Authentication Using Meticulous Keyed ISAAC,
MD5, or SHA-1 Formats
7. Procedures for BFD Authentication Using Meticulous Keyed ISAAC,
ISAAC Format
7.1. Transmission using Meticulous Keyed ISAAC Authentication,
ISAAC Format
7.2. Receipt using Meticulous Keyed ISAAC Authentication, ISAAC
Format
8. Secret Key
9. Transition to Using ISAAC
10. Seeding ISAAC
10.1. Sender Variable Initialization
10.2. Receiver Variable Initialization
11. Operation
11.1. Page Flipping
11.2. Multiple Keys
12. Transition Away from Using ISAAC
13. The YANG Module
14. IANA Considerations
14.1. BFD Auth Types
14.2. IETF XML Registry
14.3. The YANG Module Names Registry
15. Security Considerations
15.1. Protocol Security Considerations
15.1.1. Spoofing
15.1.2. Reuse of Keys
15.1.3. Random Number Considerations
15.2. YANG Security Considerations
16. References
16.1. Normative References
16.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
BFD (Section 6.7 of [RFC5880]) defines a number of authentication mechanisms, including Simple Password and various other methods based on MD5 and SHA-1 hashes. The benefit of using cryptographic hashes is that they are secure. The downside to cryptographic hashes is that they are expensive and time-consuming on resource-constrained hardware.
BFD ([RFC5880] のセクション 6.7) は、シンプル パスワードや MD5 および SHA-1 ハッシュに基づくその他のさまざまな方法を含む、多数の認証メカニズムを定義しています。暗号化ハッシュを使用する利点は、安全であることです。暗号化ハッシュの欠点は、リソースに制約のあるハードウェアでは高価で時間がかかることです。
When BFD packets are unauthenticated, it is possible for an attacker to forge, modify, and/or replay packets on a link. These attacks have a number of side effects. They can cause parties to believe that a link is down, or they can cause parties to believe that the link is up when it is, in fact, down.
BFD パケットが認証されていない場合、攻撃者がリンク上でパケットを偽造、変更、および/または再実行する可能性があります。これらの攻撃には多くの副作用があります。リンクがダウンしていると関係者に信じ込ませたり、実際にはリンクがダウンしているのにリンクがアップしていると関係者に信じ込ませたりする可能性があります。
[RFC9985] defines procedures that enable better scaling of authentication for BFD by splitting BFD Authentication work between more computationally intensive authentication used for significant changes, and less computationally intensive authentication for packets validating that the session is in the Up state. See [RFC9985] for general performance and security considerations.
[RFC9985] では、BFD 認証作業を、重要な変更に使用される計算量の多い認証と、セッションがアップ状態にあることを検証するパケットの計算量の少ない認証に分割することで、BFD の認証のスケーリングを向上させる手順を定義しています。一般的なパフォーマンスとセキュリティに関する考慮事項については、[RFC9985] を参照してください。
This document provides the definition of BFD Optimized Authentication Modes using the existing MD5 (Section 6.7.3 of [RFC5880]) and SHA-1 (Section 6.7.4 of [RFC5880]) Authentication mechanisms for the more computationally intensive work. It also defines methods for using a mechanism, ISAAC [ISAAC], for the less computationally intensive mechanism.
この文書は、より計算量の多い作業向けに、既存の MD5 ([RFC5880] のセクション 6.7.3) および SHA-1 ([RFC5880] のセクション 6.7.4) 認証メカニズムを使用した、BFD 最適化認証モードの定義を提供します。また、計算量の少ないメカニズムとして ISAAC [ISAAC] を使用する方法も定義しています。
ISAAC requires only a few CPU operations per generated 32-bit number, can take a large secret key as a seed, and it has an extremely long cycle length. These properties make it ideal for use in BFD.
ISAAC は、生成される 32 ビット数値ごとに数回の CPU 操作のみを必要とし、大きな秘密キーをシードとして使用でき、サイクル長が非常に長くなります。これらの特性により、BFD での使用に最適になります。
ISAAC+ [ISAAC-Plus] documents some cryptanalysis of the ISAAC mechanism. This analysis addressed an issue with initial seeding, and the method proposed here incorporates recommendations to address that attack.
ISAAC+ [ISAAC-Plus] は、ISAAC メカニズムの暗号解析の一部を文書化しています。この分析では初期シードの問題に対処しており、ここで提案されている方法には、その攻撃に対処するための推奨事項が組み込まれています。
[RFC5880] uses the term "meticulous keyed" and "meticulous keying" without defining those terms. That meaning of that term is found by examining the definition of the sequence number from [RFC5880] (Section 4.3):
[RFC5880] では、「細心の注意を払ったキーイング」および「細心の注意を払ったキーイング」という用語を定義せずに使用しています。この用語の意味は、[RFC5880] (セクション 4.3) のシーケンス番号の定義を調べることでわかります。
The sequence number for this packet. For Keyed MD5 Authentication, this value is incremented occasionally. For Meticulous Keyed MD5 Authentication, this value is incremented for each successive packet transmitted for a session. This provides protection against replay attacks.
このパケットのシーケンス番号。キー付き MD5 認証の場合、この値は時々増加します。Meticulous Keyed MD5 認証の場合、この値はセッションで送信される連続パケットごとに増加します。これにより、リプレイ攻撃に対する保護が提供されます。
In this context, the term "meticulous" means that the sequence number is incremented on every new packet that is sent. The term "keyed" means that the packets are authenticated via the use of a secret key or keys that are known to both sender and receiver. Therefore, the term "meticulous keyed" refers to the BFD Authentication type where each subsequently transmitted packet has a sequence number that is one greater than the immediately previous one and can be authenticated.
この文脈では、「細心の注意」という用語は、送信される新しいパケットごとにシーケンス番号がインクリメントされることを意味します。「鍵付き」という用語は、送信者と受信者の両方が知っている秘密鍵を使用してパケットが認証されることを意味します。したがって、「綿密なキー付き」という用語は、後続に送信される各パケットのシーケンス番号が直前のパケットより 1 つ大きく、認証できる BFD 認証タイプを指します。
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 describes an experimental extension to BFD [RFC5880]. This experiment is intended to provide additional insights into what happens when the authentication method defined in this document is used.
この文書では、BFD [RFC5880] の実験的拡張について説明します。この実験は、このドキュメントで定義されている認証方法が使用されたときに何が起こるかについての追加の洞察を提供することを目的としています。
This document is classified as Experimental and is not part of the IETF Standards Track. Implementations based on this document should not be considered as compliant with BFD [RFC5880] and should not assume interoperability with other implementations that conform to this document.
このドキュメントは実験版として分類されており、IETF 標準トラックの一部ではありません。この文書に基づく実装は、BFD [RFC5880] に準拠しているとみなされるべきではなく、この文書に準拠する他の実装との相互運用性を想定すべきではありません。
Some of the state variables in Section 6.8.1 of [RFC5880] are related to the authentication type being used for a particular session. However, the definitions given in [RFC5880] are specific to Keyed MD5 or SHA-1 Authentication, which limit their utility for new authentication types. This document presumes a relaxed definition for the following BFD state variables that does not limit them to MD5 and SHA-1 but instead extends them to the mechanism defined herein:
[RFC5880] のセクション 6.8.1 の状態変数の一部は、特定のセッションで使用される認証タイプに関連しています。ただし、[RFC5880] で与えられている定義は、鍵付き MD5 または SHA-1 認証に固有のものであり、新しい認証タイプに対する有用性が制限されています。このドキュメントでは、次の BFD 状態変数について、MD5 と SHA-1 に制限せず、ここで定義されているメカニズムに拡張する緩和された定義を前提としています。
* bfd.RcvAuthSeq
* bfd.RcvAuthSeq
* bfd.XmitAuthSeq
* bfd.XmitAuthSeq
* bfd.AuthSeqKnown
* bfd.AuthSeqKnown
This document specifies two Optimized BFD [RFC9985] Authentication Modes:
この文書では、2 つの最適化された BFD [RFC9985] 認証モードを指定します。
* For the more computationally intensive authentication mechanisms, the existing MD5 (Section 6.7.3 of [RFC5880]) and SHA-1 (Section 6.7.4 of [RFC5880]) Authentication mechanisms are leveraged with small PDU changes necessary to carry the Optimization Mode encoding. These changes are documented in Sections 4.2 and 4.3, respectively.
* より計算量の多い認証メカニズムの場合、既存の MD5 ([RFC5880] のセクション 6.7.3) および SHA-1 ([RFC5880] のセクション 6.7.4) 認証メカニズムが利用され、最適化モードのエンコーディングを実行するために必要な PDU の小さな変更が行われます。これらの変更は、それぞれセクション 4.2 と 4.3 に記載されています。
* For the less computationally intensive authentication mode, this document defines the Meticulous Keyed ISAAC Authentication mechanism. The PDU format for this mode is defined in Section 4.1. The procedures for using this format are covered later in this document.
* この文書では、計算量が少ない認証モードのために、Meticulous Keyed ISAAC Authentication メカニズムを定義します。このモードの PDU フォーマットはセクション 4.1 で定義されています。この形式を使用する手順については、このドキュメントで後ほど説明します。
ISAAC is used as a way to generate an infinite stream of pseudorandom numbers, referred to here as "Auth Keys". With Meticulous Keyed ISAAC Authentication, these Auth Keys are used as a signal that the sending party is authentic. That is, only the sending party can generate the correct Auth Keys. Therefore, if the receiving party sees a correct Auth Key in a BFD Control Packet in the Up state, then only the sending party could have generated it.
ISAAC は、ここでは「認証キー」と呼ばれる疑似乱数の無限ストリームを生成する方法として使用されます。Meticulous Keyed ISAAC 認証では、これらの認証キーは、送信側が本物であることを示す信号として使用されます。つまり、送信側のみが正しい認証キーを生成できます。したがって、受信側が Up 状態の BFD 制御パケット内の正しい認証キーを認識した場合、それを生成できたのは送信側だけである可能性があります。
Note that BFD Control Packets with the less computationally intensive ISAAC Authentication Format type are NOT signed or authenticated. Therefore, this format MUST NOT be used to signal BFD state changes.
計算量が少ない ISAAC 認証形式タイプの BFD 制御パケットは署名も認証もされないことに注意してください。したがって、この形式は BFD 状態の変化を通知するために使用してはなりません (MUST NOT)。
There are many cryptographically secure pseudorandom number generators (CSPRNGs) available. This section explains why ISAAC was chosen.
利用可能な暗号的に安全な擬似乱数生成器 (CSPRNG) が多数あります。このセクションでは、ISAAC が選ばれた理由について説明します。
The goal for this less computationally intensive authentication was to provide a signal that the session was in the Up state in the form of a 32-bit number, which is difficult for an attacker to guess. The number should be generated from a CSPRNG that produces results based on a Seed composed of both public and private data. Since BFD can have packet loss, the generator should also be "seekable" in that the BFD state machine should be able to query the generator (within a small window) for new numbers.
この計算量の少ない認証の目的は、攻撃者が推測するのが難しい 32 ビット数値の形式で、セッションがアップ状態にあるという信号を提供することでした。この番号は、パブリック データとプライベート データの両方で構成されるシードに基づいて結果を生成する CSPRNG から生成される必要があります。BFD にはパケット損失が発生する可能性があるため、BFD ステート マシンが (小さなウィンドウ内で) ジェネレータに新しい番号を問い合わせることができるという点で、ジェネレータも「シーク可能」である必要があります。
This last property rules out most CSPRNGs, as they are not seekable by design. That is, most CSPRNGs maintain minimal state and are designed to produce a long sequence of pseudorandom numbers from a few simple calculations. In general, every call to the CSPRNG function modifies the internal state in an irreversible fashion, and then produces a new random number as the result.
この最後のプロパティは、設計上シーク不可能であるため、ほとんどの CSPRNG を除外します。つまり、ほとんどの CSPRNG は最小限の状態を維持し、いくつかの単純な計算から長い一連の擬似乱数を生成するように設計されています。一般に、CSPRNG 関数を呼び出すたびに、内部状態が不可逆的な方法で変更され、その結果として新しい乱数が生成されます。
It could be possible to use such a generator and manually save many results in a buffer. This buffer could then enable "seeking" within a short window. In contrast, ISAAC produces large sets of numbers by design, making it an integrated solution.
このようなジェネレーターを使用して、多くの結果を手動でバッファーに保存することが可能になる可能性があります。このバッファにより、短いウィンドウ内での「シーク」が可能になります。対照的に、ISAAC は設計により大量の数値セットを生成し、統合ソリューションとしています。
Further, most CSPRNGs are designed to have small seeds. This limitation means that any secret key defined by an administrator is not directly usable as a Seed for the generator. Instead, any secret key (including any per-session data) would have to be hashed before being used to see the generator. For these reasons, ISAAC was chosen. It can accept keys up to 8192 octets in length, which is more than sufficient for BFD.
さらに、ほとんどの CSPRNG は小さなシードを持つように設計されています。この制限は、管理者が定義した秘密キーをジェネレーターのシードとして直接使用できないことを意味します。代わりに、秘密キー (セッションごとのデータを含む) は、ジェネレーターを表示するために使用される前にハッシュされる必要があります。これらの理由から、ISAAC が選ばれました。最大 8192 オクテットの長さのキーを受け入れることができ、BFD には十分以上です。
ISAAC has been subject to cryptanalysis, most notably ISAAC+ [ISAAC-Plus]. There are no known vulnerabilities.
ISAAC は暗号解析の対象となっており、特に ISAAC+ [ISAAC-Plus] が顕著です。既知の脆弱性はありません。
Two instances of ISAAC are created: one for transmission and one for reception. An instance is required for each direction since the inputs for seeding ISAAC require the locally randomly generated Seed value and the current BFD Your Discriminator value for an Up session. These values are distinct on each side of the BFD session.
ISAAC の 2 つのインスタンスが作成されます。1 つは送信用、もう 1 つは受信用です。ISAAC をシードするための入力には、ローカルでランダムに生成された Seed 値と Up セッションの現在の BFD Your Discriminator 値が必要であるため、各方向にインスタンスが必要です。これらの値は、BFD セッションの両側で異なります。
The process for using ISAAC with BFD for each direction is then as follows:
各方向の BFD で ISAAC を使用するプロセスは次のようになります。
* The administrator provides a secret key that is used to authenticate each party in the BFD sessions.
* 管理者は、BFD セッションの各当事者を認証するために使用される秘密キーを提供します。
* When the session transitions into the Up state, the secret key is combined with per-session data to seed ISAAC.
* セッションが Up 状態に移行すると、秘密キーがセッションごとのデータと結合されて、ISAAC がシードされます。
* The ISAAC process produces a "page" of 256 32-bit random numbers.
* ISAAC プロセスは、256 個の 32 ビット乱数の「ページ」を生成します。
* The BFD state machine also records a sequence number that is associated with the first entry of that page. The combination of 256 entries and the sequence number allows the BFD state machine to "seek" within a 256-packet window with zero cost through simple addition or subtraction of sequence numbers.
* BFD ステート マシンは、そのページの最初のエントリに関連付けられたシーケンス番号も記録します。256 個のエントリとシーケンス番号の組み合わせにより、BFD ステート マシンは、シーケンス番号の単純な加算または減算により、ゼロコストで 256 パケット ウィンドウ内を「シーク」できます。
* If there is a lost packet, the BFD state machine simply seeks to the entry that is associated with the received packet and checks if the received packet contains the expected number.
* 失われたパケットがある場合、BFD ステート マシンは受信したパケットに関連付けられたエントリを検索し、受信したパケットに予期された番号が含まれているかどうかを確認します。
* BFD supports packet rates of hundreds of packets per second. Even at those rates, 256 entries per ISAAC page provides for about a second of BFD operation before the next page has to be calculated.
* BFD は、1 秒あたり数百パケットのパケット レートをサポートします。これらのレートでも、ISAAC ページあたり 256 エントリにより、次のページが計算されるまでに約 1 秒間の BFD 操作が可能になります。
* As the next page calculation is complex, and there is a long period of time available before the next page is needed, this calculation can be done in the background.
* 次のページの計算は複雑で、次のページが必要になるまでに長い時間がかかるため、この計算はバックグラウンドで実行できます。
* If the next page calculation is started immediately after the current page is fully used, there should be sufficient time to calculate the next page as a background task, no matter what the packet rate.
* 現在のページが完全に使用された直後に次のページの計算が開始される場合、パケット レートに関係なく、バックグラウンド タスクとして次のページを計算するのに十分な時間が必要です。
In summary, the ISAAC Seed depends on both a secret key and per-session data, so it is difficult for an attacker to guess or attack via an offline dictionary attack. The generated numbers are saved in an array, where the BFD fast path can consume them at essentially zero cost.
要約すると、ISAAC シードは秘密キーとセッションごとのデータの両方に依存するため、攻撃者がオフライン辞書攻撃を介して推測したり攻撃したりすることは困難です。生成された数値は配列に保存され、BFD 高速パスはそれらを実質的にゼロコストで消費できます。
The only downside to this method is that it does not provide for per-packet integrity checks. This limitation is addressed by mandating that Meticulous Keyed ISAAC Authentication is only used to signal that the session remains in the Up state. The ISAAC numbers then signal that the originator of the packet is authentic, and the BFD state machine verifies that the rest of the packet is well formed and matches the expected state.
この方法の唯一の欠点は、パケットごとの整合性チェックが提供されていないことです。この制限は、Meticulous Keyed ISAAC 認証をセッションが Up 状態のままであることを通知するためにのみ使用することを義務付けることで解決されます。次に、ISAAC 番号はパケットの発信者が本物であることを通知し、BFD ステート マシンはパケットの残りの部分が適切に形成されており、予期された状態と一致していることを検証します。
The result is an authentication method that satisfies the needs of the BFD state machine and is secure.
その結果、BFD ステート マシンのニーズを満たし、安全な認証方法が得られます。
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains either Optimized MD5 Meticulous Keyed ISAAC Authentication (7) or Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8), and the Optimized Authentication Mode field contains 2 (Section 7 of [RFC9985]), the Authentication Section has the following format:
ヘッダーに認証存在 (A) ビットが設定されており、認証タイプ フィールドに最適化 MD5 細密キー ISAAC 認証 (7) または最適化 SHA-1 細密キー ISAAC 認証 (8) が含まれ、最適化認証モード フィールドに 2 ([RFC9985] のセクション 7) が含まれる場合、認証セクションの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Opt. Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Meticulous Keyed ISAAC Authentication Format
図 1: 綿密なキーを使用した ISAAC 認証形式
Auth Type:
認証タイプ:
The current Auth Type. It MUST provide for meticulous keying. That is, an authentication type where each packet is authenticated and where the Sequence Number field is incremented by one (1) for every packet that is sent.
現在の認証タイプ。細心の注意を払ったキーイングを提供しなければなりません。つまり、各パケットが認証され、送信されるパケットごとにシーケンス番号フィールドが 1 ずつ増加する認証タイプです。
Auth Len:
認証レン:
The length of the Authentication Section in bytes. For Meticulous Keyed ISAAC Authentication Format, the length is 16 bytes.
認証セクションの長さ (バイト単位)。Meticulous Keyed ISAAC 認証形式の場合、長さは 16 バイトです。
Auth Key ID:
認証キーID:
The authentication key ID in use for this packet. This allows multiple secret keys to be active simultaneously.
このパケットに使用されている認証キー ID。これにより、複数の秘密キーを同時にアクティブにすることができます。
Opt Mode:
オプトモード:
The Optimized Authentication Mode is defined in Section 7 of [RFC9985]. When the Auth Type is either Optimized MD5 Meticulous Keyed ISAAC Authentication (7) or Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8), and the format is Meticulous Keyed ISAAC Authentication Format, the Optimized Authentication Mode field will be set to 2.
最適化認証モードは [RFC9985] のセクション 7 で定義されています。認証タイプが最適化 MD5 細密キー ISAAC 認証 (7) または最適化 SHA-1 細密キー ISAAC 認証 (8) で、形式が細密キー ISAAC 認証形式の場合、[最適化認証モード] フィールドは 2 に設定されます。
Sequence Number:
シーケンス番号:
The sequence number for this packet. For Meticulous Keyed ISAAC Authentication, this value is incremented once for each successive packet transmitted for a session. This provides protection against replay attacks.
このパケットのシーケンス番号。Meticulous Keyed ISAAC 認証の場合、この値は、セッションで送信される連続パケットごとに 1 回増加します。これにより、リプレイ攻撃に対する保護が提供されます。
Seed:
シード：
A 32-bit (4 octet) Seed that is used in conjunction with the shared key in order to configure and initialize the ISAAC Pseudorandom Number Generator (PRNG). It is used to identify and secure different "streams" of random numbers that are generated by ISAAC.
ISAAC 擬似乱数ジェネレーター (PRNG) を構成および初期化するために共有キーと組み合わせて使用される 32 ビット (4 オクテット) シード。これは、ISAAC によって生成される乱数のさまざまな「ストリーム」を識別し、保護するために使用されます。
Auth Key:
認証キー:
This field carries the 32-bit (4 octet) ISAAC output that is associated with the sequence number. The ISAAC PRNG MUST be configured and initialized as given in Section 10.
このフィールドには、シーケンス番号に関連付けられた 32 ビット (4 オクテット) ISAAC 出力が含まれます。ISAAC PRNG は、セクション 10 で指定されているように設定および初期化されなければなりません (MUST)。
Note that the Auth Key here does not include any summary or hash of the BFD Control Packet. The packet itself is completely unauthenticated.
ここでの認証キーには、BFD 制御パケットのサマリーやハッシュが含まれていないことに注意してください。パケット自体は完全に認証されていません。
When the receiving party receives a BFD packet with an expected sequence number and the correct corresponding ISAAC output in the Auth Key field, it knows that only the authentic sending party could have sent that message. The sending party is therefore Up, as it is the only one who could have sent the message.
受信側が、予想されるシーケンス番号と、認証キー フィールドに対応する正しい ISAAC 出力を持つ BFD パケットを受信すると、認証された送信側のみがそのメッセージを送信できたことがわかります。したがって、送信側はメッセージを送信できる唯一の人であるため、アップ状態になります。
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains Optimized MD5 Meticulous Keyed ISAAC Authentication (7), and the Optimized Authentication Mode field contains 1 (Section 7 of [RFC9985]), the Authentication Section has the following format:
ヘッダーに認証存在 (A) ビットが設定されており、認証タイプ フィールドに最適化された MD5 精密キー付き ISAAC 認証 (7) が含まれ、最適化認証モード フィールドに 1 ([RFC9985] のセクション 7) が含まれている場合、認証セクションの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Opt. Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Digest... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Meticulous Keyed ISAAC Authentication, MD5 Format
図 2: 綿密なキー付き ISAAC 認証、MD5 形式
Auth Type:
認証タイプ:
The current Auth Type. It MUST provide for meticulous keying. That is, an authentication type where each packet is authenticated and where the Sequence Number field is incremented by one (1) for every packet that is sent.
現在の認証タイプ。細心の注意を払ったキーイングを提供しなければなりません。つまり、各パケットが認証され、送信されるパケットごとにシーケンス番号フィールドが 1 ずつ増加する認証タイプです。
Auth Len:
認証レン:
The length of the Authentication Section in bytes. For Meticulous Keyed ISAAC Authentication, MD5 Format, the length is 24 bytes.
認証セクションの長さ (バイト単位)。Meticulous Keyed ISAAC 認証、MD5 形式の場合、長さは 24 バイトです。
Auth Key ID:
認証キーID:
The authentication key ID in use for this packet. This allows multiple secret keys to be active simultaneously.
このパケットに使用されている認証キー ID。これにより、複数の秘密キーを同時にアクティブにすることができます。
Opt Mode:
オプトモード:
The Optimized Authentication Mode is defined in Section 7 of [RFC9985]. When the Auth Type is Optimized MD5 Meticulous Keyed ISAAC Authentication (7), and the format is MD5 Authentication Format, the Optimized Authentication Mode field will be set to 1.
最適化認証モードは [RFC9985] のセクション 7 で定義されています。[認証タイプ] が [最適化された MD5 精密キー付き ISAAC 認証 (7)] で、形式が [MD5 認証形式] の場合、[最適化された認証モード] フィールドは 1 に設定されます。
Sequence Number:
シーケンス番号:
The sequence number for this packet. For Meticulous Keyed ISAAC Authentication, this value is incremented once for each successive packet transmitted for a session. This provides protection against replay attacks.
このパケットのシーケンス番号。Meticulous Keyed ISAAC 認証の場合、この値は、セッションで送信される連続パケットごとに 1 回増加します。これにより、リプレイ攻撃に対する保護が提供されます。
Auth Key/Digest:
認証キー/ダイジェスト:
This field carries the 16-byte MD5 digest for the packet. The procedure for calculating this field is documented in Section 6.7.3 of [RFC5880].
このフィールドには、パケットの 16 バイトの MD5 ダイジェストが含まれます。このフィールドを計算する手順は、[RFC5880] のセクション 6.7.3 に文書化されています。
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8), and the Optimized Authentication Mode field contains 1 (Section 7 of [RFC9985]), the Authentication Section has the following format:
ヘッダーに認証存在 (A) ビットが設定されており、認証タイプ フィールドに最適化 SHA-1 Meticulous Keyed ISAAC 認証 (8) が含まれ、最適化認証モード フィールドに 1 ([RFC9985] のセクション 7) が含まれている場合、認証セクションの形式は次のようになります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Opt. Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Hash... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Meticulous Keyed ISAAC Authentication, SHA-1 Format
図 3: 綿密なキー付き ISAAC 認証、SHA-1 形式
Auth Type:
認証タイプ:
The current Auth Type. It MUST provide for meticulous keying. That is, an authentication type where each packet is authenticated and where the Sequence Number field is incremented by one (1) for every packet that is sent.
現在の認証タイプ。細心の注意を払ったキーイングを提供しなければなりません。つまり、各パケットが認証され、送信されるパケットごとにシーケンス番号フィールドが 1 ずつ増加する認証タイプです。
Auth Len:
認証レン:
The length of the Authentication Section in bytes. For Meticulous Keyed ISAAC Authentication, SHA-1 Format, the length is 28 bytes.
認証セクションの長さ (バイト単位)。Meticulous Keyed ISAAC 認証、SHA-1 形式の場合、長さは 28 バイトです。
Auth Key ID:
認証キーID:
The authentication key ID in use for this packet. This allows multiple secret keys to be active simultaneously.
このパケットに使用されている認証キー ID。これにより、複数の秘密キーを同時にアクティブにすることができます。
Opt Mode:
オプトモード:
The Optimized Authentication Mode is defined in Section 7 of [RFC9985]. When the Auth Type is Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8), and the format is SHA-1 Authentication Format, the Optimized Authentication Mode field will be set to 1.
最適化認証モードは [RFC9985] のセクション 7 で定義されています。認証タイプが最適化 SHA-1 Meticulous Keyed ISAAC Authentication (8) で、形式が SHA-1 認証形式の場合、[最適化認証モード] フィールドは 1 に設定されます。
Sequence Number:
シーケンス番号:
The sequence number for this packet. For Meticulous Keyed ISAAC Authentication, this value is incremented once for each successive packet transmitted for a session. This provides protection against replay attacks.
このパケットのシーケンス番号。Meticulous Keyed ISAAC 認証の場合、この値は、セッションで送信される連続パケットごとに 1 回増加します。これにより、リプレイ攻撃に対する保護が提供されます。
Auth Key/Digest:
認証キー/ダイジェスト:
This field carries the 16-byte SHA-1 hash for the packet. The procedure for calculating this field is documented in Section 6.7.4 of [RFC5880].
このフィールドには、パケットの 16 バイトの SHA-1 ハッシュが含まれます。このフィールドを計算する手順は、[RFC5880] のセクション 6.7.4 に文書化されています。
This document defines new state variables for use with Meticulous Keyed ISAAC Authentication.
この文書では、Meticulous Keyed ISAAC 認証で使用する新しい状態変数を定義します。
bfd.MetKeyIsaacRcvKeyKnown:
bfd.MetKeyIsaacRcvKeyKnown:
A boolean value that indicates whether or not the system knows the receive key for the Meticulous Keyed ISAAC Authentication. The initial value is false. This value is changed to "true" when a party verifies that the other party has started to use the Meticulous Keyed ISAAC Authentication with an authenticated Auth Key.
システムが Meticulous Keyed ISAAC 認証の受信キーを認識しているかどうかを示すブール値。初期値は false です。この値は、相手方が認証された認証キーを使用して Meticulous Keyed ISAAC 認証の使用を開始したことを確認すると、「true」に変更されます。
bfd.MetKeyIsaacRcvAuthBase:
bfd.MetKeyIsaacRcvAuthBase:
A 32-bit unsigned integer containing a copy of the bfd.RcvAuthSeq number that is associated with the current ISAAC "page" for authenticating received packets.
受信パケットを認証するための現在の ISAAC 「ページ」に関連付けられている bfd.RcvAuthSeq 番号のコピーを含む 32 ビットの符号なし整数。
bfd.MetKeyIsaacRcvAuthIndex:
bfd.MetKeyIsaacRcvAuthIndex:
An 8-bit number used to index within a particular "page" of pseudorandom numbers.
擬似乱数の特定の「ページ」内でインデックスを作成するために使用される 8 ビットの数値。
bfd.MetKeyIsaacRcvAuthSeed:
bfd.MetKeyIsaacRcvAuthSeed:
A 32-bit unsigned integer containing a copy of the Seed associated with received packets.
受信したパケットに関連付けられたシードのコピーを含む 32 ビットの符号なし整数。
bfd.MetKeyIsaacRcvAuthData:
bfd.MetKeyIsaacRcvAuthData:
A data structure that contains the ISAAC data for the received Auth Type method. The format and contents of this structure are implementation specific and hold the internal state of the ISAAC CSPRNG.
受信した認証タイプ方式の ISAAC データを含むデータ構造。この構造体の形式と内容は実装に固有であり、ISAAC CSPRNG の内部状態を保持します。
bfd.MetKeyIsaacXmitKeyKnown:
bfd.MetKeyIsaacXmitKeyKnown:
A boolean value that indicates whether or not the system knows the xmit key for Meticulous Keyed ISAAC Authentication. The initial value is false. This value is changed to "true" when a party starts to transmit using Meticulous Keyed ISAAC Authentication.
システムが Meticulous Keyed ISAAC 認証の xmit キーを認識しているかどうかを示すブール値。初期値は false です。この値は、当事者が Meticulous Keyed ISAAC 認証を使用して送信を開始すると、「true」に変更されます。
bfd.MetKeyIsaacXmitAuthBase:
bfd.MetKeyIsaacXmitAuthBase:
A 32-bit unsigned integer containing a copy of the bfd.XmitAuthSeq number that is associated with the current ISAAC "page" for authenticating sent packets.
送信されたパケットを認証するための現在の ISAAC 「ページ」に関連付けられている bfd.XmitAuthSeq 番号のコピーを含む 32 ビットの符号なし整数。
bfd.MetKeyIsaacXmitAuthIndex:
bfd.MetKeyIsaacXmitAuthIndex:
An 8-bit number used to index within a particular "page" of pseudorandom numbers.
擬似乱数の特定の「ページ」内でインデックスを作成するために使用される 8 ビットの数値。
bfd.MetKeyIsaacXmitAuthSeed:
bfd.MetKeyIsaacXmitAuthSeed:
A 32-bit unsigned integer containing a copy of the Seed associated with sent packets.
送信されたパケットに関連付けられたシードのコピーを含む 32 ビットの符号なし整数。
bfd.MetKeyIsaacXmitAuthData:
bfd.MetKeyIsaacXmitAuthData:
A data structure that contains the ISAAC data for the sending Auth Type method. The format and contents of this structure are implementation specific and hold the internal state of the ISAAC CSPRNG.
送信側の Auth Type メソッドの ISAAC データを含むデータ構造。この構造体の形式と内容は実装に固有であり、ISAAC CSPRNG の内部状態を保持します。
The transmit and receive procedures utilize the additional procedures documented in Section 7.1 of [RFC9985].
送信および受信手順は、[RFC9985] のセクション 7.1 に記載されている追加手順を利用します。
The authentication procedure for Meticulous Keyed ISAAC, MD5 Format is described in Section 6.7.3 of [RFC5880] for the Meticulous Keyed MD5 Authentication Mode.
Meticulous Keyed ISAAC、MD5 フォーマットの認証手順は、Meticulous Keyed MD5 認証モードに関する [RFC5880] のセクション 6.7.3 で説明されています。
The authentication procedure for Meticulous Keyed ISAAC, SHA-1 Format is described in Section 6.7.4 of [RFC5880] for the Meticulous Keyed SHA-1 Authentication Mode.
Meticulous Keyed ISAAC、SHA-1 フォーマットの認証手順は、Meticulous Keyed SHA-1 認証モードに関する [RFC5880] のセクション 6.7.4 で説明されています。
In this mode of optimized authentication, one or more secret keys (with corresponding key IDs) are configured in each system. One of the keys is used to seed the ISAAC PRNG. The output of ISAAC is used to signal that the sender is authentic. To help avoid replay attacks, a sequence number is also carried in each packet. For Meticulous Keyed ISAAC Authentication, the sequence number MUST be incremented by one on every packet.
この最適化された認証モードでは、各システムで 1 つ以上の秘密鍵 (対応する鍵 ID を持つ) が構成されます。キーの 1 つは、ISAAC PRNG をシードするために使用されます。ISAAC の出力は、送信者が本物であることを通知するために使用されます。リプレイ攻撃を回避するために、各パケットにはシーケンス番号も含まれます。Meticulous Keyed ISAAC 認証の場合、パケットごとにシーケンス番号を 1 ずつ増分しなければなりません (MUST)。
The receiving system accepts the packet if the key ID matches one of the configured Keys, and the Auth Key derived from the selected Key, Seed, and sequence number matches the Auth Key carried in the packet, and the sequence number is strictly greater than the last sequence number received (modulo wrap at 2^32). If any of these criteria do not match, the packet fails validation and is discarded.
キー ID が設定されたキーの 1 つと一致し、選択されたキー、シード、およびシーケンス番号から導出された認証キーがパケットに含まれる認証キーと一致し、シーケンス番号が最後に受信したシーケンス番号よりも厳密に大きい場合 (2^32 でモジュロラップ)、受信システムはパケットを受け入れます。これらの基準のいずれかが一致しない場合、パケットは検証に失敗し、破棄されます。
The Auth Type field MUST be set to one of two values; Optimized MD5 Meticulous Keyed ISAAC Authentication (7) or Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8).
「認証タイプ」フィールドは、2 つの値のいずれかに設定する必要があります。最適化された MD5 細密キー ISAAC 認証 (7) または最適化された SHA-1 細密キー ISAAC 認証 (8)。
The Auth Len field MUST be set to 16.
Auth Len フィールドは 16 に設定する必要があります。
The Auth Key ID field MUST be set to the ID of the current authentication key. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
「認証キー ID」フィールドは、現在の認証キーの ID に設定する必要があります。シーケンス番号フィールドは bfd.XmitAuthSeq に設定する必要があります。
The Seed field MUST be set to the value of the current Seed used for this session.
Seed フィールドは、このセッションで使用される現在の Seed の値に設定しなければなりません (MUST)。
The Auth Key field MUST be set to the output of ISAAC, which depends on the secret Key, the current Seed, and the sequence number.
Auth Key フィールドは、秘密鍵、現在のシード、シーケンス番号に応じて ISAAC の出力に設定されなければなりません (MUST)。
The Optimized Authentication Mode field MUST be 2, the "less computationally intensive authentication type". See Section 7 of [RFC9985].
[最適化された認証モード] フィールドは、「計算量が少ない認証タイプ」である 2 でなければなりません。[RFC9985] のセクション 7 を参照してください。
For Meticulous Keyed ISAAC Authentication, bfd.XmitAuthSeq MUST be incremented by one on each packet in a circular fashion (when treated as an unsigned 32-bit value). The bfd.XmitAuthSeq MUST NOT be incremented by more than one per packet.
細密なキー付き ISAAC 認証の場合、bfd.XmitAuthSeq は循環方式でパケットごとに 1 ずつ増分されなければなりません (符号なし 32 ビット値として扱われる場合)。bfd.XmitAuthSeq はパケットごとに 2 つ以上増分してはなりません (MUST NOT)。
If the received BFD Control Packet does not contain an Authentication Section, or the Auth Type is not correct (either Optimized MD5 Meticulous Keyed ISAAC Authentication (7) or Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8)), then the received packet MUST be discarded.
受信した BFD 制御パケットに認証セクションが含まれていない場合、または認証タイプが正しくない場合 (最適化された MD5 細密キー付き ISAAC 認証 (7) または最適化された SHA-1 細密キー付き ISAAC 認証 (8) のいずれか)、受信したパケットは破棄されなければなりません(MUST)。
If the Auth Key ID field does not match the ID of a configured authentication key, the received packet MUST be discarded.
Auth Key ID フィールドが設定された認証キーの ID と一致しない場合、受信したパケットは破棄されなければなりません (MUST)。
The Optimized Authentication Mode field MUST be 2, the "less computationally intensive authentication type". See Section 7 of [RFC9985].
[最適化された認証モード] フィールドは、「計算量が少ない認証タイプ」である 2 でなければなりません。[RFC9985] のセクション 7 を参照してください。
If the Auth Len field is not equal to 16, the packet MUST be discarded.
Auth Len フィールドが 16 に等しくない場合、パケットは破棄されなければなりません (MUST)。
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For Meticulous Keyed ISAAC, if the sequence number lies outside of the range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space) the received packet MUST be discarded.
bfd.AuthSeqKnown が 1 の場合は、シーケンス番号フィールドを調べます。Meticulous Keyed ISAAC の場合、シーケンス番号が bfd.RcvAuthSeq+1 から bfd.RcvAuthSeq+(3*Detect Mult) までの範囲外にある場合 (符号なし 32 ビット循環番号空間として扱われる場合)、受信したパケットは破棄されなければなりません (MUST)。
If bfd.MetKeyIsaacRcvKeyKnown is "true" and the Seed field does not match the current Seed value, bfd.MetKeyIsaacRcvAuthSeed, the packet MUST be discarded.
bfd.MetKeyIsaacRcvKeyKnown が「true」で、Seed フィールドが現在の Seed 値 bfd.MetKeyIsaacRcvAuthSeed と一致しない場合、パケットは破棄されなければなりません (MUST)。
Calculate the current expected output of ISAAC, which depends on the secret Key, the current Seed, and the sequence number. If the value does not match the Auth Key field, then the packet MUST be discarded.
ISAAC の現在予想される出力を計算します。これは、秘密キー、現在のシード、およびシーケンス番号に応じて異なります。値が Auth Key フィールドと一致しない場合、パケットは破棄されなければなりません (MUST)。
If bfd.MetKeyIsaacRcvKeyKnown is false, the ISAAC related variables are initialized as per Section 10.2 using the contents of the packet.
bfd.MetKeyIsaacRcvKeyKnown が false の場合、ISAAC 関連の変数はパケットの内容を使用してセクション 10.2 に従って初期化されます。
Note that in some cases, calculating the expected output of ISAAC will result in the creation of a new "page" of 256 numbers. This process will be irreversible and will destroy the current "page". As a result, if the generation of a new output will create a new "page", the receiving party MUST save a copy of the entire ISAAC state before proceeding with this calculation. If the outputs match, then the saved copy can be discarded and the new ISAAC state is used. If the outputs do not match, then the saved copy MUST be restored and the modified copy discarded or cached for later use.
場合によっては、ISAAC の予想される出力を計算すると、256 個の数値からなる新しい「ページ」が作成されることに注意してください。このプロセスは元に戻すことができず、現在の「ページ」が破壊されます。その結果、新しい出力の生成によって新しい「ページ」が作成される場合、受信側はこの計算を続行する前に、ISAAC 状態全体のコピーを保存しなければなりません (MUST)。出力が一致する場合、保存されたコピーは破棄され、新しい ISAAC 状態が使用されます。出力が一致しない場合は、保存されたコピーを復元し、変更されたコピーは破棄されるか、後で使用できるようにキャッシュされなければなりません。
The security of the Meticulous Keyed ISAAC Auth Type depends on the secret key. The secret key is mixed with a per-session Seed as discussed below. The result is used to initialize a stream of pseudorandom numbers using the ISAAC random number generator.
Meticulous Keyed ISAAC 認証タイプのセキュリティは、秘密キーに依存します。以下で説明するように、秘密キーはセッションごとのシードと混合されます。この結果は、ISAAC 乱数生成器を使用して擬似乱数のストリームを初期化するために使用されます。
Using the same or distinct secret keys for each Optimized Authentication Mode has security and operational impacts. See Section 15.1.2 for discussion on these points.
各最適化認証モードに同じまたは異なる秘密キーを使用すると、セキュリティと運用に影響があります。これらの点については、セクション 15.1.2 を参照してください。
It is RECOMMENDED that implementations permit distinct secret keys to be provisioned for a given Auth Key ID for each Optimized Authentication Mode. The operator's choice to use such distinct secret keys instead of a single secret key is out of scope for this document.
実装では、各最適化認証モードの特定の認証キー ID に対して個別の秘密キーをプロビジョニングできるようにすることが推奨されます。単一の秘密鍵の代わりにそのような個別の秘密鍵を使用するというオペレーターの選択は、この文書の範囲外です。
A particular secret key set is identified via the Auth Key ID field. This Auth Key ID is either placed in the packet by the sender or verified by the receiver. Meticulous Keyed ISAAC Authentication permits systems to have multiple Secret Keys configured, but we do not discuss how those keys are managed or used. A session MUST NOT, however, change the Auth Key ID for Meticulous Keyed ISAAC Authentication during a session. There is no defined way to resync or reinitialize an ongoing session with a different Auth Key ID and correspondingly different secret key.
特定の秘密キー セットは、[認証キー ID] フィールドによって識別されます。この認証キー ID は、送信者によってパケットに配置されるか、受信者によって検証されます。Meticulous Keyed ISAAC Authentication permits systems to have multiple Secret Keys configured, but we do not discuss how those keys are managed or used.ただし、セッション中に Meticulous Keyed ISAAC 認証の認証キー ID を変更してはなりません (MUST NOT)。異なる認証キー ID とそれに対応する異なる秘密キーを使用して進行中のセッションを再同期または再初期化する定義された方法はありません。
For interoperability, the management interface by which the key is configured MUST accept ASCII strings and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported.
For interoperability, the management interface by which the key is configured MUST accept ASCII strings and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form.他の設定方法もサポートされる場合があります。
The secret key MUST be at least eight (8) octets in length and SHOULD NOT be more than 128 octets in length.
秘密鍵は少なくとも 8 オクテットの長さでなければならず、128 オクテットを超えてはなりません (SHOULD NOT)。
A BFD session that uses Optimized MD5 Meticulous Keyed ISAAC Authentication or Optimized SHA-1 Meticulous Keyed ISAAC Authentication MUST begin a session with Auth Type set to the relevant authentication type and the Optimized Authentication Mode field set to 1.
最適化された MD5 細密キー付き ISAAC 認証または最適化 SHA-1 細密キー付き ISAAC 認証を使用する BFD セッションは、[認証タイプ] を関連する認証タイプに設定し、[最適化認証モード] フィールドを 1 に設定してセッションを開始する必要があります。
When a BFD session using more computationally intensive authentication transitions to the Up state, the first Up packet MUST contain an Optimized Authentication Mode field with value 1. Since state transitions require full packet integrity checks, an Optimized Authentication Mode field with value 2 is not permitted for state changes. Each party MUST continue to use the more computationally intensive authentication mode until the other side has confirmed the switch to the Up state with a packet that also uses more computationally intensive authentication.
より計算量の多い認証を使用する BFD セッションが Up 状態に遷移する場合、最初の Up パケットには値 1 の最適化認証モード フィールドが含まれなければなりません (MUST)。状態遷移には完全なパケット整合性チェックが必要であるため、値 2 の最適化認証モード フィールドは状態変更には許可されません。各当事者は、相手側がより計算量の多い認証を使用するパケットで Up 状態への切り替えを確認するまで、より計算量の多い認証モードを使用し続けなければなりません (MUST)。
Once the BFD session has transitioned to the Up state, the sender MAY send the subsequent packets for the Up state with the Optimized Authentication Mode field containing value 2 using the ISAAC Format.
BFD セッションが Up 状態に移行すると、送信者は、ISAAC フォーマットを使用して、Optimized Authentication Mode フィールドに値 2 を含む Up 状態の後続のパケットを送信してもよい(MAY)。
When a system first receives a packet containing the Optimized Authentication Mode field with value 2, it initializes the ISAAC PRNG state using the Seed from that packet. A system originating a packet using Meticulous Keyed ISAAC Authentication will generate a Seed and place it into the packet, which is then sent. Further discussion of initialization takes place in Sections 10.1 and 10.2.
システムは、値 2 の最適化認証モード フィールドを含むパケットを最初に受信すると、そのパケットのシードを使用して ISAAC PRNG 状態を初期化します。Meticulous Keyed ISAAC Authentication を使用してパケットを発信するシステムは、シードを生成してパケットに配置し、送信します。初期化についてはセクション 10.1 と 10.2 でさらに説明します。
The first packet after the transition to the Up state is the only time when the ISAAC random number generator for transmission is initialized. In contrast, a temporary transition away from using Meticulous Keyed ISAAC Authentication, ISAAC Format (Section 12) and back does not cause ISAAC to be rekeyed.
Up 状態への遷移後の最初のパケットは、送信用の ISAAC 乱数生成器が初期化される唯一の時間です。対照的に、Meticulous Keyed ISAAC Authentication、ISAAC Format (セクション 12) の使用から一時的に移行し、またその使用に戻っても、ISAAC のキーは再生成されません。
There is no negotiation as to when authentication switches from the original type to using Meticulous Keyed ISAAC Authentication using the ISAAC Format. The sender simply begins sending packets with a relevant Auth-Type and with the Optimized Authentication Mode field set to 1. When the sender switches to using Meticulous Keyed ISAAC Authentication, ISAAC Format, it sets the Optimized Authentication Mode field to 2 and starts performing the ISAAC calculations as described here.
認証が元のタイプから ISAAC 形式を使用した Meticulous Keyed ISAAC 認証の使用にいつ切り替わるかについてのネゴシエーションはありません。送信者は、関連する Auth-Type と Optimized Authentication Mode フィールドを 1 に設定したパケットの送信を開始するだけです。送信者が Meticulous Keyed ISAAC Authentication (ISAAC Format) の使用に切り替えると、Optimized Authentication Mode フィールドを 2 に設定し、ここで説明するように ISAAC 計算の実行を開始します。
Similarly, a receiving system switches to using this method when it sees that it has received a packet contains the Optimized Authentication Mode field set to 2 when bfd.MetKeyIsaacRcvKeyKnown variable is false. The receiving system then initializes its variables and authenticates the received packet by comparing the Auth Key in the packet with the key it generated itself.
同様に、受信システムは、bfd.MetKeyIsaacRcvKeyKnown 変数が false のときに 2 に設定された最適化認証モード フィールドが含まれるパケットを受信したことを確認すると、このメソッドの使用に切り替えます。次に、受信システムは変数を初期化し、パケット内の認証キーと自身が生成したキーを比較することによって、受信したパケットを認証します。
The operation of those state variables MUST now satisfy the requirements of the new Optimized Authentication Mode. That is, when changing Optimized Authentication Mode in a session, the current value of the bfd.RcvAuthSeq and bfd.XmitAuthSeq variables is used as the initial value(s) for the new mode.
これらの状態変数の操作は、新しい最適化認証モードの要件を満たさなければなりません。つまり、セッションで最適化認証モードを変更する場合、bfd.RcvAuthSeq 変数と bfd.XmitAuthSeq 変数の現在の値が新しいモードの初期値として使用されます。
The Seed field is used to identify and secure different "streams" of random numbers that are generated by ISAAC. Each session uses a different Seed, which is used along with the Your Discriminator field (Section 4.1 of [RFC5880]) and the secret key to initialize ISAAC.
シード フィールドは、ISAAC によって生成される乱数のさまざまな「ストリーム」を識別し、保護するために使用されます。Each session uses a different Seed, which is used along with the Your Discriminator field (Section 4.1 of [RFC5880]) and the secret key to initialize ISAAC.
The value of the Seed field MUST be derived from a CSPRNG source. Exactly how this can be done is outside of the scope of this document.
Seed フィールドの値は、CSPRNG ソースから取得する必要があります。これを行う正確な方法については、このドキュメントの範囲外です。
A new Seed value MUST be created every time a BFD session transitions into the Up state. In order to prevent continuous rekeying, once the session is in the Up state, the Seed for a session MUST NOT be changed until another state transition occurs.
BFD セッションが Up 状態に移行するたびに、新しいシード値を作成する必要があります。継続的なキーの再生成を防ぐために、セッションが Up 状態になると、別の状態遷移が発生するまでセッションのシードを変更してはなりません (MUST NOT)。
The ISAAC PRNG is initialized by setting all internal variables and data structures to zero (0). The PRNG is then seeded by using the following structure:
ISAAC PRNG は、すべての内部変数とデータ構造をゼロ (0) に設定することによって初期化されます。次に、次の構造を使用して PRNG がシードされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secret Key ... | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ISAAC Initialization Structure
図 4: ISAAC 初期化構造
where the Your Discriminator field is taken from the BFD packet defined in [RFC5880], Section 4.1. This field is taken from the respective values used by a sending system. For receiving systems, the field are taken from the received packet. As the size of the buffer used to seed is limited, the length of the secret key MUST be no more than 1015 octets. The Counter field is used to ensure the initial seeding of ISAAC avoids the seeding issues discussed in ISAAC+ [ISAAC-Plus].
ここで、Your Discriminator フィールドは、[RFC5880] セクション 4.1 で定義されている BFD パケットから取得されます。このフィールドは、送信システムによって使用されるそれぞれの値から取得されます。受信システムの場合、フィールドは受信パケットから取得されます。シードに使用されるバッファのサイズは制限されているため、秘密鍵の長さは 1015 オクテット以下でなければなりません。Counter フィールドは、ISAAC の初期シード処理で ISAAC+ [ISAAC-Plus] で説明されているシード処理の問題を確実に回避するために使用されます。
Whatever the API or other interface used to input the Secret Key, any implementation-specific internal representations of the secret key MUST NOT be used when encoding the secret key into the above data structure. That is, there is no length field that indicates how long the secret key is and there is no trailing zero or NUL byte that indicates the end of the secret key. Implementors are reminded that internal representations of data should not affect protocol operation.
Whatever the API or other interface used to input the Secret Key, any implementation-specific internal representations of the secret key MUST NOT be used when encoding the secret key into the above data structure.That is, there is no length field that indicates how long the secret key is and there is no trailing zero or NUL byte that indicates the end of the secret key.実装者は、データの内部表現がプロトコルの動作に影響を与えてはならないことに注意してください。
The buffer used to initialize ISAAC filled it with repeated copies of the above structure. For each complete copy of the structure, the Counter field is incremented starting from zero (0). The final portion of the initialization buffer holds a partial copy of the structure, which is however much can be accommodated in the remaining portion of the buffer.
ISAAC の初期化に使用されるバッファには、上記の構造の繰り返しコピーが格納されていました。構造の完全なコピーごとに、Counter フィールドはゼロ (0) から増分されます。The final portion of the initialization buffer holds a partial copy of the structure, which is however much can be accommodated in the remaining portion of the buffer.
Once the ISAAC "page" is initialized, the data is processed through the "randinit()" function of ISAAC [ISAAC]. Pseudo-random numbers are then produced 32 bits at a time by calling the "isaac()" function.
ISAAC「ページ」が初期化されると、データは ISAAC [ISAAC] の「randinit()」関数を通じて処理されます。次に、「isaac()」関数を呼び出すことによって、擬似乱数が一度に 32 ビットずつ生成されます。
For the sender, this calculation can be done outside of the BFD "fast path" as soon as the Your Discriminator value is known. For the receiver, this calculation can only be done when the Seed is received from the sender, and therefore the initial seeding needs to be done in the BFD "fast path".
送信者にとって、この計算は、Your Discriminator の値が判明するとすぐに、BFD の「高速パス」の外側で実行できます。受信側の場合、この計算は送信側からシードを受信したときにのみ実行できるため、最初のシード処理は BFD の「高速パス」で実行する必要があります。
The following table gives Seed and Your Discriminator as 32-bit hexadecimal values and the secret key as an eleven-character string. The subsequent table shows the first eight sequence numbers and corresponding Auth Key values that were generated using the above initial values.
次の表では、シードと識別子を 32 ビットの 16 進値として、秘密キーを 11 文字の文字列として示します。次の表は、最初の 8 つのシーケンス番号と、上記の初期値を使用して生成された対応する認証キーの値を示しています。
+============+=============+
| Field | Value(s) |
+============+=============+
| Seed | 0x0bfd5eed |
+------------+-------------+
| Y-Disc | 0x4002d15c |
+------------+-------------+
| Secret Key | RFC5880June |
+------------+-------------+
| Counter | 0...50 |
+------------+-------------+
Table 1: Test Inputs for Seeding ISAAC
表 1: ISAAC をシードするためのテスト入力
+==========+==========+
| Sequence | Auth Key |
+==========+==========+
| 0 | 9af65d83 |
+----------+----------+
| 1 | 44355d56 |
+----------+----------+
| 2 | 9334074e |
+----------+----------+
| 3 | b643ef59 |
+----------+----------+
| 4 | 74d659f1 |
+----------+----------+
| 5 | 8966dc56 |
+----------+----------+
| 6 | a1f6f9bc |
+----------+----------+
| 7 | 21895a46 |
+----------+----------+
Table 2: Expected Outputs
表 2: 期待される出力
This construct provides 64 bits of entropy, of which 32 bits are controlled by each party in a BFD session. For security, each implementation SHOULD randomize their discriminator fields at the start of a session, as discussed in [RFC5880], Section 9.
この構造は 64 ビットのエントロピーを提供し、そのうち 32 ビットは BFD セッションの各当事者によって制御されます。セキュリティのため、[RFC5880] セクション 9 で説明されているように、各実装はセッションの開始時に識別子フィールドをランダム化する必要があります (SHOULD)。
Note that this construct only uses the Your Discriminator field once to seed ISAAC. It therefore allows the My Discriminator field to change as permitted by BFD [RFC5880] (Section 6.3).
この構成では、ISAAC をシードするために Your Discriminator フィールドを 1 回だけ使用することに注意してください。したがって、BFD [RFC5880] (セクション 6.3) で許可されているように、My Discriminator フィールドを変更することができます。
While the Your Discriminator field may change, there is no way to signal or negotiate Seed changes. The Seed is set once by each party after the session transitions into the Up state, and then remains unchanged for the duration of the session. The receiving party MUST remember the current Seed value. The Seed value MUST NOT change unless sending party has signaled a BFD state change with a packet that is authenticated using a more computationally intensive authentication method. When a system receives a BFD packet containing Meticulous Keyed ISAAC Authentication, it MUST check that the received Seed contains the expected value, and if not, it MUST discard the packet as inauthentic.
Your Discriminator フィールドは変更される可能性がありますが、シードの変更を通知したりネゴシエートしたりする方法はありません。シードは、セッションが Up 状態に移行した後、各当事者によって 1 回設定され、その後はセッションの間は変更されません。受信側は現在のシード値を覚えていなければなりません。送信側が、より計算量の多い認証方法を使用して認証されたパケットで BFD 状態の変更を通知しない限り、シード値を変更してはなりません (MUST NOT)。システムが Meticulous Keyed ISAAC Authentication を含む BFD パケットを受信した場合、受信した Seed に期待値が含まれていることを確認しなければなりません (MUST)。そうでない場合は、パケットを不正なものとして破棄しなければなりません (MUST)。
A system that sends packets initializes ISAAC as described above. The ISAAC related variables are initialized as follows:
パケットを送信するシステムは、前述のように ISAAC を初期化します。ISAAC 関連の変数は次のように初期化されます。
bfd.MetKeyIsaacXmitKeyKnown:
bfd.MetKeyIsaacXmitKeyKnown:
This variable transitions from false to true when the sender decides to start using ISAAC. The sender also initializes the other variables at the same time.
送信者が ISAAC の使用を開始することを決定すると、この変数は false から true に遷移します。送信者は他の変数も同時に初期化します。
bfd.MetKeyIsaacXmitAuthBase:
bfd.MetKeyIsaacXmitAuthBase:
The sender copies the bfd.XmitAuthSeq number from the current packet to be sent into this variable.
送信者は、現在のパケットから bfd.XmitAuthSeq 番号をコピーして、この変数に送信します。
bfd.MetKeyIsaacXmitAuthIndex:
bfd.MetKeyIsaacXmitAuthIndex:
The sender sets this variable to zero.
送信者はこの変数をゼロに設定します。
bfd.MetKeyIsaacXmitAuthSeed:
bfd.MetKeyIsaacXmitAuthSeed:
The sender copies the current Seed value into this variable. This variable is then copied into the "Seed" field of each Auth Type packet.
送信者は現在のシード値をこの変数にコピーします。この変数は、各認証タイプ パケットの「シード」フィールドにコピーされます。
bfd.MetKeyIsaacXmitAuthData:
bfd.MetKeyIsaacXmitAuthData:
The ISAAC state for sending is encapsulated in this variable.
送信用の ISAAC 状態はこの変数にカプセル化されます。
When a system receives packets with Meticulous Keyed ISAAC Authentication and is able to authenticate such a packet the first time, the ISAAC related variables are initialized as follows:
システムが Meticulous Keyed ISAAC 認証を使用してパケットを受信し、そのようなパケットを初めて認証できる場合、ISAAC 関連の変数は次のように初期化されます。
bfd.MetKeyIsaacRcvKeyKnown:
bfd.MetKeyIsaacRcvKeyKnown:
This variable transitions from false to true when the receiver sees that the sender has started using Meticulous Keyed ISAAC Authentication. The receiver also initializes the other variables at the same time.
送信者が Meticulous Keyed ISAAC 認証の使用を開始したことを受信者が認識すると、この変数は false から true に遷移します。受信側は他の変数も同時に初期化します。
bfd.MetKeyIsaacRcvAuthBase:
bfd.MetKeyIsaacRcvAuthBase:
The bfd.RcvAuthSeq number from the current packet is copied into this variable.
現在のパケットの bfd.RcvAuthSeq 番号がこの変数にコピーされます。
bfd.MetKeyIsaacRcvAuthIndex:
bfd.MetKeyIsaacRcvAuthIndex:
The receiver sets this value to zero.
受信機はこの値をゼロに設定します。
bfd.MetKeyIsaacRcvAuthSeed:
bfd.MetKeyIsaacRcvAuthSeed:
The receiver copies the Seed value from the received packet into this variable. Note that this copy only occurs when the bfd.MetKeyIsaacXmitKeyKnown variable transitions from false to true.
受信側は、受信したパケットからシード値をこの変数にコピーします。このコピーは、bfd.MetKeyIsaacXmitKeyKnown 変数が false から true に遷移する場合にのみ発生することに注意してください。
bfd.MetKeyIsaacRcvAuthData:
bfd.MetKeyIsaacRcvAuthData:
The ISAAC state for receiving is encapsulated in this variable.
受信時の ISAAC 状態はこの変数にカプセル化されます。
As there may be packet loss, the receiver has to take special care to initialize the bfd.MetKeyIsaacRcvAuthBase variable. If there has been no packet loss, the bfd.MetKeyIsaacRcvAuthBase is taken directly from the bfd.RcvAuthSeq variable, and the bfd.MetKeyIsaacRcvAuthIndex is set to zero.
パケット損失が発生する可能性があるため、受信者は特別な注意を払って bfd.MetKeyIsaacRcvAuthBase 変数を初期化する必要があります。パケット損失がなかった場合、bfd.MetKeyIsaacRcvAuthBase は bfd.RcvAuthSeq 変数から直接取得され、bfd.MetKeyIsaacRcvAuthIndex はゼロに設定されます。
However, if the packet's sequence number differs from the expected value, then the difference "N" indicates how many packets were lost. The receiver can then use this difference to index into the ISAAC page to find the corresponding Auth Key. If the key in the ISAAC page does not match the corresponding Auth Key in the packets, the packet fails validation and is discarded.
ただし、パケットのシーケンス番号が期待値と異なる場合、その差「N」は失われたパケットの数を示します。受信者は、この違いを使用して ISAAC ページにインデックスを付け、対応する認証キーを見つけることができます。ISAAC ページ内のキーがパケット内の対応する認証キーと一致しない場合、パケットは検証に失敗し、破棄されます。
If a key found by indexing into this ISAAC page does match the Auth Key in the packet, then the bfd.MetKeyIsaacRcvAuthIndex field is initialized to this value. The bfd.MetKeyIsaacRcvAuthBase field is then initialized to contain the value of bfd.RcvAuthSeq, minus the value of bfd.MetKeyIsaacRcvAuthIndex. This process allows the pseudorandom stream to be resynchronized in the event of lost packets.
この ISAAC ページへのインデックス作成によって見つかったキーがパケット内の認証キーと一致する場合、bfd.MetKeyIsaacRcvAuthIndex フィールドはこの値に初期化されます。次に、bfd.MetKeyIsaacRcvAuthBase フィールドは、bfd.RcvAuthSeq の値から bfd.MetKeyIsaacRcvAuthIndex の値を引いた値を含むように初期化されます。このプロセスにより、パケットが失われた場合に擬似ランダム ストリームを再同期できます。
That is, the value for bfd.MetKeyIsaacRcvAuthBase is the sequence number for first Auth Key used in this session. This value may be from a lost packet, but can never the less be calculated by the receiver from a later packet.
つまり、bfd.MetKeyIsaacRcvAuthBase の値は、このセッションで使用される最初の認証キーのシーケンス番号です。この値は失われたパケットからのものである可能性がありますが、受信者が後のパケットから計算することは決してできません。
Once the variables have been initialized, ISAAC will be able to produce 256 random numbers to use as Auth Keys at near-zero cost. The AuthIndex field is incremented by one for every new Auth Key generated. Each new value of the Sequence Number field (sent or received) is then calculated by adding the relevant AuthBase and AuthIndex fields.
変数が初期化されると、ISAAC はほぼゼロのコストで認証キーとして使用する 256 個の乱数を生成できるようになります。AuthIndex フィールドは、新しい認証キーが生成されるたびに 1 ずつ増加します。次に、シーケンス番号フィールド (送信または受信) の各新しい値が、関連する AuthBase フィールドと AuthIndex フィールドを追加することによって計算されます。
When all 256 numbers are consumed, the AuthIndex field will wrap to zero. The ISAAC mixing function is then run, which then results in another set of 256 random numbers. The AuthBase variable is then incremented by 256 to indicate that 256 Auth Keys have been consumed. This process then continues until a BFD state change.
256 個の数値がすべて消費されると、AuthIndex フィールドは 0 にラップされます。次に、ISAAC ミキシング関数が実行され、その結果、別の 256 個の乱数セットが生成されます。次に、AuthBase 変数が 256 ずつインクリメントされ、256 個の認証キーが消費されたことを示します。このプロセスは、BFD の状態が変化するまで継続されます。
ISAAC can be thought of here as producing an infinite stream of numbers, based on a secret key, where the numbers are produced in "pages" of 256 32-bit values. This property of ISAAC allows for essentially zero-cost "seeking" within a page. The expensive operation of mixing is performed only once per 256 packets, which means that most BFD packet exchanges can be fast and efficient.
ここでの ISAAC は、秘密鍵に基づいて無限の数値ストリームを生成すると考えることができ、数値は 256 個の 32 ビット値の「ページ」で生成されます。ISAAC のこの特性により、ページ内で基本的にゼロコストの「シーク」が可能になります。高価な混合操作は 256 パケットごとに 1 回だけ実行されます。これは、ほとんどの BFD パケット交換が高速かつ効率的であることを意味します。
The receiving party can then look at the sequence number to determine which particular PRNG value is being used in the packet. By subtracting the bfd.MetKeyIsaacAuthBase from the sequence number (with possible wrapping), an expected Index can be derived and a corresponding Auth Key can be found. This process thus permits the two parties to synchronize if/when a packet or packets are lost.
受信側はシーケンス番号を調べて、パケット内でどの特定の PRNG 値が使用されているかを判断できます。シーケンス番号から bfd.MetKeyIsaacAuthBase を減算することにより (ラップの可能性あり)、期待されるインデックスを導出し、対応する認証キーを見つけることができます。したがって、このプロセスにより、1 つまたは複数のパケットが失われた場合に、2 つの当事者が同期できるようになります。
Incrementing the sequence number for every packet also prevents the reuse of any individual pseudorandom number that was derived from ISAAC.
すべてのパケットのシーケンス番号をインクリメントすると、ISAAC から導出された個々の擬似乱数の再利用も防止されます。
The sequence number can increment without bounds, though it can wrap once it reaches the limit of the 32-bit counter field. ISAAC has a cycle length of 2^8287, so there is no issue with using more than 2^32 values from it.
シーケンス番号は無制限に増加できますが、32 ビット カウンター フィールドの制限に達するとラップする可能性があります。ISAAC のサイクル長は 2^8287 であるため、2^32 を超える値を使用しても問題はありません。
The result of the above operation is an infinite series of numbers that are unguessable and that can be used to authenticate the sending party.
上記の操作の結果、推測不可能な無限の一連の数値が生成され、送信側の認証に使用できます。
Each system sending BFD packets chooses its own seed, generates its own sequence of pseudorandom numbers using ISAAC, and places those values into the Auth Key field. Each system receiving BFD packets runs a separate pseudorandom number generator and verifies that the received packets contain the expected Auth Key.
BFD パケットを送信する各システムは、独自のシードを選択し、ISAAC を使用して独自の擬似乱数シーケンスを生成し、それらの値を Auth Key フィールドに配置します。BFD パケットを受信する各システムは、個別の擬似乱数生成器を実行し、受信したパケットに予期される認証キーが含まれていることを確認します。
Once all 256 Auth Keys from the current page have been used, the next page is calculated by calling the isaac() function. This function modifies the current page to create the next page and is inherently destructive. In order to prevent issues, care should be taken to perform this process correctly.
現在のページの 256 個の認証キーがすべて使用されると、isaac() 関数を呼び出して次のページが計算されます。この関数は現在のページを変更して次のページを作成するものであり、本質的に破壊的です。問題を防ぐために、このプロセスを正しく実行するように注意する必要があります。
It is RECOMMENDED that implementations keep both a current page and a next page associated with the ISAAC state. The next page can be calculated by making a copy of the current page, and then calling the isaac() function.
実装では、現在のページと次のページの両方を ISAAC 状態に関連付けて保持することが推奨されます。次のページは、現在のページのコピーを作成し、 isaac() 関数を呼び出すことで計算できます。
The system needs to maintain the current page at all times when Meticulous Keyed ISAAC Authentication is used. The next page does not need to be maintained at all times, and can be calculated on demand. However, in order to avoid impacting the fast path, the next page should be calculated in the background in an asynchronous manner.
Meticulous Keyed ISAAC 認証が使用されている場合、システムは常に現在のページを維持する必要があります。次のページは常に維持する必要はなく、オンデマンドで計算できます。ただし、高速パスへの影響を避けるために、次のページはバックグラウンドで非同期的に計算される必要があります。
This process has a number of benefits. First, at 60 packets per second, the system has approximately four (4) seconds of time to calculate the next page. If the calculation is done quickly, the next page is available to the fast path before it is needed.
このプロセスには多くの利点があります。まず、1 秒あたり 60 パケットの場合、システムは次のページを計算するのに約 4 秒かかります。計算が迅速に完了すると、次のページが必要になる前に高速パスで使用できるようになります。
Second, having the next page available early means that an attacker cannot spoof BFD packets and force the received to spend significant resources calculating a next page on the BFD fast path. Instead, the receiver can simply check the contents of the next page at near-zero cost and discard the spoofed packet.
第 2 に、次のページが早期に利用可能になるということは、攻撃者が BFD パケットをスプーフィングして、受信したパケットに BFD 高速パス上の次のページの計算に大量のリソースを費やすことを強制できないことを意味します。代わりに、受信者はほぼゼロのコストで次のページの内容を単純にチェックし、なりすましパケットを破棄できます。
When the receiver determines that it needs to move to the next page, it can simply swap the current and next pages (updating the BFD variables as appropriate) and then begin an asynchronous calculation of the next page. Such asynchronous calculations are preferable to calculating the next page in the BFD fast path.
受信側が次のページに移動する必要があると判断した場合、現在のページと次のページを単純に交換し (必要に応じて BFD 変数を更新)、次のページの非同期計算を開始できます。このような非同期計算は、BFD 高速パスの次のページを計算するよりも適しています。
This document does not make provisions for dealing with the case of losing more than 512 packets. Implementors MUST limit the value of Detect Multi to a small enough number in order to keep the number of lost packets within an acceptable limit.
この文書では、512 個を超えるパケットが失われた場合の対処については規定していません。実装者は、損失パケット数を許容範囲内に保つために、Detect Multi の値を十分に小さい数に制限しなければなりません (MUST)。
In a keyed algorithm, the key is shared between the two systems. Distribution of this key to all the systems at the same time can be quite a cumbersome task. BFD sessions running a fast rate may require these keys to be refreshed often, which poses a further challenge.
鍵付きアルゴリズムでは、鍵は 2 つのシステム間で共有されます。このキーをすべてのシステムに同時に配布することは、非常に面倒な作業となる可能性があります。高速で実行される BFD セッションでは、これらのキーを頻繁に更新する必要がある場合があり、これによりさらなる課題が生じます。
While the Auth Key ID field provides for the provisioning of multiple keys simultaneously, there is no way within the BFD protocol for each party to signal which set of Key IDs are supported. Any such signaling or negotiation needs to be done "out of band" for BFD and usually via manual administrator configuration.
認証キー ID フィールドでは複数のキーを同時にプロビジョニングできますが、BFD プロトコル内では各当事者がどのキー ID のセットがサポートされているかを通知する方法がありません。このようなシグナリングやネゴシエーションは、BFD の「帯域外」で行う必要があり、通常は手動の管理者設定を介して行われます。
The seeding mechanism for ISAAC, covered in Section 10, is carried out only once for a BFD session. In order to rotate keys, it is REQUIRED to administratively disable the BFD session as part of changing the keys. This permits the new session to be seeded as part of bringing up the new session.
セクション 10 で説明する ISAAC のシードメカニズムは、BFD セッションに対して 1 回だけ実行されます。キーをローテーションするには、キーの変更の一環として BFD セッションを管理上無効にする必要があります。これにより、新しいセッションの起動の一部として新しいセッションをシードできるようになります。
There are two ways to transition away from using ISAAC. One way is via state changes: either the link goes down due to a fault or one party signals a state change via a packet signed with a more computationally intensive authentication. The second situation is where one party wishes to temporarily signal via a more computationally intensive method that it is still Up by setting the Optimized Authentication Mode field from value 2 to value 1.
ISAAC の使用から移行するには 2 つの方法があります。1 つの方法は状態変更によるものです。障害によりリンクがダウンするか、一方のパーティがより計算量の多い認証で署名されたパケットを介して状態変更を通知します。2 番目の状況は、一方の当事者が、最適化された認証モード フィールドを値 2 から値 1 に設定することで、まだ稼働中であることをより計算集約的な方法で一時的に通知したい場合です。
The more computationally intensive authentication type provides for full packet integrity checks, which serves as a stronger indication that the session is Up and that both parties are fully synchronized. This switch can be done at any time during a session.
より計算量の多い認証タイプでは、完全なパケット整合性チェックが行われ、セッションが開始されていて、双方が完全に同期していることをより強力に示すことができます。この切り替えはセッション中いつでも行うことができます。
It is RECOMMENDED that implementations periodically switch to the more computationally intensive authentication type for packets that maintain the session in the Up state. The interval between these switches SHOULD be long enough that the system still gains significant benefit from using Meticulous Keyed ISAAC Authentication. See [RFC9985] for the appropriate procedure on switching Optimized Authentication Mode.
実装では、セッションをアップ状態に維持するパケットについて、より計算量の多い認証タイプに定期的に切り替えることが推奨されます。これらの切り替え間の間隔は、システムが Meticulous Keyed ISAAC Authentication を使用することで大きなメリットを得るのに十分な長さである必要があります (SHOULD)。最適化認証モードの切り替えに関する適切な手順については、[RFC9985] を参照してください。
When switching to the more computationally intensive authentication mode after ISAAC has been seeded, the Authentication Section's Sequence Number field will continue meticulously increasing. In order to permit transition back to ISAAC as the less computationally intensive authentication mechanism, it is necessary for ISAAC to continue to generate pages appropriate for validating the received sequence number.
ISAAC がシードされた後に、より計算量の多い認証モードに切り替えると、認証セクションのシーケンス番号フィールドは細心の注意を払って増加し続けます。計算量の少ない認証メカニズムとして ISAAC への移行を許可するには、ISAAC が受信したシーケンス番号を検証するのに適切なページを生成し続ける必要があります。
[RFC9985] describes the procedures that require the switch to the more computationally intensive authentication mode -- particularly BFD Poll Sequences.
[RFC9985] では、より計算量の多い認証モード、特に BFD ポーリング シーケンスへの切り替えを必要とする手順について説明しています。
This YANG module adds two identities defined in this document to the YANG key chain model described in [RFC8177]. One of them uses the Meticulous Keyed MD5 as the more computationally intensive authentication and Meticulous Keyed ISAAC, ISAAC Format as the less computationally intensive authentication. The other uses the Meticulous Keyed SHA-1 as the more computationally intensive authentication and Meticulous Keyed ISAAC, ISAAC Format as the less computationally intensive authentication.
この YANG モジュールは、このドキュメントで定義されている 2 つの ID を [RFC8177] で説明されている YANG キー チェーン モデルに追加します。そのうちの 1 つは、計算量の多い認証として Meticulous Keyed MD5 を使用し、計算量の少ない認証として Meticulous Keyed ISAAC、ISAAC 形式を使用します。もう 1 つは、計算量の多い認証として Meticulous Keyed SHA-1 を使用し、計算量の少ない認証として Meticulous Keyed ISAAC、ISAAC 形式を使用します。
module ietf-bfd-met-keyed-isaac {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac";
prefix bfd-mki;
import ietf-key-chain {
prefix key-chain;
reference
"RFC 8177: YANG Data Model for Key Chains.";
}
organization
"IETF Bidirectional Forwarding Detection (BFD) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/bfd>
WG List: <rtg-bfd@ietf.org>
Authors: Mahesh Jethanandani (mjethanandani@gmail.com)
Ashesh Mishra (ashesh@aalyria.com)
Jeffrey Haas (jhaas@juniper.net)
Alan Dekok (alan.dekok@inkbridge.io)
Sonal Agarwal (sonal@arrcus.com).";
description
"This YANG module provides identities derived from the
ietf-key-chain model for the experimental BFD Meticulous Keyed
ISAAC Authentication Mechanism.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9986
(https://www.rfc-editor.org/info/rfc9986); see the RFC itself
for full legal notices.";
revision 2026-06-19 {
description
"Initial Version.";
reference
"RFC 9986: Meticulous Keyed ISAAC for Bidirectional
Forwarding Detection (BFD) Optimized Authentication.";
}
identity optimized-md5-meticulous-keyed-isaac {
base key-chain:crypto-algorithm;
description
"BFD Optimized Authentication using Meticulous Keyed MD5 as the
strong authentication and Meticulous Keyed ISAAC, ISAAC Format
as the less computationally intensive authentication.";
reference
"RFC 9986: Meticulous Keyed ISAAC for Bidirectional
Forwarding Detection (BFD) Optimized Authentication.";
}
identity optimized-sha1-meticulous-keyed-isaac {
base key-chain:crypto-algorithm;
description
"BFD Optimized Authentication using Meticulous Keyed SHA-1 as
the strong authentication and Meticulous Keyed ISAAC, ISAAC
Format as the less computationally intensive authentication.";
reference
"RFC 9986: Meticulous Keyed ISAAC for Bidirectional
Forwarding Detection (BFD) Optimized Authentication.";
}
}
IANA has assigned two BFD Auth Types, one URI, and one YANG module as described in this section.
このセクションで説明するように、IANA は 2 つの BFD 認証タイプ、1 つの URI、および 1 つの YANG モジュールを割り当てました。
IANA has added the following two Auth Types to the "BFD Authentication Types" registry and to the accompanying YANG and MIB modules:
IANA は、次の 2 つの認証タイプを「BFD 認証タイプ」レジストリと、付随する YANG および MIB モジュールに追加しました。
* 7: Optimized MD5 Meticulous Keyed ISAAC Authentication
* 7: 最適化された MD5 細密キー付き ISAAC 認証
* 8: Optimized SHA-1 Meticulous Keyed ISAAC Authentication
* 8: 最適化された SHA-1 細密キー付き ISAAC 認証
IANA has registered the following URI in the "ns" registry within the "IETF XML Registry" group [RFC3688]:
IANA は、「IETF XML Registry」グループ [RFC3688] 内の「ns」レジストリに次の URI を登録しました。
URI:
URI:
urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac
urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac
Registrant Contact:
登録者の連絡先:
The IESG
IESG
XML:
XML:
N/A; the requested URI is an XML namespace.
該当なし。要求された URI は XML 名前空間です。
IANA has registered the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group:
IANA は、「YANG Parameters」レジストリ グループ内の「YANG Module Names」レジストリ [RFC6020] に次の YANG モジュールを登録しました。
Name:
名前：
ietf-bfd-met-keyed-isaac
ietf-bfd-met-keyed-isaac
Maintained by IANA?
IANAによって保守されていますか？
N
N
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac
urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac
Prefix:
プレフィックス:
bfd-mki
bfd-mki
Reference:
参照：
RFC 9986
RFC 9986
All security considerations of [RFC5880] and [RFC9985] apply to this document.
[RFC5880] および [RFC9985] のセキュリティに関する考慮事項はすべてこの文書に適用されます。
The distribution of secret keys is typically accomplished using provisioning. Secure distribution of these keys for any particular provisioning mechanism is out of scope for this document.
秘密キーの配布は通常、プロビジョニングを使用して行われます。特定のプロビジョニング メカニズムに対するこれらのキーの安全な配布は、このドキュメントの範囲外です。
Keys generated and distributed out of band for the purposes described in this specification are generally limited in the security they can provide. It is essential that these keys are selected well and protected when stored.
この仕様で説明されている目的で帯域外で生成および配布されるキーは、通常、提供できるセキュリティが制限されています。これらのキーを適切に選択し、保管時に保護することが重要です。
The security of this proposal depends on the security of the ISAAC algorithm, which has had minimal analysis. While it is believed that the algorithm is secure enough for this use case, no proof is offered. ISAAC was chosen for the reasons discussed in Section 3.1, as no other option was found to be suitable.
この提案のセキュリティは、最小限の分析しか行われていない ISAAC アルゴリズムのセキュリティに依存します。このアルゴリズムはこの使用例に対して十分に安全であると考えられていますが、その証拠は提供されていません。他に適切なオプションが見つからなかったため、セクション 3.1 で説明した理由により ISAAC が選択されました。
The choice of ISAAC was driven in part by the limited functionality of systems that implement this specification. Many of these systems do not have hardware assistance for cryptographic operations, meaning that any CSPRNG based on a block cipher would be unsuitably slow. Where hardware assistance for block ciphers is available, ISAAC offers no advantages over those methods.
ISAAC の選択は、この仕様を実装するシステムの機能が制限されていることによってもたらされました。これらのシステムの多くは、暗号化操作のためのハードウェア支援を備えていないため、ブロック暗号に基づく CSPRNG は不適切に遅くなります。ブロック暗号に対するハードウェア支援が利用可能な場合、ISAAC にはそれらの方法に勝る利点はありません。
As CPUs get faster and hardware acceleration becomes more prevalent, more secure methods become better options. Alternative solutions could be AES with hardware acceleration in Output Feedback Mode (OFB) (see FIPS 197 and SP 800-38A), Chacha in software [RFC8439], or other well-understood techniques.
CPU が高速になり、ハードウェア アクセラレーションが普及するにつれて、より安全な方法がより良い選択肢になります。代替ソリューションとしては、出力フィードバック モード (OFB) でのハードウェア アクセラレーションを備えた AES (FIPS 197 および SP 800-38A を参照)、ソフトウェアでの Chacha [RFC8439]、またはその他のよく理解されている技術が考えられます。
For these reasons and many others, the ISAAC CSPRNG is, at best, tolerable for use in this specification and is completely unsuitable for use in any other IETF protocol.
これらの理由や他の多くの理由により、ISAAC CSPRNG は、せいぜいこの仕様での使用に耐えられますが、他の IETF プロトコルでの使用にはまったく適していません。
The security of this proposal depends strongly on the length of the secret key and on its entropy. It is RECOMMENDED that the key be 16 octets in length or more.
この提案のセキュリティは、秘密鍵の長さとそのエントロピーに大きく依存します。キーの長さは 16 オクテット以上であることが推奨されます。
The dependency on the secret key for security is mitigated through the use of two 32-bit numbers: the Your Discriminator field from the BFD protocol and the ISAAC Seed. Both numbers are procedurally required to be random. These numbers serve as a nonce that inhibits attackers from performing an offline brute-force dictionary attack to discover the key.
セキュリティのための秘密キーへの依存性は、BFD プロトコルの Your Discriminator フィールドと ISAAC シードという 2 つの 32 ビット数値の使用によって軽減されます。どちらの数値も手順上ランダムであることが必要です。これらの番号は、攻撃者がキーを発見するためにオフラインでブルート フォース辞書攻撃を実行することを禁止するノンスとして機能します。
Meticulous Keyed ISAAC Authentication protects the session against the spoofing of BFD Up packets and keeps the BFD session Up when it would otherwise be reset.
細心の注意を払ったキー付き ISAAC 認証は、BFD アップ パケットのスプーフィングからセッションを保護し、リセットされる場合でも BFD セッションをアップ状態に保ちます。
In the event that Meticulously Keyed ISAAC, which is operating as the less computationally intensive authentication mechanism for Optimized BFD, is subverted, the periodic more computationally reauthentication mechanism will limit the time that the session is kept inappropriately in the Up state (Section 5 of [RFC9985]).
最適化された BFD の計算量の少ない認証メカニズムとして動作している Meticulously Keyed ISAAC が破壊された場合、より計算量の多い定期的な再認証メカニズムにより、セッションが不適切に Up 状態に維持される時間が制限されます ([RFC9985] のセクション 5)。
The Meticulous Keyed ISAAC Authentication method allows the BFD endpoints to detect a malicious packet via a number of different methods. Packets that are malformed are discarded. Packets that do not pass the BFD state machine [RFC5880] (Section 6.2) checks are discarded. Packets that do not have the correct sequence number, Seed, and Auth Key are discarded. These discarded packets have no effect on the BFD state machine.
Meticulous Keyed ISAAC 認証方式を使用すると、BFD エンドポイントがさまざまな方法で悪意のあるパケットを検出できます。不正な形式のパケットは破棄されます。BFD ステート マシン [RFC5880] (セクション 6.2) チェックに合格しないパケットは破棄されます。正しいシーケンス番号、シード、および認証キーを持たないパケットは破棄されます。これらの破棄されたパケットは、BFD ステート マシンには影響しません。
The correlation between the sequence number and the Auth Key ensures that each sequence number has a corresponding Auth Key associated with it. The structure and design of the ISAAC CSPRNG ensures that each Auth Key is unique and is unguessable.
シーケンス番号と認証キーの相関により、各シーケンス番号に対応する認証キーが関連付けられることが保証されます。ISAAC CSPRNG の構造と設計により、各認証キーが一意であり、推測できないことが保証されます。
Performing an attack on this authentication method would require all of the following to be true:
この認証方法に対して攻撃を実行するには、次のすべてが満たされる必要があります。
* The attacker is on-path and can perform an active attack.
* 攻撃者は経路上におり、積極的な攻撃を実行できます。
* The attacker has the contents of one or more packets.
* 攻撃者は 1 つ以上のパケットの内容を持っています。
* The attacker has deduced the secret key used for ISAAC and is able to correlate the sequence number to the current ISAAC state.
* 攻撃者は、ISAAC に使用される秘密キーを推測し、シーケンス番号を現在の ISAAC 状態に関連付けることができます。
These conditions are unlikely to all be true. If the secret key is long and complex, the search space to guess the secret key is too large to discover via brute-force. The use of the Seed and Your Discriminator fields when seeding ISAAC adds 64 bits of entropy to each session, which further makes offline dictionary attacks impractical.
これらの条件がすべて当てはまる可能性は低いです。秘密キーが長くて複雑な場合、秘密キーを推測するための検索スペースが大きすぎて、総当たりで発見できなくなります。ISAAC をシードするときに Seed フィールドと Your Discriminator フィールドを使用すると、各セッションに 64 ビットのエントロピーが追加されるため、オフライン辞書攻撃はさらに非実用的になります。
The cryptographic strength of the Optimized Authentication Mode methods is significantly different between SHA-1 and ISAAC. While ISAAC has had cryptanalysis and has not been shown to be broken, that analysis is limited. The question then is whether or not it is safe to use the same key for both mechanisms (SHA-1 and ISAAC), or should we require different keys for each mechanism?
最適化認証モード方式の暗号強度は、SHA-1 と ISAAC では大きく異なります。ISAAC は暗号解析を行っており、解読されたことは証明されていませんが、その解析には限界があります。ここで問題となるのは、両方のメカニズム (SHA-1 と ISAAC) で同じキーを使用するのが安全かどうか、それともメカニズムごとに異なるキーを要求する必要があるかということです。
ISAAC is seeded not only with the secret key, but also 32 bits of random data along with 32 bits of a sequence number. The use of this added randomness increases the difficulty of breaking the secret key.
ISAAC には、秘密キーだけでなく、32 ビットのシーケンス番号とともに 32 ビットのランダム データもシードされます。この追加されたランダム性を使用すると、秘密キーを解読する難易度が高まります。
If we recommend different keys, then it is possible for the two keys to be configured differently on each side of a BFD link. For example, a correctly configured key could allow to the BFD state machine to advance to Up. Then, when the session switches to using to less computationally intensive Optimized Authentication Mode with a different key, that key may not match and the session would immediately drop. Suggesting that the keys be identical instead means that no such misconfiguration is possible.
異なるキーを推奨する場合、BFD リンクの両側で 2 つのキーが異なるように設定される可能性があります。たとえば、キーが正しく設定されていれば、BFD ステート マシンが Up に進むことができます。その後、セッションが別のキーを使用した、計算量の少ない最適化認証モードの使用に切り替わると、そのキーが一致しない可能性があり、セッションはすぐに切断されます。代わりにキーが同一であることを示唆することは、そのような構成ミスの可能性がないことを意味します。
If it becomes possible to recover the secret key for the Meticulous Keyed ISAAC Auth Type and the same key is utilized as a key for more computationally intensive authentication types, such as the MD5 and SHA-1 types defined in this document, then authentication for those mechanisms would be compromised.
Meticulous Keyed ISAAC Auth Type の秘密鍵を回復することが可能になり、同じ鍵がより計算量の多い認証タイプ (このドキュメントで定義されている MD5 や SHA-1 タイプなど) の鍵として利用される場合、これらのメカニズムの認証が危険にさらされることになります。
Implementations are therefore free to use the same key or different keys for the Optimized Authentication Modes. The choice to use the a single secret key or distinct secret key per Optimized Authentication Mode must be evaluated by the operator balancing their security and operational requirements.
したがって、実装では、最適化された認証モードに同じキーを自由に使用することも、異なるキーを使用することもできます。最適化認証モードごとに単一の秘密キーを使用するか個別の秘密キーを使用するかの選択は、セキュリティと運用要件のバランスをとったオペレーターによって評価される必要があります。
BFD [RFC5880] and its Authentication mechanisms, including Meticulous Keyed ISAAC Authentication specified in this document, make use of random numbers. Such numbers are used in:
BFD [RFC5880] と、この文書で規定されている Meticulous Keyed ISAAC Authentication を含むその認証メカニズムは、乱数を利用します。このような数値は以下で使用されます。
* Per BFD session Local Discriminators (bfd.LocalDiscr - Section 6.8.1 of [RFC5880])
* BFD セッションごとのローカル識別子 (bfd.LocalDiscr - [RFC5880] のセクション 6.8.1)
* Initial Authentication sequence number (bfd.XmitAuthSeq - Section 6.8.1 of [RFC5880])
* 初期認証シーケンス番号 (bfd.XmitAuthSeq - [RFC5880] のセクション 6.8.1)
* Meticulous Keyed ISAAC Authentication, ISAAC Format Seed (Section 4.1)
* 綿密なキー付き ISAAC 認証、ISAAC フォーマット シード (セクション 4.1)
The mechanism defined in this document creates an instance of ISAAC for each BFD session seeded by that session's secret key(s) and two locally generated random numbers: the session's Local Discriminator echoed back in the protocol as Your Discriminator and a locally generated Seed. These random numbers are infrequently generated by comparison to the use case for BFD Optimized Authentication that ISAAC addresses. Thus, stronger random number generators with better guarantees of entropy can be used for these purposes.
このドキュメントで定義されているメカニズムは、セッションの秘密キーとローカルで生成された 2 つの乱数によってシードされた BFD セッションごとに ISAAC のインスタンスを作成します。セッションのローカル ディスクリミネーターは、プロトコル内で Your Discriminator としてエコー バックされ、ローカルで生成されたシードです。ISAAC が扱う BFD 最適化認証の使用例と比較すると、これらの乱数が生成される頻度は低くなります。したがって、エントロピーの保証がより優れた強力な乱数生成器をこれらの目的に使用できます。
It is RECOMMENDED that these locally generated random numbers used for the BFD protocol and for initializing ISAAC utilize a non-ISAAC CSPRNG.
BFD プロトコルおよび ISAAC の初期化に使用されるローカルに生成された乱数は、非 ISAAC CSPRNG を利用することが推奨されます。
Random numbers in BFD MUST come from a different source than the ISAAC generator used to create per-BFD session Auth Keys. A different instance of an ISAAC generator MAY be used to create random numbers for use elsewhere in BFD. In order avoid inappropriate disclosure of local random number generator state, that instance MUST be distinct from the generator used for per-session Auth Keys, and it MUST NOT be keyed from any BFD session's secret key.
BFD の乱数は、BFD セッションごとの認証キーの作成に使用される ISAAC ジェネレーターとは異なるソースから取得しなければなりません (MUST)。ISAAC ジェネレーターの別のインスタンスを使用して、BFD の他の場所で使用する乱数を作成することができます (MAY)。ローカル乱数ジェネレーターの状態の不適切な開示を避けるために、そのインスタンスはセッションごとの認証キーに使用されるジェネレーターとは別のものでなければなりません (MUST)。また、BFD セッションの秘密キーからキーを入力してはなりません (MUST NOT)。
This section is modeled after the template described in Section 3.7.1 of [RFC9907].
このセクションは、[RFC9907] のセクション 3.7.1 で説明されているテンプレートをモデルにしています。
The "ietf-bfd-met-keyed-isaac" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication.
「ietf-bfd-met-keyed-isaac」YANG モジュールは、ネットワーク構成プロトコル (NETCONF) [RFC6241] や RESTCONF [RFC8040] などの YANG ベースの管理プロトコルを介してアクセスされるように設計されたデータ モデルを定義します。これらの YANG ベースの管理プロトコルは、(1) セキュア トランスポート層 (セキュア シェル (SSH) [RFC4252]、TLS [RFC8446]、QUIC [RFC9000] など) を使用する必要があり、(2) 相互認証を使用する必要があります。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
Network Configuration Access Control Model (NACM) [RFC8341] は、特定の NETCONF または RESTCONF ユーザーのアクセスを、利用可能なすべての NETCONF または RESTCONF プロトコルの操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
There are no particularly sensitive writable data nodes.
特に機密性の高い書き込み可能なデータ ノードはありません。
There are no particularly sensitive readable data nodes.
特に機密性の高い読み取り可能なデータ ノードはありません。
There are no particularly sensitive RPC or action operations.
特に機密性の高い RPC 操作やアクション操作はありません。
The YANG module defines a set of identities. These identities are intended to be reused by other YANG modules. The module by itself does not expose any data nodes that are writable, data nodes that contain read-only state, or RPCs. As such, there are no additional security issues related to the YANG module that need to be considered.
YANG モジュールは一連の ID を定義します。これらの ID は、他の YANG モジュールによって再利用されることを目的としています。このモジュール自体は、書き込み可能なデータ ノード、読み取り専用状態を含むデータ ノード、または RPC を公開しません。そのため、YANG モジュールに関連して考慮する必要のある追加のセキュリティ問題はありません。
[ISAAC] Jenkins, R. J., "ISAAC and RC4", 1996,
<https://www.burtleburtle.net/bob/rand/isaac.html>.
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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>.
[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
Zhang, "YANG Data Model for Key Chains", RFC 8177,
DOI 10.17487/RFC8177, June 2017,
<https://www.rfc-editor.org/info/rfc8177>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC9985] Jethanandani, M., Mishra, A., Haas, J., Saxena, A., and M.
Bhatia, "Optimizing Bidirectional Forwarding Detection
(BFD) Authentication", RFC 9985, DOI 10.17487/RFC9985,
June 2026, <https://www.rfc-editor.org/info/rfc9985>.
[ISAAC-Plus]
Aumasson, J-P., "On the pseudo-random generator ISAAC",
Cryptology ePrint Archive, Paper 2006/438, 2006,
<https://eprint.iacr.org/2006/438.pdf>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines
for Authors and Reviewers of Documents Containing YANG
Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907,
March 2026, <https://www.rfc-editor.org/info/rfc9907>.
The authors want to thank Ketan Talaulikar for his reviews and suggestions that have improved the document.
著者らは、この文書を改善するためのレビューと提案をしてくれた Ketan Talaulikar に感謝したいと思います。
The authors of this document want to acknowledge Ankur Saxena and Reshad Rahman as contributors to this document.
この文書の著者は、Ankur Saxena と Reshad Rahman がこの文書の貢献者であることを認めたいと考えています。
Alan DeKok
InkBridge Networks
100 Centrepointe Drive #200
Ottawa ON K2G 6B1
Canada
Email: alan.dekok@inkbridge.io
Mahesh Jethanandani
Arrcus
Email: mjethanandani@gmail.com
Sonal Agarwal
Arrcus, Inc.
170 W. Tasman Drive
San Jose, CA 95070
United States of America
Email: sagarwal12@gmail.com
Ashesh Mishra
Aalyria Technologies
Email: ashesh@aalyria.com
Jeffrey Haas
HPE
Email: jeffrey.haas@hpe.com