Zenn
🕌

RFC 7115: リソース公開鍵基盤(RPKI)に基づくオリジン検証の運用

2024/03/22に公開
RFC
rpki
tech

要旨

リソース公開鍵基盤(RPKI)に基づくBGPオリジン検証の展開には、多くの運用上の考慮事項が存在する。本文書は、最も重要なものを取りまとめ、提示することを目的としている。RPKIベースのオリジン検証の展開が続き、その関係性(dynamics)がよりよく理解されるにつれて、この文書も進化していくだろう。

本文書の位置付け

本文書は、インターネットのベスト・カレント・プラクティスを文書化したものである。

この文書はInternet Engineering Task Force (IETF)の成果物である。Internet Engineering Steering Group (IESG)によって公開が承認されている。BCPの詳細については、RFC 5741のセクション 2を参照のこと。

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

著作権表示

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

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

1. はじめに

RPKIベースのオリジン検証は、リソース公開鍵基盤(RPKI)[RFC6480]の広範な展開に依存している。RPKIがどのようにグローバルに配布され、維持されるかは、さまざまな側面から深刻な懸念事項である。

グローバルRPKIは展開の初期段階にあるが、単一のルート・トラストアンカーは存在せず、初期テストは地域インターネット・レジストリ(RIR)によって行われ、技術テストベッドも存在する。RPKIに基づくオリジン検証は、今後数年間にわたって段階的に導入され続けると考えられる。最終的には、パブリック・アドレス空間に対して、ルート・トラストアンカーを1つにする必要があると想定されている。[IAB]を参照。

オリジン検証は、ASのボーダー・ルータのみで実行する必要があり、インターネットBGPルーティングに参加するあらゆるネットワーク、大規模プロバイダ、アップストリームおよびダウンストリーム・ルータ、エッジ・ネットワーク(小規模なスタブまたは企業ネットワークなど)から発信されるアナウンスを保護するために使用できるように設計されている。

オリジン検証は、ハードウェアを大幅にアップグレードすることなく、現在のルータに導入できるように設計されている。これは、大規模なバックボーンから小規模なスタブ/企業/エッジ・ネットワークまで、オペレータのボーダー・ルータで使用される。

RPKIベースのオリジン検証は、慎重なローカル・ルーティング・ポリシーを使用することで、グローバルRPKIの軽率(imprudent)な展開によって、今日の通常のインターネット・ルーティングが脅かされるリスクがほとんどないように設計されている。セクション5を参照のこと。

1.1. 要件言語

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

2. 推奨文献

読者は、BGP[RFC4271]、RPKI[RFC6480]、RPKIリポジトリ構造[RFC6481]、経路オリジン認可(ROA)[RFC6482]、RPKI to Router Protocol [RFC6810]、RPKIベースのプレフィックス検証[RFC6811]、およびゴーストバスターズ・レコード[RFC6493]を理解していることを前提としている。

3. RPKIの配布と保守

RPKIは、[RFC6481]で説明するように、証明書、証明書失効リスト(CRL)、マニフェスト、ROA、およびゴーストバスターズ・レコードを含む分散データベースである。RPKIオブジェクトの生成と保守に関するポリシーと考慮事項については、別の場所で説明する。

RPKIのリポジトリ設計[RFC6481]は、リポジトリの階層構造を想定していた。これは、非階層構造よりもデータを収集するリライング・パーティーの性能を大幅に向上させるためである。そのため、パブリッシング・パーティーは階層ディレクトリ構造を実装しなければならない(MUST)。

すべてのRPKIデータを含むローカル・リライング・パーティーの有効キャッシュは、rsyncプロトコル[RFC5781]とrcynic[rcynic]などの検証ツールを使用して、グローバルな分散データベースから集める。

検証済みキャッシュには、RPKI証明書と署名済みオブジェクトの検証ルールに従って、RPが有効であると検証したすべてのRPKIオブジェクトが含まれる。[RFC6487]および[RFC6488]を参照。キャッシュを信頼するエンティティは、さらなる検証を行わず、これらのRPKIオブジェクトを使用できる。

検証済みキャッシュは、他の検証済みキャッシュから作成・維持することもできる。ネットワーク・オペレータは、グローバル分散RPKIデータベースの負荷を最小限に抑えるために、この機能を最大限に活用すべきである(SHOULD)。もちろん、受信側のリライング・パーティーはデータを再検証する必要がある。

