🐚

RFC 7606: BGP UPDATEメッセージのエラー処理の改訂

2024/07/02に公開

RFC

bgp

tech

要旨

基本BGP仕様によると、不正な属性を含むUPDATEメッセージを受信したBGPスピーカーは、問題を引き起こす属性を受信したセッションをリセットする必要がある。セッションのリセットは、問題を引き起こす属性を持つ経路だけでなく、セッションで交換された他の有効な経路にも影響を与えるため、この動作は望ましくない。本文書は、UPDATEメッセージのエラー処理を部分的に改訂し、新しい属性を定義する文書の作成者のためのガイドラインを提供する。最後に、多くの既存属性のエラー処理手順を改訂する。

本文書は、RFC 1997、4271、4360、4456、4760、5543、5701、6368のエラー処理を更新する。

本文書の位置付け

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

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 5741のセクション 2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、<https://www.rfc-editor.org/info/rfc7606>で入手できる。

著作権表示

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

本文書には、2008年11月10日以前に公開または利用可能になったIETF文書またはIETF貢献の資料が含まれている場合がある。このような資料の著作権を管理する者は、IETF標準化過程外での変更を許可する権利をIETFトラストに付与していない可能性がある。このような資料の著作権を管理する人物から適切なライセンスを取得しない限り、この文書はIETF標準化過程外で変更することはできない。また、RFCとして公開するためにフォーマットしたり、英語以外の言語に翻訳する場合を除き、本文書の派生物をIETF標準化過程外で作成してはならない。

1. はじめに

基本BGP仕様[RFC4271]によると、不正な属性を含むUPDATEメッセージを受信したBGPスピーカーは、問題を引き起こす属性を受信したセッションをリセットする必要がある。セッションのリセットは、問題を引き起こす属性を持つ経路だけでなく、セッション上で交換された他の有効な経路にも影響を与えるため、この動作は望ましくない。任意推移型(optional transitive)属性の場合、この動作は特に厄介で、潜在的なセキュリティ上の脆弱性をもたらすかもしれない。これは、属性がその属性を認識しない中間ルータによってチェックされることなく伝播される可能性があるためである。実際には、属性がトンネル化される可能性がある。つまり、属性を認識してチェックするルータに到達したときに、リセットされたセッションは、障害のあるルータに関連付けられていないかもしれない。さらに悪いことに、このような場合、問題のある属性は1つのBGPスピーカーが送信した1つのアップデートから生じた可能性があるが、属性をチェックするルータに遭遇するまでに何度も複製され、多くのピアリング・セッションがリセットを引き起こす可能性がある。そのため、被害は何倍にも膨れ上がる可能性がある。

UPDATEメッセージのエラー処理を改訂する目的は、プロトコルの正確さを可能な限り維持しながら、不正なUPDATEメッセージによるルーティングへの影響を最小限に抑えることである。これは、確立されたセッションを維持し、有効な経路の交換を維持しながら、不正なUPDATEメッセージで伝送された経路をルーティング・システムから削除することで、ほぼ達成できる。

本文書では、UPDATEメッセージのエラー処理を部分的に改訂し、新しい属性を定義する文書の作成者向けのガイドラインを提供する。最後に、多くの既存の属性のエラー処理手順を改訂する。具体的には、[RFC1997]、[RFC4271]、[RFC4360]、[RFC4456]、[RFC4760]、[RFC5543]、[RFC5701]、[RFC6368]のエラー処理手順を改訂する。

💡 本RFCについて

このRFCは、以下の2つのドラフトがまとめられたものである。

draft-scudder-idr-optional-transitive
draft-chen-ebgp-error-handling

スカダーが指摘したのは、RFC 4271のエラー処理では、任意推移型属性にエラーがあるとセッションをリセットすると規定されているが、認識できないルータはエラーチェックができず、誤った属性が広範に伝播する。これにより、問題のあるルータがリモート・セッションをリセットする問題が発生する。解決策として、問題のなる属性を撤回として扱い、セッション・リセットを避ける方法を提案している。

