📏

RFC 9319: リソース公開鍵基盤(RPKI)におけるmaxLengthの使用

2024/02/04に公開

RFC

rpki

tech

要旨

本文書では、経路オリジン認可(ROA)に含まれるIPプレフィックスを慎重に制限することで、偽造オリジン・ハイジャック攻撃の対象範囲を縮小する方法を推奨する。推奨事項の1つは、特定のケースを除き、ROAでmaxLength属性の使用を避けることである。この推奨事項は、RFC 7115の推奨事項を補完し、拡張するものである。本文書では、分散型サービス拒否(DDoS)軽減サービスの使用を容易にするためのROAの作成についても説明する。宛先ベースのRemotely Triggered Discard Route (RTDR) (「Remotely Triggered Black Hole」とも呼ばれる)フィルタリングがらみでROAとRPKIベースの経路オリジン検証(RPKI-ROV)に関連する考慮事項も焦点を当てる。

本文書の位置付け

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

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

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

著作権表示

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

1. はじめに

リソース公開鍵基盤(RPKI)[RFC6480]は、経路オリジン認可(ROA)を使用して、IPプレフィックスから、そのプレフィックスの発信を認可された一連の自律システム(AS)に対する暗号的に検証可能なマッピングを作成する。各ROAには、IPプレフィックスの集合と、その集合内のすべてのIPプレフィックスの発信を認可されたASのうちの1つのAS番号が含まれる[RFC6482]。ROAは、一連のIPプレフィックスの証明書を保有する当事者によって暗号的に署名される。

ROAの書式は、maxLength属性もサポートする。[RFC6482]によると、「maxLengthが存在する場合、ASが広告することを認可されるIPアドレス・プレフィックスの最大長を指定する。」したがって、maxLength属性は、ROAにASが発信を認可された各プレフィックスをリストすることを要求するのではなく、ASが一連のIPプレフィックスを発信することを認可する略記法を提供している。

しかし、RPKIの導入状況を測定した結果、ROAでmaxLength属性を使用するとセキュリティ上の問題が発生する傾向があることが判明した。特に、2017年6月に行われた測定によると、maxLength属性を使用するROAで指定されたプレフィックスのうち、84%は偽造オリジン・サブプレフィックス・ハイジャック[GSG17]に対して脆弱であることが示された。偽造オリジン・プレフィックスまたはサブプレフィックス・ハイジャックでは、ROAで指定されている正当なASをオリジンASとして、AS_PATHに挿入する。このハイジャックは、ROAを持つ任意のIPプレフィックス/サブプレフィックスに対して実行できる。ROAを持つプレフィックス/サブプレフィックスが未使用(つまり、正当なASによって、BGPでアナウンスされていない)であることを考える。このようなプレフィックス/サブプレフィックスを含む偽造オリジン・ハイジャックは、インターネット全体に広く伝播する可能性がある。一方、プレフィックス/サブプレフィックスが正当なASによってアナウンスされていた場合、正当なアナウンスに比べてAS_PATH長が長くなるため、偽造オリジン・ハイジャックの伝播範囲はある程度制限される。もちろん、どちらの場合も、偽造オリジンのハイジャックは有害だが、その害の程度は、アナウンスされていないプレフィックスの方が大きい。詳細についてはセクション3を参照のこと。

そのため、本文書では、可能な限り、オペレータは実際にBGPで発信されたIPプレフィックスのみを認可し、他のプレフィックスを認可しない「最小ROA」を使用する必要があると推奨している。さらに、ROAに含まれるアドレス空間を慎重に制限することで、偽造オリジンの攻撃対象範囲を減らす方法を推奨する。推奨事項の1つは、特定の場合を除き、ROAでmaxLength属性を使用しないことである。この推奨事項は、[RFC7115]の推奨事項を補完・拡張するものである。本文書では、DDoS軽減サービスの使用を促進するためのROAの作成についても説明する。宛先ベースのRemotely Triggered Discard Route (RTDR) (「Remotely Triggered Black Hole」とも呼ばれる)フィルタリングがらみでROAとRPKI-ROVに関連する考慮事項も強調されている。

