RFC 7492 - Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7492
タイトル : RFC 7492 - ルーティングプロトコルのキーイングと認証（KARP）設計ガイドラインに従った双方向転送検出（BFD）セキュリティの分析
翻訳編集 : 自動生成

[要約] RFC 7492は、Bidirectional Forwarding Detection（BFD）セキュリティの分析を提供し、Keying and Authentication for Routing Protocols（KARP）デザインガイドラインに従っています。このRFCの目的は、BFDセキュリティの要件と設計上のガイドラインを提供することです。

Internet Engineering Task Force (IETF)                         M. Bhatia
Request for Comments: 7492                                Ionos Networks
Category: Informational                                         D. Zhang
ISSN: 2070-1721                                                   Huawei
                                                         M. Jethanandani
                                                       Ciena Corporation
                                                              March 2015

Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines

ルーティングプロトコルのキーイングと認証（KARP）設計ガイドラインに従った双方向転送検出（BFD）セキュリティの分析

Abstract

概要

This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines".

このドキュメントでは、RFC 6518のセクション4.2「ルーティングプロトコルのキーイングと認証（KARP）設計ガイドライン」に記載されているガイドラインに従って、Bidirectional Forwarding Detection（BFD）プロトコルを分析します。

Status of This Memo

本文書の状態

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

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet 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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

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

このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7492で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements to Meet  . . . . . . . . . . . . . . . . . . . .   3
   3.  Current State of Security Methods . . . . . . . . . . . . . .   3
   4.  Impacts of BFD Replays  . . . . . . . . . . . . . . . . . . .   5
   5.  Impact of New Authentication Requirements . . . . . . . . . .   6
   6.  Considerations for Improvement  . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction

1. はじめに

This document performs a gap analysis of the current state of Bidirectional Forwarding Detection [RFC5880] according to the requirements of KARP Design Guidelines [RFC6518]. Previously, the OPSEC working group has provided an analysis of cryptographic issues with BFD in "Issues with Existing Cryptographic Protection Methods for Routing Protocols" [RFC6039].

このドキュメントは、KARP設計ガイドライン[RFC6518]の要件に従って、双方向転送検出[RFC5880]の現在の状態のギャップ分析を実行します。以前は、OPSECワーキンググループは、「ルーティングプロトコルの既存の暗号化保護方式の問題」[RFC6039]でBFDの暗号化問題の分析を提供していました。

The existing BFD specifications provide a basic security solution. Key ID is provided so that the key used in securing a packet can be changed on demand. Two cryptographic algorithms (MD5 and SHA-1) are supported for integrity protection of the control packets; the algorithms are both demonstrated to be subject to collision attacks. Routing protocols like "RIPv2 Cryptographic Authentication" [RFC4822], "IS-IS Generic Cryptographic Authentication" [RFC5310], and "OSPFv2 HMAC-SHA Cryptographic Authentication" [RFC5709] have started to use BFD for liveliness checks. Moving the routing protocols to a stronger algorithm while using a weaker algorithm for BFD would allow the attacker to bring down BFD in order to bring down the routing protocol. BFD therefore needs to match the routing protocols in its strength of algorithm.

既存のBFD仕様は、基本的なセキュリティソリューションを提供します。パケットの保護に使用されるキーをオンデマンドで変更できるように、キーIDが提供されます。制御パケットの完全性保護のために、2つの暗号化アルゴリズム（MD5およびSHA-1）がサポートされています。アルゴリズムはどちらも衝突攻撃の影響を受けることが実証されています。「RIPv2暗号化認証」[RFC4822]、「IS-IS汎用暗号化認証」[RFC5310]、および「OSPFv2 HMAC-SHA暗号化認証」[RFC5709]などのルーティングプロトコルは、ライブライネスチェックにBFDの使用を開始しました。 BFDに弱いアルゴリズムを使用しながらルーティングプロトコルをより強力なアルゴリズムに移動すると、攻撃者はルーティングプロトコルをダウンさせるためにBFDをダウンさせる可能性があります。したがって、BFDは、その強力なアルゴリズムでルーティングプロトコルと一致する必要があります。

While BFD uses a non-decreasing, per-packet sequence number to protect itself from intra-connection replay attacks, it still leaves the protocol vulnerable to the inter-session replay attacks.

BFDは減少しないパケットごとのシーケンス番号を使用して接続内リプレイ攻撃から保護しますが、プロトコルはセッション間リプレイ攻撃に対して脆弱です。

