[要約] RFC 8380は、TRILL（Transparent Interconnection of Lots of Links）カプセル化に関する情報を提供するものであり、ディレクトリを使用して透明なリンクの相互接続を実現することを目的としています。
Internet Engineering Task Force (IETF) L. Dunbar
Request for Comments: 8380 D. Eastlake 3rd
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
Dell/EMC
May 2018
Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation
多くのリンクのディレクトリ支援による透過的な相互接続（TRILL）カプセル化
Abstract
概要
This document describes how data center networks can benefit from non-RBridge nodes performing TRILL (Transparent Interconnection of Lots of Links) encapsulation with assistance from a directory service.
このドキュメントでは、ディレクトリサービスの支援を受けて、データセンターネットワークがRBridge以外のノードがTRILL（リンクの透過的相互接続）カプセル化を実行するメリットを説明します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8380.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8380で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Directory Assistance to Non-RBridge .............................3
4. Source Nickname in Encapsulation by Non-RBridge Nodes ...........6
5. Benefits of a Non-RBridge Performing TRILL Encapsulation ........6
5.1. Avoid Nickname Exhaustion Issue ............................6
5.2. Reduce MAC Tables for Switches on Bridged LANs .............6
6. Manageability Considerations ....................................7
7. Security Considerations .........................................7
8. IANA Considerations .............................................9
9. References .....................................................9
9.1. Normative References .....................................10
9.2. Informative References ...................................10
Acknowledgments ...................................................10
Authors' Addresses.................................................10
This document describes how data center networks can benefit from non-RBridge nodes performing TRILL encapsulation with assistance from a directory service and specifies a method for them to do so.
このドキュメントでは、ディレクトリサービスの支援を得てTRILLカプセル化を実行する非RBridgeノードがデータセンターネットワークにどのように役立つかを説明し、それらの方法を指定します。
[RFC7067] and [RFC8171] describe the framework and methods for edge RBridges to get (MAC and VLAN) <-> Edge RBridge mapping from a directory service instead of flooding unknown destination MAC addresses across a TRILL domain. If it has the needed directory information, any node, even a non-RBridge node, can perform the TRILL data packet encapsulation. This document describes the benefits of and a scheme for non-RBridge nodes performing TRILL encapsulation.
[RFC7067]と[RFC8171]では、エッジRBridgeがフレームワークとメソッドを取得する方法（MACおよびVLAN）<->エッジRBridgeマッピングを、TRILLドメイン全体で不明な宛先MACアドレスをフラッディングする代わりに、ディレクトリサービスから取得します。必要なディレクトリ情報がある場合、RBridge以外のノードであっても、どのノードでもTRILLデータパケットのカプセル化を実行できます。このドキュメントでは、TRILLカプセル化を実行する非RBridgeノードの利点とスキームについて説明します。
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]で説明されているように解釈されます。
AF: Appointed Forwarder RBridge port [RFC8139].
AF：Appointed Forwarder RBridge port [RFC8139]。
Bridge: A device compliant with IEEE 802.1Q. In this document, Bridge is used interchangeably with Layer 2 switch.
ブリッジ：IEEE 802.1Qに準拠したデバイス。このドキュメントでは、ブリッジはレイヤ2スイッチと同じ意味で使用されています。
DA: Destination Address.
DA：宛先アドレス。
ES-IS: End System to Intermediate System [RFC8171].
ES-IS：End System to Intermediate System [RFC8171]。
Host: A physical server or a virtual machine running applications. A host usually has at least one IP address and at least one MAC address.
ホスト：アプリケーションを実行している物理サーバーまたは仮想マシン。ホストには通常、少なくとも1つのIPアドレスと少なくとも1つのMACアドレスがあります。
IS-IS: Intermediate System to Intermediate System [RFC7176].
IS-IS：Intermediate System to Intermediate System [RFC7176]。
SA: Source Address.
SA：送信元アドレス。
TRILL-EN: TRILL Encapsulating Node. A node that performs the TRILL encapsulation but doesn't participate in an RBridge's IS-IS routing.
TRILL-EN：TRILLカプセル化ノード。 TRILLカプセル化を実行するが、RBridgeのIS-ISルーティングに参加しないノード。
VM: Virtual Machine.
VM：仮想マシン。
With directory assistance [RFC7067] [RFC8171], a non-RBridge node can learn if a data packet needs to be forwarded across the RBridge domain and, if so, the corresponding egress RBridge.
ディレクトリアシスタンス[RFC7067] [RFC8171]を使用すると、非RBridgeノードは、データパケットをRBridgeドメイン全体に転送する必要があるかどうか、必要な場合は対応する出力RBridgeを学習できます。
Suppose the RBridge domain boundary starts at network switches (not virtual switches embedded on servers). (See Figure 1 for a high-level diagram of a typical data center network.) A directory can assist virtual switches embedded on servers to encapsulate with a proper TRILL header by providing the nickname of the egress RBridge edge to which the destination is attached. The other information needed to encapsulate can be learned either by listening to TRILL ES-IS and/or IS-IS Hellos [RFC7176] [RFC8171], which will indicate the MAC address and nickname of appropriate local edge RBridges, or by configuration.
RBridgeドメインの境界がネットワークスイッチ（サーバーに組み込まれた仮想スイッチではない）で始まると仮定します。 （一般的なデータセンターネットワークの概要図については、図1を参照してください。）ディレクトリは、宛先が接続されている下りRBridgeエッジのニックネームを提供することにより、サーバーに組み込まれた仮想スイッチが適切なTRILLヘッダーでカプセル化するのを支援できます。カプセル化に必要なその他の情報は、MACアドレスと適切なローカルエッジRBridgeのニックネームを示すTRILL ES-ISまたはIS-IS Hellos [RFC7176] [RFC8171]をリッスンするか、構成によって学習できます。
If it is not known whether a destination is attached to one or more edge RBridges, based on the directory, the non-RBridge node can forward the data frames natively, i.e., not encapsulating with any TRILL header. Or, if the directory is known to be complete, the non-RBridge node can discard such data frames.
宛先が1つ以上のエッジRBridgeに接続されているかどうかがディレクトリに基づいてわからない場合、非RBridgeノードはデータフレームをネイティブに転送できます。つまり、TRILLヘッダーでカプセル化しません。または、ディレクトリが完全であることがわかっている場合、非RBridgeノードはそのようなデータフレームを破棄できます。
\ +-----------+ +-----------+ /
\ +/----------+ | +/----------+ | TRILL /
\ |Aggregation| | |Aggregation| | Domain /
\ | 11 | + --- | N1 | + /
\ +-----------+/ +-----------+/ /
\ / \ / \ /
\ / \ / \ /
Top- \ +---+ +---+ +---+ +---+ /
of- --> \- |T11|... |T1x| |T21| .. |T2y|---/
Rack +---+ +---+ +---+ +---+
Switches | | | |
+-|-+ +-|-+ +-|-+ +-|-+
| |... | V | | V | .. | V | <- vSwitch
+---+ +---+ +---+ +---+
| |... | V | | V | .. | V |
+---+ +---+ +---+ +---+
| |... | V | | V | .. | V |
+---+ +---+ +---+ +---+
Figure 1: TRILL Domain in a Typical Data Center Network
図1：一般的なデータセンターネットワークのTRILLドメイン
When a TRILL-encapsulated data packet reaches the ingress RBridge, that RBridge simply performs the usual TRILL processing and forwards the pre-encapsulated packet to the RBridge that is specified by the egress nickname field of the TRILL header. When an ingress RBridge receives a native Ethernet frame in an environment with complete directory information, the ingress RBridge doesn't flood or forward the received data frames when the destination MAC address in the Ethernet data frames is unknown.
TRILLでカプセル化されたデータパケットが入力RBridgeに到達すると、そのRBridgeは通常のTRILL処理を実行し、カプセル化されたパケットをTRILLヘッダーの出力ニックネームフィールドで指定されたRBridgeに転送します。完全なディレクトリ情報を持つ環境で入力RBridgeがネイティブイーサネットフレームを受信すると、イーサネットデータフレームの宛先MACアドレスが不明な場合、入力RBridgeは受信したデータフレームをフラッディングまたは転送しません。
When all end nodes attached to an ingress RBridge pre-encapsulate with a TRILL header for traffic across the TRILL domain, the ingress RBridge doesn't need to encapsulate any native Ethernet frames to the TRILL domain. The attached nodes can be connected to multiple edge RBridges by having multiple ports or through a bridged LAN. All RBridge edge ports connected to one bridged LAN can receive and forward pre-encapsulated traffic; this can greatly improve the overall network utilization. However, it is still necessary to, for example, designate AF ports to be sure that multi-destination packets from the TRILL campus are only egressed through one RBridge.
入力RBridgeに接続されたすべてのエンドノードが、TRILLドメイン全体のトラフィック用にTRILLヘッダーで事前カプセル化される場合、入力RBridgeは、ネイティブイーサネットフレームをTRILLドメインにカプセル化する必要はありません。接続されたノードは、複数のポートを持つか、またはブリッジされたLANを介して、複数のエッジRBridgeに接続できます。 1つのブリッジLANに接続されているすべてのRBridgeエッジポートは、カプセル化されたトラフィックを受信して転送できます。これにより、ネットワーク全体の使用率が大幅に向上します。ただし、たとえば、AFポートを指定して、TRILLキャンパスからの複数宛先パケットが1つのRBridgeからのみ出力されるようにする必要があります。
Item 8 of Section 4.6.2 of the TRILL base protocol specification [RFC6325] specifies that an RBridge port can be configured to accept TRILL-encapsulated frames from a neighbor that is not an RBridge.
TRILLベースプロトコル仕様[RFC6325]のセクション4.6.2の項目8は、RBridge以外のネイバーからのTRILLカプセル化フレームを受け入れるようにRBridgeポートを構成できることを指定しています。
When a TRILL frame arrives at an RBridge whose nickname matches the destination nickname in the TRILL header of the frame, the processing is exactly as normal: as specified in [RFC6325], the RBridge decapsulates the received TRILL frame and forwards the decapsulated frame to the target attached to its edge ports. When the destination MAC address of the decapsulated Ethernet frame is not in the egress RBridge's local MAC attachment tables, the egress RBridge floods the decapsulated frame to all attached links in the frame's VLAN, or drops the frame (if the egress RBridge is configured with that policy).
TRILLフレームが、ニックネームがフレームのTRILLヘッダーの宛先ニックネームと一致するRBridgeに到着すると、処理はまったく同じです。[RFC6325]で指定されているように、RBridgeは受信したTRILLフレームをカプセル化解除し、カプセル化解除されたフレームをエッジポートに接続されたターゲット。カプセル化解除されたイーサネットフレームの宛先MACアドレスが出力RBridgeのローカルMAC接続テーブルにない場合、出力RBridgeはカプセル化解除されたフレームをフレームのVLAN内のすべての接続リンクにフラッディングするか、フレームをドロップします（出力RBridgeがポリシー）。
We call a node that, as specified herein, only performs TRILL encapsulation, but doesn't participate in RBridge's IS-IS routing, a TRILL Encapsulating Node (TRILL-EN). The TRILL Encapsulating Node can pull (MAC and VLAN) <-> Edge RBridge mapping from directory servers [RFC8171]. In order to do this, a TRILL-EN MUST support TRILL ES-IS [RFC8171].
ここでは、TRILLカプセル化のみを実行し、RBridgeのIS-ISルーティングには参加しないノードをTRILLカプセル化ノード（TRILL-EN）と呼びます。 TRILLカプセル化ノードは（MACおよびVLAN）<->ディレクトリサーバーからエッジRBridgeマッピングをプルできます[RFC8171]。これを行うには、TRILL-ENはTRILL ES-IS [RFC8171]をサポートする必要があります。
Upon receiving or locally generating a native Ethernet frame, the TRILL-EN checks the (MAC and VLAN) <-> Edge RBridge mapping and performs the corresponding TRILL encapsulation if the mapping entry is found as shown in Figure 2. If the destination MAC address and VLAN of the received Ethernet frame doesn't exist in the mapping table and there is no positive reply from pull requests to a directory, the Ethernet frame is dropped or is forwarded in native form to an edge RBridge, depending on the TRILL-EN configuration.
ネイティブイーサネットフレームを受信またはローカルで生成すると、TRILL-ENは（MACおよびVLAN）<-> Edge RBridgeマッピングをチェックし、図2に示すようにマッピングエントリが見つかった場合に対応するTRILLカプセル化を実行します。宛先MACアドレス受信したイーサネットフレームのVLANがマッピングテーブルに存在せず、プルリクエストからディレクトリへの肯定的な応答がない場合、イーサネットフレームはドロップされるか、TRILL-ENに応じてネイティブの形式でエッジRBridgeに転送されます。構成。
+------------+--------+---------+---------+--+-------+---+
|OuterEtherHd|TRILL HD| InnerDA | InnerSA |..|Payload|FCS|
+------------+--------+---------+---------+--+-------+---+
|
| |<Inner Ether Header> |
|
|
| +-------+ TRILL +------+
| | RB1 |---------->| RB2 | Decapsulate
| +-------+ domain +------+ TRILL header
v ^ |
+---------->| |
| V
+--------+ +--------+
Non-RBridge node: |TRILL-EN| |TRILL-EN|
Encapsulate TRILL | 1 | | 2 |
Header for data +--------+ +--------+
Frames to traverse TRILL domain.
Figure 2: Data Frames from a TRILL-EN
図2：TRILL-ENからのデータフレーム
The TRILL header includes a Source RBridge's Nickname (ingress) and Destination RBridge's Nickname (egress). When a TRILL header is added to a data packet by a TRILL-EN, the ingress RBridge nickname field in the TRILL header is set to a nickname of the AF for the data packet's VLAN. The TRILL-EN determines the AF by snooping on IS-IS Hellos from the edge RBridges on the link with the TRILL-EN in the same way that the RBridges on the link determine the AF [RFC8139]. A TRILL-EN is free to send the encapsulated data frame to any of the edge RBridges on its link.
TRILLヘッダーには、ソースRBridgeのニックネーム（入力）と宛先RBridgeのニックネーム（出力）が含まれています。 TRILL-ENによってTRILLヘッダーがデータパケットに追加されると、TRILLヘッダーの入力RBridgeニックネームフィールドは、データパケットのVLANのAFのニックネームに設定されます。 TRILL-ENは、リンク上のRBridgeがAF [RFC8139]を決定するのと同じ方法で、TRILL-ENを持つリンク上のエッジRBridgeからIS-IS HelloをスヌーピングすることによってAFを決定します。 TRILL-ENは、カプセル化されたデータフレームをリンク上の任意のエッジRBridgeに自由に送信できます。
This section summarizes the benefits of having a non-RBridge node perform TRILL encapsulation.
このセクションでは、RBridge以外のノードにTRILLカプセル化を実行させる利点をまとめています。
For a large data center with hundreds of thousands of virtualized servers, setting the TRILL boundary at the servers' virtual switches will create a TRILL domain with hundreds of thousands of RBridge nodes; this could lead to TRILL nickname exhaustion and challenges to IS-IS. On the other hand, setting the TRILL boundary at aggregation switches that have many virtualized servers attached can limit the number of RBridge nodes in a TRILL domain, but introduces the issue of having very large (MAC and VLAN) <-> Edge RBridge mapping tables that need to be maintained by edge RBridges.
数十万の仮想サーバーがある大規模なデータセンターの場合、サーバーの仮想スイッチにTRILL境界を設定すると、数十万のRBridgeノードを持つTRILLドメインが作成されます。これは、TRILLニックネームの枯渇とIS-ISへの挑戦につながる可能性があります。一方、多くの仮想サーバーが接続されている集約スイッチでTRILL境界を設定すると、TRILLドメイン内のRBridgeノードの数が制限される可能性がありますが、非常に大きな（MACおよびVLAN）<->エッジRBridgeマッピングテーブルが存在するという問題が生じますエッジRBridgeで維持する必要があります。
Allowing non-RBridge nodes to pre-encapsulate data frames with TRILL headers makes it possible to have a TRILL domain with a reasonable number of RBridge nodes in a large data center. All the TRILL-ENs attached to one RBridge can be represented by one TRILL nickname, which can avoid the nickname exhaustion problem.
非RBridgeノードがTRILLヘッダーを使用してデータフレームを事前にカプセル化できるようにすることで、大規模なデータセンター内に適切な数のRBridgeノードを備えたTRILLドメインを作成できます。 1つのRBridgeに接続されているすべてのTRILL-ENを1つのTRILLニックネームで表すことができるため、ニックネームの枯渇の問題を回避できます。
When hosts in a VLAN (or subnet) span across multiple edge RBridges and each edge RBridge has multiple VLANs enabled, the switches on the bridged LANs attached to the edge RBridges are exposed to all MAC addresses among all the VLANs enabled.
VLAN（またはサブネット）内のホストが複数のエッジRBridgeにまたがり、各エッジRBridgeで複数のVLANが有効になっている場合、エッジRBridgeに接続されたブリッジLAN上のスイッチは、有効になっているすべてのVLANのすべてのMACアドレスに公開されます。
For example, for an Access Switch with 40 physical servers attached, where each server has 100 VMs, there are 4000 hosts under the Access Switch. If indeed hosts/VMs can be moved anywhere, the worst case for the Access Switch is when all those 4000 VMs belong to different VLANs, i.e., the Access Switch has 4000 VLANs enabled. If each VLAN has 200 hosts, this Access Switch's MAC table potentially has 200 * 4000 = 800,000 entries.
たとえば、40台の物理サーバーが接続されたアクセススイッチの場合、各サーバーには100個のVMがあり、アクセススイッチの下には4000台のホストがあります。実際にホスト/ VMをどこにでも移動できる場合、アクセススイッチの最悪のケースは、それらすべての4000 VMが異なるVLANに属している場合、つまり、アクセススイッチで4000 VLANが有効になっている場合です。各VLANに200のホストがある場合、このアクセススイッチのMACテーブルには200 * 4000 = 800,000のエントリが含まれる可能性があります。
If the virtual switches on servers pre-encapsulate the data frames destined for hosts attached to remote edge RBridges, the outer MAC destination address of those TRILL-encapsulated data frames will be the MAC address of a local RBridge edge, i.e., the ingress RBridge. The switches on the local bridged LAN don't need to keep the MAC entries for remote hosts attached to other edge RBridges.
サーバー上の仮想スイッチがリモートエッジRBridgeに接続されたホスト宛てのデータフレームを事前にカプセル化する場合、それらのTRILLカプセル化データフレームの外部MAC宛先アドレスは、ローカルRBridgeエッジ、つまり入力RBridgeのMACアドレスになります。ローカルブリッジLAN上のスイッチは、他のエッジRBridgeに接続されたリモートホストのMACエントリを保持する必要はありません。
But the TRILL traffic from nodes attached to other RBridges is decapsulated and has the true source and destination MACs. One simple way to prevent local bridges from learning remote hosts' MACs and adding to their MAC tables, if that would be a problem, is to disable this data-plane learning on local bridges. With the assistance of a directory, the local bridges can be pre-configured with MAC addresses of local hosts. The local bridges can always send frames with unknown destination MAC addresses to the ingress RBridge. In an environment where a large number of VMs are instantiated in one server, the number of remote MAC addresses could be very large. If it is not feasible to disable learning and pre-configure MAC tables for local bridges and all important traffic is IP, one effective method to minimize local bridges' MAC table size is to use the server's MAC address to hide MAC addresses of the attached VMs. That is, the server acting as an edge node uses its own MAC address in the source MAC address field of the packets originated from a host (or VM). When the Ethernet frame arrives at the target edge node (the egress), the target edge node can send the packet to the corresponding destination host based on the packet's IP address. Very often, the target edge node communicates with the embedded VMs via a Layer 2 virtual switch. In this case, the target edge node can construct the proper Ethernet header with the assistance of the directory. The information from the directory includes the proper mapping of host IP to MAC.
ただし、他のRBridgeに接続されているノードからのTRILLトラフィックはカプセル化が解除され、真の送信元および宛先MACを持っています。ローカルブリッジがリモートホストのMACを学習してMACテーブルに追加しないようにする簡単な方法の1つは、それが問題になる場合は、ローカルブリッジでこのデータプレーン学習を無効にすることです。ディレクトリを利用して、ローカルブリッジをローカルホストのMACアドレスで事前設定できます。ローカルブリッジは常に、宛先MACアドレスが不明なフレームを入力RBridgeに送信できます。 1つのサーバーで多数のVMがインスタンス化される環境では、リモートMACアドレスの数が非常に大きくなる可能性があります。ローカルブリッジの学習を無効にしてMACテーブルを事前設定できず、すべての重要なトラフィックがIPである場合、ローカルブリッジのMACテーブルサイズを最小化する効果的な方法の1つは、サーバーのMACアドレスを使用して、接続されたVMのMACアドレスを非表示にすることです。 。つまり、エッジノードとして機能するサーバーは、ホスト（またはVM）から送信されたパケットの送信元MACアドレスフィールドに独自のMACアドレスを使用します。イーサネットフレームがターゲットエッジノード（出力）に到着すると、ターゲットエッジノードは、パケットのIPアドレスに基づいて、対応する宛先ホストにパケットを送信できます。多くの場合、ターゲットエッジノードは、レイヤー2仮想スイッチを介して組み込みVMと通信します。この場合、ターゲットエッジノードは、ディレクトリを利用して適切なイーサネットヘッダーを構築できます。ディレクトリからの情報には、ホストIPからMACへの適切なマッピングが含まれています。
Directory assistance [RFC8171] is required to make it possible for a non-TRILL node to pre-encapsulate packets destined towards remote RBridges. TRILL-ENs have the same configuration options as any pull directory client. See Section 4 of [RFC8171].
非TRILLノードがリモートRBridge宛てのパケットを事前にカプセル化できるようにするには、ディレクトリアシスタンス[RFC8171]が必要です。 TRILL-ENには、他のプルディレクトリクライアントと同じ構成オプションがあります。 [RFC8171]のセクション4をご覧ください。
If the TRILL-ENs are not trusted, they can forge arbitrary ingress and egress nicknames in the TRILL Headers of the TRILL Data packets they construct. With data-plane learning, decapsulating a TRILL Data packet at an egress RBridge associates the inner source MAC address with the ingress nickname in the TRILL Header (assuming that MAC address is unicast). Thus, if those ingress nicknames are forged, incorrect learning will occur and future traffic destined for the inner source MAC will be sent to the wrong RBridge for egress. Because of this, an RBridge port should not be configured to accept encapsulated TRILL data frames on a link were it does not have an RBridge adjacency unless the end stations on that link are trusted.
TRILL-ENが信頼されていない場合、TRILL-ENは、それらが構築するTRILLデータパケットのTRILLヘッダーで任意の入力および出力ニックネームを偽造できます。データプレーン学習では、出力RBridgeでTRILLデータパケットのカプセル化を解除すると、内部ソースMACアドレスがTRILLヘッダーの入力ニックネームに関連付けられます（そのMACアドレスがユニキャストであると想定）。したがって、これらの入力ニックネームが偽造された場合、誤った学習が発生し、内部ソースMAC宛ての将来のトラフィックは、出力用の間違ったRBridgeに送信されます。このため、リンク上のエンドステーションが信頼されていない限り、RBridgeポートは、リンク上のカプセル化されたTRILLデータフレームを受け入れるように構成しないでください。
As with any end station, TRILL-ENs can forge the outer MAC addresses of packets they send. (See Section 6 of [RFC6325].) Because they pre-encapsulate, they can also forge inner MAC addresses.
他のエンドステーションと同様に、TRILL-ENは送信するパケットの外部MACアドレスを偽造できます。 （[RFC6325]のセクション6をご覧ください）。事前にカプセル化されているため、内部MACアドレスを偽造することもできます。
The pre-encapsulation performed by TRILL-ENs also means they can send data in any VLAN; this means they must be trusted in order to enforce a security policy based on VLANs. (See Section 6.1 of [RFC6325].)
TRILL-ENによって実行される事前カプセル化は、任意のVLANでデータを送信できることも意味します。つまり、VLANに基づいたセキュリティポリシーを適用するには、これらを信頼する必要があります。 （[RFC6325]のセクション6.1をご覧ください）。
Use of directory-assisted encapsulation by TRILL-ENs essentially involves those TRILL-ENs spoofing edge RBridges to which they are connected; this is another reason that TRILL-ENs should be trusted nodes. Such spoofing cannot cause persistently looping traffic because TRILL has a hop count in the TRILL header [RFC6325] so that, should there be a loop, a TRILL packet caught in that loop (i.e., an encapsulated frame) will be discarded. (In the potentially more dangerous case of multidestination packets (as compared with known unicast) where copies could multiply due to forks in the distribution tree, a Reverse Path Forwarding Check is also used [RFC6325] to discard packets that appear to be on the wrong link or when there is disagreement about the distribution tree.)
TRILL-ENによるディレクトリアシストカプセル化の使用には、基本的に、それらが接続されているエッジRBridgeをスプーフィングするTRILL-ENが含まれます。これは、TRILL-ENを信頼できるノードにする必要があるもう1つの理由です。 TRILLにはTRILLヘッダー[RFC6325]にホップカウントがあるため、このようなスプーフィングによってトラフィックが永続的にループすることはないため、ループが発生した場合、そのループ（つまり、カプセル化されたフレーム）でキャッチされたTRILLパケットは破棄されます。 （既知のユニキャストと比較して、マルチデスティネーションパケットの潜在的により危険なケースで、配布ツリーのフォークが原因でコピーが増加する可能性があります）、リバースパス転送チェックも使用され[RFC6325]、間違っていると思われるパケットを破棄しますリンクまたは配布ツリーについて不一致がある場合。）
The mechanism described in this document requires a TRILL-EN to be aware of the MAC address(es) of the TRILL edge RBridge(s) to which the TRILL-EN is attached and the egress RBridge nickname from which the destination of the packets is reachable. With that information, TRILL-ENs can learn a substantial amount about the topology of the TRILL domain. Therefore, there could be a potential security risk when the TRILL-ENs are not trusted or are compromised.
このドキュメントで説明されているメカニズムでは、TRILL-ENが接続されているTRILLエッジRBridgeのMACアドレスと、パケットの宛先の送信元である出力RBridgeニックネームをTRILL-ENが認識する必要があります。到達可能。その情報があれば、TRILL-ENはTRILLドメインのトポロジーについてかなりの量を学ぶことができます。したがって、TRILL-ENが信頼されていないか、侵害されている場合、潜在的なセキュリティリスクが存在する可能性があります。
If the path between the directory and a TRILL-EN is attacked, false mappings can be sent to the TRILL-EN causing packets from the TRILL-EN to be sent to wrong destinations, possibly violating security policy as to which end stations should receive what data. Therefore, a combination of authentication and encryption is RECOMMENDED between the directory and TRILL-EN. The entities involved will need to properly authenticate with each other, provide session encryption, maintain security patch levels, and configure their systems to allow minimal access and running processes to protect sensitive information.
ディレクトリとTRILL-ENの間のパスが攻撃されると、誤ったマッピングがTRILL-ENに送信され、TRILL-ENからのパケットが誤った宛先に送信され、どのエンドステーションが何を受信するかに関するセキュリティポリシーに違反する可能性があります。データ。したがって、認証と暗号化の組み合わせは、ディレクトリとTRILL-ENの間で推奨されます。関係するエンティティは、相互に適切に認証し、セッション暗号化を提供し、セキュリティパッチレベルを維持し、機密情報を保護するための最小限のアクセスと実行プロセスを許可するようにシステムを構成する必要があります。
For added security against the compromise of data due to its misdelivery for any reason, including the above, end-to-end encryption and authentication should be considered; that is, encryption and authentication from source end station to destination end station.
上記を含む、何らかの理由による誤配信によるデータの侵害に対する追加のセキュリティのために、エンドツーエンドの暗号化と認証を検討する必要があります。つまり、ソースエンドステーションから宛先エンドステーションへの暗号化と認証です。
For Pull Directory and TRILL ES-IS security considerations, see [RFC8171].
プルディレクトリとTRILL ES-ISのセキュリティに関する考慮事項については、[RFC8171]を参照してください。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://www.rfc-editor.org/info/rfc6325>.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<https://www.rfc-editor.org/info/rfc6325>。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <https://www.rfc-editor.org/info/rfc7176>.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、DOI 10.17487 / RFC7176、2014年5月、<https://www.rfc-editor.org/info/rfc7176>。
[RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139, June 2017, <https://www.rfc-editor.org/info/rfc8139>.
[RFC8139] Eastlake 3rd、D.、Li、Y.、Umair、M.、Banerjee、A.、and F. Hu、 "Transparent Interconnection of Lots of Links（TRILL）：Appointed Forwarders"、RFC 8139、DOI 10.17487 / RFC8139、2017年6月、<https://www.rfc-editor.org/info/rfc8139>。
[RFC8171] Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms", RFC 8171, DOI 10.17487/RFC8171, June 2017, <https://www.rfc-editor.org/info/rfc8171>.
[RFC8171] Eastlake 3rd、D.、Dunbar、L.、Perlman、R。、およびY. Li、「多数のリンクの透過的な相互接続（TRILL）：エッジディレクトリアシスタンスメカニズム」、RFC 8171、DOI 10.17487 / RFC8171、6月2017、<https://www.rfc-editor.org/info/rfc8171>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, <https://www.rfc-editor.org/info/rfc7067>.
[RFC7067] Dunbar、L.、Eastlake 3rd、D.、Perlman、R。、およびI. Gashinsky、「Directory Assistance Problem and High-Level Design Proposal」、RFC 7067、DOI 10.17487 / RFC7067、2013年11月、<https： //www.rfc-editor.org/info/rfc7067>。
Acknowledgments
謝辞
The following are thanked for their contributions:
以下は彼らの貢献に感謝します：
Igor Gashinsky Ben Nevin-Jenkins
イゴールガシンスキーベンネビンジェンキンス
Authors' Addresses
著者のアドレス
Linda Dunbar Huawei Technologies 5340 Legacy Drive, Suite 175 Plano, TX 75024 United States of America
Linda Dunbar Huawei Technologies 5340 Legacy Drive、Suite 175 Plano、TX 75024アメリカ合衆国
Phone: +1-469-277-5840
Email: linda.dunbar@huawei.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
ドナルドイーストレイク3rd Huawei Technologies 155 Beaver Streetミルフォード、マサチューセッツ州01757アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Radia Perlman Dell/EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States of America
Radia Perlman Dell / EMC 2010 256th Avenue NE、＃200 Bellevue、WA 98007アメリカ合衆国
Email: Radia@alum.mit.edu