チェンが指摘したのは、RFC 4271のエラー処理では、不正形式の属性があるとセッションをリセットするが、これは多くのネットワークに破壊的影響を与える。提案は、EBGPのUPDATEに対してセッションをリセットせず、不正形式の属性を撤回として扱う。NLRIフィールドを完全に解析し、BGPメッセージ・ヘッダの検証を行う。IBGPでは、「Treat-as-withdraw」は安全ではなく、エラーハンドリングは変更しない。これにより、影響範囲を最小限にし、プロトコルの正確性を維持する。

この2つがまとめられた。セッション・リセットはEBGPとIBGPの両方に対して破壊的であり、良い経路と悪い経路を区別しません。エラーハンドリングは経路レベルで行い、セッション・リセットの代わりに「Treat-as-withdraw」や「属性破棄」を使用して影響を最小限に抑える。属性フラグのエラーはローカルで修正し、セッション・リセットは不要。IBGPでは、問題の経路を特定し、イングレス・ルータでフィルタを適用することを推奨する。

1.1.要件言語

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119[RFC2119]の記述にしたがって解釈される。

2. エラー処理のアプローチ

本文書では、BGP UPDATEメッセージで見つかったエラーを処理する、以下の4つの異なるアプローチを言及する。これらは以下の通りである(「最も強い」アクションから「最も弱い」アクションの順にリストされている):

セッション・リセット: これは、BGPの基本仕様[RFC4271]全体で使われているアプローチで、NOTIFICATIONが送信され、セッションを終了する。
AFI/SAFIの無効化: [RFC4760]のセクション7では、特定のAFI/SAFIに対するメッセージのエラーを検出したBGPスピーカーが、オプションとして「そのセッション上で受信したそのAFI/SAFIを持つ後続のすべての経路を無視する」ことを許可している。これを「特定のAFI/SAFIの無効化」または「AFI/SAFIの無効化」と呼ぶ。
Treat-as-withdraw (撤回として扱う): このアプローチでは、問題のパス属性を含むUPDATEメッセージは、UPDATEメッセージのWITHDRAWN ROUTESフィールド(または適切な場合、MP_UNREACH_NLRI属性)にリストされているものと同じように、含まれるすべての経路が撤回されたものとして扱われなければならず(MUST)、その結果、[RFC4271]の手順に従ってAdj-RIB-Inから削除される。
属性破棄(Attribute discard): このアプローチでは、不正な属性は破棄しなければならず(MUST)、UPDATEメッセージは処理を継続する。このアプローチは、経路の選択やインストールに影響を与えない属性の場合を除き、使用してはならない(MUST NOT)。

3. BGP UPDATEメッセージのエラー処理の改訂

本仕様は、[RFC4271]のセクション6.3を多くの点で修正する。特定のパス属性の処理については、セクション7を参照のこと。

a. 最初の段落は以下のように修正する:

古い文章:

UPDATEメッセージの処理中に検出されたすべてのエラーは、エラーコードUPDATEメッセージ・エラーを含むNOTIFICATIONメッセージを送信することで示さなければならない(MUST)。エラー・サブコードは、エラーの具体的な性質について詳しく説明する。

新しい文章:

セッション・リセットが指定されているUPDATEメッセージの処理中に検出されたエラーは、エラーコードUPDATEメッセージ・エラーを含むNOTIFICATIONメッセージを送信することによって示さなければならない(MUST)。エラー・サブコードは、エラーの具体的な性質について詳しく説明する。

b. 以下の場合のエラー処理に変更はない:

撤回経路長または合計属性長が大きすぎる場合(つまり、撤回経路長 + 合計属性長 + 23がメッセージ長を超える場合)、エラー・サブコードは不正な属性リストに設定しなければならない(MUST)。

c. 属性フラグのエラー処理を以下のように変更する:

古い文章:

認識された属性が属性タイプコードと競合する属性フラグを持つ場合、エラー・サブコードは属性フラグ・エラーに設定しなければならない(MUST)。データ・フィールドは、エラーのある属性(タイプ、長さ、値)を含まなければならない(MUST)。

新しい文章:

属性フラグのオプション・ビットまたは推移ビットのいずれかの値が、指定された値と矛盾している場合、属性の仕様が不正な属性フラグに対して異なる処理を義務付けていない限り、その属性は不正な形式として扱われ、「Treat-as-withdraw」アプローチを使用しなければならない(MUST)。

