🏹

RFC 8444: Bit Index Explicit Replication (BIER)用のOSPFv2拡張

2024/05/07に公開

RFC

multicast

bier

tech

要旨

Bit Index Explicit Replication (BIER)は、中間ルータがマルチキャスト関連のフローごとの状態を維持する必要なく、「BIERドメイン」を介して最適なマルチキャスト・フォワーディングを提供するアーキテクチャである。また、BIERは、その動作に明示的なツリー構築プロトコルを必要としない。マルチキャスト・データ・パケットは、Bit-Forwarding Ingress Router (BFIR)でBIERドメインに入り、1つ以上のBit-Forwarding Egress Routers (BFER)でBIERドメインから出る。BFIRは、BIERパケット・ヘッダをパケットに追加する。BIERパケット・ヘッダには、各ビットはパケットのフォワード先となる1つのBFERを正確に表すBitStringが含まれる。マルチキャスト・パケットのフォワード先となるBFERセットは、BIERパケット・ヘッダ内のビット・セットで表される。

本文書では、MPLSカプセル化 (RFC 8296で定義)を使用したBIERに必要なOSPFプロトコル拡張(RFC 2328による)について説明する。他のカプセル化タイプのサポートや複数のカプセル化タイプの使用は、本文書の範囲外である。

本文書の位置付け

本文書はインターネット標準化過程の文書である。

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc8444 で入手できる。

著作権表示

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

BIERアーキテクチャは、BIERに参加しているルータが特定のドメイン内でBIER関連の情報を交換する必要があり、リンクステート・ルーティング・プロトコルがそのような情報の配信を実行できるようにしている。本文書は、[RFC8296]で説明しているように、BIERがMPLSカプセル化を使用する場合に、BIER固有の情報を広告するために必要なOSPFの拡張について説明する。

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

2. OSPFにおけるBIER情報のフラッディング

ビット・フォワーディング・ルータ(BFR)が他のBFRに広告するために必要なすべてのBIER固有の情報は、BFRプレフィックスに関連付けられる。BFRプレフィックスは、[RFC8279]のセクション2で詳細に説明しているように、各BFRに割り当てられる(指定されたBIERドメイン内で)ユニークなルーティング可能なIPアドレスである。

BIER情報をBFRプレフィックスに関連付ける必要があることを考慮し、OSPFv2 Extended Prefix Opaque LSA [RFC7684]が広告に選ばれた。

⚠️ OSPFv2 Extended Prefix Opaque LSAのフォーマット

OSPFv2 Extended Prefix Opaque LSA

ospf-ex-op-lsa

OSPFv2 Extended Prefix TLV

ospf-ex-pfx-tlv

2.1. BIERサブTLV

OSPFv2 Extended Prefix TLV ([RFC7684] で定義)のサブTLVは、BIER情報を配布するために定義されている。サブTLVはBIERサブTLVと呼ぶ。複数のBIERサブTLVがOSPFv2 Extended Prefix TLVに含まれる場合がある。

BIERサブTLVのフォーマットは以下のとおり:

fig1

タイプ: 9

長さ: サブTLVに応じて可変

サブドメインid: [RFC8279]のセクション1に記載されているように、BIERドメイン内のBIERサブドメインを識別する一意の値

MT-ID: BIERサブドメインに関連付けられたトポロジを識別するマルチトポロジID ([RFC4915]で定義)。

BFR-id: [RFC8279]のセクション2に記載されているように、BFR-idを符号化する2オクテットのフィールド。BFRが有効なBFR-idでローカルに設定されていない場合、このフィールドの値は0に設定されるが、これは [RFC8279]で不正と定義されている。

BAR(BIERアルゴリズム): 他のBFRに到達するためのアンダーレイ・パスを計算するために使用されるシングル・オクテットのBIERアルゴリズム。値は、[RFC8401]で定義されている「BIER Algorithm」レジストリから割り当てられる。

IPA(IGPアルゴリズム): BAR値で定義された他のBFRに到達するためのアンダーレイ・パスの計算を変更、強化、または置換するために使用されるシングル・オクテットIGPアルゴリズム。値は、「IGP Algorithm Type」レジストリ[IANA-IGP]で定義されている。

