Zenn
🍣

RFC 6811: BGPプレフィックス発信元の検証

2024/03/01に公開
RFC
bgp
tech

要旨

プレフィックスの誤アナウンスや中間者攻撃など、BGPに対する既知の脅威を減らすためのセキュリティ要件の1つは、BGP経路の発信元自律システム(AS)を検証する機能である。具体的には、(BGP経路のAS_PATH属性から導き出される)アドレス・プレフィックスを発信していると主張するAS番号が、実際にプレフィックス保有者によって認可されていることを検証する必要がある。本文書では、この要件を部分的に満たすための簡単な検証メカニズムについて説明する。

本文書の位置付け

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

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

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

著作権表示

Copyright (c) 2013 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

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

1. はじめに

BGP経路は、アドレス・プレフィックスと、そのプレフィックスがBGPアナウンスの形式で通過したドメイン間パスを識別する自律システム(AS)の集合に関連付ける。この集合は、BGP[RFC4271]のAS_PATH属性として表され、プレフィックスを発信したASから始まる。プレフィックスの誤アナウンスや中間者攻撃など、BGPに対する既知の脅威を減らすための、セキュリティ要件の1つは、BGP経路の発信元ASを検証する機能である。具体的には、(BGP経路のAS_PATH属性から導き出される)アドレス・プレフィックスの発信元であると主張するAS番号が、実際にそのプレフィックスを発信することをプレフィックス保有者によって認可されていることを検証する必要がある。本文書では、この要件を部分的に満たすための簡単な検証メカニズムについて説明する。リソース公開鍵基盤(RPKI)は、IPアドレスとAS番号をリソースとして形式上に検証可能なデータベースを構築するアプローチを説明する。[RFC6480]で定義されているRPKIの全体的なアーキテクチャは、次の3つの主要コンポーネントで構成される。

  • 必要な証明書オブジェクトを持つ公開鍵基盤(PKI)、

  • デジタル署名されたルーティング・オブジェクト、そして

  • 定期的な取り出しもサポートするオブジェクトを格納する分散リポジトリ・システム。

RPKIシステムは、IPアドレスとAS識別子[RFC3779]を表すX.509の拡張を定義するリソース証明書に基づいている。したがって、RPKIという名前が付けられている。経路オリジン認可(ROA)[RFC6482]は、ASとIPアドレス・ブロック間の関連付けを定義する別のデジタル署名オブジェクトである。最後に、リポジトリ・システムは、IANA、地域インターネット・レジストリ(RIR)階層、およびISPを通じて分散方式で運用される。

RPKIシステムの利益を享受するには、ASレベルまたは組織レベルのいずれかのリライング・パーティー(RP)が、署名済みのオブジェクト・コレクションのローカルコピーを取得し、署名を検証し、処理することが想定されている。キャッシュも定期的に更新する必要がある。ローカルキャッシュを取得するために使用される正確なアクセス・メカニズムは、本文書の範囲外である。

個々のBGPスピーカーは、BGPアナウンスを検証するために、ローカルキャッシュに含まれる処理済みデータを利用できる。BGPスピーカーが、ローカルキャッシュから処理済みデータを取得するプロトコルの詳細は、この文書の範囲外である(そのようなメカニズムについては[RFC6810]を参照)。本文書では、BGPスピーカーが受信したBGP UPDATEメッセージの各プレフィックスに「検証状態」を割り当てるために、処理済みデータを利用できる手段を提案する。

経路のAS_PATH属性に対する完全なパス証明書は、本文書の範囲外であることに留意すること。

DNSと同様に、グローバルRPKIは、タイミング、更新、フェッチなどにより、緩く一貫性のあるビューのみを提示する。したがって、あるキャッシュやルータは、特定のプレフィックスに関して、別のキャッシュやルータとは異なるデータを持つ可能性がある。これに対する「修正」はない。これは、分散キャッシュを利用した分散データの性質である。

RPKIを本文書の文脈に基づいて説明するが、プレフィックスを認可されたオリジンASにマッピングできる他のデータベースを使用することも同様に可能である。各データベースには、それぞれ特有の運用上およびセキュリティ上の特徴を持つ。このような特徴については、本文書の範囲外である。

1.1. 要件言語

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、すべて大文字で表示される場合のみ、RFC 2119 [RFC2119]に記述されているように解釈される。また、特別な意味を持たずに、英単語として小文字または大文字が混在して表示されることもある。

2. Prefix-to-ASマッピング・データベース

BGPスピーカーは、検証済みオブジェクトをキャッシュからローカル・ストレージに読み込む。読み込まれたオブジェクトはコンテンツ(IPアドレス、プレフィックス長、最大長、オリジンAS番号)を持つ。このようなローカルに保存されたオブジェクトを「検証済みROAペイロード」または「VRP」と呼ぶ。