d. 周知必須(well-known mandatory)属性のいずれかがUPDATEメッセージに存在しない場合、「Treat-as-withdraw」を使用しなければならない(MUST)。([RFC4760]では、NEXT_HOPが実質的に任意のものとして再分類していることに留意する。)

e. セッション・リセットを指定し、属性ORIGIN、AS_PATH、NEXT_HOP、MULTI_EXIT_DISC、LOCAL_PREFのいずれかの属性が関係する場合は、「Treat-as-withdraw」を使用しなければならない。

f. セッション・リセットを指定し、属性ATOMIC_AGGREGATEまたはAGGREGATORが関係する場合は、「属性破棄」を使用しなければならない(MUST)。

g. MP_REACH_NLRI属性またはMP_UNREACH_NLRI[RFC4760]属性が、UPDATEメッセージに複数回出現する場合、エラー・サブコード「Malformed Attribute List」を含むNOTIFICATIONメッセージを送信しなければならない(MUST)。他の属性(認識されているかどうかに関係なく)がUPDATEメッセージに複数回出現する場合、最初の属性以外のすべての属性は破棄しなければならず(SHALL)、UPDATEメッセージは処理を継続する。

h. UPDATEメッセージに複数の属性エラーが存在する場合、これらの不正な属性の処理に同じアプローチ(セクション2で説明)が指定されていれば、指定されたアプローチを使用しなければならない(MUST)。そうでなければ、最も強力なアクションを持つアプローチを使用しなければならない(MUST)。

i. 撤回経路フィールドは、NLRIフィールドと同じ方法で構文の正確性をチェックしなければならない(MUST)。これについては、以下およびセクション5.3で詳しく説明する。

j. 最後に、「Treat-as-withdraw」アプローチを使用するには、NLRIフィールド全体及び/またはMP_REACH_NLRI属性とMP_UNREACH_NLRI属性が正常に解析する必要があることに従う。これに伴う内容については、セクション5で詳しく説明する。これが不可能な場合は、[RFC4271]及び/または[RFC4760]の手順が引き続き適用される。つまり、「セッション・リセット」アプローチ(または「AFI/SAFIの無効化」アプローチ)に従わなければならない(MUST)。

4. 属性長フィールド

合計属性長の値が、属性自体が長さの値を持つ同封されたパス属性と衝突する可能性のあるエラーケースが2つある:

最初のケースでは、最後に遭遇したパス属性の長さが、同封されたパス属性を解析する際に合計属性長を超える原因となる。
2番目のケースでは、属性の解析を開始するとき、残っているオクテットは3オクテット未満(または、属性フラグ・フィールドに拡張された長さ(Extended Length)ビットが設定されている場合は4オクテット未満)である。つまり、パス属性に未使用のデータが残っているが、最小サイズのパス属性を符号化するにはデータが不十分な場合に、このケースが発生する。

どちらのケースも、エラー状態が存在するので、「Treat-as-withdraw」アプローチを使用しなければならない(MUST)(より強力なアプローチを指示する他の、より深刻なエラーが発生した場合を除く)。そして、合計属性長は、NLRIフィールドの先頭を特定できるようにするために信頼しなければならない(MUST)。

属性長がゼロの可能性があると指定された属性以外のすべてのパス属性は、属性長がゼロの場合は構文エラーと見なさなければならない(SHALL)。この仕様で考慮されているパス属性のうち、AS_PATHとATOMIC_AGGREGATEだけが、属性長ゼロを持つことができる。

5. ネットワーク層到達可能性情報(NLRI)フィールドの解析

5.1. NLRIの符号化

不正な属性を持つUPDATEメッセージのNLRIフィールドの判別を容易にするには:

MP_REACH_NLRIまたはMP_UNREACH_NLRI属性(存在する場合)は、UPDATEメッセージの真に最初のパス属性として符号化しなければならない(SHALL)。
UPDATEメッセージには、空でない撤回経路フィールド、空でないネットワーク層到達可能性情報フィールド、MP_REACH_NLRI属性、MP_UNREACH_NLRI属性のうち1つ以上を含んではならない(MUST NOT)。