各BFRサブドメインは、MT-IDで識別される1つだけのOSPFトポロジに関連付けられなければならない(MUST)。他のBFRがBIERサブTLVで広告するBIERサブドメインとOSPFトポロジの関連付けが、受信ルータ上でローカルに設定された関連付けと競合する場合、そのような競合するサブドメインのBIERサブTLVは無視しなければならない(MUST)。

[RFC4915]で規定されているようにMT-IDに無効な値が含まれている場合、競合するサブドメインのBIERサブTLVは無視しなければならない(MUST)。

BFRが複数のBIERサブTLVで同じサブドメインIDを広告する場合、BFRはそのようなサブドメインのBIERサブTLVを広告しなかったものとして扱われなければならない(MUST)。

すべてのBFRは、指定されたMT-IDとサブドメインIDに対して重複した有効なBFR-idの広告を検出しなければならない(MUST)。このような重複がBFRによって検出された場合、[RFC8279]のセクション5に記載されているように動作しなければならない(MUST)。

サポートされるBARおよびIPAアルゴリズムは、特定のBFRサブドメインをサポートするすべてのルータで一貫していなければならない。ルータがBARまたはIPAフィールドの値が、指定されたBFRサブドメインに対してローカルに設定された値と一致しないBIERサブTLV広告を受信した場合、ルータはそのようなBIERサブドメインの設定ミスを報告しなければならず(MUST)、エラーを含むBIERサブTLVを無視しなければならない(MUST) 。

BARフィールドまたはIPAフィールドのいずれかでのゼロ以外の値の使用することは、本文書の範囲外である

2.2. BIER MPLSカプセル化サブTLV

BIER MPLSカプセル化サブTLVは、BIERサブTLVのサブTLVである。BIER MPLSカプセル化サブTLVは、BIERに使用されるMPLS固有の情報を広告するために使用される。BIERサブTLV内に複数回出現してもよい(MAY)。

BIER MPLSカプセル化サブTLVのフォーマットは以下の通り:

fig2

タイプ: 10

長さ: 8オクテット

Max SI: このBitString長のBIERサブドメインのカプセル化に使用される最大のセット識別子(SI)([RFC8279]のセクション1を参照)を符号化する1オクテットのフィールド。

ラベル: 3オクテットのフィールドで、右端の20ビットがラベル範囲内の最初のラベルを表す。左端の4ビットは無視しなければならない(MUST)。

BS Len(BitString Length): このBFRプレフィックスに関連付けられたサポートされているBitString長を符号化する4ビットフィールド。このフィールドで許可される値は、[RFC8296]のセクション2で規定されている。

予約済み: 送信時には0に設定するべきであり(SHOULD)、受信時には無視しなければならない(MUST)。

「ラベル範囲」とは、ラベルで始まり(ラベル + (最大SI))で終わるラベル・セットである。BitString長とサブドメインIDごとにユニークなラベル範囲が割り当てられる。これらのラベルは、[RFC8279]と[RFC8296]で説明しているように、BIERのフォワーディングに使用される。

ラベル範囲のサイズは、ネットワークで使用されるSI([RFC8279]のセクション1)の数によって決まる。各SIは、ラベル範囲内の1つのラベル、最初のラベルはSI=0用、2番目のラベルはSI=1用などにマップされる。

最大のセット識別子に関連付けられたラベルが20ビットの範囲を超える場合、エラーを含むBIER MPLSカプセル化サブTLVは無視しなければならない(MUST)。

BitString長が[RFC8296]で指定されている許容値のいずれにも一致しない値に設定されている場合、エラーを含むBIER MPLSカプセル化サブTLVは無視しなければならない(MUST)。

同じBitString長が同じBIERサブTLV内の複数のBIER MPLSカプセル化サブTLVで繰り返される場合、競合を含むBIERサブTLV全体を無視しなければならない(MUST)。

同じBFRによって広告されるすべてのBIER MPLSカプセル化サブTLV内のラベル範囲は重複してはならない(MUST NOT)。重複が検出された場合、そのようなルータによって広告されたすべてのBIERサブTLVを無視しなければならない(MUST)。

⚠️ IS-ISとOSPF

	IS-IS	OSPF
TLV/LSA	TLV 135、235、236、237	OSPFv2 Extended Prefix Opaque LSA
サブTLV	BIER情報サブTLV	BIERサブTLV
サブサブTLV	BIER MPLSカプセル化サブサブTLV	BIER MPLSカプセル化サブTLV

