😎

RFC 8210: リソース公開鍵基盤(RPKI)からルータへのプロトコル、バージョン1

2024/04/03に公開

RFC

rpki

tech

要旨

ルータが、BGPアナウンスの発信元の自律システムと自律システム・パスを検証可能な形で(verifiably)検証するには、リソース公開鍵基盤(RFC 6480)のプレフィックス発信元データとルータ鍵を信頼できるキャッシュから受け取るための、シンプルだが信頼性の高いメカニズムが必要である。本文書では、それらを送るプロトコルについて規定する。

本文書では、RPKI-Routerプロトコルのバージョン1について規定する。RFC 6810はバージョン0について規定している。本文書はRFC 6810を更新するものである。

本文書の位置付け

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

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

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

著作権表示

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

1. はじめに

ルータが、BGPアナウンスの発信元の自律システム(AS)とASパスを検証可能な形で検証するには、暗号的に検証されたリソース公開鍵基盤(RPKI)[RFC6480]のプレフィックス発信元データとルータ鍵を信頼できるキャッシュから受け取るための、シンプルだが信頼性の高いメカニズムが必要である。本文書では、これらを配信するためのプロトコルを規定する。このデザインは、現行世代のISPルータ・プラットフォームの多くで使用できるよう、意図的に制約されている。

本文書は[RFC6810]を更新するものである。

セクション3では展開構造について説明し、セクション4では運用の概要を示す。プロトコルのバイナリ・ペイロードはセクション5で正式に記載し、予期されるプロトコル・データ・ユニット(PDU)のシーケンスはセクション8に記載する。トランスポート・プロトコルのオプションはセクション9に記載する。セクション10ではルータとキャッシュがどのように接続され、認証が設定されるかを詳述する。セクション11では、想定される導入シナリオを記載する。従来のセキュリティとIANAに関する考慮事項で、本文書は終わる。

このプロトコルは、導入経験から新しいセマンティクスを持つPDUが必要だと判断された場合に、それをサポートするために拡張可能である。PDUは、導入経験から変更が要求された場合、バージョン管理される。

⚠️ RPKI-Routerプロトコル・バージョン2について