トラストアンカー・ロケータ(TAL)[RFC6490]は、RPKI信頼モデルにとって重要であるため、オペレータは最初の選択に細心の注意を払い、その保守にも注意を払う必要がある。

キャッシュ間の同期、およびキャッシュとグローバルRPKI間の同期のタイミングは、本文書の範囲外であり、ルータがキャッシュからフィードする頻度、グローバルRPKIが大幅に変更されたとオペレータが感じる頻度などに依存する。

オペレータのネットワーク内のキャッシュ間同期はグローバルRPKIリソースに影響を与えないため、オペレータは高い頻度での同期を選択してもよい。

証明書の検証や暗号化操作などの負荷からルータを解放するため、RPKI-Routerプロトコル[RFC6810]は、ルータにオブジェクト・ベースのセキュリティを提供しない。つまり、ルータは既知のトラストアンカーからデータを暗号的に検証しない。ルータはキャッシュを信頼して正しいデータを提供し、キャッシュから受信したデータに対してトランスポート・ベースのセキュリティに頼る。したがって、キャッシュからのデータの真正性と完全性は十分に保護されている必要がある。[RFC6810]のセクション7を参照のこと。

RPKIベースのオリジン検証はRPKIデータの可用性に依存する。オペレータはローカル・ルーティング、中間デバイス、長距離回線などで発生する可能性のある障害の影響を最小限に抑えるため、これらのデータとサービスを必要とするルータの近くに RPKIキャッシュを配置する必要がある(SHOULD)。信頼境界、ルーティング・ブートストラップの到達可能性なども考慮する必要がある。

例えば、ルータはDNSやルーティング・プロトコルなどの他のインフラへの依存を最小限に抑え、到達可能なキャッシュからブートストラップする必要がある。ルータがキャッシュに到達するためにBGPやIGPを収束させる必要がある場合、キャッシュが到達可能になると、ルータはBGP経由で学習済みのプレフィックスを再評価しなければならなくなる。このような構成は、合理的な範囲で避けるべきである。

オペレータのキャッシュとルータ間で安全でないトランスポートが使用される場合、[RFC6810]のトランスポート・セキュリティの推奨事項に従う必要がある(SHOULD)。特に、オペレータは、ルータと他の自律システムにあるRPKIキャッシュの間で安全でないトランスポートを使用してはならない(MUST NOT)。

冗長性を確保するには、ルータは同時に複数のキャッシュとピアリングする必要がある。少なくとも1つはローカル、もう1つはリモートで、2つ以上とピアリングすることを推奨する。

オペレータがトラフィックを伝送するために　アップストリームを信頼する場合、そのアップストリームがキャッシュする RPKI データも信頼することができ、そのアップストリームが利用可能にしてくれたキャッシュとピアリングする必要がある(SHOULD)。 これにより、アップストリームには、新しい(fresh)信頼性の高いキャッシュを維持し、顧客が利用できるようにする義務が課されることに留意すること。そしていつものように、受信者はデータを再検証する必要がある(SHOULD)。

トランジット・プロバイダまたはピアを持つネットワークは、アップストリーム、ダウンストリーム、およびピアによるアナウンスのオリジンを検証する必要がある(SHOULD)。また、アップストリームが提供するキャッシュを信頼する必要がある。

スーパーブロックのROAを発行する前に、オペレータは、他のAS(例えば、顧客など)がアナウンスするそのブロックからのすべてのサブ割り当てがRPKIに正しいROAを持っていることを確認しなければならない(MUST)。そうしないと、スーパーブロックのROAを発行すると、ROAを持たないサブ割り当てのアナウンスが無効とみなされる。[RFC6811]を参照のこと。サブ割り当てのすべての受信者がROAを登録するのを待つ間、スーパーブロックの所有者は、ライブBGPデータを使用して代理としてROAを投入することができる。その後、スーパーブロックのROAを安全に発行できる。

RPKIベースのオリジン検証を使用することで、Less-Specificなプレフィックスの誤発信を防ぐために、More-Specificな情報をBGPに注入する必要がなくなる。カバーするプレフィックスにROAを設定することで、そのプレフィックスを保護できる。