本文書で使用する用語「RPKIベースの経路オリジン検証」および対応する頭字語「RPKI-ROV」は、[RFC6811]で使用する用語「プレフィックス・オリジン検証」と同じ意味であることに注意すること。

ROA関連の推奨事項を実装する理想的な場所の1つは、ROAを設定するためのユーザ・インタフェースである。そのようなユーザ・インタフェースの実装者に対する推奨事項は、セクション7に記載する。

本文書に記載されている実践方法は、RPKI仕様の変更を必要とせず、ROAはすでにIPプレフィックス[RFC6482]のリストを対応しているため、RPKI 内の署名済みROAの数は増加しない。

1.1. 要件

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

1.2. 例示用プレフィックス

[RFC5737]で推奨されている文章作成用プレフィックスは、本文書の例示用プレフィックスとして使用するには不十分である。したがって、本文書では、[RFC1918]で定義されているアドレス空間を使用して例示用プレフィックスを構成する。

本文書の例ではIPv4プレフィックスを使用しているが、その分析結果と推奨事項はすべてて、同等のIPv6にも同じように有効であることに注意すること。

2. 参考文献

読者は、BGP [RFC4271]、RPKI [RFC6480]、ROA [RFC6482]、RPKI-ROV [RFC6811]、およびBGPsec [RFC8205]を理解していることを前提としている。

3. 偽造オリジン・サブプレフィックス・ハイジャック

ここでは、特にサブプレフィックスがBGPでアナウンスされない場合を考慮して、偽造オリジン・サブプレフィックス・ハイジャックに関する詳細な説明と考察を行う。偽造オリジン・サブプレフィックス・ハイジャックは、以下のようなシナリオに関連する:

(1) RPKI[RFC6480]が展開されており、かつ
(2) ルータは無効な経路をドロップするためにRPKI-ROVを使用している[RFC6811]、しかし、
(3) BGPsec [RFC8205] (またはBGP AS_PATH属性の真実性を検証する同様の方法)は導入されていない。

この一連の仮定は、執筆時点において、相当数に達していると同時に、増え続けるインターネット・ネットワークを正確に表していることに注意すること。

偽造オリジン・サブプレフィックス・ハイジャック[RFC7115] [GCHSS]について、実行例を用いて説明する。

AS 64496を運用している組織に割り当てられているIPプレフィックス192.168.0.0/16について考える。AS 64496は、BGPでIPプレフィックス192.168.0.0/16とそのサブプレフィックス192.168.225.0/24を発信している。したがって、RPKIには、AS 64496がこれら2つのIPプレフィックスを発信することを認可するROAが含む必要がある。

しかし、組織がmaxLength値24を含むROAを発行し、公開したとする。

ROA:(192.168.0.0/16-24, AS 64496)

AS 64496は、BGPでアナウンスすることを意図したプレフィックスだけでなく、長さ/24までの192.168.0.0/16の任意のサブプレフィックスをアナウンスすることを認可しているため、上記を「loose ROA」と呼ぶ。

AS 64496は、BGPで2つのプレフィックス(192.168.0.0/16と192.168.225.0/24)のみを発信するため、loose ROAで認可された他のすべてのプレフィックス(例えば、192.168.0.0/24)は、以下のような偽造オリジン・サブプレフィックス・ハイジャック[RFC7115] [GCHSS]に対して脆弱である。

⚠️ 参考図

ハイジャッカーAS 64511は、BGPアナウンス「192.168.0.0/24: AS 64511, AS 64496」を送信し、AS 64511がAS 64496のネイバーであり、AS 64496がIPプレフィックス192.168.0.0/24を発信していると偽っている。実際には、IPプレフィックス192.168.0.0/24はAS 64496が発信しているわけではない。

ROA (192.168.0.0/16-24, AS 64496)は、AS 64496が192.168.0.0/24のBGP経路を発信すること認可しているため、ハイジャッカーのBGPアナウンスはRPKIに従って有効である。