「VRP」以外にもいくつかの用語を定義する。これらの用語を使用する場合は大文字で始める。

  • Prefix (プレフィックス): (IPアドレス、プレフィックス長)、慣例に従って解釈される([RFC4632]を参照)。

  • Route (経路): [RFC4271]セクション1.1で定義されているように、受信したBGP UPDATEから得られたデータ。経路は1つのプレフィックスとAS_PATHを含む。プレフィックスを特徴付ける他の属性を含む場合がある。

  • VRPプレフィックス: VRPから得たプレフィックス。

  • VRP ASN: VRPから得たオリジンAS番号。

  • Route Prefix (経路プレフィックス): 経路から得られるプレフィックス。

  • Route Origin ASN (経路オリジンASN): 次のように経路から得られるオリジンAS番号:

    • 経路内のAS_PATH属性の最終セグメントの右端のAS(セグメントがAS_SEQUENCEタイプの場合)、または

    • セグメントがAS_CONFED_SEQUENCEまたはAS_CONFED_SETタイプの場合、またはAS_PATHが空の場合は、BGPスピーカー自身のAS番号、または

      • AS_PATH属性の最終セグメントが他のタイプの場合は、識別値「NONE」。

  • Coverd (カバー): VRPプレフィックス長が経路プレフィックス長以下であり、かつVRPプレフィックス・アドレスと経路プレフィックス・アドレスがVRPプレフィックス長で指定されたすべてのビットで同一である場合(つまり、経路プレフィックスはVRPプレフィックスと同一であるか、VRPプレフィックスよりもMore-Specific)、経路プレフィックスは VRPによってカバーされていると言う。

  • Matched (一致): 経路プレフィックスがVRPによってカバーされ、経路プレフィックス長がVRPの最大長以下であり、経路オリジンASNがVRP ASNと等しい場合、経路プレフィックスはVRPと一致するという。

これらの定義から、あるBGP経路は以下の検証状態のいずれかを持つことが分かる:

  • NotFound (不明): 経路プレフィックスをカバーするVRPが存在しない。

  • Valid (有効): 少なくとも1つのVRPが経路プレフィックスと一致する。

  • Invalid (無効): 少なくとも1つのVRPが、経路プレフィックスをカバーしているが、一致するVRPが存在しない。

どのVRPも、VRP ASNに値「NONE」を持つことができない。したがって、オリジンASNが「NONE」の経路は、どのVRPにも一致しない。同様に、オリジンASNがゼロ[AS0]の有効な経路は存在しない。したがって、ASNが0であるVRPと一致する経路は存在しない。

BGPスピーカーはネイバーからUPDATEを受信した場合、UPDATEメッセージ内の各経路について、上記の探索を実行する必要がある(SHOULD)。探索は、別のプロトコルやローカルで定義されたスタティック経路など、別のソースからBGPに再配布された経路にも適用する必要がある(SHOULD)。実装は、探索が適用される経路を制御するための設定オプションを提供してもよい(MAY)。経路の検証状態は、探索の結果を反映するように設定されなければならない(MUST)。実装は、この文書に記載されている検証状態を、経路のローカル・プロパティまたは属性として考慮する必要がある。経路上で検証が実行されない場合、実装はそのような経路の検証状態を「不明」に初期化する必要がある(SHOULD)。

検証状態の使用については、セクション3と5で説明する。実装は、明示的にそうするように設定されていない限り、経路をAdj-RIB-Inから除外したり、決定プロセスにおいて考慮から除外してはならない(MUST NOT)。

経路は複数のVRPに一致またはカバーされる可能性がある。この手順では、VRPにアクセスする順番を強制するものではない。しかし、検証状態のアウトプットは完全に決定される。

2.1. 疑似コード

以下の疑似コードは、上記の手順を示している。擬似コードが曖昧な場合は、コードではなく、上記手順を信頼できるものとして解釈する必要がある。

   result = BGP_PFXV_STATE_NOT_FOUND;

   //ローカルVRPデータベースpfx_validate_table内のすべてのカバー
   //エントリを反復処理する。
   entry = next_lookup_result(pfx_validate_table, route_prefix);

   while (entry != NULL) {
     prefix_exists = TRUE;

     if (route_prefix_length <= entry->max_length) {
       if (route_origin_as != NONE
           && entry->origin_as != 0
           && route_origin_as == entry->origin_as) {
         result = BGP_PFXV_STATE_VALID;
         return (result);
       }
     }
     entry = next_lookup_result(pfx_validate_table, input.prefix);
   }

   //経路プレフィックスをカバーするVRPエントリが1つ以上あるが、1つも一致
   //しない場合、「無効」検証状態を返す。
   if (prefix_exists == TRUE) {
     result = BGP_PFXV_STATE_INVALID;
   }

   return (result);
⚠️ オリジン検証のアルゴリズム

cfig1

3. ポリシー制御

実装は、経路ポリシー・フィルタリング機能の一部として、経路の検証状態を照合し、設定する機能を提供しなければならない(MUST)。経路ポリシーでの検証状態の使用については、セクション5で詳しく説明する。運用ポリシーに関する考慮事項の詳細については、[ORIGIN-OPS]を参照のこと。