ROAをルータの効率的な検索アルゴリズムに変換しやすくするため、ROAは可能な限り正確である必要がある。つまり、BGPでアナウンスしたプレフィックスと一致する必要がある。例えば、ソフトウェアとオペレータは、運用上必要な場合を除き、ROAに過大なMaxlength(最大長)値の使用を避けるべきである(SHOULD)。

最小ROA長(minimal ROA length)の利点の1つは、長すぎる最大長でカバーされないサブプレフィックスに対して、偽造オリジン攻撃が機能しないことである。例えば、10.0.0.0/16-24の代わりに10.0.0.0/16と10.0.42.0/24を発行した場合、10.0.666.0/24に対する偽造オリジン攻撃は成功しない。攻撃者は、/16全体を攻撃する必要があり、そのサイズ故に気づかれる可能性が高くなる。

したがって、ROA生成ソフトウェアは、ユーザが最大長を指定しない場合、プレフィックス長を最大長として使用しなければならない(MUST)。

オペレータは、ROAの最大長を慎重に使用する必要がある。例えば、プレフィックスが数個のサブプレフィックスしかアナウンスしない場合、長い最大長を持つ1つのROAではなく、特定のアナウンスに複数のROAを使用すべきである。

プレフィックスPを保有するオペレータは、Pをアナウンスする可能性のあるすべてのASに対してROAを発行すべきである。プレフィックスが複数のASから正当にアナウンスされている場合、すべてがASが有効だとみなされるよう、すべてのASに対してROAを発行する必要がある(SHOULD)。

プライベート・アドレス空間が外部BGP(eBGP)でアナウンスされる環境では、オペレータはこれらのプライベート空間をカバーするプライベートRPKIオブジェクトを持つことができる。これには、その環境が作成し、所有するトラストアンカーが必要になる。[LTA-USE]を参照のこと。

ROAを発行するオペレータには、自身のプレフィックスとASをグローバルeBGPにアナウンスするが、関連する証明書とROAの管理作業を望まない顧客がいるかもしれない。オペレータは、このような顧客に対して、他の多くのものを援助(provision)するのと同じように、RPKIデータの援助を申し出るべきである(SHOULD)。

RPKIデータを使用するオペレータは、新しいRPKIキャッシュを確保するため、希望するポーリング頻度を選択してもよい(MAY)。ただし、運用上のルーティング決定の入力として、RPKIデータを使用する場合は、少なくとも4～6時間ごとに、AS内のローカル・キャッシュが相互に同期していることを保証すべきである(SHOULD)。

オペレータは、自身のデータの有効性に影響を与える可能性のある、ROAまたは証明書の有効期限が迫っていることを警告するツールを使用すべきである。ゴーストバスターズ・レコード[RFC6493]は、アップストリームの認証局(CA)との連絡を容易にし、修復を行うために使用することができる。

4. ネットワーク内で

オリジン検証は、ネットワーク内のエッジ・ルータ、つまり他のネットワークやASとのボーダーに接するルータだけが実行する必要がある。

検証ルータは、そのネットワーク内のローカル・ポリシーに影響を与えるために、オリジン検証の結果を使用する。セクション5を参照のこと。展開において、このポリシーはASの既存のポリシーやプリファレンスなどに適合する必要がある。これにより、ネットワークは検証可能なボーダー・ルータを段階的に展開することができる。

オペレータは、RPKIベースのオリジン検証は、他のポリシー変更と同様に、ネットワーク内のトラフィックの変化を引き起こす可能性があることに認識すべきである。そして、通常のポリシー変更の実践と同様に、賢明な(prudent)オペレータは、予測、測定、修正などを行うためのツールや方法を持っている。

5. ルーティング・ポリシー

RPKIに基づくオリジン検証では、受信したアナウンスの発信元が有効(Valid)、不明(NotFound)、または無効(Invalid)であるとマークする。[RFC6811]を参照のこと。ルーティングでこれをどのように使用するかは、オペレータのローカル・ポリシーで指定する必要がある。

初期展開時のシステムに関連する不確実性を管理するため、相対的プリファレンス(relative preference)を使用するローカル・ポリシーを提案する。ローカル・ポリシーは、不適切な認証ポリシーや誤った認証データによるプレフィックス到達不能の恐れを排除できる。例えば、コミュニティがRPKIデータに安心して依存できるようになるまでは、プレファレンスは低くして、無効というオリジン有効性に基づくルーティングが発生してもよい(MAY)。