2.3. BIER情報のフラッディング範囲

BIERサブTLVの広告に使用されるOSPFv2 Extended Prefix Opaque LSA [RFC7684]のフラッディング範囲はエリア・ローカルに設定されている。マルチエリア環境でBIERを展開できるようにするには、OSPFがエリア間でBIER情報を伝播する必要がある。

fig3
図1: エリア間のBIERの伝播

エリア間でBIER関連情報を伝播するには、以下の手順を使用する:

OSPFエリア・ボーダー・ルータ(ABR)が、エリア内またはエリア間プレフィックスからのタイプ3サマリーLSAをそのすべての接続エリアに広告するとき、[RFC7684]に記載されているように、OSPFv2 Extended Prefix Opaque LSAも発信される。OSPFv2 Extended Prefix Opaque LSAタイプのフラッディング範囲は、エリア・ローカルに設定される。OSPFv2 Extended Prefix TLVの経路タイプはエリア間に設定される。BIERサブTLVをこのLSAに含めるべきかどうかを決定するとき、OSPF ABRは以下のことを行う:

ソース・エリア内のプレフィックスへの最適パスを調べ、そのプレフィックスへの最適パスに関連付けられた広告ルータを見つける。

広告ルータがプレフィックスのBIERサブTLVを広告したかどうかを確認する。「Yes」の場合、ABRはBIERサブTLVを各接続エリアに広告するときに、そのBIERサブTLVの情報をコピーする。

図1では、R1はエリア1でプレフィックス192.0.2.1/32を広告している。また、プレフィックス192.0.2.1/32のOSPFv2 Extended Prefix Opaque LSAを広告し、その中にBIERサブTLVを含んでいる。ABR R2は、エリア1内のプレフィックス192.0.2.1/32の到達可能性を計算し、エリア0に伝播する。その際、エリア1のR1から受信したBIERサブTLV全体(すべてのサブTLVを含む)をコピーし、エリア0の192.0.2.1/32に対して生成するOSPFv2 Extended Prefix Opaque LSAに含める。ABR R3は、エリア0内のプレフィックス192.0.2.1/32の到達可能性を計算し、エリア2に伝播する。その際、エリア0のR2から受信したBIERサブTLV全体(すべてのサブTLVを含む)をコピーし、エリア2の192.0.2.1/32用に生成したOSPFv2 Extended Prefix Opaque LSAに含める。

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

本文書は、既存のOSPFv2 Extended Prefix TLVの新しいサブTLVを紹介する。OSPFに新たなセキュリティ・リスクが生じることはない。[RFC2328]および[RFC7684]で説明している既存のセキュリティ拡張能が適用される。

BIER層とOSPF層の両方が単一の管理ドメインの下にあることを前提としている。潜在的な攻撃者がOSPFルーティング・ドメイン内の1つ以上のネットワークにアクセスできる展開もあり得る。そのような展開では、[RFC7474]で規定されているような、より強力な認証メカニズムを使用する必要がある(SHOULD)。

[RFC8279]のセキュリティに関する考慮事項セクションでは、BIERでカプセル化されたパケットのBitStringに多くのビットを設定することで、サービス拒否(DoS)攻撃が実行される可能性について説明している。しかし、この種のDoS攻撃は、本文書で規定しているOSPF BIER広告を修正することで開始することはできない。BFIRは、BIERがカプセル化したパケットをどのシステムが受信するかを決定する。この決定を行う際、OSPF制御メッセージの影響を受けない。カプセル化を作成するとき、BFIRは宛先システムごとにカプセル化に1つのビットを設定する。OSPF BIER広告内の情報は、カプセル化内の各ビットを、そのビットで識別されるホストのネクストホップ・セットにマップするフォワーディング・テーブルを構築するために使用されるが、BFIRがどのビットをセットするかを決定するために、その情報を使用することはない。したがって、OSPFコントロール・プレーンに対する攻撃は、この種のDoS攻撃を引き起こすことはできない。