古いBGPスピーカーはこれらの制限を実装していない可能性があるため、実装はこれらのフィールドを任意の位置または組み合わせで受信できるように準備しておかなければならない(MUST)。

[RFC4271]の符号化を使用する場合、IPv4ユニキャスト・アドレス・ファミリーのNLRIフィールドは、UPDATEメッセージ内のすべての属性の直後に伝送される。このようなUPDATEメッセージを受信した場合、NLRIフィールドは、メッセージ内の個々の属性の長さに頼るのではなく、メッセージで伝送されるメッセージ長、撤回経路長、合計属性長(これらが一致している場合)を使用して決定できる場合がある。

5.2. NLRIの欠落

[RFC4724]は、NLRIを符号化しないMP_UNREACH_NLRI属性のみを含むUPDATEメッセージとして符号化できるEnd-of-RIB(EoR)メッセージを規定している(「レガシーな」符号化の場合、完全に空のUPDATEメッセージになることもある)。他の適切に指定されたケースでは、UPDATEメッセージは、撤回経路のみを伝えるか(撤回経路フィールドまたはMP_UNREACH_NLRI属性のいずれか)、または到達可能な経路を通知する(ネットワーク層到達可能性情報フィールドまたはMP_REACH_NLRI属性のいずれか)。

したがって、MP_UNREACH_NLRI以外のパス属性を含み、到達可能なNLRIを符号化していないUPDATEメッセージが検出された場合、セクション3 (j)で要求しているように、NLRIが正常に解析されたことを確信することはできない。そのため、このようなUPDATEメッセージでパス属性エラーが検出され、検出されたエラーが「属性破棄」以外のエラー処理方法を指定している場合、「セッション・リセット」アプローチを使用しなければならない(MUST)。

5.3. NLRIフィールドの構文の正確性

NLRIフィールドまたは撤回経路フィールドは、以下のいずれかが当てはまる場合、「構文的に正しくない」とみなさなければならない(SHALL)。

含まれるNLRIのいずれかの長さが32より大きい。
フィールドに含まれるNLRIを解析するとき、最後に見つかったNLRIの長さが、フィールドに残っている未使用データの量を超えている。

同様に、アップデートのMP_REACH_NLRIまたはMP_UNREACH_NLRI属性は、以下のいずれかが当てはまる場合、不正と見なされる。

含まれるNLRIのいずれかの長さが、指定されたAFI/SAFIと一致しない(例えば、IPv4 NLRIの長さが32より大きい場合、またはIPv6 NLRIの長さが128より大きい場合)。
属性に含まれるNLRIを解析するとき、最後に見つかったNLRIの長さが、属性に残っている未使用データの量を超えている。
属性の属性フラグが[RFC4760]で規定するものと矛盾している。
MP_UNREACH_NLRI属性の長さが3未満か、MP_REACH_NLRI属性の長さが5未満である。

5.4. タイプ付きNLRI

MCAST-VPN[RFC6514]、MCAST-VPLS [RFC7117]、EVPN [RFC7432]などの特定のアドレス・ファミリーには、タイプ付きNLRIがある。アドレス・ファミリー内でサポートされているタイプ値は、マルチプロトコル BGP(MP-BGP)ケイパビリティ[RFC4760]で表現されないため、BGPスピーカーは、アドレス・ファミリーとサブアドレス・ファミリーのサポートを広告できるが、そのAFI/SAFI内の特定のタイプのNLRIをまだサポートしていない。

このようなタイプ付きアドレス・ファミリーのサポートを広告しているBGPスピーカーは、そのアドレス・ファミリーの関連仕様で別途指定がない限り、そのアドレス・ファミリーの中で認識されないNLRI タイプを持つ経路を破棄して処理しなければならない(MUST)。

6. 運用上の考慮事項

セクション2で定義されている「Treat-as-withdraw」エラー処理動作は、BGPの正確性を維持するためにあらゆる努力を払っているが、内部BGP(IBGP)セッションで受信したUPDATEメッセージがこの処理の対象となった場合、影響を受ける自律システム内で一貫性のないルーティングが発生する可能性があることに留意する。一貫性のないルーティングの結果、長時間の転送ループやブラックホールが発生する可能性がある。残念だが、この問題は実際にはほとんど起こらないと予想され、さらに重要なことに、セッション・リセットを置き換える動作よりも問題が少ないと考えられている。