実装は4オクテットのAS番号[RFC6793]もサポートしなければならない(MUST)。

4. ローカルキャッシュとのやり取り

本文書で説明するプレフィックス検証をサポートする各BGPスピーカーは、1つ以上のRPKIキャッシュと通信することが想定されており、それぞれのRPKIキャッシュはグローバルRPKIデータベースのローカルコピーを格納している。これらのデータを収集および検証し、BGPスピーカーに提示するために使用されるプロトコルのメカニズムは[RFC6810]に記載されている。

BGPスピーカーが使用するprefix-to-ASマッピングは、時間の経過とともに更新されることが予想される。マッピングが追加または削除されたとき、実装は影響を受けるプレフィックスを再検証し、必要に応じてBGP決定プロセスを実行しなければならない(MUST)。 「影響を受けるプレフィックス」とは、削除または更新されたマッピングと一致していたプレフィックス、あるいは追加または更新されたマッピングと一致する可能性のあるプレフィックスである。

5. 導入に関する考慮事項

経路が検証のために選択されると、セクション2で説明した手順に従って分類される。その後、セクション3で説明したルーティング・ポリシーを使用して、検証状態に基づいてアクションを実行できる。

実装可能なポリシーには、検証状態に基づいて経路をフィルタリング(例えば、すべての「無効な」経路を拒否する)や、検証状態に基づいて選択アルゴリズムにおける経路の優先度を調整することが含まれる。後者は、LOCAL_PREFのような属性の値を調整することで実現できる。BGP決定プロセスで無効な経路を考慮することは、純粋にローカル・ポリシーの問題であり、細心の注意を払って行う必要がある。

場合によっては(特に、選択アルゴリズムが内部BGP(IBGP)に伝播されない経路プロパティの調整によって影響を受ける場合)、IBGPピアに検証状態を伝播することがルーティングの正確性のために必要になる場合がある。これは、送信側では検証状態に基づいてコミュニティまたは拡張コミュニティを設定することで実現でき、受信側では(拡張)コミュニティを照合して検証状態を設定することで実現できる。

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

この仕様では、BGP経路を検証するシステムの一部について説明したが、検証情報を提供するためにデータベース(RPKIなど)に依存していることに注意する必要がある。そのため、ソリューション全体が提供するセキュリティを決定するには、そのデータベースのセキュリティ特性を考慮する必要がある。この仕様が示唆するように「無効な」経路がブロックされると、システム全体がサービス拒否ベクトルを引き起こす可能性がある。例えば、攻撃者が検証データベースに(または検証データベースから)1つ以上のレコードを挿入(または削除)できる場合、有効な経路が無効としてマークされる可能性がある。

さらに、このシステムは、断固たる攻撃者に対して限定的な保護しか提供できない。攻撃者は、このシステムが提供する保護を破るためには、偽造されたBGP経路アナウンスの先頭に「有効な」発信元ASを追加するだけで済む。

このメカニズムは、「AS-in-the-middle攻撃」からの保護も、パス検証も提供しない。発信元の検証のみを試みる。一般に、このシステムは強い意味での真の「セキュリティ」というよりも、誤った設定に対する保護として考えるべきである。

7. 謝辞

レックス・フェルナンド、ハンネス・グレドラー、ムーシン・グエンヌン、ラス・ハウスリー、ジュナイド・イスラール、ミヤ・コウノ、シン・ミヤカワ、タカ・ミライ、フセイン・ムフタ、キール・パテル、トモヤ・ヨシダ、カンナン・ヴァラダン、ウェス・ジョージ、ジェイ・ボーケンハーゲン、サンドラ・マーフィーに感謝する。SIDRワーキング・グループのメンバーからのフィードバックに感謝する。

ジュナイド・イスラールのこの仕様への貢献は、オタワ大学での博士課程の研究成果と論文の一部である。

8. 参考資料

8.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.

[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.

[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, December 2012.

8.2. 参考規格

[AS0] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 processing.", Work in Progress, August 2012.

[ORIGIN-OPS] Bush, R., "RPKI-Based Origin Validation Operation", Work in Progress, August 2012.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.

[RFC6810] Bush, R. and R. Austein, "The RPKI/Router Protocol", RFC 6810, January 2013.

著者のアドレス

プラドシュ・モハパトラ
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
アメリカ合衆国
メール: pmohapat@cisco.com

ジョン・スカダー
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
アメリカ合衆国
メール: jgs@juniper.net

デビッド・ウォード
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
アメリカ合衆国
メール: dward@cisco.com

ランディ・ブッシュ
インターネット・イニシアチブ・ジャパン
5147 Crystal Springs
Bainbridge Island, WA 98110
アメリカ合衆国
メール: randy@psg.com

ロブ・オースタイン
Dragon Research Labs
メール: sra@hactrn.net

変更履歴

  • 2024.3.1
GitHubで編集を提案

Discussion