RFC 9324: ルートリフレッシュを伴わないリソース公開鍵基盤(RPKI)に基づくポリシー
概要
リソース公開鍵基盤(RPKI)に基づいてポリシーを実行するBGPスピーカーは、新しいRPKIデータを受け取ったからといって、そのネイバーにルートリフレッシュを発行すべきではない。本文書はRFC 8481を更新し、完全なAdj-RIB-Inを保持するか、ROV (経路オリジン検証)によってドロップされたパスを保存し、新しいRPKI データを再評価できるようにすることで、ルートリフレッシュを回避する方法を説明する。
このメモの位置付け
本文書は、インターネット標準化過程の文書である。
この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 7841のセクション 2を参照のこと。
本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9324 で入手できる。
著作権表示
Copyright (c) 2022 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。
本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。
1. はじめに
初期のBGPスピーカーのメモリ制約によって、古いBGP実装[RFC4271]は完全なAdj-RIB-Inを保持していなかった([RFC4271]のセクション1.1)。RPKIベースの経路オリジン検証(ROV) [RFC6811] [RFC8481]や同じようなRPKIベースのポリシーを実行する場合、そのようなBGPスピーカーが新しいRPKIデータを受信すると、以前に無効とマークしたパスを保持していない可能性がある。そのような実装では、新しいRPKIデータでカバーされる可能性のあるパスを回復するために、ネイバーにルートリフレッシュ[RFC2918] [RFC7313]を要求しなければならない。これは、深刻なリソース負担をネイバーに強いることになるため、そのネイバーからは不作法な行為(rude)と受け取られるだろう。本文書では、RPKIベースのポリシーの影響を受けるパスを保持し、マークする実装を推奨する。そのため、ルートリフレッシュはもはや不要となる。
⚠️ BGPルータのアーキテクチャ
Adj-RIBs-Inには、ピアからローカルBGPスピーカーに広告された未処理のルーティング情報が含まれる。
1.1. 要件言語
この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。
2. 関連仕様
BGP [RFC4271]、ルートリフレッシュ[RFC7313]、RPKI [RFC6480]、経路オリジン認証(ROA) [RFC6482]、Resource Public Key Infrastructure (RPKI) to Routerプロトコル [RPKI-ROUTER- PROT-v2]、RPKIベースのプレフィックス検証[RFC6811]、そしてオリジン検証の明確化[RFC8481]を理解していることが前提である。
本文書の「RPKIベースの経路オリジン検証」という用語は、[RFC6811]で使用されている「プレフィックス・オリジン検証」という用語と同じ意味であることに注意すること。
3. ROVでの経験
無効をドロップする経路オリジン検証が展開されるにつれて、一部のBGPスピーカーの実装は、新しいRPKIデータ(検証済みROAペイロード(VRP) [RPKI-ROUTER-PROT-v2])を受信すると、すべての送信先となるBGPピアにBGPルートリフレッシュ[RFC7313]を発行して、受信したパスを新しいデータに照らして再評価できるようにする。
実際の展開では、これは非常に破壊的であり、疑いを持たないピアに深刻なリソース負担を強いることが判明している。その反動で、RPKIベースの経路オリジン検証(ROV)がオフになっており、事実上のピアリング解除も行われている。
⚠️ リソース負担
VRPの変更をルートリフレッシュで行う場合、変更が頻繁になるとピアへのルートリフレッシュ要求が増え、ピアのCPUリソースを消費する。
RPKIの登録とROAの作成が着実に増加するにつれて、この問題は単純な比例ではなく、ROVを実装するBGPスピーカーの度合いに比例して増加している。Autonomous System Provider Authorization (ASPA) [AS_PATH-VER]が使用されるようになると、この問題は増加するだろう。
自動ポリシー・プロビジョニングのような、ROVと同様の流動速度(つまり、数分のオーダー)を持つ他のメカニズムも、同様の問題を引き起こす可能性が非常に高い。
したがって、本文書はこの問題を回避する方法を記述することで[RFC8481]を更新する。
4. 部分的なAdj-RIB-Inデータの保持
新しいRPKIデータが到着し、オペレータ・ポリシーが最適経路を無効にし、BGPスピーカーがドロップされた経路を保持していなければ、BGPスピーカーはルートリフレッシュを発行することになるが、この機能はこれを防ぐことを目的としている。
ROVが原因でオペレータ・ポリシーによってドロップされた経路は、本来、最適経路を競う資格がないとみなされ、将来の評価のためにAdj-RIB-Inに保持しなければならない(MUST)。
完全なAdj-RIB-Inを保持することでルートリフレッシュの問題を改善することは、リソースに制約のあるBGPスピーカーにとって問題となる。実際には、保持する必要があるのは一部のデータだけである。実装が完全なAdj-RIB-Inを保持しないことを選択した場合、将来の評価に備えて、少なくともROVによってドロップされた経路を保持しなければならない(MUST)。
これらの経路を保存することは、リソースに制約のあるデバイスで問題を引き起こすかもしれないため、オペレータがこの機能を有効にしてドロップされた経路を保存できるようにするグローバル操作、CLI、YANG、または他のメカニズムがなければならない(MUST)。このようなオペレータ制御は、一貫性のない動作を引き起こす可能性があるため、ピアごとに行ってはならない(MUST NOT)。
補足として、ROVのようなRPKIベースのチェック(将来的にはASPA、BGPsec[RFC8205]など)が原因で、経路をドロップする可能性のあるポリシーは、RPKI以外のポリシーが実行される前に、このセクションに従ってドロップされた経路を保存しなければならない(MUST)。後者はパス属性を変更する可能性がある。
⚠️ コメント
後者とはBGPsec
5. 運用上の推奨事項
ROVおよび/または他のRPKIベースのポリシーを導入しているオペレータは、BGPスピーカーの実装はネイバーに対してルートリフレッシュ要求を引き起こしていないことを確認する必要がある。
BGPスピーカーは、完全なAdj-RIB-Inを保持するか、セクション4の仕様を実装しなければならない(MUST)。この動作への準拠は、ROVを実行するBGPスピーカーの追加の必須機能である。
⚠️ 実装について
Juniperはデフォルトで完全なAdj-RIB-Inテーブル(ネイバーから受信したすべてのポリシー前の経路)を保持するよう設定されている。Cisco(IOS-XR/IOS-XE)は、「soft-reconfiguration inbound」を設定する必要がある。これを設定しておかないと、RPKIのデータ更新のたびに、ルートリフレッシュ要求が頻繁に発生する。
| 実装 | Adj-RIB-In | ROVの挙動 | 備考 |
|---|---|---|---|
| Cisco IOS-XE | No | VRPの更新がルートリフレッシュの引き金となる | ワークアラウンドは「soft-reconfiguration inbound」を設定する |
| Cisco IOS-XR | No | VRPの更新がルートリフレッシュの引き金となる | ワークアラウンドは「soft-reconfiguration inbound」を設定する |
| Juniper JUNOS | Yes | VRPの更新はローカルに処理 | 「set protocols bgp group keep none」でオフにできる(マニュアル) |
| Bird 2.0.8 | ? | VRPの更新はローカルに処理 | 2.0.8で「rpki reload on」がデフォルト(マニュアル) |
| FRR 8.1 | ? | ? | ? |
| Arista EOS | Default | VRPの更新はローカルに処理 | オフにできる |
BGPスピーカーがこれらの推奨事項を実装していない場合、オペレータはAdj-RIB-Inを完全に保持するようにベンダー固有の制御を有効にする必要がある。これは「soft reconfiguration inbound」と呼ばれることもある。そしてオペレータは、ネイバーに不必要なルートリフレッシュ要求が送信されていないことを確認するために測定が必要である。
BGPスピーカーの機器が、提案された2つのオプション(完全なAdj-RIB-Inを保持するか、少なくともドロップされた経路をを保持する)のいずれかをサポートするのに十分なリソースがない場合、その機器は機能のある機器と交換するか、ROVを使用することはない(SHOULD NOT)。
セクション4の構成設定は、スケーリングの問題が十分に理解され、予測されるような、非常によく知られ、管理された状況でのみ使用する必要がある。
セクション4の仕様を使用するオペレータは、設定を誤ったネイバーが大量のパスを誤って送信する可能性があり、その結果、多くのメモリを消費する可能性があることに注意する必要がある。したがって、[MAXPREFIX-INBOUND]で説明しているような事前ポリシー・フィルタリングを使用することで、この暴露(exposure)を軽減できる。
ルートリフレッシュが複数のピアに向けて発行された場合、リフレッシュデータの受信順序によって、最適な経路選択とアウトバウンド・シグナリングの両方でチャーンが発生する可能性がある。
ルートサーバ[RFC7947]を提供するインターネット・エクスチェンジ・ポイント(IXP)は、一部のメンバーがルートサーバに過度のルートリフレッシュ負荷を引き起こしている可能性があることを認識し、適切な管理および/または技術的措置を講じる必要がある。BGPスピーカーをルートサーバとして使用するIXPは、過度のルートリフレッシュ要求を生成していないことを確認する必要がある。
⚠️ コメント
IXPはどうなっているか?
6. セキュリティに関する考慮事項
この文書では、経路オリジン検証または他のRPKIポリシーがBGPネイバーに課す可能性のあるサービス拒否と、それを改善する方法について説明する。
それ以外の点では、本文書は参考文献で既に説明されているセキュリティに関する考慮事項に追加するものではない。
7. IANA に関する考慮事項
本文書にはIANAのアクションはない。
8. 参考文献
8.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>.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000, <https://www.rfc-editor.org/info/rfc2918>.
[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>.
[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>.
[RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced Route Refresh Capability for BGP-4", RFC 7313, DOI 10.17487/RFC7313, July 2014, <https://www.rfc-editor.org/info/rfc7313>.
[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>.
[RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)", RFC 8481, DOI 10.17487/RFC8481, September 2018, <https://www.rfc-editor.org/info/rfc8481>.
8.2. 参考規格
[AS_PATH-VER] Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Resource Public Key Infrastructure (RPKI) Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-verification-11, 24 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-11>.
[MAXPREFIX-INBOUND] Aelmans, M., Stucchi, M., and J. Snijders, "BGP Maximum Prefix Limits Inbound", Work in Progress, Internet-Draft, draft-sas-idr-maxprefix-inbound-04, 19 January 2022, <https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound-04>.
[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>.
[RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, <https://www.rfc-editor.org/info/rfc7947>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RPKI-ROUTER-PROT-v2] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2", Work in Progress, Internet-Draft, draft-ietf-sidrops-8210bis-10, 16 June 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis-10>.
謝辞
アルバロ・レタナ、ベン・マディソン、デレク・インヤン、ジョン・ヒースリー、ジョン・スカダー、マティアス・ヴァエリッシュ、ニック・ヒリアード、サク・イッティ、タイ・デ・コックに感謝する。
著者のアドレス
ランディ・ブッシュ
IIJリサーチラボ ＆ アーカス社
1856 SW Edgewood Dr
Portland, OR 97210
アメリカ合衆国
メール: randy@psg.com
ケユール・パテル
アーカス社
2077 Gateway Place, Suite #400
San Jose, CA 95119
アメリカ合衆国
メール: keyur@arrcus.com
フィリップ・スミス
PFS Internet Development Pty Ltd
PO Box 1908
Milton QLD 4064
オーストラリア
メール: pfsinoz@gmail.com
マーク・ティンカ
SEACOM
Building 7, Design Quarter District
Leslie Avenue, Magaliessig
Fourways, Gauteng
2196
南アフリカ
メール: mark@tinka.africa
変更履歴
- 2024.1.24
- 2024.1.25
- 2024.1.31
Discussion