IBGPセッション上で実際に不正な属性が検出された場合、その不正な属性を持つ経路を特定し、経路が外部から発信または受信されたネットワーク内のイングレス・ルータまでさかのぼって追跡し、イングレス・ルータにフィルタを適用して、その経路が発信または受信されないようにすることを推奨する。これにより、ネットワーク内のルーティングの一貫性を保つことができる。

一貫性のないルーティングが発生しない場合でも、「Treat-as-withdraw」動作により、影響を受けるUPDATEメッセージで経路が伝送される宛先に対して、完全に到達不能になるか、ルーティングが最適ではなくなる可能性がある。

「Treat-as-withdraw」動作は、UPDATEメッセージの破棄とは異なることに留意すること。後者は、基本的なBGP原則である増分更新に違反し、無効な経路が保持される可能性がある。

このような潜在的な問題があるため、BGPスピーカーは不正な属性に起因する問題を診断できるように、デバッグ機能を提供しなければならない。少なくとも、このような機能には、そのような属性が検出されたときに、関連するNLRIをリストアップし、不正形式のUPDATEメッセージ全体を含むエラーをログに記録することが含まれなければならない。不正形式のUPDATEメッセージを分析し、根本原因を調査する必要がある。

セクション8では、「問題の属性が経路選択に影響を及ぼす、または影響を及ぼす可能性がある」場合には「属性破棄」を使用すべきではないと述べている。本文書で「属性破棄」を指定しているすべてのケースは、デフォルトでは経路選択に影響を与えないが、原則として、そのような属性に基づく選択に影響を与えるルーティング・ポリシーを記述できる。オペレータは、そのようなポリシーを記述するときに、属性破棄の起こり得る結果を考慮する必要がある。一般に、そのようなポリシーが外部BGPセッションにのみ適用される限り、正確性の問題は発生しないと想定される。

7. 既存の属性に対するエラー処理手順

以下のサブセクションでは、さまざまなパス属性のエラーチェックの条件について詳しく説明し、不正な形式を処理するためにどのようなアプローチを使用すべきかを指定する。実装がここで考慮されていない他のエラーチェックを適用する可能性もある。その場合、一般的には、ここで示したエラー処理のアプローチを適用する必要がある。

このセクションでは、セクション8に準拠したエラー処理で定義されておらず、「BGPパス属性」レジストリ[IANA-BGP-ATTRS]で「非推奨」としてマークされていない、本文書の執筆時点で定義されているすべてのパス属性を説明する。属性17(AS4_PATH)、18(AS4_AGGREGATOR)、22(PMSI_TUNNEL)、23(トンネル・カプセル化属性)、26(AIGP)、27(PE識別子ラベル)、及び29(BGP-LS属性)は、セクション8に準拠したエラー処理があるため、ここではこれ以上説明しない。属性11(DPA)、12(ADVERTISER)、13(RCID_PATH / CLUSTER_ID)、19(SAFI固有属性)、20(コネクタ属性)、21(AS_PATHLIMIT)、及び28(BGPエントロピー・ラベル機能属性)は非推奨であるため、ここではこれ以上説明しない。

7.1. ORIGIN

属性の長さが1でない場合、または値が未定義の場合、属性は不正形式と見なされる[RFC4271]。

不正形式のORIGIN属性を持つUPDATEメッセージは、「Treat-as-withdraw」のアプローチを使って処理しなければならない(SHALL)。

7.2. AS_PATH

認識されないセグメント・タイプを検出した場合、または不正形式のセグメントを含む場合、AS_PATHは不正形式と見なされる。以下のいずれかが当てはまる場合、セグメントは不正形式とみなされる。

最後に遭遇したセグメントのパス・セグメント長フィールドが属性長が超過するオーバーランが発生する。
最後に正常に解析されたセグメントの後に、1オクテットしか残っていない(つまり、空のセグメント・ヘッダを提供するのに十分な未使用データがない)アンダーランが発生する。
パス・セグメント長フィールドが0である。