2. Requirements to Meet

2. 満たすべき要件

There are several requirements described in Section 4 of [RFC6862] that BFD, as defined in BFD [RFC5880], does not currently meet:

[RFC6862]のセクション4で説明されている要件のうち、BFD [RFC5880]で定義されているBFDが現在満たさない要件はいくつかあります。

Replay Protection: BFD provides an incomplete intra-session and no inter-session replay attack protection; this creates significant denial-of-service opportunities.

リプレイ保護：BFDは不完全なセッション内リプレイを提供し、セッション間リプレイアタック保護は提供しません。これにより、サービス拒否の大きな機会が生まれます。

Strong Algorithms: The cryptographic algorithms adopted for message authentication in BFD are MD5 or SHA-1 based. However, both algorithms are known to be vulnerable to collision attacks. "BFD Generic Cryptographic Authentication" [BFD-CRYPTO] and "Authenticating BFD using HMAC-SHA-2 procedures" [BFD-HMAC] together propose a solution to support Hashed Message Authentication Code (HMAC) with the SHA-2 family of hash functions for BFD.

強力なアルゴリズム：BFDのメッセージ認証に採用されている暗号化アルゴリズムは、MD5またはSHA-1ベースです。ただし、どちらのアルゴリズムも衝突攻撃に対して脆弱であることがわかっています。「BFD Generic Cryptographic Authentication」[BFD-CRYPTO]と「HMAC-SHA-2プロシージャを使用したBFDの認証」[BFD-HMAC]は、ハッシュ関数のSHA-2ファミリーでハッシュメッセージ認証コード（HMAC）をサポートするソリューションを提案します。 BFDの場合。

Preventing DoS Attacks: BFD packets can be sent at millisecond intervals (the protocol uses timers at microsecond intervals). When malicious packets are sent at short intervals, with the authentication bit set, it can cause a DoS attack. There is currently no lightweight mechanism within BFD to address this issue and is one of the reasons BFD authentication is still not widely deployed in the field.

DoS攻撃の防止：BFDパケットはミリ秒間隔で送信できます（プロトコルはマイクロ秒間隔でタイマーを使用します）。悪意のあるパケットが短い間隔で送信され、認証ビットが設定されている場合、DoS攻撃を引き起こす可能性があります。現在、この問題に対処する軽量のメカニズムはBFD内にありません。これが、BFD認証がまだフィールドに広く展開されていない理由の1つです。

The remainder of this document explains the details of how these requirements fail to be met and proposes mechanisms for addressing them.

このドキュメントの残りの部分では、これらの要件が満たされない方法の詳細を説明し、それらに対処するためのメカニズムを提案します。

3. Current State of Security Methods

3. セキュリティ手法の現状

BFD [RFC5880] describes five authentication mechanisms for the integrity protection of BFD control packets: Simple Password, Keyed MD5 [RFC1321], Meticulous Keyed MD5, Keyed SHA-1, and Meticulous Keyed SHA-1. In the simple password mechanism, every control packet is associated with a password transported in plain text; attacks eavesdropping the network traffic can easily learn the password and compromise the security of the corresponding BFD session. In the Keyed MD5 and the Meticulous Keyed MD5 mechanisms, BFD nodes use shared secret keys to generate Keyed MD5 digests for control packets. Similarly, in the Keyed SHA-1 and the Meticulous Keyed SHA-1 mechanisms, BFD nodes use shared secret keys to generate Keyed SHA-1 digests for control packets. Note that in the keyed authentication mechanisms, every BFD control packet is associated with a non-decreasing, 32-bit sequence number to resist replay attacks. In the Keyed MD5 and the Keyed SHA-1 mechanisms, the sequence member is only required to increase occasionally. However, in the Meticulous Keyed MD5 and the Meticulous Keyed SHA-1 mechanisms, the sequence member is required to increase with each successive packet.