AS 64496は実際には192.168.0.0/24への経路を発信していないため、ハイジャッカーの経路が192.168.0.0/24への唯一の経路となる。Longest-prefix-matchルーティングにより、サブプレフィックス192.168.0.0/24へのハイジャッカーの経路が、AS 64496が発信する192.168.0.0/16への正当な経路よりも常に優先されることを保証する。

したがって、ハイジャッカーの経路はインターネットを伝播し、IPアドレス192.168.0.0/24宛てのトラフィックがハイジャッカーに配信される。

Loose ROAの代わりに、セクション5で説明する最小ROAを使用した場合、偽造オリジン・サブプレフィックス・ハイジャックは失敗しただろう。この例では、最小ROAは次のようになる。

ROA: (192.168.0.0/16, 192.168.225.0/24, AS 64496)

このROAは、AS 64496がBGPで発信するIPプレフィックスのみを含み、他のIPプレフィックスを含まないため、「最小」である[RFC6907]。

最小ROAはAS 64511のBGPアナウンスを無効にする:

(1) このROAは、(192.168.0.0/24は192.168.0.0/16のサブプレフィックスであるため)攻撃者のアナウンスを「カバー」する、そして
(2) 攻撃者のアナウンスに「一致する」ROAがない(AS 64511とIPプレフィックス192.168.0.0/24のROAがない)[RFC6811]。

ルータが無効なBGPアナウンスを無視すれば、上記の最小ROAによって、サブプレフィックス・ハイジャックは確実に失敗する。

したがって、もし、最小ROAを使用していた場合、攻撃者はトラフィックを引き寄せるために、次のような偽造オリジン・プレフィックス・ハイジャックを送らざるを得なくなる:

ハイジャッカーAS 64511は、BGPアナウンス「192.168.0.0/16: AS 64511, AS 64496」を送信し、AS 64511がAS 64496のネイバーであると偽っている。

この偽造オリジン・プレフィックス・ハイジャックは、偽造オリジン・サブプレフィックス・ハイジャックよりも大幅に被害が少ない:

AS 64496はBGPで正当に192.168.0.0/16を発信しているため、ハイジャッカーAS 64511は192.168.0.0/16への唯一の経路を提示しているわけではない。

さらに、AS 64511が発信したパスは、正当なオリジンAS 64496が発信したパスよりも1ホップ長くなる。

[LSG16]で考察されているように、これはハイジャッカーがハイジャックされたサブプレフィックスへの唯一の経路を提示する、偽造オリジンのサブプレフィックス・ハイジャックよりも、ハイジャッカーが引き寄せるトラフィックが少なくなることを意味する。

要約すると、偽造オリジン・サブプレフィックス・ハイジャックは、不正な経路のAS_PATH長が長くなるにもかかわらず、通常のサブプレフィックス・ハイジャックと同じ影響を与える。偽造オリジン・サブプレフィックス・ハイジャックは、偽造オリジン・プレフィックス・ハイジャックよりも被害が大きくなる。

4. RPKIの測定

2017年6月に実施されたネットワーク測定では、ROAで認可されたIPプレフィックスの12%が、プレフィックス長よりも長いmaxLength値を持っていることが明らかになった。このうち、大多数(84%)は最小ではなかった。これらは、正当なASがBGPでアナウンスしていないサブプレフィックスが含まれているため、偽造オリジン・サブプレフィックス・ハイジャックに対して脆弱であった。詳細は、[GSG17]を参照のこと。

これらの測定結果は、オペレータが一般的にmaxLength属性の設定を誤り、知らず知らずのうちに、偽造オリジン・サブプレフィックス・ハイジャックに加担していることを示唆している。つまり、オペレータは、偽造オリジン・ハイジャックに対して、必要以上に大きな攻撃対象をさらしていることになる。

5. 最小ROAとmaxLengthに関する推奨事項

オペレータは、可能な限り最小ROAを使用する必要がある(SHOULD)。最小ROAには、BGPでASが実際に発信したIPプレフィックスだけが含まれ、それ以外のIPプレフィックスは含まれない。例についてはセクション3を参照のこと。