不正なAS_PATH属性を持つUPDATEメッセージは、「Treat-as-withdraw」アプローチを使用して処理しなければならない(SHALL)。

[RFC4271]は、実装がオプションで「AS_PATH属性の左端の ... ASが、メッセージを送信したピアの自律システム番号と等しいかどうかをチェックしてもよい(MAY)」とも述べている。BGP実装はこのチェックに違反する経路も、「Treat-as-withdraw」を使用して処理する必要がある(SHOULD)が、そのように設定されていれば「セッション・リセット」動作に従ってもよい(MAY)。

7.3. NEXT_HOP

属性の長さが4でない場合、その属性は不正とみなされる[RFC4271]。

不正なNEXT_HOP属性を持つUPDATEメッセージは、「Treat-as-withdraw」アプローチを使用して処理しなければならない(SHALL)。

7.4. MULTI_EXIT_DISC

属性の長さが4でない場合、その属性は不正とみなされる[RFC4271]。

不正なMULTI_EXIT_DISC属性を持つUPDATEメッセージは、「Treat-as-withdraw」アプローチを使用して処理しなければならない(SHALL)。

7.5. LOCAL_PREF

[RFC4271]のエラー処理は以下のように修正する:

LOCAL_PREF属性を外部ネイバーから受信した場合、「属性破棄」アプローチを使用して破棄しなければならない(SHALL)。または
内部ネイバーから受信した場合、長さが4でない場合は不正とみなされる。不正な場合は、UPDATEメッセージは「撤回として扱う」アプローチを使用して処理しなければならない(SHALL)。

7.6. ATOMIC_AGGREGATE

属性の長さが0でない場合、不正とみなさなければならない(SHALL)[RFC4271]。

不正なATOMIC_AGGREGATE属性を持つUPDATEメッセージは、「属性破棄」アプローチを使用して処理しなければならない(SHALL)。

7.7. AGGREGATOR

[RFC4271]で属性に対して指定されているエラー条件は、以下のように修正する:

AGGREGATOR属性は、以下のいずれかに該当する場合は不正とみなされる:

長さが6ではない(4オクテットのAS番号ケイパビリティがピアに広告されないか、ピアから受信されない場合[RFC6793])。
長さが8ではない(4オクテットのAS番号ケイパビリティがピアに広告され、ピアから受信される場合)。

不正な形式のAGGREGATOR属性を持つUPDATEメッセージは、「属性破棄」のアプローチを使用して処理しなければならない(SHALL)。

7.8. コミュニティ

[RFC1997]のエラー処理は以下のように修正する:

コミュニティ属性は、その長さが4のゼロ以外の倍数でない場合、不正な形式であるとみなさなければならない(SHALL)。
不正な形式のコミュニティ属性を持つUPDATEメッセージは、「Treat-as-withdraw」のアプローチを使用して処理しなければならない(SHALL)。

7.9. ORIGINATOR_ID

[RFC4456]のエラー処理は以下のように修正する:

ORIGINATOR_ID属性が外部ネイバーから受信した場合、「属性破棄」のアプローチを使用して破棄しなければならない(SHALL)。または
内部ネイバーから受信した場合、長さが4でない場合は不正形式とみなさなければならない(SHALL)。不正形式の場合、UPDATEメッセージは「撤回として扱う」アプローチを使用して処理しなければならない(SHALL)。

7.10. CLUSTER_LIST

[RFC4456]のエラー処理は以下のように修正する:

CLUSTER_LIST属性が外部ネイバーから受信した場合、属性は「属性破棄」アプローチを使用して破棄しなければならない(SHALL)。または
内部ネイバーから受信した場合、長さが4のゼロ以外の倍数でない場合は不正形式とみなさなければならない(SHALL)。不正形式の場合、UPDATEメッセージは「Treat-as-withdraw」アプローチを使用して処理しなければならない(SHALL)。

7.11. MP_REACH_NLRI

MP_REACH属性のネクストホップ・ネットワーク・アドレス・フィールドの長さが、期待されたものと一致しない場合、その属性は不正形式とみなされる。属性内のNLRIフィールドの前にネクストホップがあるため、この場合、NLRIを確実に見つけることはできない。したがって、「セッション・リセット」または「AFI/SAFI 無効化」アプローチを使用しなければならない(MUST)。