2024.4.3時点で、RPKI-Routerプロトコルのバージョン2の仕様策定が進んでいる(https://www.ietf.org/archive/id/draft-ietf-sidrops-8210bis-12.html)。RFC 8210からの変更点は以下の通り:

ASPA (Autonomous System Provider Authorization)をサポートするための新しいASPA PDUタイプの追加。

考えられる2つのROA PDUの競合状態、Break Before MakeとShorter Prefix Firstの処理の追加。

複数のキャッシュが構成されている場合の表現の明確化。

プロトコルのバージョン番号は1(1)から2(2)になった。

1.1. 要件言語

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

1.2. RFC 6810からの変更点

本セクションでは、[RFC6810]と本文書に記載されているプロトコルとの間の重要な変更点をまとめる。

新しいルータ鍵PDUタイプ(セクション5.10)が追加された。
明確な(explicit)タイミング・パラメータ(セクション5.8、セクション6)が追加された。
プロトコルのバージョン番号は0(ゼロ)から1にインクリメントされた。
プロトコルのバージョン番号ネゴシエーション(セクション7)が追加された。

2. 用語集

以下の用語は特別な意味で使用する。

グローバルRPKI: RPKIの信頼できるデータは、IANA、地域インターネット・レジストリ(RIR)、各国のインターネット・レジストリ(NIR)、そしてISPの分散サーバ・セットで公開される。[RFC6481]を参照のこと。

キャッシュ: キャッシュとは、公開されたグローバルRPKIデータの結合コピーであり、rsyncプロトコル[RFC5781]またはその後継プロトコルを使用して、定期的に直接または間接的に、フェッチ(取得)またはリフレッシュ(更新)される。リライング・パーティーのソフトウェアは、RPKIの分散データをキャッシュに収集し、検証するために使用される。このキャッシュをさらに信頼するかどうかは、キャッシュ・プロバイダとリライング・パーティー間の問題である。

シリアル番号: 「シリアル番号」は、2^32-1から0までをラップする、正確に増加する32ビットの符号なし整数である。キャッシュの論理バージョンを示す。キャッシュは、親キャッシュまたはプライマリRPKIデータからのデータを正常に更新すると、この値をインクリメントする。キャッシュが更新を受信している間、新しい受信データと暗黙の削除は新しいシリアルと関連付けられるが、フェッチが完了するまで送信してはならない(MUST NOT)。シリアル番号は、異なるキャッシュ間や異なるプロトコルのバージョン間で互換性があるわけではなく、キャッシュ・サーバのリセット後も維持する必要はない。このテーマの詳細については、DNSのシリアル番号計算に関する[RFC1982]を参照のこと。

セッションID: キャッシュ・サーバーが起動すると、セッションIDが生成され、キャッシュのインスタンスを一意に識別し、そのキャッシュ・インスタンスが生成する一連のシリアル番号に結び付ける。これにより、ルータは、使用しているシリアル番号がキャッシュのシリアル番号と一致していることを認識した上で、失敗したセッションを再開することができる。

ペイロードPDU: ペイロードPDUは、このプロトコルの制御メカニズムを伝えるPDUとは対照的に、ルータが使用するデータを含むプロトコル・メッセージである。プレフィックスとルータ鍵はペイロードPDUの例である。

3. 展開構造

ルータに到達するためのRPKIの展開は、以下の3段階の構造になっている。

グローバルRPKI: RPKIの信頼できるデータは、IANA、RIR、NIR、ISPの分散サーバセットで公開される([RFC6481]参照)。

ローカルキャッシュ: ローカルキャッシュは、RPKIデータの収集および検証されたキャッシュのローカルセットである。ルータや他のクライアントなどのリライング・パーティーは、使用するキャッシュとの信頼関係を築き、信頼されたトランスポート・チャネルを持たなければならない(MUST)。

ルータ: ルータは、本文書に記載するプロトコルを使用してローカルキャッシュからデータをフェッチする。これはキャッシュのクライアントと呼ばれる。ルータ自身がキャッシュの信頼性を保証し、キャッシュに対して自身を認証するメカニズムがあってもよい(MAY)(セクション9参照)。

4. 運用概要

ルータは、クライアント/サーバ関係を持つ1つ以上のキャッシュへの接続を確立し、オープンのままにする。ルータはキャッシュをセミオーダ・リストで設定し、接続を受け入れる最も優先されるキャッシュまたはキャッシュ・セットへの接続を確立する。

ルータはオペレータがキャッシュとグローバルRPKIの負荷をコントロールできるように、設定によって最も優先されるキャッシュまたはキャッシュ・セットを選択しなければならない(MUST)。

ルータは定期的に、キャッシュからデータを受信した最新のシリアル番号、つまりルータの現在のシリアル番号を、シリアルクエリ形式でキャッシュに送信する。ルータがキャッシュとの新しいセッションを確立するとき、または現在の関係をリセットしたいとき、リセットクエリを送信する。

キャッシュはシリアルクエリに、指定されたシリアル番号以降に行われたすべてのデータ変更を応答する。これはNULLセットかも知れず、その場合はデータ終了PDU(セクション5.8)を送信する。「指定されたシリアル番号以降」を判断するために使用されるシリアル番号の比較は、折り返し(wrap-around)を考慮しなければならない(MUST)ことに留意すること。[RFC1982]を参照のこと。

ルータがキャッシュからすべてのデータレコードを受信すると、現在のシリアル番号を受信したデータ終了PDUのシリアル番号に設定する。

キャッシュがそのデータベースを更新すると、現在接続しているすべてのルータに通知PDUを送信する。これは、ルータがアップデートのためにポーリングするには今が良いタイミングであることを示すヒントだが、あくまで単なるヒントに過ぎない。このプロトコルは、いかなる場合でも、ルータは更新を定期的にポーリングする必要がある。

厳密に言えば、ルータは更新のたびに完全なデータセットを要求するだけで、キャッシュを追随できるが、これは非常に非効率的である。シリアル番号ベースの増分更新メカニズムにより、最後の更新以降に変更されたデータレコードだけを効率的に転送することができる。増分転送に基づく他の更新プロトコルと同様、ルータは何らかの理由でキャッシュが必要な増分データを提供できない場合、完全転送にフォールバックできるように準備しなければならない。いくつかの増分転送プロトコルとは異なり、このプロトコルはフォールバック・プロセスを開始するための明示的な要求をルータが行う必要がある。これは意図的なもので、キャッシュには、そのルータがより良いサービスを提供できるかも知れない他のキャッシュとのセッションも確立しているかどうかを知る方法がないからである。

キャッシュサーバは時間に依存する証明書とROA(経路オリジン認可、[RFC6480]を参照)を評価しなければならないため、サーバの時計は約1時間の許容範囲内で正確でなければならない(MUST)。

5. プロトコル・データ・ユニット (PDU)

キャッシュとルータ間のやり取りは、セクション8に記載しているルールに従って、以下のPDUの交換シーケンスとなる。

予約フィールド(PDU図で「ゼロ」とマークされている)は、送信時にはゼロでなければならず(MUST)、受信時には無視しなければならない(MUST)。

5.1. PDUのフィールド

PDUは以下のデータ要素を含む:

プロトコル・バージョン: プロトコルのバージョンを示す8ビットの符号なし整数(現在は1)。

PDUタイプ: PDUのタイプを示す8ビットの符号なし整数(IPv4プレフィックスなど)。

シリアル番号: このPDUセットが上流キャッシュサーバから受信したとき、またはグローバルRPKIから収集されたときのRPKIキャッシュのシリアル番号。キャッシュは、親キャッシュまたはグローバルRPKIから厳密に検証された更新を完了すると、そのシリアル番号をインクリメントする。

セッションID: 16ビットの符号なし整数。キャッシュサーバが起動すると、キャッシュのインスタンスを識別し、そのキャッシュ・インスタンスが生成するシリアル番号のシーケンスに結び付けるためにセッションIDを生成する。これにより、ルータは使用しているシリアル番号がキャッシュのシリアル番号と一致していることを認識している上で、失敗したセッションを再開することができる。プロトコル・バージョンがネゴシエートされた後(セクション7)、ルータまたはキャッシュのいずれかが、セッションIDの値が相手の値と同じでないことを検出した場合、不一致を検出した側は、コード0(「破損したデータ」)のエラーレポートPDUで直ちにセッションを終了しなければならない(MUST)。ルータはそのキャッシュから学習したすべてのデータをフラッシュしなければならない(MUST)。

セッションは、特定のプロトコル・バージョンに固有であることに留意する。つまり、キャッシュサーバがこのプロトコルの複数バージョンをサポートし、たまたま複数のプロトコル・バージョンで同じセッションID値を使い、さらに、たまたま同じセッションIDで異なるプロトコルのバージョンを使う2つ以上のセッションに同じシリアル番号値を使う場合、シリアル番号が一致しない。シリアル番号が一致しているかどうかを完全にテストするには、プロトコル・バージョン、セッションID、シリアル番号を比較する必要がある。混乱のリスクを軽減するために、キャッシュサーバは複数のプロトコル・バージョン間で同じセッションIDを使用すべきではない(SHOULD NOT)が、使用する場合でも、ルータは同じセッションIDを持っていたとしても、異なるプロトコル・バージョン・フィールドを持つセッションを別個のセッションとして扱わなければならない(MUST)。

キャッシュがセッションIDを誤って再利用し、ルータがセッションが変更された(古いセッションIDと新しいセッションIDが同じ数値を持つ)ことに気付かない場合、ルータはキャッシュの内容について混乱する可能性がある。ルータが混乱していることを発見するまでにかかる時間は、シリアル番号も再利用されているかどうかによって異なる。古いセッションと新しいセッションのシリアル番号が十分に異なれば、キャッシュはルータのシリアルクエリにキャッシュリセットで応答し、問題は解決する。しかし、シリアル番号が近い場合、キャッシュはキャッシュ応答で応答するが、ルータを同期させるには十分ではないかも知れない。このような場合、ルータがキャッシュが予期する状態と自身の状態との間に何らかの不一致を検出する可能性は高いが、確実ではない。例えば、キャッシュ応答は、ルータが保持していないレコードを削除するようにルータに指示するかも知れないし、ルータがすでに保持しているレコードを追加するようにルータに指示するかも知れない。このような場合、ルータはエラーを検出してセッションをリセットする。ルータが同期しないまま続く可能性がある1つのケースは、キャッシュ応答の中に、ルータが現在保持しているデータと矛盾するものがない場合である。

セッションIDのために永続的ストレージを使うか、セッションIDを生成するためにクロックベースのスキームを使うことで、セッションIDの衝突のリスクを回避すべきである。

セッションIDは疑似ランダム値かも知れないし、キャッシュが信頼できるストレージを持つなら厳密に増加する値かも知れない。POSIXのtime()関数のようなエポックからの秒数のタイムスタンプ値は良いセッションID値になる。

長さ: 長さフィールドを含む8バイトのヘッダを含む、PDU全体のバイト数を値として持つ32ビットの符号なし整数。

フラグ: フラグ・フィールドの最下位ビットは、アナウンスの場合は1、撤回の場合は0である。プレフィックスPDU(IPv4またはIPv6)の場合、このフラグは、このPDUがプレフィックスをアナウンスする新しい権利をアナウンスするか、以前にアナウンスした権利を撤回するかを示す。撤回は、まったく同じプレフィックス、長さ、最大長、自律システム番号(ASN)を持つ、以前にアナウンスされた1つのプレフィックスPDUを実質的に削除する。同様に、ルータ鍵PDUの場合、このフラグは、この PDUが新しいルータ鍵をアナウンスするのか、まったく同じAS番号、subjectKeyIdentifier、および subjectPublicKeyInfoを持つ、以前にアナウンスされた1つのルータ鍵PDUを削除するのかを示す。

フラグ・フィールドの残りのビットは、将来の使用のために予約されている。プロトコル・バージョン1では、それらは送信時にはゼロでなければならず(MUST)、受信時には無視されなければならない(MUST)。

プレフィックス長: プレフィックス要素で許可される最短のプレフィックスを示す8ビットの符号なし整数。

最大長: プレフィックス要素で許容される最長のプレフィックスを示す8ビットの符号なし整数。これは、プレフィックス長要素より小さくしてはならない(MUST NOT)。

プレフィックス: ROAのIPv4またはIPv6プレフィックス。

自律システム番号: プレフィックスをアナウンスすることを許可された、またはルータ鍵に関連付けられたASNを表す32ビットの符号なし整数。

サブジェクト鍵識別子: [RFC6487]に記載されている、ルータ鍵の20オクテットのサブジェクト鍵識別子(SKI)値。

サブジェクト公開鍵情報: [RFC8208]に記載されている、ルータ鍵のsubjectPublicKeyInfo値。これは、subjectPublicKeyInfo SEQUENCEのASN.1タグと長さの値を含む、subjectPublicKeyInfoの完全なASN.1 DER符号化である。

更新間隔: 通常のキャッシュ・ポーリング間の間隔。セクション6を参照のこと。

再試行間隔: キャッシュ・ポーリングが失敗した後に再試行する間隔。セクション6を参照のこと。

有効期限切れ間隔: 後続のキャッシュ・ポーリングが成功しなかった場合に、キャッシュからフェッチされたデータが有効であり続ける間隔。セクション6を参照のこと。

5.2. シリアル通知

キャッシュは、キャッシュに新しいデータがあることをルータに通知する。

セッションIDは、シリアル番号が見合ったもの(commensurate)であること。つまり、キャッシュ・セッションが変更されていないことをルータに再確認させるものであること。

シリアル通知PDUを受信すると、ルータは更新間隔タイマー(セクション6を参照)が期限切れになるのを待たずに、直ちにシリアルクエリ(セクション5.3)またはリセットクエリ(セクション5.4)を発行してもよい(MAY)。

シリアル通知は、ルータからのメッセージに応答しない、キャッシュが送信できる唯一のメッセージである。

ルータとキャッシュの間でプロトコル・バージョンの合意に、まだネゴシエーションを行っている初期起動期間中、ルータがシリアル通知PDUを受信した場合、たとえそのシリアル通知PDUが予期しないプロトコル・バージョンであっても、ルータはそのシリアル通知PDUを単純に無視しなければならない(MUST)。詳細についてはセクション7を参照のこと。

fig1

5.3. シリアルクエリ

ルータはシリアルクエリを送信し、シリアルクエリで指定されたシリアル番号以降に発生したすべてのアナウンスと撤回をキャッシュに問い合わせる。

キャッシュは、ルータが指定したシリアル番号以降の変更(おそらくNULLの)記録を持っている場合、キャッシュ応答PDU(セクション5.5)でこのクエリに応答し、続いて0個以上のペイロードPDUとデータ終了PDU(セクション5.8)が続く。

シリアルクエリに応答するとき、キャッシュはルータをキャッシュと同期させるために必要な最小限の変更セットを返さなければならない(MUST)。つまり、特定のプレフィックスまたはルータ鍵が、ルータが指定したシリアル番号とキャッシュの現在のシリアル番号の間で複数の変更を受けた場合、キャッシュはそれらの変更をマージして、それらの変更の可能な限り単純なビューをルータに提示しなければならない(MUST)。一般に、これは特定のプレフィックスまたはルータ鍵に対して、データ・ストリームは最大でも1つの撤回とそれに続く最大でも1つのアナウンスを含むことを意味し、すべての変更がキャンセルされた場合、データ・ストリームはプレフィックスまたはルータについてまったく言及しないことを意味する。

このアプローチの理論的根拠は、RPKI-Routerプロトコルの全体の目的が、ルータからキャッシュに作業をオフロードすることであり、したがって、変更セットを簡素化し、ルータの作業を軽減するのがキャッシュの仕事であるべきだということである。

キャッシュがルータを更新するために必要なデータを持っていない場合(おそらく、そのレコードがシリアルクエリのシリアル番号まで遡らないため)、キャッシュはキャッシュリセットPDU(セクション5.9)で応答する。

セッションIDは、シリアル番号が適切であること、つまりキャッシュセッションが変更されていないことを保証するために、ルータがどのインスタンスを期待しているかをキャッシュに伝える。

fig1

5.4. リセットクエリ

ルータ、アクティブで現在の、撤回されていないデータベース全体を受信したいことをキャッシュに伝える。キャッシュはキャッシュ応答PDU(セクション5.5)で応答し、続いて0個以上のペイロードPDUとデータ終了PDU(セクション5.8)が続く。

fig1

5.5. キャッシュ応答

キャッシュは0個以上のペイロードPDUでクエリに応答する。シリアルクエリ(セクション5.3)に応答するとき、キャッシュは、クライアントルータから送信されたシリアル番号以降に発生したアナウンスと撤回を送信する。リセットクエリ(セクション5.4)に応答するとき、キャッシュは保持しているすべてのデータレコード・セットを送信する。この場合、ペイロードPDUの撤回/アナウンス・フィールドの値は1(アナウンス)を持たなければならない(MUST)。

リセットクエリに応答して、セッションIDの新しい値が、将来の確認のためにキャッシュセッションのインスタンスをルータに伝える。シリアルクエリに応答して、セッションIDが同じであれば、ルータはシリアル番号が相応であること、つまりキャッシュセッションが変更されていないことを再確認する。

fig1

5.6. IPv4プレフィックス

fig1

フラグフィールドの最下位ビットは、アナウンスの場合は1、撤回の場合は0である。

RPKIでは、署名証明書が同一のROAを2つ発行することを妨げるものはない。この場合、オブジェクト間に意味上の違いはなく、単にプロセスが冗長なだけである。

RPKIでは、ルータが同一のIPvX PDUに見える実際のニーズもある。これは、アップストリームの証明書が再発行される場合、または検証チェーンでアドレス保有権の移転が行われる場合に発生する可能性がある。ROAはルータ的には同一である。つまり、同じ {Prefix、Len、Max-Len、ASN}を持つが、RPKI内の検証パスは異なる。これはRPKIにとっては重要だが、ルータにとっては重要ではない。

キャッシュサーバは、ルータクライアントに対し、任意の時点で一意の{Prefix, Len, Max-Len, ASN}に対するIPvX PDUを1つだけ持つように伝えたことを確認しなければならない(MUST)。ルータクライアントが、既にアクティブになっているものと同じ{Prefix, Len, Max-Len, ASN}を持つIPvX PDUを受信した場合、Duplicate Notice Receivedエラーを発生させる必要がある(SHOULD)。

5.7. IPv6プレフィックス

fig1

96ビット増えただけで、IPv4プレフィックスPDUと同様である。

5.8. データ終了

キャッシュは、要求に対するデータがもうないことをルータに伝える。

セッションIDとプロトコル・バージョンは、ペイロードPDU(おそらくNULL)シーケンスを開始した、対応するキャッシュ応答のものと同じでなければならない(MUST)。

fig1

更新間隔、再試行間隔、期限切れ間隔はすべて、秒単位で測定される32ビットの経過時間である。これらのパラメータは、後続のシリアルクエリまたはリセットクエリPDUをいつキャッシュに送信するかを決定する際に、キャッシュがルータに期待するタイミング・パラメータを表す。これらのパラメータの使用法と許容値の範囲については、セクション6を参照のこと。

5.9. キャッシュリセット

キャッシュは、ルータが指定したシリアル番号から始まる増分更新をキャッシュが提供できないことをルータに通知するシリアルクエリに応答する場合がある。ルータは、リセットクエリを発行するか、別のキャッシュに切り替えるかを決定しなければならない。

fig1

5.10. ルータ鍵

fig1

フラグ・フィールドの最下位ビットは、アナウンスの場合は1、撤回の場合は0である。

キャッシュサーバは、ルータクライアントに対して、一意の{SKI, ASN, サブジェクト公開鍵}に対するルータ鍵PDUを常に1 だけ持つように指示したことを確認しなければならない(MUST)。ルータクライアントが、すでにアクティブになっているものと同じ {SKI, ASN, サブジェクト公開鍵}を持つルータ鍵PDUを受信した場合、Duplicate Announcement Receivedエラーを発生させる必要がある(SHOULD)。

特定のASNは、異なるサブジェクト公開鍵値を持つ複数のルータ鍵PDUに出現する可能性がある一方、特定のサブジェクト公開鍵値が、異なるASNを持つ複数のルータ鍵 PDUに出現する可能性があることに留意する。ルータにとってアナウンスと撤回のセマンティクスをできるだけシンプルに保つという観点から、本プロトコルはこれらのケースを圧縮する試みは行わない。

また、複数の異なるサブジェクト公開鍵値が同じSKIにハッシュされる可能性は、非常に低いとはいえ、あり得ることも留意する。そのため、実装は重複するPDUを検出する際に、SKIだけでなくサブジェクト公開鍵値も比較しなければならない(MUST)。

5.11. エラー報告

このPDUは、いずれかのパーティーがもう一方のパーティーにエラーを報告するために使用する。

エラー報告は他のPDUへの応答としてのみ送信され、エラー報告PDUでエラーを報告するためではない。

エラーコードはセクション12で説明する。

エラーが一般的なもの(例えば「内部エラー」)で、応答先のPDUに関連しない場合、誤りPDUフィールドは空でなければならず(MUST)、カプセル化PDUフィールド長はゼロでなければならない(MUST)。

エラー報告PDUに対して、エラー報告PDUを送信してはならない(MUST NOT)。誤ったエラー報告PDUを受信した場合、そのセッションは切断する必要がある(SHOULD)。

エラーが長過ぎるPDUに関連付けられている場合、つまり、他のエラー報告以外の正当なPDUとしては長過ぎるか、破損している可能性がある長さの場合、エラーPDUフィールドは切り捨ててもよい(MAY)。

診断テキストはオプションである。存在しない場合、エラーテキストの長さフィールドはゼロでなければならない。エラーテキストが存在する場合、それはUTF-8符号化文字列でなければならない(MUST)([RFC3629]参照)。

fig1

6. プロトコル・タイミング・パラメータ

キャッシュがRPKI-Routerプロトコルを介して配布するデータは、キャッシュだけが知っている間隔でグローバルRPKIシステムから取得されるため、ルータがキャッシュをポーリングする意味のある頻度や、データが有効なまま(あるいは、少なくとも変更されないまま)である可能性を、実際に知ることができるのはキャッシュだけである。このような理由から、また、クライアントルータによってキャッシュにかかる負荷をある程度コントロールできるようにするため、データ終了PDUは、キャッシュがルータにタイミング・パラメータを通信できるようにする3つの値を含まれている。

更新間隔: このパラメータは、シリアルクエリまたはリセットクエリPDUを使用して、次にキャッシュのポーリングするまでの待機時間と、その後のポーリングまでの待機時間をルータに指示する。ルータは、このパラメータで示されるよりも早くキャッシュをポーリングしてはならない(SHOULD NOT)。

シリアル通知PDUの受信は、この間隔をオーバーライドし、ルータが更新間隔の期限切れを待たずに即時にクエリを発行することを意味することに留意すること。このタイマーのカウントダウンは、含まれるデータ終了PDUを受信したときに始まる。

最小許容値: 1秒
最大許容値: 86400秒(1日)
推奨されるデフォルト: 3600秒(1時間)

再試行間隔: このパラメータは、失敗したシリアルクエリまたはリセットクエリを再試行するまでの待機時間をルータに指示する。ルータは、このパラメータで示されるより早く再試行してはならない(SHOULD NOT)。プロトコル・バージョンの不一致によってこの間隔は無効になることに留意する。ルータがより低いプロトコル・バージョン番号にダウングレードする必要がある場合、最初のシリアルクエリまたはリセットクエリを直ちに送信してもよい(MAY)。このタイマーのカウントダウンはクエリが失敗した時に開始され、クエリが成功するまで、その後の失敗のたびに再開される。

最小許容値: 1秒
最大許容値: 7200秒(2時間)
推奨されるデフォルト: 600秒(10分)

期限切れ間隔: このパラメータは、後続のクエリを正常に実行できない間に、現在のバージョンのデータを使用し続けることができる期間をルータに指示する。ルータは、このパラメータで指定された時間を超えてデータを保持してはならない(MUST NOT)。このタイマーのカウントダウンは、含まれるデータ終了PDUを受信したときに開始する。

最小許容値: 600 秒(10分)
最大許容値: 172800秒(2日)
推奨デフォルト: 7200 秒(2時間)

ルータが特定のキャッシュに対して一度もクエリを成功させたことがない場合、上記のデフォルトの再試行間隔を使用して定期的に再試行する必要がある(SHOULD)。

キャッシュは、有効期限間隔を更新間隔または再試行間隔よりも大きい値に設定しなければならない(MUST)。

7. プロトコル・バージョンのネゴシエーション

ルータは、リセットクエリまたはシリアルクエリのいずれかを発行して、各トランスポート接続を開始しなければならない(MUST)。このクエリは、ルータが実装しているプロトコル・バージョンをキャッシュに伝える。

バージョン1をサポートするキャッシュが、バージョン0を指定するルータからクエリを受信した場合、キャッシュはプロトコル・バージョン0[RFC6810]にダウングレードするか、エラーコード4(「Unsupported Protocol Version」)を持つバージョン1のエラー報告PDUを送信して、接続を終了しなければならない(MUST)。

バージョン1をサポートしているルータがバージョン0しかサポートしないキャッシュにクエリを送信すると、次の2つのうちのいずれかが起こる。

キャッシュは、おそらくバージョン0のエラー報告PDUで接続を終了する可能性がある。この場合、ルータはプロトコル・バージョン0を使用して接続を再試行してもよい(MAY)。
キャッシュはバージョン0の応答を返す場合がある。この場合、ルータはバージョン0にダウングレードするか、接続を終了しなければならない(MUST)。

上記のどのダウングレードの組み合わせでも、バージョン1の新機能は利用できず、すべてのPDUのバージョン・フィールドは0になる。

このネゴシエーションの間に、どちらかのパーティーが認識できないプロトコル・バージョン(0でも1でもない)を含むPDUを受信した場合、受信したPDU自体がエラー報告PDUでない限り、既知のバージョンにダウングレードするか、エラー報告PDUで接続を終了しなければならない(MUST)。

ルータは、シリアル通知PDUのプロトコル・バージョン・フィールドに関係なく、この初期起動期間中にキャッシュから受け取るかもしれないシリアル通知PDUをすべて無視しなければならない(MUST)。セッションIDとシリアル番号の値は特定のプロトコル・バージョンに固有なので、通知中の値はルータにとって有用ではない。これらの値に意味があったとしても、通知を処理することが持つ唯一の効果は、まだ完了していないバージョン・ネゴシエーション・プロセスの一部として、ルータがすでに送ったものとまったく同じリセットクエリまたはシリアルクエリをトリガーすることである。したがって、バージョン・ネゴシエーションが完了するまで、通知を処理しても何も得られない。

キャッシュは、バージョン・ネゴシエーションが完了する前にシリアル通知PDUを送信してはならない(SHOULD NOT)。しかし、ルータは、プロトコル・バージョン0を提供するキャッシュとの下位互換性のために、そのような通知を(無視することで)処理しなければならない(MUST)。

キャッシュとルータが上記のネゴシエーション・プロセスでプロトコル・バージョンに合意すると、そのバージョンはセッションが存続する間は不変である。プロトコル・バージョンとセッションID間の相互作用についての説明は、セクション5.1を参照のこと。

上記のネゴシエーションが完了した後、いずれかのパーティーが異なるプロトコル・バージョンのPDUを受信した場合、そのパーティーはセッションを切断しなければならない(MUST)。予期しないプロトコル・バージョンを含むPDU自体がエラー報告PDUでない限り、セッションを切断する側は、エラーコード8(「Unexpected Protocol Version」)のエラー報告を送る必要がある(SHOULD)。

8. プロトコルシーケンス

PDU送信のシーケンスは、以下の4つのやり取りに分類される:

8.1. 開始あるいは再起動

fig1

トランスポート接続が最初に確立されるとき、ルータはリセットクエリかシリアルクエリのいずれかを送信しなければならない(MUST)。シリアルクエリは、ルータが同じキャッシュとの壊れたセッションからの有効期限が切れていない重要なデータを持ち、そのセッションのセッションIDを覚えている場合に適している。その場合、前のセッションのセッションIDを含むシリアルクエリは、シリアル番号が相応であること、およびルータとキャッシュが互換性のあるプロトコルのバージョンでやり取りしていることを確認しながら、ルータ自体が最新状態に更新できる。それ以外の場合はすべて、ルータは高速再同期に必要なデータが不足しているため、リセットクエリにフォールバックしなければならない(MUST)。

リセットクエリのシーケンスは、ルータがキャッシュリセットを受信した場合、新しいキャッシュを選択するとき、またはルータが接続を失った可能性がある場合にも使用する。

バージョン・ネゴシエーションの詳細についてはセクション7を参照のこと。

増分更新の生成に必要なデータをキャッシュが保持しなければならない期間を制限するために、ルータは定期的にシリアルクエリまたはリセットクエリを送信しなければならない(MUST)。これは、アプリケーション層でのキープアライブとしても機能する。必要なポーリング頻度の詳細については、セクション6を参照のこと。

8.2. 典型的なやり取り

fig1

キャッシュサーバは、キャッシュのシリアル番号が変更されたときに、ルータは、他の方法よりも早くシリアルクエリを発行する(MAY)見込みで、現在のシリアル番号を持つ通知PDUを送信する必要がある(SHOULD)。これは、[RFC1996]の DNS NOTIFYに似ている。キャッシュは、シリアル通知のレートを1分あたり1回以下に制限しなければならない(MUST)。

トランスポート層が立ち上がり、ルータのタイマーが切れるか、キャッシュが通知PDUを送信したとき、ルータはシリアルクエリを送信して新しいデータを問い合わせ、キャッシュはシリアルクエリよりも新しいすべてのデータを送信する。

キャッシュが古いデータ(withdraws)を保持しなければならない期間を制限するため、ルータは定期的にシリアルクエリまたはリセットクエリのいずれかを送信しなければならない(MUST)。必要なポーリング頻度の詳細については、セクション6を参照のこと。

8.3. 利用可能な増分更新はない

fig1

キャッシュは、ルータが指定したシリアル番号から増分更新を提供できないことをルータに通知する場合、キャッシュリセットでシリアルクエリに応答するかもしれない。これは、キャッシュの状態が失われたか、ルータがポーリング間の待機時間が長過ぎて、キャッシュが不要になったと考える古いデータをクリーンアップしたため、あるいはキャッシュの記憶領域が不足して初期の古いデータを有効期限切れにしなければならなかったことが考えられる。この状態がどのように発生したかに関係なく、キャッシュはキャッシュリセットで応答し、ルータに要求を処理できないことを伝える。ルータがこれを受け取ると、キャッシュリストにあるより優先度の高いキャッシュへの接続を試みる必要がある(SHOULD)。優先度の高いキャッシュがない場合、リセットクエリを発行し、キャッシュから新しくデータ全体を取得しなければならない(MUST)。

8.4. キャッシュに利用可能なデータがありません

fig1

キャッシュは、シリアルクエリまたはリセットクエリのいずれかに応答して、キャッシュが更新をまったく提供できないことをルーターに通知する。最も可能性の高い原因は、おそらく再起動によってキャッシュの状態が失われ、まだ回復していないことである。キャッシュが、アクティブなセッションが切断することなく、そのような状態になる可能性はあるが、ルータは最初に接続し、キャッシュがまだデータベースを再構築中にリセットクエリを発行したときに、この動作が発生する可能性が高い。

ルータは、この種のエラーを受け取るとき、そのキャッシュリストにある他のキャッシュへの接続を優先順位に従って試みる必要がある(SHOULD)。他に利用可能なキャッシュがない場合、ルータはキャッシュから新しい使用可能なデータを取得するまで、定期的にリセットクエリを発行しなければならない(MUST)。

9. トランスポート

ルーターとキャッシュ間のトランスポート層セッションは、永続的なセッションでバイナリPDUを伝送する。

不正なルータによるキャッシュのなりすましやDoS攻撃を防ぐために、ルータとキャッシュが相互に認証されていることが強く望まれる。ペイロードの完全性保護は、中間者攻撃(MITM)攻撃から保護するためにも望ましい。残念ながら、現在使用されているすべてのプラットフォームにおいて、これを行うためのプロトコルは存在しない。したがって、本文書の執筆時点では、認証と完全性保護を提供する実装が必須のトランスポートは存在しない。

切断されたが終了していないセッションの危険を減らすために、選択したトランスポート・プロトコルで利用可能な場合、キャッシュとルータの両方でキープアライブを有効にする必要がある(SHOULD)。

TCP認証オプション(TCP-AO)[RFC5925]が、オペレータが展開するすべてのプラットフォームで利用できるようになったとき、実装が必須のトランスポートになることが期待される。

キャッシュとルータは、ポートrpki-rtr (323)を利用してTCP経由で保護されていないトランスポートを実装しなければならない(MUST)。セクション14を参照のこと。オペレータは、認証問題への露出を減らすために、アクセス制御リスト(ACL)のような手続き的手段を使用する必要がある(SHOULD)。

保護されていないTCPがトランスポートである場合、キャッシュとルータは同じ信頼され制御されたネットワーク上に存在しなければならない(MUST)。

オペレータが利用できる場合、キャッシュとルータは以下のより保護されたプロトコルのいずれかを使用しなければならない(MUST)。

キャッシュとルータは、rpki-rtrポート経由でTCP-AOトランスポート[RFC5925]を使用する必要がある(SHOULD)。
キャッシュとルータは、通常のSSHポートを使用してSecure Shellバージョン2(SSHv2)トランスポート[RFC4252]を使用してもよい(MAY)。例については、セクション9.1を参照のこと。
キャッシュとルータは、rpki-rtrポート経由でTCP MD5トランスポート[RFC2385]を使用してもよい(MAY)。TCP MD5はTCP-AO[RFC5925]によって廃止されたことに留意すること。
キャッシュとルータは、rpki-rtrポート経由でTCP over IPsecトランスポート[RFC4301]を使用してもよい(MAY)。
キャッシュとルータは、ポートrpki-rtr-tls(324)経由でトランスポート層セキュリティ(TLS)トランスポート[RFC5246]を使用してもよい(MAY)。セクション14を参照のこと。

9.1. SSHトランスポート

SSH上で実行するには、クライアント・ルータはまずSSHv2トランスポート・プロトコルを使用してSSHトランスポート接続を確立し、クライアントとサーバはメッセージの完全性と暗号化のために鍵を交換する。次に、クライアントは、SSH認証プロトコル[RFC4252]に記載されているように、アプリケーションを認証するために「ssh-userauth」サービスを呼び出す。アプリケーションの認証が成功すると、クライアントはSSH接続プロトコルとしても知られる「ssh-connection」サービスを呼び出す。

ssh-connectionサービスが確立された後、クライアントは「session」タイプのチャネルを開き、SSHセッションを確立する。

SSHセッションが確立されると、アプリケーションは「rpki-rtr」と呼ばれるSSHサブシステムとしてアプリケーション・トランスポートを呼び出す。サブシステムのサポートはSSHv2の機能であり、SSHv1には含まれていない。このプロトコルをSSHサブシステムとして実行すると、アプリケーションがシェル・プロンプトを認識したり、シェル起動時に送信されるシステム・メッセージのような余計な情報をスキップする必要がなくなる。

ルータとキャッシュは、何らかの合理的に安全な手段で、アウトオブバンドで鍵を交換しているものと仮定する。

SSHトランスポートをサポートするキャッシュサーバは、RSA認証を受け入れなければならず(MUST)、楕円曲線デジタル署名アルゴリズム(ECDSA)認証も受け入れる必要がある(SHOULD)。ユーザ認証に対応しなければならない(MUST)。ホスト認証に対応してもよい(MAY)。実装ではパスワード認証をサポートしてもよい(MAY)。クライアントルータは、MITM攻撃を回避するためにキャッシュの公開鍵を検証する必要がある(SHOULD)。

9.2. TLSトランスポート

TLSトランスポートを使用するクライアント・ルータは、無許可のルータからの接続を拒否することでキャッシュが負荷を管理できるようにするために、自分自身をキャッシュに認証するためにクライアント側の証明書を提示しなければならない(MUST)。原則的に、どのようなタイプの証明書と認証局(CA)を使用してもよいが、一般的に、キャッシュ・オペレータは独自の小規模CAを作成し、認可された各ルータに証明書を発行することを望むだろう。これは資格情報(credential)のロールオーバーを簡素化し、適切なCAからの、未失効かつ期限切れになっていない証明書であればどれでも使用できる。

このプロトコルでクライアント・ルータを認証するために使用される証明書は、1つ以上のiPAddressアイデンティティを含むsubjectAltName拡張[RFC5280]を含まれなければならない (MUST)。ルータの証明書を認証するとき、キャッシュはTLS接続のIPアドレスをこれらのiPAddressアイデンティティと照合しなければならず(MUST)、どのiPAddressアイデンティティも接続に一致しない場合、接続を拒否する必要がある(SHOULD)。

ルータは、MITM攻撃を回避するために、[RFC6125]に記載されているように、 subjectAltName dNSNameアイデンティティを使用して、キャッシュのTLSサーバ証明書も検証しなければならない(MUST)。ここでは、[RFC6125]で定義されているルールとガイドラインを適用するが、以下の考慮事項がある:

DNS-ID識別子タイプ(つまり、subjectAltName拡張のdNSName ID)のサポートは、TLSを使用するrpki-rtrサーバおよびクライアントの実装において必須である。rpki-rtrサーバ証明書を発行する認証局は、DNS-ID識別子タイプをサポートしなければならず(MUST)、DNS-ID識別子タイプがrpki-rtrサーバ証明書に存在しなければならない(MUST)。
rpki-rtrサーバ証明書のDNS名には、ワイルドカード文字「*」を含めるべきではない(SHOULD NOT)。
TLSを使用するrpki-rtr実装では、コモンネーム(CN-ID)識別子を使用してはならない(MUST NOT)。CNフィールドはサーバ証明書のサブジェクト名に存在する可能性があるが、[RFC6125]に記載されているルール内の認証に使用してはならない(MUST NOT)。
クライアントルータは、その「参照識別子」をrpki-rtrキャッシュのDNS名に設定しなければならない(MUST)。

9.3. TCP MD5トランスポート

TCP MD5を使用する場合、実装は[RFC2385]のセクション4.5に従って、少なくとも印刷可能ASCII文字80バイトの鍵長をサポートしなければならない(MUST)。実装は、少なくとも32文字、つまり128ビットの16進数シーケンスもサポートしなければならない(MUST)。

TCP MD5での鍵ロールオーバーは問題がある。キャッシュサーバは[RFC4808]をサポートする必要がある(SHOULD)。

9.4. TCP-AOトランスポート

実装は、少なくとも印刷可能ASCII文字80バイトの鍵長をサポートしなければならない(MUST)。実装はまた、少なくとも32文字、つまり128ビットの16進数シーケンスもサポートしなければならない(MUST)。[RFC5925]のセクション5.1に従い、少なくとも96ビットのメッセージ認証コード(MAC)長をサポートしなければならない(MUST)。

[RFC5926]に記載されている暗号アルゴリズムと関連パラメータをサポートしなければならない(MUST)。

10. ルータ-キャッシュの設定

キャッシュは、各ルータの公開認証データを持ち、そのデータはサポートのために設定済みである。

ルータは、選択したキャッシュとピアリングするように設定し、キャッシュは選択されたルータをサポートするように設定されている。それぞれが、各ピアの名前と認証データが必要である。さらに、ルータにおいて、このリストは各サーバに対して一意ではないプリファレンス値を持つ。このプリファレンスは、単に近接性を示すだけで、信頼や優先の考えなどを示すものではない。クライアント・ルータは、優先順位の高いサーバ・キャッシュとセッションを確立し、接続と認証が可能な最も優先順位の高いキャッシュからデータの読み込みを開始する。ルータのキャッシュ・リストには以下の要素が含まれる:

プリファレンス: そのキャッシュに接続するルータの優先順位を示す符号なし整数。値が小さいほど優先される。

名前: キャッシュのIPアドレスまたは完全修飾ドメイン名。

キャッシュ資格情報: キャッシュのIDをルータに認証するために必要な任意の資格情報(公開鍵など)。

ルータ資格情報: キャッシュに対してルータのアイデンティティを認証するために必要な資格情報(秘密鍵や証明書など)。

RPKIの分散特性により、キャッシュは厳密に同期することはできない。クライアントは複数のキャッシュからデータを保持することができるが、後の更新が正しいデータに影響を与えなければならない(MUST)ため、ソースとしてマークされたデータを保持しなければならない(MUST)。

単一のキャッシュから複数をカバーするROAが存在する可能性があるように、複数のキャッシュから複数をカバーするROAが存在する可能性がある。結果は[RFC6811]に記載されているとおりである。

複数のキャッシュからのデータが保持されている場合、実装はBGPアナウンスの検証を行うときにデータソースを区別してはならない(MUST NOT)。

より優先度の高いキャッシュが利用可能になったとき、リソースが許せば、クライアントはそのキャッシュからフェッチを開始するのが賢明である。

クライアントは、別のキャッシュを選択したか、前のキャッシュに新しい接続を確立したかに関係なく、少なくとも1つのデータセットを維持しようと試みる必要がある(SHOULD)。

クライアントは、1つ以上の他のキャッシュと完全に同期したときに、特定のキャッシュからデータを削除してもよい(MAY)。

クライアントが特定のキャッシュから更新できない場合の対処方法の詳細については、セクション6を参照のこと。

クライアントが使用しているキャッシュへの接続を失うか、さもなければ新しいキャッシュに切り替えることを決定した場合、1つ以上の他のキャッシュから完全なデータセットが揃うまで、前のキャッシュのデータを保持すべきである(SHOULD)。クライアントが複数のキャッシュに接続している場合、接続が失われた時点ですでにこれが当てはまる可能性があることに留意すること。

⚠️ ルータの実装

Cisco IOS/IOS-XEの場合、「bgp rpki server」コマンドを用いる。

router bgp 64500
  bgp rpki server tcp 100.64.1.1 port 323 refresh 300

Cisco IOS-XRの場合、「rpki server」コマンドを用いる。

router bgp 64500
  rpki server 100.64.1.1
     transport tcp port 323
     refresh-time 300

Juniper/Junosの場合、以下のコマンドを用いる。

routing-options {
   autonomous-system 64500;
   validation {
      group rpki-validator {
         session 100.64.1.1 {
            refresh-time 120;
            hold-time 180;
            port 323;
            local-address 100.64.1.2;
}}}}

CiscoもJunosもコマンドから類推すると、生のTCP上にRPKI-to-RTRが実装されていると思われる。

11. 導入シナリオ

説明のために、考えられる3つの導入シナリオを示す:

小規模なエンドサイト: 小規模なマルチホーム・エンドサイトは、RPKIキャッシュを1つ以上の上流ISPにアウトソーシングすることを望む場合がある。ISPは、何らかのアウトオブバンドのメカニズムを使用して認証材料をISPと交換し、ISPのルータは1つ以上の上流ISPのキャッシュに接続する。ISPは、自社のBGPスピーカがピアリングするキャッシュとは別に、顧客用のキャッシュを配備している可能性が高い。

大規模なエンドサイト: 大規模なマルチホーム・エンドサイトでは、1つ以上のキャッシュを実行し、クライアント・キャッシュを階層構造に配置し、各キャッシュはグローバルRPKIに近い供給キャッシュからフェッチする。上流ISPキャッシュへのフォールバック・ピアリングを設定する場合もある。

ISPバックボーン: 大規模なISPは、各主要ポイント・オブ・プレゼンス(PoP)に1つ以上の冗長キャッシュがある可能性が高く、これらのキャッシュは、グローバルRPKIに過度の負荷をかけないように、ISP従属トポロジで相互にフェッチする。

大規模なDNSキャッシュの展開の経験から、複雑なトポロジは、ループのない状態を維持できないなど、エラーが発生しやすいため、得策ではないことが分かっている。

もちろん、これらは一例であり、他の展開戦略も考えられる。グローバルRPKIサーバの負荷を最小限に抑えることが、主な考慮事項になると想定される。

グローバルRPKIサービスの負荷が不必要なピークに達しないようにするには、分散グローバルRPKIから負荷をかけるプライマリ・キャッシュを、すべて同時に(例えば、正時など)行わないことを推奨する。ランダムな時間、おそらくISPのAS番号を60で割った余りを選択し、フェッチ間のタイミングを揺らす(jitter)。

12. エラーコード

このセクションには、エラーコードの暫定リストを含む。著者らは、初期実装の開発中にリストに追加されることを期待する。有効なエラーコードが列挙されているIANAレジストリがある。セクション14を参照のこと。致命的とみなされるエラーは、セッションを切断しなければならない(MUST)。

0: 破損したデータ(致命的): 受信側は、受信したPDUが他のエラーコードで指定されていない方法で破損していると考える。

1: 内部エラー(致命的): エラーを報告した側が、プロトコルの動作とは関係のない何らかの内部エラーが発生した(メモリ不足、コーディング・アサーションの失敗など)。

2: 利用可能なデータがない: キャッシュはそれ自体が正常に動作していると考えているが、現時点では利用可能な有用なデータがないため、シリアルクエリにもリセットクエリにも応答できない。これは一時的なエラーである可能性が高く、キャッシュがこれまで保持していたデータを無効にする何らかのイベント(再起動、ネットワーク・パーティションなど)が発生した後、グローバルRPKIシステムから最初の現在のデータセットをまだ引き出し終えていないことを示す可能性が高い。

3: 無効なリクエスト(致命的): キャッシュサーバはクライアントのリクエストが無効であると判断した。

4: サポートされていないプロトコル・バージョン (致命的): PDUの受信側はプロトコル・バージョンを認識できない。

5: サポートされていないPDUタイプ(致命的): PDUの受信側がPDUタイプを認識できない。

6: 不明なレコードの取り消し(致命的): 受信したPDUは「フラグ=0」だが、一致するレコード(IPvX PDUの場合は「{Prefix, Len, Max-Len, ASN}タプル」、ルータ鍵の場合は「{SKI, ASN, Subject Public Key}タプル」)が受信側のデータベースに存在しない。

7: 重複したアナウンスを受信(致命的): 受信したPDUは「フラグ=1」だが、一致するレコード(IPvX PDUの場合は「{Prefix, Len, Max-Len, ASN}タプル」、ルータ鍵PDUの場合は「{SKI, ASN, Subject Public Key}タプル」)がルータ内で既にアクティブである。

8: 予期しないプロトコル・バージョン (致命的): 受信したPDUは、セクション7でネゴシエートされたプロトコル・バージョンとは異なるプロトコル・バージョン・フィールドがある。

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

本文書はセキュリティ・プロトコルについて記載しているため、セキュリティに関する多くの側面が関連セクションに記載されている。本セクションは、他のセクションで明らかでない問題を指摘する。

キャッシュの検証: セクション11に記載している、キャッシュのコレクションが一貫したビューを保証するためには、それらの内部検証プロセスで使用する一貫したトラストアンカーをキャッシュに与える必要がある。一貫性のあるトラストアンカーの配布は、アウトオブバンドだと想定される。

キャッシュピアの識別: ルータは、IPアドレスまたは完全修飾ドメイン名のいずれかで識別し、キャッシュへのトランスポート接続を開始する。DNSまたはアドレス偽装攻撃により、正しいキャッシュにアクセスできなくなる可能性があることに留意すること。認証鍵が一致しなければ、セッションは確立されない。

トランスポート・セキュリティ: RPKIは、サーバやトランスポートではなく、オブジェクトの信頼に依存する。つまり、IANAルートのトラストアンカーは、何らかのアウトオブバンド手段を通じて、すべてのキャッシュに配布され、その後、各キャッシュが証明書とROAをツリーの下位まで検証するために使用できる。キャッシュ間の関係は、このオブジェクト・セキュリティ・モデルに基づいている。したがって、キャッシュ間トランスポートは容易に保護することができる。

ただし、このプロトコル文書では、ルータが検証暗号化を実行できないことを前提としている。したがって、キャッシュからルータまでの最後のリンクは、サーバ認証とトランスポート・レベルのセキュリティで保護される。サーバ認証とトランスポートにはオブジェクト・セキュリティとはまったく異なる脅威モデルがあるため、これは危険である。

したがって、ルータとキャッシュ間の信頼関係とトランスポートの強度が重要である。あなたはこれにルーティングを賭けているのだ。

キャッシュが同じLAN上になければならないとは言えないが、企業がキャッシュ・タスクを上流のISPにオフロードしたいという問題があるにせよ、ここでは局所性、信頼性、コントロールが非常に重要な問題になる。キャッシュは、(DDoSやMITMに対して)トランスポートをコントロールおよび保護するという意味で、可能な限りルータの近くに設置すべきである(SHOULD)。また、ルータがキャッシュに自力でアクセスするため、必要な最小限の有効なルーティング・データで済むように、トポロジー的に近い必要がある(SHOULD)。

キャッシュサーバのアイデンティティは、データが交換される前に、ルータクライアントによって検証および認証する必要があり、逆も同様である。

必要な認証と完全性(セクション9を参照)を提供できないトランスポートは、なりすまし/破損攻撃に対する保護を提供するために、ネットワーク設計と運用制御に依存しなければならない。セクション9で指摘したように、TCP-AOは長期的な計画である。完全性と真正性を提供するプロトコルを使用する必要がある(SHOULD)。それができない場合、つまりTCPがトランスポートとして使用される場合、ルータとキャッシュは同じ信頼できる制御されたネットワーク上になければならない(MUST)。

14. IANAに関する考慮事項

本セクションでは、このプロトコルのバージョン1に対応するために既存のIANAプロトコル・レジストリで必要な更新についてのみ説明する。オリジナル(バージョン0)のプロトコルのIANAの考慮事項については、[RFC6810]を参照のこと。

IANAの「rpki-rtr-pdu」レジストリにある既存のエントリはすべて、プロトコル・バージョン0に対して、有効のままである。プロトコル・バージョン0で許可されているすべてのPDUタイプは、新しいルータ鍵PDUが追加されているため、プロトコル・バージョン1でも許可される。混乱の可能性を減らすために、プロトコル・バージョン1のルータ鍵PDUによって使用されるPDU番号は、プロトコル・バージョン0では予約済み(未使用)として登録する。

レジストリへの追加ポリシーは、[RFC8126]による「RFC Required」である。文書は、標準化過程(Standards Track)または実験(Experimental)のいずれかでなければならない。

「rpki-rtr-pdu」レジストリは以下のように更新する:

プロトコル・バージョン	PDUタイプ	説明
0-1	0	シリアル通知
0-1	1	シリアルクエリ
0-1	2	リセットクエリ
0-1	3	キャッシュ応答
0-1	4	IPv4プレフィックス
0-1	6	IPv6プレフィックス
0-1	7	データ終了
0-1	8	キャッシュリセット
0	9	予約済み
1	9	ルータ鍵
0-1	10	エラー報告
0-1	255	予約済み

IANA「rpki-rtr-error」レジストリの既存の全エントリは、すべてのプロトコル・バージョンで引き続き有効である。プロトコル・バージョン1では、以下の新しいエラーコードが1つ追加する:

エラーコード	説明
8	予期しないプロトコルのバージョン

15. 参考文献

15.1. 引用規格

[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.

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

[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1998, <https://www.rfc-editor.org/info/rfc2385>.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.

[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <https://www.rfc-editor.org/info/rfc4252>.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, DOI 10.17487/RFC5926, June 2010, <https://www.rfc-editor.org/info/rfc5926>.

[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.

[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <https://www.rfc-editor.org/info/rfc6810>.

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

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

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

[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <http://www.rfc-editor.org/info/rfc8208>.

15.2. 参考規格

[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.

[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, DOI 10.17487/RFC4808, March 2007, <https://www.rfc-editor.org/info/rfc4808>.

[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, <https://www.rfc-editor.org/info/rfc5781>.

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

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.

謝辞

ニルス・バーズ、スティーブ・ベロビン、ティム・ブリュインツェルス、レックス・フェルナンド、リチャード・ハンセン、ポール・ホフマン、ファビアン・ホラー、ラス・ハウズリー、プラドシュ・モハパトラ、キール・パテル、デビッド・マンデルバーグ、サンディ・マーフィー、ロバート・ラズスク、アンドレアス・ロイター、トーマス・C・シュミット、ジョン・スカダー、ルディガー・ヴォルク、マティアス・ヴァエリッシュ、デヴィッド・ウォードに感謝する。特に、不必要なフィールドの危険性を教えてくれたハンネス・グレドラーに感謝する。

このリストが不完全であることは間違いない。名前を見落とした貢献者に謝罪する。

著者のアドレス

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

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

更新履歴

2024.4.3

GitHubで編集を提案

要旨

本文書の位置付け

著作権表示

1. はじめに

1.1. 要件言語

1.2. RFC 6810からの変更点

2. 用語集

3. 展開構造

4. 運用概要

5. プロトコル・データ・ユニット (PDU)

5.1. PDUのフィールド

5.2. シリアル通知

5.3. シリアルクエリ

5.4. リセットクエリ

5.5. キャッシュ応答

5.6. IPv4プレフィックス

5.7. IPv6プレフィックス

5.8. データ終了

5.9. キャッシュリセット

5.10. ルータ鍵

5.11. エラー報告

6. プロトコル・タイミング・パラメータ

7. プロトコル・バージョンのネゴシエーション

8. プロトコルシーケンス

8.1. 開始あるいは再起動

8.2. 典型的なやり取り

8.3. 利用可能な増分更新はない

8.4. キャッシュに利用可能なデータがありません

9. トランスポート

9.1. SSHトランスポート

9.2. TLSトランスポート

9.3. TCP MD5トランスポート

9.4. TCP-AOトランスポート

10. ルータ-キャッシュの設定

11. 導入シナリオ

12. エラーコード

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

14. IANAに関する考慮事項

15. 参考文献

15.1. 引用規格

15.2. 参考規格

謝辞

著者のアドレス

更新履歴

Discussion