オペレータは、無効なアナウンスを受け入れると、それがどんなに優先度が低くても(de-preferenced)、多くの場合、完全に有効なアナウンスとして扱うのと同等であることに留意する必要がある。プレフィックス10.0.0.0/16-24に対してAS 42のROAがあるとする。AS 666からの10.0.666.0/24に対するBGPアナウンスは無効となる。もし、ポリシーがそれを破棄するように設定されていなければ、最長一致転送はローカル・プリファレンスの値に関係なく、AS 666にパケットが送信される。

オリジン検証は段階的に展開されるため、カバー範囲は長期間にわたって不完全となる。そのため、有効性状態が不明(NotFound)である場合のルーティングは長期間行う必要がある(SHOULD)。 移行が進むにつれて、検証状態が不明のBGPアナウンス数は減少するはずである。したがって、オペレータのポリシーは厳しすぎるべきではなく、有効なアナウンスを優先させる必要がある。不明のアナウンスに低い優先順位を付けるが、引き続き使用し、無効なアナウンスを削除するか非常に低い優先順位を与えるべきである。単に無効なアナウンスの優先順位を下げることは賢明ではない。前項を参照のこと。

プロバイダによっては、RPKIの検証結果に基づいて、ローカル・プリファレンスの設定を選択する場合がある。別のプロバイダは、RPKIの検証結果がAS_PATH長よりも重要になることを望まないかもしれない。このようなプロバイダは、AS_PATHが評価された後に、BGP のパス選択プロセスで評価される何らかのBGP属性にRPKI検証結果をマッピングする必要がある。RPKIベースのオリジン検証を実装するルータは、オペレータにそのようなオプションを提供しなければならない(MUST)。

ローカル・プリファレンスは、プレフィックスの有効性状態とトラフィック・エンジニアリング(TE)特性の両方を伝送するために使用できる。すでにローカル・プリファレンスを使用しているオペレータは、悪影響を与えたり権限昇格攻撃を受けたりすることなく、同じBGP属性にこれら2つの異なる特性をエンコードできるようにポリシーを変更しなければならないだろう。例えば、検証状態をTEで使用されるよりも高位のビット(higher bits)でエンコードしない。

他のローカル・ポリシーにも影響する指標(metric)を使用する場合、オペレータは権限昇格の脆弱性が生じないように注意する必要がある。例えば、ローカル・プリファレンス(Local Pref)が有効性状態に応じて設定されている場合、ピアのコミュニティ信号(signaling)は無効なアナウンスを有効以上に昇格すべきではない(SHOULD NOT)。

無効のオリジンを受け入れる場合、有効なオリジンを持つアナウンスは不明または無効のオリジンを持つアナウンスよりも優先する必要がある。

不明のオリジンを持つアナウンスは、無効なオリジンを持つアナウンスよりも優先する必要がある。

無効なオリジンのアナウンスは使用すべきではない(SHOULD NOT)が、特別な運用上のニーズを満たすために使用することがある。そのような状況では、アナウンスは有効または不明よりも低い優先度を持つ必要がある。

初めてオリジン検証を導入する場合、ログ、SNMP、あるいは他のデータの検査で正しい結果が得られることが示されるまで、無効なオリジンを持つアナウンスをドロップしないことが賢明である。

有効性状態の信号は、隣接ASから受け入れるべきではない(SHOULD NOT)。受信したアナウンスの有効性状態は、信頼の範囲、RPKIの同期、ローカル・トラストアンカー[LTA-USE]の管理などの問題のため、ローカルスコープに限られる。

6. 注意事項と推奨事項

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

オペレータは、シングルAS内であってもRPKIキャッシュの同期が緩やかであることに留意する必要がある。したがって、プレフィックスの有効性状態の変更は、オペレータのネットワーク内で異なる可能性がある。さらに、RPKIキャッシュが更新されてから、新しい情報がこのプロトコルを介してルータにプッシュまたはプルされるまでの間隔は保証されていない。そのため、AS内のすべてのルータがすべてのRPKIキャッシュに反映されたプレフィックスの有効性状態と平衡(equilibrium)に達するまで、オペレータ・ネットワーク内のトラフィックが突然変わる可能性がある。