通常、ROAにmaxLength属性を含めると、たいていのROAは最小ではなくなるため、オペレータはROAにmaxLength属性を使用することを避ける必要がある(SHOULD)。

このような例外の1つは、maxLength値で認可されるすべてのMore Specificプレフィックスがすべて、実際にASからROAでアナウンスされている場合である。もう1つの例外は、(a) maxLength値がROAで指定されたプレフィックス長に比べて大幅に大きく、(b) その範囲内でMore SpecificプレフィックスがROAのASから多数アナウンスされている場合である。実際には、このようなケースは(発生したとしても)稀である。この場合、オペレーターの裁量が必要である。

ROAはすでにIPプレフィックスのリスト[RFC6482]に対応しているため、この慣行では、RPKI仕様を変更する必要はなく、RPKIの署名済みROAの数をむやみに増やす必要もない。この実践がRPKIエコシステムのパフォーマンスに最小限の影響しか与えない理由の詳細については、[GSG17]を参照のこと。

これらの推奨事項を実装し、RPKIシステムで既存のROAを公開しているオペレータは、特にmaxLength属性を使用する場合、そのようなオブジェクトのレビューを実行し、含まれるプレフィックス・セットが現在のBGPオリジンとルーティング・ポリシーに関して「最小」であることを確認しなければならない(MUST)。公開されたROAは、必要に応じて置き換えなければならない(MUST)。このような作業は、オペレータがいずれかのポリシーに変更を加えるたびに繰り返さなければならない(MUST)。

5.1. アドホックなルーティングの変更とDDoS軽減の促進

運用要件として、IPプレフィックスの経路がほとんど、あるいはまったく事前の警告なしに、アドホックに発信されることが必要になる場合がある。このような状況の例として、オペレータがBGPを使用して「スクラビング(洗浄)・センター」経由でトラフィックをリダイレクトするDDoS軽減サービスを利用する場合がある。

このようなアドホックなルーティング変更が有効であることを保証するには、新しい経路を検証するROAの存在が必要である。しかし、RPKIで新しく作成されたオブジェクトは、BGPのルーティング・アップデートよりもかなり遅い速度で、リライリング・パーティーに見えるようになるという事実があるため、問題が生じる。

理想的には、アドホック経路を検証するROAを事前に作成するのではなく、必要に応じて「オンザフライ」で作成したい。ただし、これは、RPKIデータの伝播によって課せられる遅延が、その状況で許容範囲内であることが保証されている場合に限り、実際に役に立つ。DDoS攻撃への対応など、一刻を争う介入では、これが当てはまらない可能性がある。

したがって、問題のROAは通常、ルーティング介入よりかなり前に作成する必要があるが、そのようなROAは、場合によっては(常にではないが)BGPで発信されるIPプレフィックスを含むため、最小にはならない。

この場合、ROAは以下のIPプレフィックスだけを含める必要がある(SHOULD):

(1) 常にBGPで発信されるIPプレフィックスの集合、および
(2) BGPで発信されることもあるが、常に発信されるわけではないIPプレフィックスの集合。

ROAには、オペレータがBGPで発信されないことが分かっているIPプレフィックスを含めないほうがよい(SHOULD NOT)。一般的に、ROAはmaxLength属性を使用しても含まれるプレフィックスの集合に影響を与えない限り、使用しないほうがよい(SHOULD NOT)。

最小ROAを発行できない状況を説明するために、実行例を示す。