BFD [RFC5880]では、BFD制御パケットの整合性保護のための5つの認証メカニズムについて説明しています。シンプルパスワード、キー付きMD5 [RFC1321]、Meticulousキー付きMD5、キー付きSHA-1、およびMeticulousキー付きSHA-1です。単純なパスワードメカニズムでは、すべての制御パケットがプレーンテキストで転送されるパスワードに関連付けられます。ネットワークトラフィックを盗聴する攻撃は、パスワードを容易に学習し、対応するBFDセッションのセキュリティを危険にさらす可能性があります。鍵付きMD5およびMeticulous鍵付きMD5メカニズムでは、BFDノードは共有秘密鍵を使用して、制御パケットの鍵付きMD5ダイジェストを生成します。同様に、Keyed SHA-1およびMeticulous Keyed SHA-1メカニズムでは、BFDノードは共有秘密鍵を使用して、制御パケットのKeyed SHA-1ダイジェストを生成します。キー付き認証メカニズムでは、すべてのBFD制御パケットが、減少しない32ビットのシーケンス番号に関連付けられて、リプレイアタックに抵抗することに注意してください。キー付きMD5メカニズムとキー付きSHA-1メカニズムでは、シーケンスメンバーは時々増加する必要があるだけです。ただし、Meticulous Keyed MD5およびMeticulous Keyed SHA-1メカニズムでは、シーケンスメンバーは、連続するパケットごとに増加する必要があります。

Additionally, limited key updating functionality is provided. There is a Key ID in every authenticated BFD control packet indicating the key used to hash the packet. However, there is no mechanism described to provide a smooth key rollover that the BFD routers can use when moving from one key to the other.

さらに、限定されたキー更新機能が提供されます。認証されたすべてのBFD制御パケットには、パケットのハッシュに使用されるキーを示すキーIDがあります。ただし、1つのキーから別のキーに移動するときにBFDルータが使用できるスムーズなキーロールオーバーを提供するメカニズムは説明されていません。

The BFD session timers are defined with the granularity of microseconds, and it is common in practice to send BFD packets at millisecond intervals. Since the cryptographic sequence number space is only 32 bits, a sequence number used in a BFD session may reach its maximum value and roll over within a limited period. For instance, if a sequence number is increased by one every 3.3 milliseconds, then it will reach its maximum value in less than 24 weeks. This can result in potential inter-session replay attacks, especially when BFD uses the non-meticulous authentication modes.

BFDセッションタイマーはマイクロ秒単位で定義されており、実際にはBFDパケットをミリ秒間隔で送信するのが一般的です。暗号化シーケンス番号スペースは32ビットしかないため、BFDセッションで使用されるシーケンス番号は最大値に達し、限られた期間内にロールオーバーする可能性があります。たとえば、シーケンス番号が3.3ミリ秒ごとに1つ増えると、24週間未満で最大値に達します。これにより、特にBFDが非細かい認証モードを使用する場合に、潜在的なセッション間リプレイ攻撃が発生する可能性があります。

Note that when using authentication mechanisms, BFD drops all packets that fall outside the limited range (3 times the Detection Time multiplier). Therefore, when meticulous authentication modes are used, a replayed BFD packet will be rejected if it cannot fit into a relatively short window (3 times the detection interval of the session). This introduces some difficulties for replaying packets. However, in a non-meticulous authentication mode, such windows can be large (as sequence numbers are only increased occasionally), thus making it easier to perform replay attacks .

認証メカニズムを使用する場合、BFDは制限された範囲外にあるすべてのパケットをドロップすることに注意してください（検出時間乗数の3倍）。したがって、詳細な認証モードが使用されている場合、再生されたBFDパケットは、比較的短いウィンドウ（セッションの検出間隔の3倍）に収まらない場合、拒否されます。これにより、パケットの再生が困難になります。ただし、非詳細認証モードでは、このようなウィンドウが大きくなる可能性があるため（シーケンス番号がたまにしか増加しないため）、リプレイ攻撃を実行しやすくなります。

In a BFD session, each node needs to select a 32-bit discriminator to identify itself. Therefore, a BFD session is identified by two discriminators. If a node randomly selects a new discriminator for a new session and uses authentication mechanisms to secure the control packets, inter-session replay attacks can be mitigated to some extent. However, in existing BFD demultiplexing mechanisms, the discriminators used in a new BFD session may be predictable. In some deployment scenarios, the discriminators of BFD routers may be decided by the destination and source addresses. So, if the sequence number of a BFD router rolls over for some reason (e.g., reboot), the discriminators used to identify the new session will be identical to the ones used in the previous session. This makes performing a replay attack relatively simple.

