RFC 8481: リソース公開鍵基盤(RPKI)に基づくBGPオリジン検証の明確化
要旨
リソース公開鍵基盤(RPKI)に基づくBGPオリジン検証の展開は、どの経路が検証されるのか、そして設定が指定されていない場合にポリシーを適用するのかという2つの重要な部分に関するベンダーの誤った実装によって阻まれている。この文書は、このような誤った実装の原因となり得る誤解を明確にすることを目的としている。すべてのプレフィックスに検証状態を設定する必要があること、オペレータの設定なしにポリシーを適用してはならないことを明確にすることで、RFC 6811を更新する。
本文書の位置付け
本文書はインターネット標準化過程の文書である。
本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。
文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc8481 で入手できる。
著作権表示
Copyright (c) 2018 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。
本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。
1. はじめに
RPKIベースのBGPオリジン検証の展開は、特に、どの経路が検証されるのか、そして設定において指定されていない場合にポリシーが適用されるのかという2つの重要な部分に関するベンダーの誤った実装によって阻まれている。この文書は、こうした誤った実装の原因となっている誤解を明確にすることを目的としている。
経路がBGPに配布されると、[RFC6811]に従って発信元の検証状態が不明(NotFound)、有効(Valid)、無効(Invalid)に設定される。このRFCの仕様では、実装のばらつきを回避するには不十分であることが、運用テストによって明らかとなった。本文書では、混乱を引き起こすと思われる2つの部分を明確にすることを試みる。
実装の問題は、検証方法、つまり経路が不明(NotFound)、有効(Valid)、無効(Invalid)のいずれかを判断する方法に関するものではないようだ。問題は、どの経路を評価して、その評価状態を持つ必要があるのか、オペレータの設定なしにポリシーを適用するかどうかということである。
2. 要件言語
この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。
3. 推薦文献
読者は、BGP[RFC4271]、RPKI[RFC6480]、経路オリジン認可(ROA) [RFC6482]、およびRPKI ベースのプレフィックス検証 [RFC6811]を理解しているものとする。
4. すべてのプレフィックスを評価する
重要な明確化: ルータは、オペレータによって明確に設定されない限り、あらゆるソース(eBGP、iBGP、またはスタティック経路やコネクティッド経路からの再配布など)から届くBGP内のすべての経路の検証状態を評価し、設定しなければならない(MUST)。さもなければ、オペレータは、すべての潜在的なソースから届く無効な経路をドロップする能力を持っておらず、したがって、無効な経路の伝播に関するネイバーからの苦情を受ける可能性がある。このような理由から、FAQ[RFC6811]は次のように述べている:
BGPスピーカーはネイバーからUPDATEを受信すると、UPDATEメッセージの各経路に対して、上記のルックアップを実行する必要がある(SHOULD)。このルックアップは、別のプロトコルやローカルに定義されたスタティック経路など、別のソースからBGPに再配布された経路にも適用する必要がある(SHOULD)。
[RFC6811]は続けて、「実装は、ルックアップがどの経路に適用されるかを制御するための設定オプションを提供してもよい(MAY)」と述べている。
任意のソース(IGP、iBGP、またはスタティックまたはコネクテッド経路など)からBGPに再配布する場合、発信元の自律システム(AS)のRPKI検証を可能にするAS_PATHが入力にはない。このような場合、ルータはルータのBGP設定のASを使用しなければならない(MUST)。コンフェデレーション、ASマイグレーション、または他のマルチAS構成によって、それが曖昧な場合、ルータの設定は、再配布ごとにまたはグローバルに、再配布で使用するASを指定する手段を提供しなければならない(MUST)。
5. Set State, Don't Act
重要な明確化: 経路が評価され、その状態が設定されると、オペレータは評価状態に基づいて適用されるポリシーを完全にコントロールする必要がある。特定のオペレータ設定がない限り、ポリシーを適用してはならない(MUST NOT)。
「BGPプレフィックス・オリジン検証状態拡張コミュニティ」[RFC8097]で説明されているような自動オリジン検証ポリシー・アクションは、オペレータによって特別に設定されない限り、実行または適用してはならない(MUST NOT)。
6. セキュリティに関する考慮事項
この文書は、[RFC6811] のセキュリティに関する考慮事項を超えるものではありません。
7. IANA に関する考慮事項
この文書には IANA のアクションはありません。
8. 引用規格
[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.
[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, https://www.rfc-editor.org/info/rfc4271.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, https://www.rfc-editor.org/info/rfc6480.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, https://www.rfc-editor.org/info/rfc6482.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, https://www.rfc-editor.org/info/rfc6811.
[RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R. Bush, "BGP Prefix Origin Validation State Extended Community", RFC 8097, DOI 10.17487/RFC8097, March 2017, https://www.rfc-editor.org/info/rfc8097.
[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.
謝辞
何度も忍耐強く建設的なレビューをしてくれたジョン・スカッダーと、ASを指定する必要があるかもしれないと指摘してくれたケイユール・パテルに多大な感謝をする。ジョージ・ミケルソン、ジェイ・ボルケンハーゲン、ジョン・ヒースリー、マティアス・ヴェールシュが、散漫な表現の修正を親切に手伝ってくれた。
著者のアドレス
ランディ・ブッシュ
インターネット・イニシアチブ・ジャパン
5147 Crystal Springs
Bainbridge Island, Washington 98110
アメリカ合衆国
メール: randy@psg.com
変更履歴
- 2024.1.25
- 2024.3.3
- 2024.3.5
Discussion