[要約] RFC 7175は、TRILL（Transparent Interconnection of Lots of Links）プロトコルにおけるBFD（Bidirectional Forwarding Detection）サポートに関するものです。このRFCの目的は、TRILLネットワークでのリンクの状態を監視し、障害を検出するためのBFDの使用方法を定義することです。
Internet Engineering Task Force (IETF) V. Manral
Request for Comments: 7175 Ionos Corp.
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Huawei R&D USA
D. Ward
Cisco Systems
A. Banerjee
Cumulus Networks
May 2014
Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support
多数のリンクの透過的な相互接続（TRILL）：双方向転送検出（BFD）のサポート
Abstract
概要
This document specifies use of the Bidirectional Forwarding Detection (BFD) protocol in Routing Bridge (RBridge) campuses based on the RBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol.
このドキュメントでは、リンクの透過的な相互接続（TRILL）プロトコルへのRBridgeチャネル拡張に基づいて、ルーティングブリッジ（RBridge）キャンパスで双方向転送検出（BFD）プロトコルを使用する方法を説明します。
BFD is a widely deployed Operations, Administration, and Maintenance (OAM) mechanism in IP and MPLS networks, using UDP and Associated Channel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL.
BFDは、IPおよびMPLSネットワークで広く展開されている運用、管理、および保守（OAM）メカニズムであり、UDPおよび関連チャネルヘッダー（ACH）カプセル化をそれぞれ使用します。このドキュメントでは、TRILLを介したBFDカプセル化について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7175.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7175で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
1.1. Terminology ................................................3
2. BFD over TRILL ..................................................3
2.1. Sessions and Initialization ................................4
3. TRILL BFD Control Protocol ......................................5
3.1. One-Hop TRILL BFD Control ..................................5
3.2. BFD Control Frame Processing ...............................5
4. TRILL BFD Echo Protocol .........................................6
4.1. BFD Echo Frame Processing ..................................6
5. Management and Operations Considerations ........................7
6. Default Authentication ..........................................7
7. Security Considerations .........................................8
8. IANA Considerations .............................................9
9. Acknowledgements ................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ...................................10
Faster convergence is a critical feature of Transparent Interconnection of Lots of Links (TRILL) [RFC6325] networks. The TRILL IS-IS Hellos [RFC7177] [IS-IS] used between RBridges provide a basic neighbor and continuity check for TRILL links. However, failure detection by non-receipt of such Hellos is based on the Holding Time parameter that is commonly set to a value of tens of seconds and, in any case, has a minimum expressible value of one second.
より高速な収束は、リンクの透過的な相互接続（TRILL）[RFC6325]ネットワークの重要な機能です。 RBridge間で使用されるTRILL IS-IS Hellos [RFC7177] [IS-IS]は、基本的なネイバーとTRILLリンクの連続性チェックを提供します。ただし、このようなHelloの非受信による障害検出は、通常は数十秒の値に設定され、いずれの場合も最小の表現可能な値が1秒である[Holding Time]パラメータに基づいています。
Some applications, including Voice over IP, may wish, with high probability, to detect interruptions in continuity within a much shorter time period. In some cases, physical-layer failures can be detected very rapidly, but this is not always possible, such as when there is a failure between two bridges that are in turn between two RBridges. There are also many subtle failures possible at higher levels. For example, some forms of failure could affect unicast frames while still letting multicast frames through; since all TRILL IS-IS Hellos are multicast, such a failure cannot be detected with Hellos. Thus, a low-overhead method for frequently testing continuity for the TRILL Data between neighbor RBridges is necessary for some applications. The BFD protocol [RFC5880] provides a low-overhead method for the rapid detection of connectivity failures.
Voice over IPを含む一部のアプリケーションは、非常に短い時間内に連続性の中断を検出する可能性が高い可能性があります。場合によっては、物理層の障害を非常に迅速に検出できますが、2つのRBridgeの間にある2つのブリッジ間に障害が発生した場合など、これが常に可能であるとは限りません。より高いレベルでは、多くの微妙な障害が発生する可能性もあります。たとえば、一部の形式の障害は、マルチキャストフレームを通過させながらユニキャストフレームに影響を与える可能性があります。すべてのTRILL IS-IS Helloはマルチキャストであるため、このような障害はHelloでは検出できません。したがって、一部のアプリケーションでは、隣接するRBridge間のTRILLデータの連続性を頻繁にテストするためのオーバーヘッドの少ない方法が必要です。 BFDプロトコル[RFC5880]は、接続障害の迅速な検出のための低オーバーヘッドの方法を提供します。
BFD is a widely deployed OAM [RFC6291] mechanism in IP and MPLS networks, using UDP and ACH encapsulation, respectively. This document describes a TRILL encapsulation for BFD packets for networks that forward based on the TRILL Header.
BFDは、UDPおよびACHカプセル化をそれぞれ使用して、IPおよびMPLSネットワークで広く展開されているOAM [RFC6291]メカニズムです。このドキュメントでは、TRILLヘッダーに基づいて転送するネットワークのBFDパケットのTRILLカプセル化について説明します。
This document uses the acronyms defined in [RFC6325] along with the following:
このドキュメントでは、[RFC6325]で定義されている頭字語と以下を使用しています。
BFD: Bidirectional Forwarding Detection
BFD：双方向転送検出
IP: Internet Protocol
IP：インターネットプロトコル
IS-IS: Intermediate System to Intermediate System
IS-IS：中間システムから中間システム
MH: Multi-Hop
MH：マルチホップ
PPP: Point-to-Point Protocol
PPP：ポイントツーポイントプロトコル
OAM: Operations, Administration, and Maintenance
OAM：運用、管理、およびメンテナンス
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
TRILL supports unicast neighbor BFD Echo and one-hop and multi-hop BFD Control, as specified below, over the RBridge Channel facility [RFC7178]. (Multi-destination BFD is a work in progress [MultiBFD].) BFD-over-TRILL support is similar to BFD-over-IP support [RFC5881], except where differences are explicitly mentioned.
TRILLは、RBridgeチャネルファシリティ[RFC7178]を介して、ユニキャストネイバーBFDエコーと、以下に指定されている1ホップおよびマルチホップBFDコントロールをサポートします。 （マルチ宛先BFDは、進行中の作業[MultiBFD]です。）BFD-over-TRILLサポートは、相違点が明示的に述べられている場合を除いて、BFD-over-IPサポート[RFC5881]に似ています。
Asynchronous and demand modes MUST be supported [RFC5880]. BFD over TRILL supports the Echo function; however, implementation of TRILL BFD Echo is optional, and it can only be used for single-hop sessions.
非同期モードとデマンドモードをサポートする必要があります[RFC5880]。 BFD over TRILLはEcho機能をサポートしています。ただし、TRILL BFD Echoの実装はオプションであり、シングルホップセッションでのみ使用できます。
The TRILL Header hop count in the BFD packets is sent out with the maximum value of 0x3F. To prevent spoofing attacks, the TRILL hop count of a received session is checked [RFC5082]. For a single-hop session, if the hop count is less than 0x3F and the RBridge Channel Header MH flag is zero, the packet is discarded. For multi-hop sessions, the hop count check can be disabled if the MH flag is one.
BFDパケットのTRILLヘッダーホップカウントは、最大値0x3Fで送信されます。スプーフィング攻撃を防ぐために、受信したセッションのTRILLホップカウントがチェックされます[RFC5082]。シングルホップセッションの場合、ホップカウントが0x3F未満で、RBridge Channel Header MHフラグがゼロの場合、パケットは破棄されます。マルチホップセッションでは、MHフラグが1の場合、ホップカウントチェックを無効にできます。
As in BFD for IP, the format of the Echo Packet content is not defined.
IPのBFDと同様に、エコーパケットコンテンツの形式は定義されていません。
New RBridge Channel code points for BFD TRILL Control and BFD Echo packets are specified.
BFD TRILLコントロールおよびBFDエコーパケットの新しいRBridgeチャネルコードポイントが指定されています。
Authentication mechanisms as supported in BFD are also supported for BFD running over TRILL.
BFDでサポートされている認証メカニズムは、TRILLで実行されているBFDでもサポートされています。
Within an RBridge campus, there will be no more than one TRILL BFD Control session from any RBridge RB1 to RBridge RB2 for each RB1 TRILL port. This BFD session must be bound to this interface. As such, both sides of a session MUST take the "Active" role (sending initial BFD Control packets with a zero value of Your Discriminator), and any BFD packet from the remote machine with a zero value of Your Discriminator MUST be associated with the session bound to the remote system and interface.
RBridgeキャンパス内では、RB1 TRILLポートごとに、RBridge RB1からRBridge RB2へのTRILL BFD制御セッションは1つしかありません。このBFDセッションは、このインターフェイスにバインドされている必要があります。そのため、セッションの両側が「アクティブ」の役割（ゼロの値のディスクリミネーターを持つ初期BFDコントロールパケットを送信する）を取り、リモートマシンからのゼロの値のディスクリミネーターを持つBFDパケットは、リモートシステムとインターフェースにバインドされたセッション。
Note that TRILL BFD provides OAM facilities for the TRILL data plane. This is above whatever protocol is in use on a particular link, such as a pseudowire [RFC7173], Ethernet [RFC6325], or PPP link [RFC6361]. Link-technology-specific OAM protocols may be used on a link between neighbor RBridges, for example, Continuity Fault Management [802.1Q] if the link is Ethernet. But such link-layer OAM (and coordination between it and OAM in the TRILL data-plane layer, such as TRILL BFD) is beyond the scope of this document.
TRILL BFDはTRILLデータプレーンにOAM機能を提供することに注意してください。これは、疑似配線[RFC7173]、イーサネット[RFC6325]、PPPリンク[RFC6361]など、特定のリンクで使用されているプロトコルよりも上です。リンク技術固有のOAMプロトコルは、隣接するRBridge間のリンクで使用できます。たとえば、リンクがイーサネットの場合、Continuity Fault Management [802.1Q]です。ただし、そのようなリンク層OAM（およびそれとTRILL BFDなどのTRILLデータプレーン層のOAM間の調整）は、このドキュメントの範囲を超えています。
If lower-level mechanisms are in use, such as link aggregation [802.1AX], that present a single logical interface to TRILL IS-IS, then only a single TRILL BFD session can be established to any other RBridge over this logical interface. However, lower-layer OAM could be aware of and/or run separately on each of the components of an aggregation.
リンク集約[802.1AX]など、TRILL IS-ISに単一の論理インターフェイスを提供する下位レベルのメカニズムが使用されている場合、この論理インターフェイスを介して他のRBridgeに対して確立できるTRILL BFDセッションは1つだけです。ただし、下位層のOAMは、アグリゲーションの各コンポーネントを認識および/または個別に実行できます。
TRILL BFD Control frames are unicast TRILL RBridge Channel frames [RFC7178]. The RBridge Channel Protocol value is given in Section 8. The protocol-specific data associated with the TRILL BFD Control protocol is as shown in Section 4.1 of [RFC5880].
TRILL BFD制御フレームはユニキャストTRILL RBridge Channelフレームです[RFC7178]。 RBridge Channel Protocolの値はセクション8に記載されています。TRILLBFD制御プロトコルに関連するプロトコル固有のデータは、[RFC5880]のセクション4.1に示されています。
One-hop TRILL BFD Control is typically used to rapidly detect link and RBridge failures. TRILL BFD frames over one hop for such purposes SHOULD be sent with high priority; that is, the Inner.VLAN tag priority should be 7, they should be queued for transmission as maximum priority frames, and, if they are being sent on an Ethernet link where the output port is configured to include an Outer.VLAN tag, that tag should specify priority 7.
ワンホップTRILL BFDコントロールは通常、リンクとRBridgeの障害を迅速に検出するために使用されます。このような目的で1つのホップを介してBILLフレームをTRILLする場合は、高い優先度で送信する必要があります。つまり、Inner.VLANタグの優先度は7である必要があり、最大優先度フレームとして送信のためにキューに入れられる必要があります。また、出力ポートがOuter.VLANタグを含むように構成されているイーサネットリンクで送信される場合は、タグには優先度7を指定する必要があります
For neighbor RBridges RB1 and RB2, each RBridge sends one-hop TRILL BFD Control frames to the other only if TRILL IS-IS has detected bidirectional connectivity; that is, the adjacency is in the 2-Way or Report state [RFC7177], and both RBridges indicate support of TRILL BFD is enabled. The BFD-Enabled TLV is used to indicate this as specified in [RFC6213].
隣接RBridge RB1およびRB2の場合、各RBridgeは、TRILL IS-ISが双方向接続を検出した場合にのみ、1ホップのTRILL BFD制御フレームを他のRBridgeに送信します。つまり、隣接関係は2-WayまたはReport状態にあり[RFC7177]、両方のRBridgeがTRILL BFDのサポートが有効になっていることを示しています。 [RFC6213]で指定されているように、BFD対応TLVを使用してこれを示します。
The following tests SHOULD be performed on received TRILL BFD Control frames before generic BFD processing.
次のテストは、一般的なBFD処理の前に、受信したTRILL BFD制御フレームで実行する必要があります（SHOULD）。
o Is the M bit in the TRILL Header non-zero? If so, discard the frame. (Multi-destination BFD is a work in progress [MultiBFD].) Failure to perform this test would make a denial-of-service attack using bogus multi-destination BFD Control frames easier.
o TRILLヘッダーのMビットはゼロ以外ですか？その場合、フレームを破棄します。 （Multi-destination BFDは進行中の作業です[MultiBFD]。）このテストを実行しないと、偽のmulti-destination BFDコントロールフレームを使用したサービス拒否攻撃が簡単になります。
o If the Channel Header MH flag is zero, indicating one hop, test that the TRILL Header hop count received was 0x3F (i.e., is 0x3E if it has already been decremented); if it is any other value, discard the frame. If the Channel Header MH flag is one, indicating multi-hop, test that the TRILL Header hop count received was not less than a configurable value that defaults to 0x30. If it is less, discard the frame. Failure to perform these tests would make it easier to spoof BFD Control frames. However, if forged BFD Control frames are a concern, then BFD Authentication [RFC5880] should be used.
o チャネルヘッダーMHフラグがゼロで、1ホップを示している場合、受信したTRILLヘッダーホップカウントが0x3Fであったことをテストします（つまり、すでに減少している場合は0x3Eです）。それ以外の値の場合は、フレームを破棄します。チャネルヘッダーMHフラグが1で、マルチホップを示している場合は、受信したTRILLヘッダーホップカウントが、デフォルトで0x30に設定されている構成可能な値以上であることをテストします。少ない場合は、フレームを破棄します。これらのテストを実行しないと、BFDコントロールフレームのなりすましが容易になります。ただし、偽造されたBFD制御フレームが問題になる場合は、BFD認証[RFC5880]を使用する必要があります。
A TRILL BFD Echo frame is a unicast RBridge Channel frame, as specified in [RFC7178], which should be forwarded back by an immediate neighbor because both the ingress and egress nicknames are set to a nickname of the originating RBridge. Normal TRILL Data frame forwarding will cause the frame to be returned unless micro-loop suppression logic in the neighbor RBridge prohibits sending a frame back out the port on which it was received or the like. RBridges with such prohibitions cannot support BFD Echo. The TRILL OAM protocol number for BFD Echo is given in Section 8.
TRILL BFDエコーフレームは、[RFC7178]で指定されているように、ユニキャストRBridgeチャネルフレームです。これは、入口と出口のニックネームの両方が元のRBridgeのニックネームに設定されているため、直接のネイバーによって転送される必要があります。通常のTRILLデータフレーム転送では、隣接するRBridgeのマイクロループ抑制ロジックが、フレームを受信したポートなどからフレームを送り返すことを禁止していない限り、フレームが返されます。このような禁止事項があるRBridgeは、BFDエコーをサポートできません。 BFDエコーのTRILL OAMプロトコル番号は、セクション8に記載されています。
TRILL BFD Echo frames SHOULD be sent on a link only if the following conditions are met. An Echo originating under other circumstances will consume bandwidth and CPU resources but is unlikely to be returned.
TRILL BFDエコーフレームは、次の条件が満たされた場合にのみ、リンク上で送信される必要があります。他の状況で発生したエコーは、帯域幅とCPUリソースを消費しますが、返される可能性はほとんどありません。
- A TRILL BFD Control session has been established,
- TRILL BFDコントロールセッションが確立されました。
- TRILL BFD Echo support is indicated by the RBridge that would potentially respond to the BFD Echo,
- TRILL BFD Echoサポートは、BFD Echoに応答する可能性があるRBridgeによって示されます。
- The adjacency is in the Report state [RFC7177], and
- 隣接関係がレポート状態[RFC7177]であり、かつ
- The TRILL BFD Echo originating RBridge wishes to make use of this optional feature.
- TRILL BFD Echoが発信するRBridgeは、このオプション機能を利用したいと考えています。
Since the originating RBridge is the RBridge that will be processing a returned Echo frame, the entire TRILL BFD Echo protocol-specific data area is considered opaque and left to the discretion of the originating RBridge. Nevertheless, it is suggested that this data include information by which the originating RBridge can authenticate the returned BFD Echo frame and confirm the neighbor that echoed the frame back. For example, it could include its own System ID, the neighbor's System ID, a session identifier, and a sequence count as well as a Message Authentication Code.
元のRBridgeは返されたエコーフレームを処理するRBridgeであるため、TRILL BFDエコープロトコル固有のデータ領域全体は不透明と見なされ、元のRBridgeの裁量に任されます。それにもかかわらず、このデータには、元のRBridgeが返されたBFDエコーフレームを認証し、フレームをエコーバックしたネイバーを確認できる情報が含まれていることが推奨されます。たとえば、独自のシステムID、ネイバーのシステムID、セッション識別子、シーケンスカウント、およびメッセージ認証コードを含めることができます。
The following tests MUST be performed on returned TRILL BFD Echo frames before other processing. The RBridge Channel document [RFC7178] requires that the information in the TRILL Header be given to the BFD protocol.
他の処理の前に、返されたTRILL BFDエコーフレームに対して次のテストを実行する必要があります。 RBridge Channelドキュメント[RFC7178]では、TRILLヘッダーの情報をBFDプロトコルに提供する必要があります。
o Is the M bit in the TRILL Header non-zero? If so, discard the frame. (Multi-destination BFD is a work in progress [MultiBFD].)
o TRILLヘッダーのMビットはゼロ以外ですか？その場合、フレームを破棄します。 （マルチ宛先BFDは、進行中の作業です[MultiBFD]。）
o The TRILL BFD Echo frame should have gone exactly two hops, so test that the TRILL Header hop count as received was 0x3E (i.e., 0x3D if it has already been decremented), and if it is any other value, discard the frame. The RBridge Channel Header in the frame MUST have the MH bit equal to one, and if it is zero, discard the frame.
o TRILL BFDエコーフレームは正確に2ホップ進んでいるはずなので、受信したTRILLヘッダーのホップカウントが0x3E（つまり、既にデクリメントされている場合は0x3D）であることをテストし、それ以外の値の場合はフレームを破棄します。フレーム内のRBridgeチャネルヘッダーは、1に等しいMHビットを持つ必要があり、それがゼロの場合、フレームを破棄します。
The TRILL BFD parameters on an RBridge are configurable. The default values are the same as in the IP BFD case [RFC5881], except where specified in this document, such as for hop count.
RBridgeのTRILL BFDパラメーターは構成可能です。デフォルト値は、ホップカウントなど、このドキュメントで指定されている場合を除いて、IP BFDケース[RFC5881]と同じです。
It is up to the operator of an RBridge campus to configure the rates at which TRILL BFD frames are transmitted on a link to avoid congestion (e.g., link, input/output (I/O), CPU) and false failure detection. See also the discussion of congestion in Section 2 of [RFC5881].
輻輳（リンク、入力/出力（I / O）、CPUなど）および誤った障害検出を回避するために、リンク上でTRILL BFDフレームが送信されるレートを構成するのは、RBridgeキャンパスのオペレーターの責任です。 [RFC5881]のセクション2にある輻輳の説明もご覧ください。
As stated in [RFC5880]:
[RFC5880]で述べられているように：
It is worth noting that a single BFD session does not consume a large amount of bandwidth. An aggressive session that achieves a detection time of 50 milliseconds, by using a transmit interval of 16.7 milliseconds and a detect multiplier of 3, will generate 60 packets per second. The maximum length of each packet on the wire is on the order of 100 bytes, for a total of around 48 kilobits per second of bandwidth consumption in each direction.
単一のBFDセッションが大量の帯域幅を消費しないことは注目に値します。 16.7ミリ秒の送信間隔と3の検出乗数を使用して50ミリ秒の検出時間を達成するアグレッシブセッションは、1秒あたり60パケットを生成します。ワイヤ上の各パケットの最大長は100バイトのオーダーであり、各方向で合計で約48キロビット/秒の帯域幅が消費されます。
Consistent with TRILL's goal of being able to operate with minimum configuration, the default for BFD authentication between neighbor RBridges is based on the state of the IS-IS shared secret authentication for Hellos between those RBridges as detailed below. The BFD authentication algorithm and methods in this section MUST be implemented at an RBridge if TRILL IS-IS authentication and BFD are implemented at that RBridge. If such BFD authentication is configured, then its configuration is not restricted by the configuration of IS-IS security.
最小限の構成で操作できるというTRILLの目標と一致して、ネイバーRBridge間のBFD認証のデフォルトは、以下で説明するように、これらのRBridge間のHelloのIS-IS共有シークレット認証の状態に基づいています。このセクションのBFD認証アルゴリズムとメソッドは、RBILLでTRILL IS-IS認証とBFDが実装されている場合、RBridgeで実装する必要があります。このようなBFD認証が設定されている場合、その設定はIS-ISセキュリティの設定によって制限されません。
If IS-IS authentication is not in effect between neighbor RBridges, then, by default, TRILL BFD between those RBridges is also unsecured.
IS-IS認証が隣接するRBridge間で有効でない場合、デフォルトでは、それらのRBridge間のTRILL BFDも保護されません。
If such IS-IS authentication is in effect, then, unless configured otherwise, TRILL BFD Control frames sent between those RBridges MUST use BFD Meticulous Keyed SHA1 authentication [RFC5880]. The BFD authentication keys between neighbor RBridges by default are derived from the IS-IS shared secret authentication keys for Hellos between those RBridges as detailed below. However, such BFD authentication keys MAY be configured to some other value.
そのようなIS-IS認証が有効である場合、特に構成されていない限り、それらのRBridge間で送信されるTRILL BFD制御フレームは、BFD Meticulous Keyed SHA1認証[RFC5880]を使用する必要があります。デフォルトでネイバーRBridge間のBFD認証キーは、以下に詳細を示すように、それらのRBridge間のHelloのIS-IS共有秘密認証キーから派生します。ただし、そのようなBFD認証キーは他の値に設定される場合があります。
HMAC-SHA256 ( ( "TRILL BFD Control" | originPortID | originSysID ), IS-IS-shared-key )
HMAC-SHA256（（ "TRILL BFD Control" | originPortID | originSysID）、IS-IS-shared-key）
In the above, "|" indicates concatenation; HMAC-SHA256 is as described in [FIPS180] and [RFC6234]; and "TRILL BFD Control" is the 17-byte US ASCII [ASCII] string indicated that is then concatenated with the 2-byte Port ID of the originating port and the 6-byte IS-IS System ID of the originating RBridge, the last two items being in network byte order. The Port and System IDs are included to minimize exposure of the same key to improve resistance to cryptanalysis. IS-IS-shared-key is secret keying material being used for IS-IS authentication on the link.
上記では、「|」連結を示します。 HMAC-SHA256は[FIPS180]と[RFC6234]で説明されています。 「TRILL BFD Control」は、17バイトのUS ASCII [ASCII]文字列であり、発信元ポートの2バイトのポートIDと、発信元RBridgeの6バイトのIS-ISシステムIDで連結されます。 2つのアイテムがネットワークバイトオーダーになっています。ポートIDとシステムIDは、暗号解読に対する耐性を向上させるために同じキーの露出を最小限にするために含まれています。 IS-IS-shared-keyは、リンクのIS-IS認証に使用される秘密の鍵情報です。
The use of the above derived key is accomplished by associating the above default authentication type and key with the Key ID of the IS-IS-shared-key used in the derivation and then using that Key ID in the Authentication Section of the BFD Control frame OAM protocol-specific data. Also, Auth Type would be 5, and Auth Len would be 28 in the Authentication Section. RBridges MAY be configured to use other BFD security modes or keying material or configured to use no security.
上記の派生キーの使用は、上記のデフォルトの認証タイプとキーを、派生で使用されるIS-IS共有キーのキーIDに関連付け、次にBFD制御フレームの認証セクションでそのキーIDを使用することで実現されます。 OAMプロトコル固有のデータ。また、Auth Typeは5で、Auth LenはAuthenticationセクションで28になります。 RBridgesは、他のBFDセキュリティモードまたはキー情報を使用するように構成することも、セキュリティを使用しないように構成することもできます。
Authentication for TRILL BFD Echo is a local implementation issue as BFD Echo frames are authenticated by their sender when returned by a neighbor. However, if TRILL IS-IS and BFD Control are being authenticated to a neighbor and BFD Echo is in use, BFD Echo frames to be returned by that neighbor should be authenticated, and such authentication should use different keying material from other types of authentication. For example, it could use keying material derived as follows, where "|" indicates concatenation:
BFDエコーフレームはネイバーから返されたときに送信者によって認証されるため、TRILL BFDエコーの認証はローカル実装の問題です。ただし、TRILL IS-ISおよびBFDコントロールがネイバーに対して認証されており、BFDエコーが使用されている場合、そのネイバーによって返されるBFDエコーフレームは認証される必要があり、そのような認証では他のタイプの認証とは異なるキーイングマテリアルを使用する必要があります。たとえば、次のように派生したキー素材を使用できます。ここで、「|」連結を示します。
HMAC-SHA256 ( ( "TRILL BFD Echo" | originPortID | originSysID ), IS-IS-shared-key )
HMAC-SHA256（（ "TRILL BFD Echo" | originPortID | originSysID）、IS-IS-shared-key）
BFD over TRILL utilizes the RBridge Channel extension to the TRILL protocol and is generally analogous to BFD over IP. As such, the BFD authentication facility is available to authenticate BFD-over-TRILL packet payloads, but no encryption or other security features are provided at the BFD-over-TRILL level. See the following:
BFD over TRILLは、TRILLプロトコルへのRBridgeチャネル拡張を利用し、一般にBFD over IPに類似しています。そのため、BFD認証機能を使用してBFD-over-TRILLパケットペイロードを認証できますが、BFD-over-TRILLレベルでは暗号化やその他のセキュリティ機能は提供されません。以下を参照してください。
- [RFC5881] for general BFD security considerations,
- [RFC5881] BFDのセキュリティに関する一般的な考慮事項
- [RFC7178] for general RBridge Channel security considerations, and
- [RFC7178] RBridge Channelのセキュリティに関する一般的な考慮事項
- [RFC6325] for general TRILL protocol security considerations.
- [RFC6325] TRILLプロトコルのセキュリティに関する一般的な考慮事項。
Section 3.2 describes security concerns with multi-hop BFD Control packets and failure to check the TRILL Header M bit in BFD Control packets.
セクション3.2では、マルチホップBFD制御パケットのセキュリティ上の問題と、BFD制御パケットのTRILLヘッダーMビットのチェックの失敗について説明します。
IANA has allocated two RBridge Channel protocol numbers [RFC7178] from the Standards Action range, as follows:
IANAは、次のように、標準アクション範囲から2つのRBridgeチャネルプロトコル番号[RFC7178]を割り当てました。
Protocol Number
-------- ------
BFD Control 0x002
BFD Echo 0x003
The authors would like to specially thank Dave Katz, an author of [RFC5880] and [RFC5881], from which some material herein has been reproduced.
著者は、[RFC5880]と[RFC5881]の著者であるDave Katzに特に感謝します。
The following individuals are thanked for their comments and suggestions: Scott Bradner, Stewart Bryant, Stephen Farrell, Eric Gray, Brian Haberman, Barry Leiba, Erik Nordmark, John Scudder, Robert Sparks, Martin Stiemerling, and Sean Turner.
スコットブラドナー、スチュワートブライアント、スティーブンファレル、エリックグレイ、ブライアンハーバーマン、バリーレイバ、エリックノードマーク、ジョンスカッダー、ロバートスパークス、マーティンスティーマーリング、ショーンターナーの各個人からのコメントと提案に感謝します。
[ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[ASCII] American National Standards Institute、「Coded Character Set-7-bit American Standard Code for Information Interchange」、ANSI X3.4、1986。
[FIPS180] National Institute of Science and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standard (FIPS) 180-4, March 2012, <http://csrc.nist.gov/ publications/fips/fips180-4/fips-180-4.pdf>.
[FIPS180]国立科学技術研究所、「セキュアハッシュ標準（SHS）」、連邦情報処理標準（FIPS）180-4、2012年3月、<http://csrc.nist.gov/publications/fips/fips180- 4 / fips-180-4.pdf>。
[IS-IS] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", Second Edition, November 2002.
[IS-IS]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システム間ドメイン内ルーティング情報交換プロトコル」、第2版、2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[RFC5881] Katz、D。およびD. Ward、「IPv4およびIPv6（シングルホップ）の双方向転送検出（BFD）」、RFC 5881、2010年6月。
[RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 6213, April 2011.
[RFC6213] Hopps、C。およびL. Ginsberg、「IS-IS BFD-Enabled TLV」、RFC 6213、2011年4月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、May 2014。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014.
[RFC7178] Eastlake 3rd、D.、Manral、V.、Li、Y.、Aldrin、S.、and D. Ward、 "Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Support"、RFC 7178、May 2014 。
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks -- Link Aggregation", IEEE Std 802.1AX-2008, January 2008.
[802.1AX] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、IEEE Std 802.1AX-2008、January 2008。
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 2011.
[802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、IEEE Std 802.1Q-2011、2011年8月。
[MultiBFD] Katz, D. and D. Ward, "BFD for Multipoint Networks", Work in Progress, February 2014.
[MultiBFD] Katz、D。、およびD. Ward、「BFD for Multipoint Networks」、Work in Progress、2014年2月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、「Generalized TTL Security Mechanism（GTSM）」、RFC 5082、2007年10月。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、2011年5月。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6291] Andersson、L.、van Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「IETFでの「OAM」の頭字語の使用に関するガイドライン」、BCP 161、RFC 6291 、2011年6月。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.
[RFC6361] Carlson、J。およびD. Eastlake 3度、「PPP Transparent Interconnection of Lots of Links（TRILL）Protocol Control Protocol」、RFC 6361、2011年8月。
[RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, "Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires", RFC 7173, May 2014.
[RFC7173] Yong、L.、Eastlake 3rd、D.、Aldrin、S。、およびJ. Hudson、「トランスペアレントインターコネクションオブリンクス（TRILL）Transport using Pseudowires」、RFC 7173、2014年5月。
Authors' Addresses
著者のアドレス
Vishwas Manral Ionos Corp. 4100 Moorpark Ave. San Jose, CA 95117 USA
ビスワスミネラルニーニョスカップ。 4100 Murky Av。 95117彼
EMail: vishwas@ionosnetworks.com
Donald Eastlake 3rd Huawei R&D USA 155 Beaver Street Milford, MA 01757 USA
ドナルドイーストレイク3rd Huawei R＆D USA 155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Dave Ward Cisco Systems 170 W. Tasman Drive San Jose, CA 95138 USA
Dave Ward Cisco Systems 170 W. Tasman Drive San Jose、CA 95138 USA
EMail: dward@cisco.com
Ayan Banerjee Cumulus Networks 1089 West Evelyn Avenue Sunnyvale, CA 94086 USA
Ayan Banerjee Cumulus Networks 1089 West Evelyn Avenue Sunnyvale、CA 94086 USA
EMail: ayabaner@gmail.com