BFDセッションでは、各ノードは32ビットの識別子を選択して自身を識別する必要があります。したがって、BFDセッションは2つの弁別子によって識別されます。ノードが新しいセッションの新しい識別子をランダムに選択し、認証メカニズムを使用して制御パケットを保護する場合、セッション間リプレイ攻撃をある程度軽減できます。ただし、既存のBFD逆多重化メカニズムでは、新しいBFDセッションで使用される弁別子は予測可能です。一部の展開シナリオでは、BFDルーターの識別子は宛先アドレスと送信元アドレスによって決定される場合があります。したがって、BFDルーターのシーケンス番号が何らかの理由（再起動など）でロールオーバーした場合、新しいセッションの識別に使用される識別子は、前のセッションで使用されたものと同じになります。これにより、リプレイ攻撃の実行が比較的簡単になります。

BFD allows a mode called the echo mode. Echo packets are not defined in the BFD specification, though they can keep the BFD session up. The format of the echo packet is local to the sending side, and there are no guidelines on the properties of these packets beyond the choice of the source and destination addresses. While the BFD specification recommends applying security mechanisms to prevent spoofing of these packets, there are no guidelines on what type of mechanisms are appropriate.

BFDでは、エコーモードと呼ばれるモードを使用できます。エコーパケットはBFD仕様で定義されていませんが、BFDセッションを維持できます。エコーパケットの形式は送信側にローカルであり、送信元アドレスと宛先アドレスの選択以外のこれらのパケットのプロパティに関するガイドラインはありません。 BFD仕様では、これらのパケットのスプーフィングを防止するためにセキュリティメカニズムを適用することを推奨していますが、適切なメカニズムのタイプに関するガイドラインはありません。

4. Impacts of BFD Replays

4. BFDリプレイの影響

As discussed, BFD cannot meet the requirements of inter-session or intra-session replay protection. This section discusses the impacts of BFD replays.

説明したように、BFDはセッション間またはセッション内のリプレイ保護の要件を満たすことができません。このセクションでは、BFDリプレイの影響について説明します。

When cryptographic authentication mechanisms are adopted for BFD, a non-decreasing, 32-bit-long sequence number is used. In the Keyed MD5 and the Keyed SHA-1 mechanisms, the sequence member is not required to increase for every packet. Therefore, an attacker can keep replaying the packets with the latest sequence number until the sequence number is updated. This issue is eliminated in the Meticulous Keyed MD5 and the Meticulous Keyed SHA-1 mechanisms. However, note that a sequence number may reach its maximum and be rolled over in a session. In this case, without the support from a automatic key management mechanism, the BFD session will be vulnerable to replay attacks performed by sending the packets before the roll over of the sequence number. For instance, an attacker can replay a packet with a sequence number that is larger than the current one. If the replayed packet is accepted, the victim will reject the legal packets whose sequence members are less than the one in the replayed packet. Therefore, the attacker can get a good chance to bring down the BFD session. This kind of attack assumes that the attacker has access to the link when the BFD session is on a point-to-point link or can inject packets for a BFD session with multiple hops.

暗号認証メカニズムがBFDに採用されている場合、減少しない32ビット長のシーケンス番号が使用されます。キー付きMD5およびキー付きSHA-1メカニズムでは、シーケンスメンバーはパケットごとに増やす必要はありません。したがって、攻撃者は、シーケンス番号が更新されるまで、最新のシーケンス番号を持つパケットを再生し続けることができます。この問題は、Meticulous Keyed MD5およびMeticulous Keyed SHA-1メカニズムでは解消されています。ただし、シーケンス番号が最大値に達し、セッションでロールオーバーされる場合があることに注意してください。この場合、自動キー管理メカニズムのサポートがなければ、BFDセッションは、シーケンス番号のロールオーバーの前にパケットを送信することによって実行されるリプレイ攻撃に対して脆弱になります。たとえば、攻撃者は現在のシーケンス番号より大きいシーケンス番号を持つパケットを再生できます。リプレイされたパケットが受け入れられた場合、被害者はシーケンスメンバーがリプレイされたパケットのパケットよりも少ない正当なパケットを拒否します。したがって、攻撃者はBFDセッションを停止する可能性が高くなります。この種の攻撃は、BFDセッションがポイントツーポイントリンク上にある場合、または複数のホップを持つBFDセッションのパケットを注入できる場合に、攻撃者がリンクにアクセスできることを想定しています。

Additionally, the BFD specification allows for the change of authentication state based on the state of a received packet. For instance, according to BFD [RFC5880], if the state of an accepted packet is down, the receiver of the packet needs to transfer its state to down as well. Therefore, a carefully selected replayed packet can cause a serious denial-of-service attack.