「予期されたもの」とは、多少曖昧だが、アドレス・ファミリー識別子と後続アドレス・ファミリー識別子フィールドで指定されたネクストホップを包含することを意図しており、使用中の拡張によって修正される可能性がある。例えば、[RFC5549]が使用されている場合、ネクストホップの長さは4または16でなければならない。

セクション3と5で、この属性の扱いについてさらに説明している。

7.12. MP_UNREACH_NLRI

セクション3と5で、この属性の扱いについて説明する。

7.13. トラフィック・エンジニアリング・パス属性

私たちは、[RFC5543]がトラフィック・エンジニアリング・パス属性の「不正」を構成する要素について詳しく説明していないことに留意する。この仕様の将来の更新で、より詳細な指針が示されるかもしれない。当面は、UPDATEメッセージに不正なトラフィック・エンジニアリング・パス属性が含まれていると(何らかの理由で)判断した実装は、「Treat-as-withdraw」アプローチを使用してそれを処理しなければならない(MUST)。

7.14. 拡張コミュニティ

[RFC4360]のエラー処理は以下のように修正する:

拡張コミュニティ属性は、その長さが8のゼロ以外の倍数でない場合は不正であるとみなさなければならない(SHALL)。
拡張コミュニティ属性が不正なUPDATEメッセージは、「Treat-as-withdraw」アプローチを使用して処理しなければならない(SHALL)。

BGPスピーカーは認識できない拡張コミュニティ・タイプまたはサブタイプをエラーとして処理してはならない(MUST NOT)ことに留意する。

7.15. IPv6アドレス固有のBGP拡張コミュニティ属性

[RFC5701]のエラー処理は以下のように修正する:

IPv6アドレス固有の拡張コミュニティ属性は、その長さが20の0以外の倍数でない場合、不正とみなさなければならない(SHALL)。
不正なIPv6アドレス固有の拡張コミュニティ属性を持つUPDATEメッセージは、「撤回として扱う」アプローチを使用して処理しなければならない(SHALL)。

BGPスピーカーは、認識できないIPv6アドレス固有拡張コミュニティ・タイプまたはサブタイプをエラーとして扱ってはならない(MUST NOT)ことに留意する。

7.16. ATTR_SET

[RFC6368]のセクション5の最終段落を以下のように修正する:

旧テキスト:

不正なATTR_SET属性を持つUPDATEメッセージは、以下のように処理しなければならない(SHALL)。その部分フラグが設定され、近隣完了フラグがクリアされている場合、UPDATEメッセージは、[OPT-TRANS-BGP]で説明されているように、経路撤回として扱われる。そうではない場合(つまり、部分フラグがクリアされているか、近隣完了フラグが設定されている場合)、オプション属性エラーに関しては、BGP-4基本仕様[RFC4271]の手順に従わなければならない(MUST)。

新テキスト:

不正なATTR_SET属性を持つUPDATEメッセージは、「Treat-as-withdraw」アプローチを使用して処理しなければならない(SHALL)。

さらに、[RFC6368]の[OPT-TRANS-BGP]への引用規格を削除した。

8. BGP仕様の作成者向けのガイダンス

新しいBGP属性を規定する文書は、何がその属性のエラーを構成し、要素とそのエラーがどのように処理されるかに関する詳細を提供しなければならない(MUST)。許容されるエラー処理アプローチはセクション2で詳しく説明している。「Treat-as-withdraw」アプローチが一般的に望ましく、「セッション・リセット」アプローチは推奨されない。BGP文書の作成者は、この文書の「はじめに」の最初の段落にある任意推移型属性に関する説明も確認する必要がある。本文書はまた、不正な属性に起因する問題を診断できるようにするために、どのようなデバッグ機能が必要であるかについての考察を提供する必要がある(SHOULD)。

「Treat-as-withdraw」アプローチではなく、「属性破棄」アプローチで処理される不正な属性については、そうすることの潜在的な影響を考慮することが重要である。特に、問題の属性が経路選択やインストールに影響を及ぼしているか、及ぼす可能性がある場合、慎重な分析によってそうではないことが証明されない限り、その属性を破棄することは安全ではないと推定される。分析では、接続性の維持と潜在的な副作用との間のトレードオフを考慮に入れる必要がある。