RPKIを導入する前に、次のシナリオを考えてみる。AS 64496が192.168.0.0/16をアナウンスし、AS 64500を保持するDDoS軽減サービス・プロバイダと契約しているとする。さらに、DDoS軽減サービス契約は 192.168.0.0/22でカバーされるすべてのIPアドレスに適用されると仮定する。DDoS攻撃が検出され、AS 64496によって報告されると、AS 64500は直ちに192.168.0.0/22を発信し、すべてのDDoSトラフィックを自身のAS 64500に引き付ける。トラフィックはAS 64500で洗浄され、バックホール・リンクを経由して、AS 64496に送り返される。DDoS攻撃中、DDoS軽減サービス・プロバイダAS 64500は、AS 64496の/16プレフィックスよりも長い/22プレフィックスを発信するため、通常AS 64496に送信されるすべてのトラフィック (192.168.0.0/22のアドレス宛て)が、代わりにAS 64500に送られることに注意する。いくつかの展開では、/22経路の発信はAS 64496によって実行され、AS 64500にのみアナウンスされ、AS 64500はそのプレフィックスのトランジットをアナウンスする。このバリエーションは、ここで考慮される特性を変えるものではない。

⚠️ 実行例

まず、セクション3で説明したように、RPKIがAS 64496の最小ROAしか持たなかったと仮定する。しかし、AS 64500に/22プレフィックスをアナウンスすることを認可するROAが存在しない場合、DDoS軽減(およびトラフィック洗浄)スキームは機能しない。つまり、DDoS攻撃中にAS 64500がBGPで/22プレフィックスを発信した場合、そのアナウンスは無効となる[RFC6811]。

したがって、RPKIは2つのROAが必要となる。1つはAS 64496用、もう1つはAS 64500用である。

ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) 
ROA:(192.168.0.0/22, AS 64500)

どちらのROAも maxLength属性を使用していないが、2番目のROAには、通常の運用時にBGPの誰からも発信されはない/22プレフィックスが含まれているため、「最小」ではない。この/22プレフィックスは、AS 64500がDDoS攻撃時にDDoS軽減サービスの一環として発信するものである。

ただし、このスキームにリスクがないわけではない。つまり、192.168.0.0/22のすべてのIPアドレスは、/22プレフィックスが発信されていない通常運用時の、偽造オリジン・サブプレフィックス・ハイジャックに対して脆弱である。(ハイジャッカーAS 64511は、「192.168.0.0/22: AS 64511, AS 64500」というBGPアナウンスを送り、AS 64511がAS 64500のネイバーであると偽り、AS 64500が192.168.0.0/22から発信されていると偽る。)

状況によっては、AS 64500のDDoS軽減サービスは、DDoSトラフィックを引き付け、洗浄する量を制限したい場合がある。DDoS攻撃が192.168.0.0/24のIPアドレスのみをターゲットにしていたとする。次に、AS 64500のDDoS軽減サービスは、攻撃を受けている/24プレフィックスに指定されたトラフィックのみを引き付け、/22プレフィックス全体を引き付けないようしたい。これを可能にするために、RPKIはAS 64496 用とAS 64500用の2つのROAを持つ必要がある。

ROA:(192.168.0.0/16, 192.168.225.0/24, AS 64496) 
ROA:(192.168.0.0/22-24, AS 64500)

2番目のROAは、AS 64500が192.168.0.0/22の/24サブプレフィックスを明示的に発信できるようにするために、maxLength属性を使用している。

先ほどと同様に、2つ目のROAは、通常の運用中にBGP内の誰からも発信されないプレフィックスが含まれているため、「最小」ではない。また、192.168.0.0/22に含まれるすべてのIPアドレスは、/22プレフィックスが発信されない通常運用時、偽造オリジン・サブプレフィックス・ハイジャックに対して脆弱である。

この2つ目のROAで、maxLength属性の使用には、追加のリスクも伴う。AS 64500のDDoS軽減サービスが、この空間でのDDoS攻撃中に、プレフィックス192.168.0.0/24を発信することを認可する一方で、/22プレフィックスがカバーする他の/24プレフィックス(つまり、192.168.1.0/24、192.168.2.0/24、192.168.3.0/24)は、偽装オリジン・サブプレフィックス攻撃に対して脆弱になる。

5.2. プレフィックス・ハイジャックに対応した防御的デアグリゲーション