さらに、BFD仕様では、受信したパケットの状態に基づいて認証状態を変更できます。たとえば、BFD [RFC5880]によれば、受け入れられたパケットの状態がダウンしている場合、パケットの受信者もその状態をダウンに転送する必要があります。したがって、慎重に選択された再生パケットは、深刻なサービス拒否攻撃を引き起こす可能性があります。

BFD does not provide any solution to deal with inter-session replay attacks. If two subsequent BFD sessions adopt an identical discriminator pair and use the same cryptographic key to secure the control packets, it is intuitive to use a malicious authenticated packet (stored from the past session) to perform interconnection replay attacks.

BFDは、セッション間リプレイ攻撃に対処するためのソリューションを提供していません。後続の2つのBFDセッションが同じ弁別子ペアを採用し、同じ暗号キーを使用して制御パケットを保護する場合、悪意のある認証済みパケット（過去のセッションから保存されたもの）を使用して相互接続リプレイ攻撃を実行するのは直感的です。

Any security issues in the BFD echo mode will directly affect the BFD protocol and session states, and hence the network stability. For instance, any replay attacks would be indistinguishable from normal forwarding of the tested router. An attack would still cause a faulty link to be believed to be up, but there is little that can be done about it. However, if the echo packets are guessable, it may be possible to spoof from an external source and cause BFD to believe that a one-way link is really bidirectional. As a result, it is important that the echo packets contain random material that is also checked upon reception.

BFDエコーモードでのセキュリティの問題は、BFDプロトコルとセッションステートに直接影響するため、ネットワークの安定性に影響します。たとえば、リプレイ攻撃は、テストされたルーターの通常の転送と区別がつきません。攻撃によって依然として障害のあるリンクがアップしていると思われる可能性がありますが、それに対して実行できることはほとんどありません。ただし、エコーパケットが推測可能な場合は、外部ソースからスプーフィングして、BFDに一方向リンクが本当に双方向であると信じ込ませることができる場合があります。その結果、エコーパケットにはランダムな素材が含まれ、受信時にもチェックされることが重要です。

5. Impact of New Authentication Requirements

5. 新しい認証要件の影響

BFD can be run in software or hardware. Hardware implementations run BFD at a much smaller timeout, typically in the order of few milliseconds. For instance, with a timeout of 3.3 milliseconds, a BFD session is required to send or receive 3 packets every 10 milliseconds. Software implementations typically run with a timeout in hundreds of milliseconds.

BFDはソフトウェアまたはハードウェアで実行できます。ハードウェアの実装では、通常数ミリ秒程度のはるかに短いタイムアウトでBFDを実行します。たとえば、タイムアウトが3.3ミリ秒の場合、10ミリ秒ごとに3つのパケットを送受信するには、BFDセッションが必要です。ソフトウェア実装は通常、数百ミリ秒のタイムアウトで実行されます。

Additionally, it is not common to find hardware support for computing the authentication data for the BFD session in hardware or software. In the Keyed MD5 and Keyed SHA-1 implementation where the sequence number does not increase with every packet, software can be used to compute the authentication data. This is true if the time between the increasing sequence number is long enough to compute the data in software. The ability to compute the hash in software is difficult with Meticulous Keyed MD5 and Meticulous Keyed SHA-1 if the time interval between transmits or between receives is small. The computation problem becomes worse if hundred or thousands of sessions require the hash to be recomputed every few milliseconds.

さらに、ハードウェアまたはソフトウェアでBFDセッションの認証データを計算するためのハードウェアサポートを見つけることは一般的ではありません。パケットごとにシーケンス番号が増加しないKeyed MD5およびKeyed SHA-1の実装では、ソフトウェアを使用して認証データを計算できます。これは、増加するシーケンス番号の間の時間がソフトウェアでデータを計算するのに十分長い場合に当てはまります。 Meticulous Keyed MD5とMeticulous Keyed SHA-1では、送信または受信間の時間間隔が短い場合、ソフトウェアでハッシュを計算する機能は困難です。数ミリ秒ごとにハッシュを再計算する必要があるセッションが数百または数千ある場合、計算の問題はさらに悪化します。