BIERカプセル化パケットがネットワークを通過する間、BitStringにnビットが設定されたBIERカプセル化パケットを受信したBFRは、パケットを複製して複数のコピーをフォワードする必要があるかもしれない。ただし、特定のビットはパケットの1つのコピーにのみ設定される。これは、受信したパケットの各送信レプリカは、受信パケットよりもセットされるビットが少ない(つまり、より少ない宛先をターゲットにしている)ことを意味する。これは、[RFC8279]で定義されているBIERフォワーディング・プロセスの重要な特性である。このプロセスに障害が発生すると、([RFC8279]のセキュリティに関する考慮事項セクションで説明されているように)DoS攻撃が発生する可能性があるが、そのような障害はOSPFコントロール・プレーンに対する攻撃では発生しない。

実装は、本文書で定義されているような不正な形式のBIERおよびBIER MPLSカプセル化サブTLVを確実に検出し、攻撃者がOSPFルータやルーティング・プロセスをクラッシュさせる脆弱性を提供しないようにしなければならない(MUST)。不正な形式のTLVやサブTLVの受信は、さらなる分析のためにカウントおよび/または記録するべきである(SHOULD)。不正な形式のTLVやサブTLVのロギングは、DoS攻撃(分散攻撃かそれ以外か)がOSPFコントロール・プレーンに過負荷をかけるのを防ぐために、レート制限すべきである(SHOULD)。

4. IANA に関する考慮事項

IANAは、[RFC7684]で定義している「OSPFv2 Extended Prefix TLV Sub-TLVs」レジストリから以下を割り当てている。

BIERサブTLV: 9

BIER MPLSカプセル化サブTLV: 10

⚠️ OSPFv2 Extended Prefix TLV Sub-TLVs

値	説明	参照先
0	予約	[RFC7684]
1	SID/Label Sub-TLV	[RFC8665]
2	Prefix-SID Sub-TLV	[RFC8665]
3	Flexible Algorithm Prefix Metric (FAPM)	[RFC9350, Section 9]
4	Prefix Source OSPF Router-ID	[RFC9084]
5	Prefix Source Router Address	[RFC9084]
6	OSPFv2 IP Algorithm Prefix Reachability	[RFC9502, Section 6.3]
7	OSPFv2 IP Forwarding Address	[RFC9502, Section 6.3.1]
8	Unassigned
9	BIER Sub-TLV	[RFC8444]
10	BIER MPLS Encapsulation Sub-TLV	[RFC8444]
11	OSPFv2 Prefix Attribute Flags (TEMPORARY - registered 2024-04-05, expires 2025-04-05)	[draft-ietf-lsr-ospf-prefix-extended-flags-02]
12-32767	Unassigned
32768-33023	Reserved for Experimental Use	[RFC7684]
33024-65535	Reserved	[RFC7684]

5. 参考文献

5.1. 引用規格

[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>.

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <https://www.rfc-editor.org/info/rfc4915>.

[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, <https://www.rfc-editor.org/info/rfc7474>.

[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>.

[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>.

[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>.

[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, <https://www.rfc-editor.org/info/rfc8296>.

[RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. Zhang, "Bit Index Explicit Replication (BIER) Support via IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, <https://www.rfc-editor.org/info/rfc8401>.

5.2. 参考規格

[IANA-IGP] IANA, "IGP Algorithm Types", <https://www.iana.org/assignments/igp-parameters/>.

謝辞

ラジブ・アサティ、クリスチャン・マーティン、グレッグ・シェパード、エリック・ローゼンの貢献に感謝する。

著者のアドレス

ピーター・プセナク (編集者)
Cisco
Apollo Business Center
Mlynske nivy 43
Bratislava 821 09
スロバキア
メール: ppsenak@cisco.com

ナゲンドラ・クマール
Cisco
7200 Kit Creek Road
Research Triangle Park, NC 27709
アメリカ合衆国
メール: naikumar@cisco.com

イースブランド・ワイナンズ
Cisco
De Kleetlaan 6a
Diegem 1831
ベルギー
メール:ice@cisco.com

アンドリュー・ドルガノウ
Nokia
750 Chai Chee Rd
06-06 Viva Business Park
Singapore 469004
シンガポール
メール: andrew.dolganow@nokia.com

トニー・プジジエンダ
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
アメリカ合衆国
メール: prz@juniper.net

ジェフリー・チャン
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
アメリカ合衆国
メール: zzhang@juniper.net

サム・オルドリン
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA
アメリカ合衆国
メール: aldrin.ietf@gmail.com

更新履歴

2024.5.4

GitHubで編集を提案

要旨