テストと展開により、リライング・パーティーに対するキャッシュの読み込みとタイミングに関するアドバイスが得られることが期待される。

集約経路のオリジンASと使用できるROAがあるとすれば、何であるかについては、ある程度不確実性が伴う。これに対する長期的な解決策は、AS_SETを非推奨にすることである。[RFC6472]を参照のこと。

グローバルRPKIとオペレータのキャッシュ(および場合によってはDNSルートサーバなど他のホスト)への信頼性の高いアクセスが重要であるため、オペレータはプレフィックスの検証に悪影響を与えるようなBGPまたはRPKIデータの変更を報告するリライング・パーティーのツールを利用する必要がある。

オペレータは、リポジトリのコンテンツが権威を持つアドレス空間にRPKIリポジトリを配置するには、トレードオフがあることに留意する必要がある。一方では、オペレータはリポジトリに対するコントロールを最大化することを望むだろう。一方では、アドレス空間への到達可能性に問題がある場合、それを修正するためのリポジトリの変更は、他のユーザが簡単にアクセスできない可能性がある。

証明書を管理するオペレータは、RPKIゴーストバスターズ・レコード([RFC6493]を参照)を、管理する各公開ポイントに関連付ける必要がある。これらは、運用者が発行したCRL、ROA、および他の署名済みオブジェクトを保持する公開ポイントであり、パブリック・インターネット上のルーティングをサポートするために、他のASが利用できるようになる。

RPKIベースのオリジン検証を実行するルータは、特にAS 23456 (AS_TRANS)のROAを生成するのは合理的ではないため、4オクテットのAS番号([RFC6793]を参照)をサポートしなければならない。

ターゲット・ルータが4オクテットAS番号([RFC6793]を参照)をサポートしていない場合、ルータ用のフィルタリストや他の制御フォームを生成するソフトウェアは、4オクテットAS番号を受け入れ、適切な2オクテットの出力を生成するように準備しなければならない。

ルータは時間に依存する証明書とROAを評価しなければならないため、ルータの時計は約1時間の許容誤差まで正確でなければならない(MUST)。

サーバは、NTPv4[RFC5905]などのタイムサービスをクライアント・ルータに提供する必要がある。

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

UPDATE(メッセージ)のBGPオリジンASは署名されていないため、オリジン検証は悪意のあるなりすまし(spoofing)の可能性がある。したがって、RPKIベースのオリジン検証は、不注意による誤った広告にのみ対処することを想定する。

オリジン検証は、AS_PATHの検証の問題に対処していない。したがって、パスは悪意があるものであれ、偶発的なものであれ、操作される可能性がある。

BGPはトラフィックが広告したパスを流れることを保証しないため、データ・プレーンがコントロール・プレーンに追従しない可能性がある。

上記のセクション 5で説明した特権昇格問題の類に留意すること。

8. 謝辞

シェーン・アマンテ、ロブ・オーステイン、スティーブ・ベロビン、ジェイ・ボーケンハーゲン、ウェス・ジョージ、川村聖一、スティーブ・ケント、プラドシュ・モハパト、クリス・モロー、サンディ・マーフィー、エリック・オスターヴァイル、キール・パテル、ヘザー＆ジェイソン・シラー、ジョン・スカダー、コティカラプディ・スリラム、モーリーン・スティルマン、デイブ・ウォードに感謝する。

9. 参考文献

9.1. 引用規格

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

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.

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

[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.

[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012.

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

[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, January 2013.

[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013.

9.2. 参考規格

[LTA-USE] Bush, R., "RPKI Local Trust Anchor Use Cases", Work in Progress, September 2013.

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

[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.

[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.

[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, December 2011.

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

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.

[IAB] IAB, "IAB statement on the RPKI", January 2010, <http://www.iab.org/documents/correspondence-reports-documents/docs2010/iab-statement-on-the-rpki/>.

[rcynic] "rcynic RPKI validator", November 2013, <http://rpki.net/rcynic>.

著者のアドレス

ランディ・ブッシュ
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington 98110
アメリカ
メール: randy@psg.com

更新履歴

  • 2024.3.22
  • 2024.3.22: Errata追加 (セクション3と5)
GitHubで編集を提案

Discussion