Smaller and cheaper boxes that have to support a few hundred BFD sessions are boxes that also use a slower CPU. The CPU is used for running the entire control plane software in addition to supporting the BFD sessions. As a general rule, no more than 40-45% of the CPU can be dedicated towards supporting BFD. Adding computation of the hash for every BFD session can easily cause the CPU to exceed the 40-45% limit even with a few tens of sessions. On higher-end boxes with faster and more CPU cores, the expectation is that the number of sessions that need to be supported are in the thousands, but the number of BFD sessions with authentication that CPU can support is still in the hundreds.

数百のBFDセッションをサポートする必要がある小さくて安価なボックスは、低速のCPUも使用するボックスです。 CPUは、BFDセッションのサポートに加えて、コントロールプレーンソフトウェア全体を実行するために使用されます。原則として、CPUの40〜45％をBFDのサポートに割り当てることはできません。すべてのBFDセッションのハッシュの計算を追加すると、数十のセッションがあっても、CPUが40〜45％の制限を簡単に超える可能性があります。より高速でより多くのCPUコアを備えたハイエンドボックスでは、サポートする必要のあるセッションの数は数千であると予想されますが、CPUがサポートできる認証付きのBFDセッションの数は依然として数百です。

Implementors should assess the impact of authenticating BFD sessions on their platform.

実装者は、プラットフォームでのBFDセッションの認証の影響を評価する必要があります。

6. Considerations for Improvement

6. 改善のための考慮事項

This section suggests changes that can be adopted to improve the protection of BFD.

このセクションでは、BFDの保護を改善するために採用できる変更を提案します。

The security risks brought by SHA-1 and MD5 have been well understood. However, when using a stronger digest algorithm, e.g., SHA-2, the imposed computing overhead will seriously affect the performance of BFD implementation. In order to make the trade-off between the strong algorithm requirement and the imposed overhead, Galois Message Authentication Code (GMAC) can be a candidate option. This algorithm is relatively effective and has been supported by IPsec for data origin authentication. More detailed information can be found in "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH" [RFC4543].

SHA-1とMD5によってもたらされるセキュリティリスクはよく理解されています。ただし、SHA-2などのより強力なダイジェストアルゴリズムを使用すると、課せられる計算オーバーヘッドがBFD実装のパフォーマンスに深刻な影響を与えます。強力なアルゴリズム要件と課せられたオーバーヘッドとの間のトレードオフを行うために、ガロアメッセージ認証コード（GMAC）が候補のオプションになります。このアルゴリズムは比較的効果的で、データ発信元認証のためにIPsecによってサポートされています。詳細については、「IPsec ESPおよびAHでのガロアメッセージ認証コード（GMAC）の使用」[RFC4543]を参照してください。

There has been some hallway conversation around the idea of using BFD cryptographic authentication only when some data in the BFD payload changes. The other BFD packets can be transmitted and received without authentication enabled. The bulk of the BFD packets that are transmitted and received have no state change associated with them. Limiting authentication to BFD packets that affect a BFD session state allows for more sessions to be supported for authentication. This change can significantly help the routers since they don't have to compute and verify the authentication digest for the BFD packets coming at the millisecond intervals. This proposal needs some more discussion in the BFD working group and is certainly a direction that BFD could look at.

BFDペイロードの一部のデータが変更された場合にのみBFD暗号化認証を使用するという考えについては、いくらか話し合いがありました。その他のBFDパケットは、認証を有効にせずに送受信できます。送受信されるBFDパケットの大部分には、状態の変化が関連付けられていません。認証をBFDセッションステートに影響を与えるBFDパケットに制限すると、認証でサポートされるセッションを増やすことができます。ルーターは、ミリ秒間隔で着信するBFDパケットの認証ダイジェストを計算および検証する必要がないため、ルーターを大幅に支援できます。この提案は、BFDワーキンググループでさらに議論する必要があり、BFDが検討できる方向性です。

7. Security Considerations

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

This document discusses vulnerabilities in the existing BFD protocol and suggests possible mitigations.

このドキュメントでは、既存のBFDプロトコルの脆弱性について説明し、可能な軽減策を提案します。

In analyzing the improvements for BFD, the ability to repel a replay attack is discussed. For example, increasing the sequence number to a 64-bit value makes the wrap-around time much longer, and a replay attack can be easily prevented.

BFDの改善を分析する際に、リプレイ攻撃を撃退する機能について説明します。たとえば、シーケンス番号を64ビット値に増やすと、ラップアラウンド時間がはるかに長くなり、リプレイ攻撃を簡単に防ぐことができます。