ある種のプレフィックス・ハイジャック(特に、上記で説明した偽造オリジン・サブプレフィックス・ハイジャック)に対応する場合、被害者は「防御的デアグリゲーション」を実行する、つまり、RPKI-ROV[RFC6811]を実行していないネットワークにおいて、ハイジャックされた経路と競合して最適パスとして選択されるように、More-Specificプレフィックスを発信し始めることができる。

被害者とハイジャッカー間のすべてのパスにおいて、少なくとも1つのASがRPKI-ROV無効なプレフィックスをフィルタリングしているトポロジーでは、被害者が発行した最小ROAの存在により、攻撃者にトポロジー的に近いネットワークに、防御的なMore-Specificプレフィックスが伝播されなくなる場合がある。そのため、この対応の有効性が損なわれる。

とはいえ、本文書では、このようなリスクがある場合でも、可能な限り、ネットワーク・オペレータは最小ROAを公表することを推奨する。その理由は:

最小ROAは、このような攻撃の直接的な影響に対して、可能な限り最善の保護を提供し、このような対応が必要になる可能性を低くする。
ネットワーク・オペレータによるRPKI-ROVの採用が増えれば、時間の経過とともに、このリスクが存在する近隣の規模が縮小する。そして
潜在的な被害者は、防御経路が隠蔽されているネットワークと直接外部BGP(EBGP)隣接関係を確立するなど、このような近隣のサイズを縮小する他の方法を利用できる。

6. RTDRフィルタリング・シナリオの考慮事項

ここでは、宛先ベースのRTDR(他では「Remotely Triggered Black Hole」と呼ばれる)フィルタリングの場合のROAとRPKI-ROV[RFC6811]に関連する考慮事項を説明する。RTDRフィルタリングでは、特定性の高いプレフィックス(IPv4では/24よりも大きく、IPv6では/48よりも大きく、場合によっては IPv4では/32、IPv6では/128)が BGPでアナウンスされる。これらのアナウンスには、[RFC7999]で定義されているよく知られたBGPコミュニティのタグが付けられる。上記の理由から、宛先ベースのRTDRフィルタリングに対応するために、大きなmaxLength値を使用したり、このような特定性の高いプレフィックスをROAに含めることは、明らかに望ましくない。

結果として、RPKI-ROV[RFC6811]はRTDR経路の検証には適していない。RPKIの使用を通じてこのユースケースに対処するための新しい手順の仕様は、本文書の範囲外である。

したがって、

オペレータは、RTDR経路を広告する目的で(追加のROAを作成するか、maxLength属性を使用して)非・最小ROAを作成しないほうがよい(SHOULD NOT)。そして
隣接する自律システムのオペレータがBGP経由でRTDR経路を広告する手段を提供するオペレータは、非・最小ROAの作成をその使用の前提条件にしてはならない(MUST NOT)。

7. ユーザ・インタフェース設計の推奨事項

ROAを作成または変更する場合、オペレータによるRPKIシステムとのやり取りのほとんどは、基本となるエンコード、署名、発行操作を抽象化したユーザ・インタフェースを介して行われる。

本文書は、このようなユーザ・インタフェースの設計者および/または提供者が、一般的に非・最小ROAを作成するリスク、特にmaxLength属性を使用することのリスクについて、ユーザの注意を喚起する警告を提供する必要がある(SHOULD)と推奨する。

このようなシステムによって提供される警告は、純粋にmaxLength属性を組み込むことに基づく一般的な警告から、問題のオペレータの監視可能なBGPルーティング・ポリシーに基づくカスタマイズされたガイダンスまで、性質が異なるかもしれない。この点で行われる選択は、実装の対象となるユーザ層に依存することが予想される。

8. 運用上の考慮事項

本文書で規定する推奨事項(特にセクション5の推奨事項)には、運用の機敏性とセキュリティの間のトレードオフを伴う。

最小ROAを発行するという推奨慣行を採用するオペレータは、定義上、BGPで発信されるプレフィックスの集合の変更を有効にするために、既存の発行済みROAの集合に変更を加える必要がある。

