Internet Engineering Task Force (IETF) M. Jethanandani
Request for Comments: 9985 Arrcus
Category: Experimental A. Mishra
ISSN: 2070-1721 Aalyria Technologies
J. Haas
HPE
A. Saxena
Ciena Corporation
M. Bhatia
Google
June 2026
This document describes an experimental optimization to Bidirectional Forwarding Detection (BFD) Authentication. This optimization enables BFD to scale better when there is a desire to use authentication where applying the same authentication mechanism to every BFD Control Packet may adversely impact performance. This optimization partitions BFD Authentication into a more computationally intensive (MCI) mechanism that is applied to BFD significant changes and a less computationally intensive (LCI) mechanism that is applied to the majority of BFD Control Packets.
このドキュメントでは、双方向転送検出 (BFD) 認証の実験的な最適化について説明します。この最適化により、すべての BFD 制御パケットに同じ認証メカニズムを適用するとパフォーマンスに悪影響を及ぼす可能性がある場合に認証を使用する必要がある場合に、BFD をより適切に拡張できるようになります。この最適化により、BFD 認証は、BFD の重要な変更に適用される計算量の多い (MCI) メカニズムと、BFD 制御パケットの大部分に適用される計算量の少ない (LCI) メカニズムに分割されます。
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/rfc9985.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9985 で入手できます。
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. Requirements Language
2. Terminology
3. BFD Control Packets That Require MCI Authentication
3.1. Protecting BFD Significant Changes with MCI Authentication
4. Using LCI Auth Types
5. Periodic MCI Reauthentication
6. Optimized Authentication Modes
7. Signaling Optimized Authentication
7.1. Transmitting and Receiving Using Optimized Authentication
7.2. Optimized Authentication Operations
8. Optimizing Authentication YANG Data Model
8.1. Data Model Overview
8.2. Tree Diagram
8.3. The YANG Data Model
9. IANA Considerations
9.1. IETF XML Registry
9.2. The YANG Module Names Registry
10. Security Considerations
10.1. Protocol Security Considerations
10.2. YANG Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Examples
A.1. Single-Hop BFD Configuration
Appendix B. Experimental Status
Acknowledgments
Contributors
Authors' Addresses
BFD [RFC5880] authentication procedures, when enabled, authenticate each control packet using the same authentication mechanism. Devices implementing BFD are often resource-constrained and authentication may adversely impact the performance of BFD, thus discouraging the deployment of authentication.
BFD [RFC5880] 認証手順が有効になっている場合、同じ認証メカニズムを使用して各制御パケットが認証されます。BFD を実装するデバイスはリソースに制約があることが多く、認証が BFD のパフォーマンスに悪影響を与える可能性があるため、認証の導入が妨げられます。
When implemented in software, BFD Authentication mechanisms compete with other necessary work done by the systems implementing the protocol. When implemented using hardware acceleration, these mechanisms may scale better situationally, but they still impose a cost on the implementation. BFD's value is tied to its ability to scale in terms of numbers of sessions and a Detection Time that relies on sending its control packets at a high rate. Implementers and operators are forced to evaluate trade-offs of the benefits of authentication vs. its impact on BFD performance.
ソフトウェアに実装されると、BFD 認証メカニズムは、プロトコルを実装するシステムによって実行される他の必要な作業と競合します。ハードウェア アクセラレーションを使用して実装すると、これらのメカニズムは状況に応じてより適切に拡張できる可能性がありますが、実装には依然としてコストがかかります。BFD の価値は、セッション数と、高速での制御パケットの送信に依存する検出時間の点で拡張する能力に結びついています。実装者と運用者は、認証の利点と BFD パフォーマンスへの影響のトレードオフを評価する必要があります。
The authentication mechanisms documented in [RFC5880], MD5 Message-Digest Algorithm [RFC1321], and Secure Hash Algorithm (SHA-1) [RFC3174] are not particularly strong in a cryptographic sense. However, they may still not appropriately scale situationally in a given implementation. In the future, there may be a desire to use stronger authentication mechanisms than those already specified, and those mechanisms are likely to use even more resources.
[RFC5880]、MD5 Message-Digest Algorithm [RFC1321]、および Secure Hash Algorithm (SHA-1) [RFC3174] に文書化されている認証メカニズムは、暗号化の意味ではそれほど強力ではありません。ただし、特定の実装では状況に応じて適切にスケーリングできない場合があります。将来的には、すでに指定されている認証メカニズムよりも強力な認証メカニズムを使用することが望まれる可能性があり、それらのメカニズムはさらに多くのリソースを使用する可能性があります。
The BFD protocol can broadly be described as the set of procedures that handle its state machine changes to reach the Up state, and once BFD is in the Up state, it will send those Up packets at the negotiated high rate. The number of BFD Control Packets needed to signal state changes (called significant changes) is very small, while the majority of the Control Packets validate that the session remains in the Up state.
BFD プロトコルは、Up 状態に到達するためにステート マシンの変更を処理する一連の手順として大まかに説明できます。BFD が Up 状態になると、ネゴシエートされた高レートで Up パケットを送信します。状態変化（重大な変化と呼ばれる）を通知するのに必要な BFD 制御パケットの数は非常に少ないですが、制御パケットの大部分はセッションがアップ状態に留まることを検証します。
This document describes an experimental optimization to BFD Authentication. This optimization partitions BFD Authentication into a more computationally intensive (MCI) mechanism used to authenticate significant changes, and a less computationally intensive (LCI) mechanism applied to the majority of the BFD Control Packets that don't signal such significant changes.
このドキュメントでは、BFD 認証の実験的な最適化について説明します。この最適化により、BFD 認証は、重要な変更の認証に使用される計算量の多い (MCI) メカニズムと、そのような重要な変更を通知しない BFD 制御パケットの大部分に適用される計算量の少ない (LCI) メカニズムに分割されます。
The details of the motivation for experimental status are given in Appendix B.
実験ステータスの動機の詳細は付録 B に記載されています。
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 terms used in this document have been defined in BFD [RFC5880].
この文書で使用される以下の用語は、BFD [RFC5880] で定義されています。
* Auth Type
* 認証タイプ
* Detect Multiplier
* 乗数の検出
* Detection Time
* 検出時間
The following terms are introduced in this document.
この文書では次の用語が紹介されています。
significant change:
大きな変化:
A state change, demand mode change (to D bit), or poll sequence change (P or F bit). Changes to BFD Control Packets that do not require a poll sequence, such as bfd.DetectMult, are also considered a significant change.
状態の変更、デマンド モードの変更 (D ビットへ)、またはポーリング シーケンスの変更 (P または F ビット)。bfd.DetectMult など、ポーリング シーケンスを必要としない BFD 制御パケットへの変更も重要な変更とみなされます。
More Computationally Intensive (MCI) authentication:
より多くの計算集約型 (MCI) 認証:
The authentication mechanism applied to BFD Control Packets that are significant changes.
BFD 制御パケットに適用される認証メカニズムは大幅に変更されています。
Less Computationally Intensive (LCI) authentication:
計算量が少ない (LCI) 認証:
The authentication mechanism applied to BFD Control Packets that are NOT significant changes.
BFD 制御パケットに適用される認証メカニズムは、大きな変更ではありません。
configured MCI reauthentication interval:
設定された MCI 再認証間隔:
Interval at which BFD Control Packets are retried using MCI authentication.
MCI 認証を使用して BFD 制御パケットが再試行される間隔。
The authentication mechanisms described in this optimization are paired as MCI and LCI. While it will be generally the case that the relationship between these mechanisms will be "stronger" and "less strong", this document doesn't use the term "strong" to avoid conflation with either mechanism's relative cryptographic strength. The relative criteria for each mechanism is the impact on the implementation.
この最適化で説明されている認証メカニズムは、MCI と LCI としてペアになっています。これらのメカニズム間の関係は「強い」場合と「弱い」場合が一般的ですが、このドキュメントでは、どちらかのメカニズムの相対的な暗号強度との混同を避けるために「強い」という用語を使用しません。各メカニズムの相対的な基準は、実装への影響です。
The intention of these optimized procedures is to permit more computationally intensive authentication for BFD state changes and utilize the less computationally intensive authentication mechanisms to provide protection for the session in the Up state while performing less work overall. Such procedures are intended to aid BFD session scaling without compromising BFD session security.
The intention of these optimized procedures is to permit more computationally intensive authentication for BFD state changes and utilize the less computationally intensive authentication mechanisms to provide protection for the session in the Up state while performing less work overall.このような手順は、BFD セッションのセキュリティを損なうことなく、BFD セッションのスケーリングを支援することを目的としています。
All BFD Control Packets with the state AdminDown, Down, and Init MUST use MCI authentication.
状態が AdminDown、Down、および Init であるすべての BFD 制御パケットは、MCI 認証を使用する必要があります。
Once the BFD state machine has reached the Up state, it will continue to send BFD Control Packets with MCI authentication in the Up state for a period as discussed in Section 7.2. If optimized authentication mechanisms are in use, as defined in Section 6, the session MAY switch to the LCI mode.
BFD ステート マシンが Up 状態に達すると、セクション 7.2 で説明したように、一定期間 Up 状態で MCI 認証を含む BFD 制御パケットを送信し続けます。セクション 6 で定義されているように、最適化された認証メカニズムが使用されている場合、セッションは LCI モードに切り替わってもよい(MAY)。
The contents of an Up packet must not change aside from the Authentication Section unless MCI authentication is in use.
MCI 認証が使用されている場合を除き、Up パケットの内容は認証セクションを除いて変更してはなりません。
This document proposes that BFD Control Packets that signal a state change, a change in demand mode (D bit), or a poll sequence (P or F bit change) be categorized as a "significant change". Control packets that do not require a poll sequence, such as bfd.DetectMult, are also considered a significant change.
この文書では、状態変化、デマンド モードの変化 (D ビット)、またはポーリング シーケンス (P または F ビットの変化) を通知する BFD 制御パケットを「重大な変化」として分類することを提案しています。bfd.DetectMult など、ポーリング シーケンスを必要としない制御パケットも重要な変更とみなされます。
Such significant changes are intended to be protected by more computationally intensive authentication.
このような重要な変更は、より計算量の多い認証によって保護されることを目的としています。
The majority of packets exchanged in a BFD session in the Up state are not significant changes. This document proposes a new optimized authentication mode where packets that are not significant changes may use an LCI authentication mechanism.
Up 状態の BFD セッションで交換されるパケットの大部分は、重大な変更ではありません。この文書は、重要な変更ではないパケットが LCI 認証メカニズムを使用できる、新しい最適化された認証モードを提案します。
Once the session has reached the Up state, the session can use an LCI Auth Type derived from the format in Section 7. Currently, this includes:
セッションが Up 状態に達すると、セッションはセクション 7 の形式から派生した LCI 認証タイプを使用できます。現在、これには以下が含まれます。
* Meticulous Keyed ISAAC Authentication as described in [RFC9986]. This authentication type protects the BFD session when BFD Up packets do not change, because only the paired devices know the shared secret, key, and sequence number to select the ISAAC result.
* [RFC9986] で説明されている細心の鍵付き ISAAC 認証。この認証タイプは、ISAAC 結果を選択するための共有シークレット、キー、およびシーケンス番号を知っているのはペアになったデバイスだけであるため、BFD Up パケットが変更されない場合に BFD セッションを保護します。
Other mechanisms may be defined in the future.
将来的には他のメカニズムも定義される可能性があります。
When using the LCI authentication mechanism, BFD should periodically test the session using the MCI authentication mechanism. MCI authentication is tested using a Poll sequence. To test MCI authentication, a Poll sequence SHOULD be initiated by the sender using the MCI authentication mode rather than the LCI mechanism. If a control packet with the Final (F) bit is not received using MCI authentication within twice the Detect Interval as would be calculated by the receiving system, the session has been compromised, and it MUST be brought down.
LCI 認証メカニズムを使用する場合、BFD は MCI 認証メカニズムを使用してセッションを定期的にテストする必要があります。MCI 認証は、ポーリング シーケンスを使用してテストされます。MCI 認証をテストするには、送信者が LCI メカニズムではなく MCI 認証モードを使用してポーリング シーケンスを開始する必要があります (SHOULD)。最終 (F) ビットを持つ制御パケットが、受信システムによって計算される検出間隔の 2 倍以内に MCI 認証を使用して受信されない場合、セッションは危険にさらされており、セッションをダウンしなければなりません。
The value "twice the Detect interval as would be calculated by the receiving system" is, roughly, twice the number of packets the local system would transmit to the receiving system within its own Detect Interval. This accommodates for possible packet loss from the sending system during the Poll sequence to the receiving system, plus time for the receiving system to transmit a control packet with the Final (F) bit set to the local system.
「受信システムによって計算される検出間隔の 2 倍」という値は、ローカル システムが自身の検出間隔内で受信システムに送信するパケット数のおよそ 2 倍です。これにより、ポーリング シーケンス中の送信システムから受信システムへのパケット損失の可能性と、受信システムが最終 (F) ビットが設定された制御パケットをローカル システムに送信する時間に対応できます。
This "MCI reauthentication interval" for performing such periodic tests using the MCI authentication mechanism can be configured depending on the capability of the system.
このような MCI 認証機構を使用した定期的なテストを実行するための「MCI 再認証間隔」は、システムの能力に応じて設定できます。
Most packets transmitted in a BFD session are BFD Up packets. MCI authenticating a limited subset of these packets with a Poll sequence as described above, e.g., every one minute, significantly reduces the computational demand for the system while maintaining security of the session across the configured MCI reauthentication interval.
BFD セッションで送信されるほとんどのパケットは BFD アップ パケットです。前述したように、ポーリング シーケンスを使用してこれらのパケットの限定されたサブセットを、たとえば 1 分ごとに認証する MCI は、設定された MCI 再認証間隔全体でセッションのセキュリティを維持しながら、システムの計算需要を大幅に削減します。
The cryptographic authentication mechanisms specified in Section 6.7 of BFD [RFC5880] describe enabling and disabling of authentication as a one-time operation. The following is stated in Section 6.7.1 of [RFC5880]:
BFD [RFC5880] のセクション 6.7 で指定されている暗号化認証メカニズムでは、認証の有効化と無効化を 1 回限りの操作として説明しています。The following is stated in Section 6.7.1 of [RFC5880]:
... implementations using this method SHOULD only allow the authentication state to be changed at most once without some form of intervention (so that authentication cannot be turned on and off repeatedly simply based on the receipt of BFD Control Packets from remote systems).
... このメソッドを使用する実装では、何らかの介入を行わずに認証状態の変更を最大 1 回のみ許可する必要があります (リモート システムからの BFD 制御パケットの受信に基づいて認証を繰り返しオンまたはオフにすることができないように)。
Once enabled, every packet must have the Authentication Present (A) bit set and the associated Authentication Type appended (Section 4.1 of [RFC5880]). In addition, Section 6.7.1 of [RFC5880] states that an implementation SHOULD NOT allow the authentication state to be changed based on the receipt of a BFD Control Packet.
有効にすると、すべてのパケットに認証存在 (A) ビットが設定され、関連する認証タイプが追加されなければなりません ([RFC5880] のセクション 4.1)。さらに、[RFC5880] のセクション 6.7.1 では、実装では BFD 制御パケットの受信に基づいて認証状態を変更することを許可すべきではないと述べています。
This document proposes that an "optimized" authentication mode that permits both an MCI authentication mode and an LCI mode be used within the same BFD session. This pairing of an MCI and an LCI mode of authentication is carried in new BFD Authentication types representing a given optimized authentication type pairing.
この文書では、MCI 認証モードと LCI モードの両方を同じ BFD セッション内で使用できる「最適化された」認証モードを提案しています。MCI と LCI 認証モードのこのペアリングは、特定の最適化された認証タイプのペアリングを表す新しい BFD 認証タイプで実行されます。
This document defines which BFD Control Packets require MCI authentication in Section 3.1. A BFD Control Packet that fails authentication, or a BFD Control Packet that was supposed to be MCI-authenticated but was not (e.g., a significant change packet), is discarded. However, there is no change to the state machine for BFD, as the decision of a significant change is still decided by how many valid consecutive packets were received.
この文書では、セクション 3.1 で、どの BFD 制御パケットが MCI 認証を必要とするかを定義します。認証に失敗した BFD 制御パケット、または MCI 認証されるはずだったが認証されなかった BFD 制御パケット（重大な変更パケットなど）は、破棄されます。ただし、重要な変更の決定は依然として有効な連続パケットの数によって決定されるため、BFD のステート マシンには変更はありません。
In this specification, the contents of an Up packet MUST NOT change aside from the Authentication Section without MCI authentication. The full procedure is documented in the following sections.
この仕様では、MCI 認証なしで、認証セクションを除き、Up パケットの内容を変更してはなりません (MUST NOT)。完全な手順については、次のセクションで説明します。
When the Authentication Present (A) bit is set and the Auth Type ([RFC5880], Section 4.1) is a type supporting Optimized BFD Authentication, the Auth Type signals a pairing of an MCI authentication type and an LCI authentication type. This pairing is advertised in a single Auth Type value in order to permit implementations to be aware that:
Authentication Present (A) ビットが設定されており、Auth Type ([RFC5880]、セクション 4.1) が最適化 BFD 認証をサポートするタイプである場合、Auth Type は MCI 認証タイプと LCI 認証タイプのペアを通知します。このペアリングは、実装が次のことを認識できるようにするために、単一の Auth Type 値でアドバタイズされます。
* Optimized BFD procedures will be in use.
* 最適化された BFD 手順が使用されます。
* The pairing of the MCI and LCI authentication mechanisms will be used for that session.
* MCI と LCI 認証メカニズムのペアがそのセッションに使用されます。
* There is a requirement to carry a Sequence Number.
* シーケンス番号を保持する必要があります。
* The current MCI or LCI mode will be carried as described below.
* 現在の MCI または LCI モードは以下のように実行されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Specific Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Common Optimized BFD Authentication Section
図 1: 共通の最適化された BFD 認証セクション
The values of Auth Type and Auth Len are defined in their respective Optimized BFD Authentication procedural documents.
Auth Type と Auth Len の値は、それぞれの最適化 BFD 認証手順文書で定義されています。
The values of the Optimized Authentication Mode field are:
[最適化された認証モード] フィールドの値は次のとおりです。
1. The MCI authentication type for Optimized BFD Auth Types.
1. 最適化された BFD 認証タイプの MCI 認証タイプ。
2. The LCI authentication type for Optimized BFD Auth Types.
2. 最適化された BFD 認証タイプの LCI 認証タイプ。
Authentication Specific Data: When using the more computationally intensive authentication type, the remainder of the Authentication Section carries that type's data.
認証固有のデータ: より計算量の多い認証タイプを使用する場合、認証セクションの残りの部分にはそのタイプのデータが含まれます。
The procedures for authenticating BFD Control Packets using Optimized Authentication are similar to the existing procedures covered in Section 6.7 of [RFC5880]. Optimized Authentication modes have common procedural requirements for authentication regardless of which more or less computationally intensive authentication modes are used.
最適化認証を使用して BFD 制御パケットを認証する手順は、[RFC5880] のセクション 6.7 で取り上げられている既存の手順と似ています。最適化された認証モードには、多かれ少なかれ計算集約型の認証モードが使用されるかどうかに関係なく、認証のための共通の手順要件があります。
The required value of the Auth Len field for a given Optimized Authentication mode is defined in the respective specifications for their respective MCI and LCI modes.
特定の最適化認証モードに必要な Auth Len フィールドの値は、それぞれの MCI モードおよび LCI モードの仕様で定義されています。
The following common procedures apply to authenticating BFD Control packets utilizing Optimized Authentication:
次の一般的な手順は、最適化認証を利用した BFD 制御パケットの認証に適用されます。
* If the received BFD Control Packet does not contain an Authentication Section ([RFC5880], Section 4.1), or the Auth Type is not a supported Optimized Authentication Auth Type, then the received packet MUST be discarded.
* 受信した BFD 制御パケットに認証セクション ([RFC5880]、セクション 4.1) が含まれていない場合、または認証タイプがサポートされている最適化認証認証タイプではない場合、受信したパケットは破棄されなければなりません(MUST)。
* If the received BFD Control Packet contains an optimized authentication type using these procedures and the Optimized Authentication Mode field is not 1 or 2, then the received packet MUST be discarded.
* 受信した BFD 制御パケットにこれらの手順を使用して最適化された認証タイプが含まれており、最適化認証モード フィールドが 1 または 2 でない場合、受信したパケットは破棄されなければなりません (MUST)。
* If bfd.SessionState is AdminDown, Down, or Init and the Optimized Authentication Mode field is not 1, then the received packet MUST be discarded.
* bfd.SessionState が AdminDown、Down、または Init で、Optimized Authentication Mode フィールドが 1 でない場合、受信したパケットは破棄されなければなりません (MUST)。
* If bfd.SessionState is Up and there is a significant change as defined in Section 3.1, and the Optimized Authentication Mode field is not 1, then the received packet MUST be discarded.
* bfd.SessionState が Up であり、セクション 3.1 で定義されているような重大な変更があり、最適化認証モード フィールドが 1 でない場合、受信したパケットは破棄されなければなりません (MUST)。
* If the Auth Len field is not equal to a value appropriate for the Optimized Authentication Mode field, the packet MUST be discarded.
* Auth Len フィールドが Optimized Authentication Mode フィールドに適切な値と等しくない場合、パケットは破棄されなければなりません (MUST)。
* If bfd.AuthSeqKnown is 1, examine the Sequence Number field. If the sequence number lies outside of the inclusive range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) when treated as an unsigned 32-bit circular number space, the received packet MUST be discarded.
* bfd.AuthSeqKnown が 1 の場合は、シーケンス番号フィールドを調べます。符号なし 32 ビット循環番号空間として扱われるときに、シーケンス番号が bfd.RcvAuthSeq+1 から bfd.RcvAuthSeq+(3*Detect Mult) の包括的範囲外にある場合、受信したパケットは破棄されなければなりません (MUST)。
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number field, and the received packet MUST be accepted.
それ以外の場合 (bfd.AuthSeqKnown が 0)、bfd.AuthSeqKnown を 1 に設定しなければならず、bfd.RcvAuthSeq を受信したシーケンス番号フィールドの値に設定しなければならず、受信したパケットは受け入れられなければなりません。
For the specified Auth Type and Optimized Authentication Mode, perform the appropriate authentication procedures. If authentication succeeds, the received packet MUST be accepted. Otherwise, the received packet MUST be discarded.
指定された認証タイプと最適化された認証モードに対して、適切な認証手順を実行します。認証が成功した場合、受信したパケットは受け入れられなければなりません。それ以外の場合、受信したパケットは破棄されなければなりません(MUST)。
As noted in Section 3.1, when using Optimized BFD procedures, MCI authentication is used in the BFD state machine to bring a BFD session to the Up state or to make any change of the BFD parameters as carried in the BFD Control Packet when in the Up state.
セクション 3.1 で説明したように、最適化された BFD プロシージャを使用する場合、BFD セッションを Up 状態にするため、または Up 状態のときに BFD 制御パケットで伝送される BFD パラメータを変更するために、BFD ステート マシンで MCI 認証が使用されます。
Once the BFD session has reached the Up state, the BFD Up state MUST be signaled to the remote BFD system using the MCI authentication mode for an interval that is at least the Detection Time before switching to the LCI authentication mode. This is to permit mechanisms such as Meticulous Keyed ISAAC for BFD Optimized Authentication [RFC9986] or other approved, less intensive authentication mechanisms to be bootstrapped before switching to the LCI mode.
BFD セッションが Up 状態に到達したら、LCI 認証モードに切り替える前に、MCI 認証モードを使用して、少なくとも検出時間の間隔で BFD Up 状態をリモート BFD システムに通知する必要があります。これは、BFD 最適化認証 [RFC9986] のための Meticulous Keyed ISAAC などのメカニズム、またはその他の承認された負荷の低い認証メカニズムを、LCI モードに切り替える前にブートストラップできるようにするためです。
It is RECOMMENDED that when using optimized authentication that implementations switch from MCI authentication to LCI authentication mode after an interval that is at least the Detection Time. In the circumstances where a BFD session successfully reaches the Up state with MCI authentication, but there are problems with the LCI authentication, this will permit the remote system to tear down the session as quickly as possible.
最適化された認証を使用する場合、実装は少なくとも検出時間の間隔の後に MCI 認証から LCI 認証モードに切り替えることが推奨されます。BFD セッションが MCI 認証で Up 状態に正常に到達したが、LCI 認証に問題がある状況では、リモート システムはできるだけ早くセッションを切断できます。
BFD sessions using optimized authentication that succeed in reaching the Up state using MCI authentication and fail using LCI authentication SHOULD bring the issue to the attention of the operator. Furthermore, implementations MAY wish to throttle session restarts.
最適化された認証を使用する BFD セッションが、MCI 認証を使用して Up 状態に到達することに成功し、LCI 認証を使用すると失敗する場合は、この問題にオペレータの注意を払う必要があります (SHOULD)。さらに、実装ではセッションの再開を抑制することもできます (MAY)。
It is further RECOMMENDED that BFD implementations using optimized authentication defer notifying their client that the session has reached the Up state until it has transitioned to using the LCI authentication mode. In the event where LCI authentication is failing in the protocol, this avoids propagating the failed transitions to the LCI mode to their clients.
さらに、最適化された認証を使用する BFD 実装では、LCI 認証モードの使用に移行するまで、セッションがアップ状態に達したことをクライアントに通知することを延期することが推奨されます。プロトコルで LCI 認証が失敗した場合、これにより、失敗した LCI モードへの移行がクライアントに伝播することが回避されます。
The YANG 1.1 [RFC7950] data model defined in this document augments the "ietf-bfd" module to add data nodes relevant to the management of the feature defined in this document. It adds an interval value that specifies how often the BFD session should be reauthenticated using more computationally intensive authentication once it is in the Up state.
この文書で定義されている YANG 1.1 [RFC7950] データ モデルは、「ietf-bfd」モジュールを拡張して、この文書で定義されている機能の管理に関連するデータ ノードを追加します。BFD セッションが Up 状態になった後、より計算量の多い認証を使用して再認証する頻度を指定する間隔値を追加します。
The tree diagram for the YANG modules defined in this document uses annotations defined in YANG Tree Diagrams [RFC8340].
この文書で定義されている YANG モジュールのツリー図は、YANG ツリー図 [RFC8340] で定義されている注釈を使用しています。
module: ietf-bfd-opt-auth
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:sessions/bfd-ip-sh:session
/bfd-ip-sh:authentication:
+--rw reauth-interval? uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh
/bfd-ip-mh:session-groups/bfd-ip-mh:session-group
/bfd-ip-mh:authentication:
+--rw reauth-interval? uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
/bfd-lag:sessions/bfd-lag:session/bfd-lag:authentication:
+--rw reauth-interval? uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls
/bfd-mpls:session-groups/bfd-mpls:session-group
/bfd-mpls:authentication:
+--rw reauth-interval? uint32
This YANG module imports modules defined in "A YANG Data Model for Routing Management (NMDA Version)" [RFC8349] and "YANG Data Model for Bidirectional Forwarding Detection (BFD)" [RFC9314].
この YANG モジュールは、「ルーティング管理のための YANG データ モデル (NMDA バージョン)」[RFC8349] および「双方向転送検出のための YANG データ モデル (BFD)」[RFC9314] で定義されたモジュールをインポートします。
Implementations supporting the optimization procedures defined in this document enable optimization by using one of the newly defined key-chain crypto-algorithms in the ietf-bfd-met-keyed-isaac YANG module in [RFC9986].
この文書で定義されている最適化手順をサポートする実装では、[RFC9986] の ietf-bfd-met-keyed-isaac YANG モジュールで新しく定義されたキーチェーン暗号化アルゴリズムの 1 つを使用して最適化が可能になります。
module ietf-bfd-opt-auth {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth";
prefix bfd-oa;
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA version).";
}
import ietf-bfd {
prefix bfd;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD).";
}
import ietf-bfd-ip-sh {
prefix bfd-ip-sh;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD).";
}
import ietf-bfd-ip-mh {
prefix bfd-ip-mh;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD).";
}
import ietf-bfd-lag {
prefix bfd-lag;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD).";
}
import ietf-bfd-mpls {
prefix bfd-mpls;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection (BFD).";
}
organization
"IETF Bidirectional Forwarding Detection (BFD) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/bfd>
WG List: <rtg-bfd@ietf.org>
Authors: Mahesh Jethanandani (mjethanandani@gmail.com)
Ashesh Mishra (ashesh@aalyria.com)
Ankur Saxena (ankurpsaxena@gmail.com)
Manav Bhatia (mnvbhatia@google.com)
Jeffrey Haas (jeffrey.haas@hpe.com).";
description
"This YANG module augments the base BFD YANG module to add
attributes related to the experimental BFD Optimized
Authentication.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
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 9985
(https://www.rfc-editor.org/info/rfc9985); see the RFC itself
for full legal notices.";
revision "2026-06-19" {
description
"Initial Version.";
reference
"RFC 9985: Optimizing BFD Authentication.";
}
feature optimized-auth {
description
"Indicates that the implementation supports optimized
authentication.";
reference
"RFC 9985: Optimizing BFD Authentication.";
}
grouping bfd-opt-auth-config {
description
"Grouping for BFD Optimized Authentication Parameters.";
leaf reauth-interval {
type uint32;
units "seconds";
default "60";
description
"Interval of time after which more computationally intensive
authentication should be utilized to prevent an
on-path-attacker attack.
A value of zero means that we do not do periodic
reauthentication using the more computationally intensive
authentication method.
This value SHOULD have jitter applied to it to avoid
self-synchronization during expensive authentication
operations.";
}
}
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh"
+ "/bfd-ip-sh:sessions/bfd-ip-sh:session"
+ "/bfd-ip-sh:authentication" {
uses bfd-opt-auth-config;
description
"Augment the 'authentication' container for single-hop BFD
module to add attributes related to BFD Optimized
Authentication.";
}
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh"
+ "/bfd-ip-mh:session-groups/bfd-ip-mh:session-group"
+ "/bfd-ip-mh:authentication" {
uses bfd-opt-auth-config;
description
"Augment the 'authentication' container for multi-hop BFD
module to add attributes related to BFD Optimized
Authentication.";
}
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/bfd:bfd/bfd-lag:lag"
+ "/bfd-lag:sessions/bfd-lag:session"
+ "/bfd-lag:authentication" {
uses bfd-opt-auth-config;
description
"Augment the 'authentication' container for BFD over LAG
module to add attributes related to BFD Optimized
Authentication.";
}
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls"
+ "/bfd-mpls:session-groups/bfd-mpls:session-group"
+ "/bfd-mpls:authentication" {
uses bfd-opt-auth-config;
description
"Augment the 'authentication' container for BFD over MPLS
module to add attributes related to BFD Optimized
Authentication.";
}
}
IANA has assigned one URI and one YANG module as described in this section.
このセクションで説明するように、IANA は 1 つの URI と 1 つの YANG モジュールを割り当てました。
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-opt-auth
urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth
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-opt-auth
ietf-bfd-opt-auth
Maintained by IANA:
IANA によって維持されます:
N
N
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth
urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth
Prefix:
プレフィックス:
bfd-oa
bfd-oa
Reference:
参照：
RFC 9985
RFC 9985
Devices implementing BFD are often resource-constrained, whether in a single session or a multidimensional set of scaled sessions. Desired detection intervals for the BFD sessions, and their number, are common scaling considerations for BFD implementations. Security mechanisms also impact the performance of implementations, whether in software or hardware, due to the use of additional computational resources these mechanisms use.
BFD を実装するデバイスは、単一セッションであっても、拡張されたセッションの多次元セットであっても、リソースに制約があることがよくあります。BFD セッションの望ましい検出間隔とその数は、BFD 実装の一般的なスケーリング考慮事項です。セキュリティ メカニズムは、これらのメカニズムが使用する追加の計算リソースの使用により、ソフトウェアまたはハードウェアの実装のパフォーマンスにも影響を与えます。
The optimized procedures in this document provide a different level of resistance to attack than methods using a single authentication mechanism:
このドキュメントの最適化された手順は、単一の認証メカニズムを使用する方法とは異なるレベルの攻撃に対する耐性を提供します。
* The MCI authentication mechanisms used for optimized authentication are expected to have similar cryptographic strength acceptable for BFD for authenticating the entire session, as described in [RFC5880].
* [RFC5880] で説明されているように、最適化された認証に使用される MCI 認証メカニズムは、セッション全体を認証するための BFD に許容される同様の暗号強度を備えていることが期待されます。
* When the BFD state machine is attempting to move from the Down state to the Up state, the MCI authentication mechanism is intended to protect vs. attempt to inappropriately start BFD sessions.
* BFD ステート マシンがダウン状態からアップ状態に移行しようとしているとき、MCI 認証メカニズムは、BFD セッションを不適切に開始しようとする試みを保護することを目的としています。
* When the BFD state machine is in the Up state, the MCI authentication mechanism is intended to protect vs. attempt to change BFD session parameters or to reset the BFD session.
* BFD ステート マシンが Up 状態の場合、MCI 認証メカニズムは、BFD セッション パラメータの変更や BFD セッションのリセットの試みを保護することを目的としています。
* When the BFD state machine is in the Up state, the LCI authentication mechanism is intended to provide resistance to keeping a BFD session in the Up state inappropriately. Since the procedures for changing BFD state require utilizing the MCI mechanism, and the LCI mechanism requires that the contents of the Control Packet in the Up state remain unchanged, the only thing that successfully spoofing such packets can do is keep the session Up.
* BFD ステート マシンが Up 状態にある場合、LCI 認証メカニズムは、BFD セッションを不適切に Up 状態に維持することに対する抵抗を提供することを目的としています。BFD 状態を変更する手順では MCI メカニズムを利用する必要があり、LCI メカニズムではアップ状態の制御パケットの内容が変更されないことが必要であるため、このようなパケットのスプーフィングに成功できる唯一のことはセッションをアップ状態に維持することです。
* The periodic, MCI reauthentication procedure provides protection against long-term successful spoofing of the LCI authentication mechanism.
* 定期的な MCI 再認証手順により、LCI 認証メカニズムの長期にわたる成功したなりすましに対する保護が提供されます。
In other words, the intention of Optimized BFD procedures is to make it difficult to reset or inappropriately start BFD sessions. However, protecting against keeping the session Up is seen as a less interesting attack and can receive less protection.
言い換えれば、最適化された BFD 手順の目的は、BFD セッションのリセットまたは不適切な開始を困難にすることです。ただし、セッションを維持しないように保護することは、あまり興味のない攻撃とみなされ、保護が受けられる可能性が低くなります。
The recent escalating series of attacks on MD5 and SHA-1 described in Finding Collisions in the Full SHA-1 [SHA-1-attack1] and New Collision Search for SHA-1 [SHA-1-attack2] raise concerns about their remaining useful lifetime as outlined in Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm [RFC6151] and Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithm [RFC6194]. If replaced by stronger algorithms, the computational overhead will make the task of authenticating every packet even more difficult to achieve.
完全な SHA-1 での衝突の発見 [SHA-1-攻撃 1] および SHA-1 の新しい衝突検索 [SHA-1-攻撃 2] で説明されている最近エスカレートする MD5 および SHA-1 に対する一連の攻撃は、MD5 メッセージ ダイジェストおよび HMAC-MD5 アルゴリズムの更新されたセキュリティに関する考慮事項 [RFC6151] および SHA-0 および SHA-1 のセキュリティに関する考慮事項で概説されているように、残りの耐用期間に関する懸念を引き起こしています。SHA-1 メッセージ ダイジェスト アルゴリズム [RFC6194]。より強力なアルゴリズムに置き換えられた場合、計算オーバーヘッドにより、すべてのパケットを認証するタスクの達成がさらに困難になります。
The procedures described in this document provide a mechanism that could enable implementations to leverage stronger security to address the concerns above when strong authentication is required. However, this requires operators to evaluate the trade-offs of the less computationally intensive mechanisms to adequately address their desired security stance.
このドキュメントで説明されている手順は、強力な認証が必要な場合に、実装でより強力なセキュリティを活用して上記の懸念事項に対処できるメカニズムを提供します。ただし、これには、運用者が望ましいセキュリティスタンスに適切に対処するために、計算量が少ないメカニズムのトレードオフを評価する必要があります。
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.
この仕様で説明されている目的で帯域外で生成および配布されるキーは、通常、提供できるセキュリティが制限されています。これらのキーを適切に選択し、保管時に保護することが重要です。
This section is modeled after the template described in Section 3.7.1 of [RFC9907].
このセクションは、[RFC9907] のセクション 3.7.1 で説明されているテンプレートをモデルにしています。
The "ietf-bfd-opt-auth" 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-opt-auth」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 a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities:
この YANG モジュールには、書き込み可能/作成可能/削除可能 (つまり、デフォルトの「config true」) のデータ ノードが多数定義されています。一部のネットワーク環境では、すべての書き込み可能なデータ ノードが機密性が高いか脆弱である可能性があります。適切な保護や認証を行わずにこれらのデータ ノードへの書き込み操作 (edit-config など) や削除操作を行うと、ネットワーク操作に悪影響を及ぼす可能性があります。次のサブツリーとデータ ノードには、特定の感度/脆弱性があります。
* 'reauth-interval' specifies the interval in Up state, after which MCI authentication SHOULD be performed to prevent a Person-in-the-Middle (PITM) attack. If this interval is set very low, the utility of these optimization procedures is lessened. If this interval is set very high, attacks detected by the MCI authentication mechanisms may happen overly late.
* 「reauth-interval」は、Up 状態の間隔を指定します。この間隔が経過すると、中間者 (PITM) 攻撃を防ぐために MCI 認証が実行される必要があります。この間隔が非常に低く設定されている場合、これらの最適化手順の有用性は低くなります。この間隔が非常に長く設定されている場合、MCI 認証メカニズムによって検出される攻撃が非常に遅くなる可能性があります。
There are no particularly sensitive readable data nodes.
特に機密性の高い読み取り可能なデータ ノードはありません。
There are no RPC operations defined in this model.
このモデルには RPC 操作が定義されていません。
[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>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[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>.
[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>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[RFC9314] Jethanandani, M., Ed., Rahman, R., Ed., Zheng, L., Ed.,
Pallagatti, S., and G. Mirsky, "YANG Data Model for
Bidirectional Forwarding Detection (BFD)", RFC 9314,
DOI 10.17487/RFC9314, September 2022,
<https://www.rfc-editor.org/info/rfc9314>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<https://www.rfc-editor.org/info/rfc3174>.
[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>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>.
[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>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[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>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[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>.
[RFC9986] DeKok, A., Jethanandani, M., Agarwal, S., Mishra, A., and
J. Haas, "Meticulous Keyed ISAAC for Bidirectional
Forwarding Detection (BFD) Optimized Authentication",
RFC 9986, June 2026,
<https://www.rfc-editor.org/info/rfc9986>.
[SHA-1-attack1]
Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
Full SHA-1", Advances in Cryptology - CRYPTO 2005, Lecture
Notes in Computer Science, vol. 3621, pp. 17-36,
DOI 10.1007/11535218_2, 2005,
<https://doi.org/10.1007/11535218_2>.
[SHA-1-attack2]
Wang, X., Yao, A., and F. Yao, "Cryptanalysis on SHA-1",
2005, <https://csrc.nist.gov/csrc/media/events/first-
cryptographic-hash-workshop/documents/wang_sha1-new-
result.pdf>.
This section tries to show some examples in how the model can be configured.
このセクションでは、モデルを構成する方法の例をいくつか示します。
This example demonstrates how a single-hop BFD session can be configured for optimized authentication. Note that line wrapping is used per [RFC8792].
この例では、認証を最適化するためにシングルホップ BFD セッションを設定する方法を示します。[RFC8792] に従って行の折り返しが使用されることに注意してください。
=============== NOTE: '\' line wrapping per RFC 8792 ===============
<?xml version="1.0" encoding="UTF-8"?>
<key-chains
xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain"
xmlns:opt-auth="urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth"
xmlns:bfd-mki="urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-i\
saac">
<key-chain>
<name>bfd-auth-config</name>
<description>"An example for BFD Optimized Auth configuration."\
</description>
<key>
<key-id>55</key-id>
<lifetime>
<send-lifetime>
<start-date-time>2017-01-01T00:00:00Z</start-date-time>
<end-date-time>2017-02-01T00:00:00Z</end-date-time>
</send-lifetime>
<accept-lifetime>
<start-date-time>2016-12-31T23:59:55Z</start-date-time>
<end-date-time>2017-02-01T00:00:05Z</end-date-time>
</accept-lifetime>
</lifetime>
<crypto-algorithm>bfd-mki:optimized-sha1-meticulous-keyed-isa\
ac</crypto-algorithm>
<key-string>
<keystring>testvector</keystring>
</key-string>
</key>
</key-chain>
</key-chains>
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:if-type="urn:ietf:params:xml:ns:yang:iana-if-type">
<interface>
<name>eth0</name>
<type>if-type:ethernetCsmacd</type>
</interface>
</interfaces>
<routing
xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"
xmlns:bfd-types="urn:ietf:params:xml:ns:yang:ietf-bfd-types"
xmlns:iana-bfd-types="urn:ietf:params:xml:ns:yang:iana-bfd-type\
s"
xmlns:opt-auth="urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth"
xmlns:bfd-mki="urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-i\
saac">
<control-plane-protocols>
<control-plane-protocol>
<type>bfd-types:bfdv1</type>
<name>name:BFD</name>
<bfd xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd">
<ip-sh xmlns="urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh">
<sessions>
<session>
<interface>eth0</interface>
<dest-addr>2001:db8:0:113::101</dest-addr>
<desired-min-tx-interval>10000</desired-min-tx-interv\
al>
<required-min-rx-interval>
10000
</required-min-rx-interval>
<authentication>
<key-chain>bfd-auth-config</key-chain>
<opt-auth:reauth-interval>30</opt-auth:reauth-inter\
val>
</authentication>
</session>
</sessions>
</ip-sh>
</bfd>
</control-plane-protocol>
</control-plane-protocols>
</routing>
This document describes an experiment that presents a candidate solution to update BFD Authentication that is currently specified in [RFC5880]. This experiment is intended to provide additional insights into what happens when the optimized authentication mechanism defined in this document is used. Here are the reasons why this document is on the Experimental track:
この文書では、現在 [RFC5880] で規定されている BFD 認証を更新するための候補ソリューションを提示する実験について説明します。この実験は、このドキュメントで定義されている最適化された認証メカニズムが使用されたときに何が起こるかについての追加の洞察を提供することを目的としています。このドキュメントが実験段階にある理由は次のとおりです。
* In the initial stages of the document, there were significant participation and reviews from the working group. Since then, there have been considerable changes to the document, such as the use of ISAAC, the allowance for ISAAC bootstrapping when a BFD session comes up, and the use of a single Auth Type to indicate optimized authentication. These changes did not get significant review from the working group and therefore do not meet the bar set in Section 4.1.1 of [RFC2026].
* この文書の初期段階では、ワーキンググループから多くの参加とレビューが行われました。それ以来、ISAAC の使用、BFD セッション開始時の ISAAC ブートストラップの許可、最適化された認証を示すための単一の認証タイプの使用など、ドキュメントに大幅な変更が加えられました。これらの変更はワーキンググループから重要なレビューを受けていないため、[RFC2026] のセクション 4.1.1 に設定された基準を満たしていません。
* There are no known implementations at this time.
* 現時点では既知の実装はありません。
* The work in this document could become very valuable in the future, especially if the need for deploying BFD Authentication at scale becomes a reality.
* このドキュメントの作業は、将来、特に BFD 認証を大規模に展開する必要性が現実になった場合、非常に価値のあるものになる可能性があります。
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].
このドキュメントは実験版として分類されており、IETF 標準トラックの一部ではありません。この文書に基づく実装は、BFD [RFC5880] に準拠していると見なされるべきではありません。
The authors would like to thank Qiufang Ma, Stephen Farrell, and Acee Lindem for providing directorate reviews of this document.
著者らは、この文書の総括レビューを提供してくれた Qiufang Ma、Stephen Farrell、および Acee Lindem に感謝の意を表します。
The authors of this document would like to acknowledge Reshad Rahman as a contributor to this document.
この文書の著者は、Reshad Rahman をこの文書の貢献者として認めたいと考えています。
Mahesh Jethanandani
Arrcus
United States of America
Email: mjethanandani@gmail.com
Ashesh Mishra
Aalyria Technologies
Email: ashesh@aalyria.com
Jeffrey Haas
HPE
Email: jeffrey.haas@hpe.com
Ankur Saxena
Ciena Corporation
3939 N 1st Street
San Jose, CA 95134
United States of America
Email: ankurpsaxena@gmail.com
Manav Bhatia
Google
Bagmane Capital Park
Bengaluru 560048
Karnataka
India
Email: mnvbhatia@google.com