Mindful of the impact that stronger algorithms can have on the performance of BFD, the document suggests GMAC as a possible candidate for MAC function.

より強力なアルゴリズムがBFDのパフォーマンスに与える可能性のある影響に注意して、ドキュメントはGMACをMAC機能の可能な候補として示唆しています。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.

[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月、<http://www.rfc-editor.org/info/rfc1321>。

[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.

[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月、<http://www.rfc-editor.org/info/rfc5880>。

[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010, <http://www.rfc-editor.org/info/rfc6039>.

[RFC6039] Manral、V.、Bhatia、M.、Jaeggli、J。、およびR. White、「Issues with Existing Cryptographic Protection Methods for Routing Protocols」、RFC 6039、2010年10月、<http：//www.rfc- editor.org/info/rfc6039>。

8.2. Informative References

8.2. 参考引用

[BFD-CRYPTO] Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, "BFD Generic Cryptographic Authentication", Work in Progress, draft-ietf-bfd-generic-crypto-auth-06, April 2014.

[BFD-CRYPTO] Bhatia、M.、Manral、V.、Zhang、D。、およびM. Jethanandani、「BFD Generic Cryptographic Authentication」、Work in Progress、draft-ietf-bfd-generic-crypto-auth-06、 2014年4月。

[BFD-HMAC] Zhang, D., Bhatia, M., Manral, V., and M. Jethanandani, "Authenticating BFD using HMAC-SHA-2 procedures", Work in Progress, draft-ietf-bfd-hmac-sha-05, July 2014.

[BFD-HMAC] Zhang、D.、Bhatia、M.、Manral、V。、およびM. Jethanandani、「HMAC-SHA-2プロシージャを使用したBFDの認証」、作業中、draft-ietf-bfd-hmac-sha -05、2014年7月。

[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006, <http://www.rfc-editor.org/info/rfc4543>.

[RFC4543] McGrew、D。およびJ. Viega、「IPsec ESPおよびAHでのガロアメッセージ認証コード（GMAC）の使用」、RFC 4543、2006年5月、<http://www.rfc-editor.org/info / rfc4543>。

[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007, <http://www.rfc-editor.org/info/rfc4822>.

[RFC4822] Atkinson、R。およびM. Fanto、「RIPv2 Cryptographic Authentication」、RFC 4822、2007年2月、<http://www.rfc-editor.org/info/rfc4822>。

[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.

[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、2009年2月、<http ：//www.rfc-editor.org/info/rfc5310>。

[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009, <http://www.rfc-editor.org/info/rfc5709>.

[RFC5709] Bhatia、M.、Manral、V.、Fanto、M.、White、R.、Barnes、M.、Li、T。、およびR. Atkinson、「OSPFv2 HMAC-SHA Cryptographic Authentication」、RFC 5709、 2009年10月、<http://www.rfc-editor.org/info/rfc5709>。

[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012, <http://www.rfc-editor.org/info/rfc6518>.

[RFC6518] Lebovitz、G。およびM. Bhatia、「ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドライン」、RFC 6518、2012年2月、<http://www.rfc-editor.org/info/rfc6518>。

[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, March 2013, <http://www.rfc-editor.org/info/rfc6862>.

[RFC6862] Lebovitz、G.、Bhatia、M。、およびB. Weis、「ルーティングプロトコル（KARP）のキーイングと認証の概要、脅威、および要件」、RFC 6862、2013年3月、<http：//www.rfc -editor.org/info/rfc6862>。

Acknowledgements

謝辞

We would like to thank Alexander Vainshtein for his comments on this document.

このドキュメントに対する彼のコメントについて、Alexander Vainshteinに感謝します。

Authors' Addresses

著者のアドレス

Manav Bhatia Ionos Networks Bangalore India

Manav Bhatia Ionos Networks Bangaloreインド

   EMail: manav@ionosnetworks.com

Dacheng Zhang Huawei

DAがZhang hu Aになる

   EMail: dacheng.zhang@gmail.com

Mahesh Jethanandani Ciena Corporation 3939 North 1st Street San Jose, CA 95134 United States

Mahesh Jethanandani Ciena Corporation 3939 North 1st Street San Jose、CA 95134アメリカ合衆国

Phone: 408.904.2160 Fax: 408.436.5582 EMail: mjethanandani@gmail.com

電話：408.904.2160ファックス：408.436.5582メール：mjethanandani@gmail.com