事前に計画されたルーティング変更の場合でも、発行されたROAへの変更を組み込むために既存の手順を更新する必要があり、その変更が反映されるまでに追加の時間が必要になるかもしれない。

オペレータは、強調表示された問題(特にセクション5.1と5.2の問題)を、それぞれの運用要件に照らし合わせて慎重に検討することが推奨される。これを怠ると、最悪の場合、自らによるサービス拒否が発生する可能性がある。

セクション5での推奨事項は、BGPで多くのMore-Specific広告が行われるような大規模なIPアドレス空間を利用するオペレータにとっては、より面倒なものになる可能性がある。このようなネットワーク・オペレータは、手作業による運用負荷を最小限に抑えるために、必要な手順を自動化する機会を模索することが推奨される。

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

本文書は、[RFC6811]で定義されているRPKI-ROVの使用に関する推奨事項を示しており、そこで規定されている以上の追加のセキュリティ考慮事項を導入するものではない。

10. IANA に関する考慮事項

この文書にはIANAのアクションはない。

11. 参考文献

11.1. 引用文献

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.

[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>.

[RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, <https://www.rfc-editor.org/info/rfc7115>.

[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>.

11.2. 参考文献

[GCHSS] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. Shulman, "Are We There Yet? On RPKI's Deployment and Security", NDSS 2017, February 2017, <https://eprint.iacr.org/2016/1010.pdf>.

[GSG17] Gilad, Y., Sagga, O., and S. Goldberg, "MaxLength Considered Harmful to the RPKI", CoNEXT '17, DOI 10.1145/3143361.3143363, December 2017, <https://eprint.iacr.org/2016/1015.pdf>.

[LSG16] Lychev, R., Shapira, M., and S. Goldberg, "Rethinking security for internet routing", Communications of the ACM, DOI 10.1145/2896817, October 2016, <http://cacm.acm.org/magazines/2016/10/207763-rethinking-security-for-internet-routing/>.

[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, DOI 10.17487/RFC5737, January 2010, <https://www.rfc-editor.org/info/rfc5737>.

[RFC6907] Manderson, T., Sriram, K., and R. White, "Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties", RFC 6907, DOI 10.17487/RFC6907, March 2013, <https://www.rfc-editor.org/info/rfc6907>.

[RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G. Hankins, "BLACKHOLE Community", RFC 7999, DOI 10.17487/RFC7999, October 2016, <https://www.rfc-editor.org/info/rfc7999>.

[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>.

謝辞

本文書の執筆にあたり、オマール・サッガとアリス・ランブリアニディスに貢献と協力をいただいた。また、マティアス・ヴァエリッシュ、タイ・デ・コック、アムリーシュ・フォーカー、エリック・ヴィンク、アルバロ・レタナ、ジョン・スカダー、ロマン・ダニリュー、アンドリュー・アルストン、マレー・クチェラウィにコメントと提案、Gen-ARTのレビューをしてくれたロニ・イーブン、ART-ARTのレビューをしてくれたジーン・マホーニー、Routing Area Directorateのレビューをしてくれたエース・リンデム、Security Area Directorateのレビューをしてくれたショーン・ターナーにも感謝する。

著者のアドレス

ヨッシ・ギラッド
エルサレムのヘブライ大学
Rothburg Family Buildings
Edmond J. Safra Campus
Jerusalem 9190416
イスラエル
メール: yossigi@cs.huji.ac.il

シャロン・ゴールドバーグ
ボストン大学
111 Cummington St, MCS135
Boston, MA 02215
アメリカ合衆国
メール: goldbe@cs.bu.edu

コティカラプディ・スリラム
米国国立標準技術研究所
100 Bureau Drive
Gaithersburg, MD 20899
アメリカ合衆国
メール: kotikalapudi.sriram@nist.gov

ジョブ・スナイダース
Fastly
アムステルダム
オランダ
メール: job@fastly.com

ベン・マディソン
Workonline Communications
114 West St
Johannesburg
2196
南アフリカ
メール: benm@workonline.africa

更新履歴

2024.2.4

GitHubで編集を提案

要旨