例についてはセクション7を参照のこと。

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

この仕様は、遠距離の攻撃者が、間にあるルータに認識されない不正な任意推移型属性を生成することができる潜在的な攻撃に対するBGPスピーカーの脆弱性に対処する。間にあるルータはその属性を認識しないため、チェックせずに伝播する。不正な属性が、指定された属性タイプを認識するルータに到着すると、そのルータは、その属性が到着したセッションをリセットする。攻撃者と属性タイプを認識するルータとの間で大きなファンアウトが発生する可能性があるため、この攻撃は特に有害の可能性がある。

この仕様の改善されたエラー処理は、将来BGPを保護するために、このようなメカニズムが使用される場合、理論的には、現在知られているより弱い暗号メカニズムと悪い相互作用を及ぼす可能性がある。例えば、データの完全性を提供しない(架空の)メカニズムが使用された場合、攻撃者は受信者の反応を変更したり、監視したりするために、暗号文を操作することができる。この仕様があることで、BGPセッションは終了していただろう。この仕様があれば、攻撃者は潜在的に何度も試行することができる。このような機密性のみのメカニズムは現在定義されることはないだろうが、過去には、同様の脆弱性を明らかに悪用できるわけではないものの、そのような結果をもたらすメカニズムの定義があった[RFC7366]。このような問題を回避するために現在推奨されているアプローチは、認証付き暗号(AEAD)[RFC5116]の使用を優先し、検証できないメッセージを破棄することである。

その他の点では、この仕様はBGPのセキュリティ特性を変更するものではない。

10. 参考文献

10.1. 引用規格

[IANA-BGP-ATTRS] IANA, "BGP Path Attributes", <http://www.iana.org/assignments/bgp-parameters>.

[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.

[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <http://www.rfc-editor.org/info/rfc4456>.

[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <http://www.rfc-editor.org/info/rfc4724>.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.

[RFC5543] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP Traffic Engineering Attribute", RFC 5543, DOI 10.17487/RFC5543, May 2009, <http://www.rfc-editor.org/info/rfc5543>.

[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, <http://www.rfc-editor.org/info/rfc5701>.

[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. Yamagata, "Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 6368, DOI 10.17487/RFC6368, September 2011, <http://www.rfc-editor.org/info/rfc6368>.

[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.

10.2. 参考規格

[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.

[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, DOI 10.17487/RFC5549, May 2009, <http://www.rfc-editor.org/info/rfc5549>.

[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.

[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, <http://www.rfc-editor.org/info/rfc7117>.

[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, <http://www.rfc-editor.org/info/rfc7366>.

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-editor.org/info/rfc7432>.

謝辞

ファン・アルカイデ、デニズ・バハディル、ロン・ボニカ、マッハ・チェン、アンディ・デヴィッドソン、ブルーノ・デクレーヌ、スティーブン・ファレル、レックス・フェルナンド、ジェフ・ハース、クリス・ホール、ジョエル・ハルパーン、ドン・ジエ、加藤朗、河野美也、ウォーレン・クマリ、トニー・リー、アルトン・ロー、宮川晋、タマス・モンダル、ジョナサン・オディ、トニー・プリジーエンダ、ロバート・ラズスク、ヤコフ・レクター、エリック・ローゼン、シャム・セスラム、ロブ・シャキール、シェン・ナイミン、アダム・シンプソン、アナンス・スリヤナーラーヤナ、カリラジ・ヴァイラヴァッカライ、リリ・ワン、オンドレイ・ザジチェクには、このトピックに関する観察と議論、及びこの文書へのレビューに感謝する。

著者のアドレス

エンケ・チェン (編集者)
Cisco Systems, Inc.
メール: enkechen@cisco.com

ジョン・G・スカダー (編集者)
Juniper Networks
メール: jgs@juniper.net

プラドシュ・モハパトラ
Sproute Networks
メール: mpradosh@yahoo.com

キール・パテル
Cisco Systems, Inc.
メール: keyupate@cisco.com

更新履歴

2024.7.2

GitHubで編集を提案

要旨