Zenn
🦩

RFC 8182: RPKIリポジトリ・デルタ・プロトコル(RRDP)

2024/04/12に公開
#
rfc
#
bgp
#
rpki
tech

要旨

リソース公開鍵基盤(RPKI)において、認証局(CA)が、エンド・エンティティ証明書、証明書失効リスト(CRL)、RPKI署名済みオブジェクトを含む証明書をリポジトリに公開する。リライング・パーティーは、これらのリポジトリから公開情報を取得する。本文書では、この目的のために新しいRPKIリポジトリ・デルタ・プロトコル(RRDP)を規定する。RRDPは、特にスケーリングのために設計されている。これは、HTTPS (HTTP over Transport Layer Security (TLS))を使用して取得できる現在のスナップショット・ファイルとデルタ・ファイルの一覧を示す更新通知ファイルに依存しており、 これらのファイルの取得にコンテンツ配信ネットワーク(CDN)または他のキャッシュ基盤を使用できるようにする。

本文書の位置付け

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

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

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

著作権表示

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

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

1. はじめに

リソース公開鍵基盤(RPKI)では、認証局が、証明書[RFC6487]、RPKI署名済みオブジェクト[RFC6488]、マニフェスト[RFC6486]、およびCRLをリポジトリに公開する。CAは、これらのリポジトリに公開するメカニズムが組み込まれている場合もあれば、別のリポジトリ・サーバと公開プロトコルを使用している場合もある。RPKIリポジトリは現在、rsyncプロトコル[RSYNC]を使用してアクセス可能で、リライング・パーティーは検証に使用されるRPKIリポジトリのローカルコピーをリモート・リポジトリと同期することができる[RFC6481]。

rsync[RSYNC]は、カスタム・プロトコルを考案する必要なく、オペレータが経験を積むことができるため、RPKIの初期展開において貴重であることが証明された。ただし、運用経験から、ここで取り上げたい懸念事項が浮き彫りとなった。

  • rsync[RSYNC]は、クライアントとサーバ間で転送する必要のあるデータ量を制限するように設計されている。しかし、サーバは接続ごとにCPUとメモリに大量のリソースを消費する必要がある。これは、数千のリライング・パーティーが少数の中央リポジトリにクエリを実行するRPKI展開の想定では問題であり、これらのリポジトリがサービス拒否攻撃に対して脆弱になる。

  • 次に懸念されるのは、サポートされているrsyncサーバとクライアントのライブラリが欠けていることである。実際には、すべての実装でrsyncバイナリへのシステム・コールを行わなければならない。これは非効率的であり、このバイナリの更新に脆弱性が生じ、問題を見つけてオペレータに報告することが難しくなり、ソフトウェアの開発とテストが複雑になる。

本文書では、リライング・パーティーがHTTPSプロトコル経由で取得できる、更新通知、スナップショット、デルタファイルに基づく代替リポジトリ・アクセス・プロトコルを規定する。これにより、リライング・パーティーは、スナップショット・ファイルを使用してリポジトリのローカルコピーの完全な(再)同期を実行したり、デルタファイルを使用して初期同期後にローカル・リポジトリを最新の状態に保つことができる。これをRPKIリポジトリ・デルタ・プロトコル(略してRRDP)と呼ぶ。

RRDPは、RPKIの非対称的な展開におけるスケーリングをサポートするように設計された。これは、公開プロトコル[RFC8181]と(データ構造の点で)一貫しており、1つ以上のリポジトリ・オブジェクトの公開イベントを、リライング・パーティーに通信可能な個別のイベントとして扱う。このアプローチは、ネットワークを通過するデータ量を最小化し、リポジトリの収束が起こるまでの時間を最小化するのに役立つ。また、RRDPは、単一リポジトリの一貫した一時点(point-in-time)のビューを取得するための標準ベースの方法も提供し、一貫性に関連する多くの問題を取り除く。最後に、このアプローチは、これらの個別のイベントをイミュータブル・ファイルとしてやり取りできる。これにより、リポジトリ・サーバはすべてのクライアントに対して1度だけこれらのファイルを事前計算することができ、必要なCPUとメモリへの投資を制限することができる。多数のリライング・パーティーがリポジトリ・サーバにクエリを送信する場合、キャッシュ基盤を使用してリポジトリ・サーバの負荷を軽減することができる。

本文書は、RPKIの追加のリポジトリ配布メカニズムとして、RRDPを利用できるようにする。やがて、RRDPはrsync[RSYNC]に代わって、実装が義務付けられた唯一のリポジトリ配布メカニズムになる可能性がある。ただし、この移行は本文書の範囲外である。

2. 要件の表記

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

3. RPKIリポジトリ・デルタ・プロトコルの実装

3.1. 非公式な概要

RPKIの認証局は、マニフェスト、CRL、署名済み証明書、RPKI署名済みオブジェクトなどのRPKIプロダクトを公開するために、リポジトリ・サーバを使用する。このリポジトリ・サーバはリモートまたは認証局エンジン自体に組み込まれている。RRDPをサポートするリポジトリ・サーバを使用するRPKIの証明書には、更新通知ファイルを参照する特別なサブジェクト情報アクセス(SIA)ポインタが含まれる。

更新通知ファイルには、バージョン4の汎用ユニーク識別子(UUID)[RFC4122]の形式で、グローバルにユニークなsession_idと、リライング・パーティーがリポジトリと同期しているかどうかを判断するために使用できるシリアル番号が含まれている。さらに、リポジトリ・サーバによって公開されている現在のオブジェクトの最新の完全なスナップショットへのリンクと、リポジトリ・サーバによって決定された時点から始まり、リポジトリの現在のリビジョンまでの各リビジョンのデルタファイルへのリンクのリストが含まれている。

初めて更新通知ファイルの場所を知ったリライング・パーティーは、それをダウンロードして最新のスナップショット・ファイルのダウンロードに進み、リポジトリ・サーバと同期したリポジトリのローカルコピーを作成することができる。リライング・パーティーは、この更新通知ファイルの場所、session_id、および現在のシリアル番号を記録する。

リライング・パーティーは、この更新通知ファイルを定期的に再フェッチすることが推奨されるが、そん頻度は1分に1回を超えないものとする。更新通知ファイルを再フェッチした後、リライング・パーティーは、そのローカル・リポジトリをリポジトリ・サーバの現在の状態と同期できる、利用可能な1つ以上のデルタファイルが存在することに気付くかもしれない。リライング・パーティーのシリアルから最新のリポジトリ・シリアルまでの連続したデルタチェーンが利用できない場合、またはsession_idが変更された場合、リライング・パーティーは代わりに完全な再同期を実行する。

リライング・パーティーはこの方法で新しいコンテンツを取得すると、すぐに検証プロセスを開始することができる。リライング・パーティーがこれをすぐに行わない理由の一例として、複数の通知先を認識しており、検証する前にすべての更新を完了することを好むからである。

特に、特定のsession_idおよびシリアル番号のスナップショットとデルタは、ある時点におけるリポジトリ・サーバの状態のイミュータブルな記録が含まれているため、リポジトリ・サーバはキャッシュ基盤を使用して負荷を軽減できる。このため、これらのファイルは無期限にキャッシュできる。更新通知ファイルは、更新が存在するかどうかを検出するためにリライング・パーティーによってポーリングされる。このため、更新通知ファイルは1分を超えてキャッシュされない。

3.2. 認証局の使用

RRDPを使用する認証局は、[RFC6487]で定義されているものに加えて、生成するリソース証明書にSIA AccessDescription拡張のインスタンスを含めなければならない(MUST)。

          AccessDescription ::= SEQUENCE {
            accessMethod OBJECT IDENTIFIER,
            accessLocation GeneralName }

この拡張は、id-ad-rpkiNotifyのaccessMethodを使用しなければならない(MUST)。セクション6を参照のこと。

  id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
    dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

  id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

  id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 }

accessLocationは、[RFC7230]で定義されているように、この認証局証明書のプロダクトを公開するリポジトリ・サーバの更新通知ファイルを指すHTTPS URIでなければならない(MUST)。

3.3. リポジトリ・サーバの使用

3.3.1. 初期化

リポジトリ・サーバは初期化時に以下の動作を実行する:

  • サーバは、session_idとして使用する新しいランダムなバージョン4のUUID([RFC4122]のセクション4.1.3参照)を生成しなければならない(MUST)。

  • 次にサーバは、リポジトリ・サーバが責任を負う、現在既知の公開オブジェクトをすべて含む、この新しいセッションのシリアル番号1(ONE)のスナップショット・ファイルを生成しなければならない(MUST)。このスナップショット・ファイルには、まだ公開のために提出された(submitted)オブジェクトがない場合、この時点ではpublish要素がゼロである可能性があることに留意する。

  • このスナップショット・ファイルは、無期限にキャッシュできるように、このsession_idとシリアル番号に固有のURLで利用できるようにしなければならない(MUST)。スナップショット・ファイルの形式とキャッシュに関する詳細は、セクション3.5.2で説明する。

  • スナップショット・ファイルが公開された後、リポジトリ・サーバは、新しいsession_idを含み、シリアル番号が1(ONE) で、公開されたばかりのスナップショット・ファイルへの参照を1つ持ち、デルタ参照が含まない新しい更新通知ファイルを公開しなければならない(MUST)。更新通知ファイルの形式とキャッシュに関する詳細は、セクション3.5.1で説明する。

3.3.2. 更新の公開

リポジトリ・サーバは認証局から更新を受け取るたびに、1分以内に新しいスナップショット・ファイルとデルタファイルを生成しなければならない(MUST)。リポジトリ・サーバが多数の認証局にサービスを提供する場合、複数のCAからの更新を組み合わせることを選択してもよい(MAY)。リポジトリ・サーバがこの方法で更新を結合する場合、関係するCAのいずれについても、公開が1分を超えて延期されることがないように保証しなければならない(MUST)。

更新は以下のように処理される:

  • 新しいリポジトリのシリアル番号は、現在のリポジトリのシリアル番号より1つ大きくなければならない(MUST)。

  • 新しいデルタファイルは、この新しいシリアルに対して生成しなければならない(MUST)。このデルタファイルは、該当する場合、複数のCAのすべての新規、置換、および撤回されたオブジェクトを、1つの変更セットとして含まれなければならない(MUST)。

  • このデルタファイルは、無期限にキャッシュできるように、現在のsession_idとシリアル番号に固有のURLで利用できるようにしなければならない(MUST)。

  • デルタファイルの形式とキャッシュに関する詳細は、セクション3.5.3で説明する。

  • リポジトリ・サーバは、この新しいシリアルのために新しいスナップショット・ファイルを生成しなければならない。このファイルには、現在のすべてのオブジェクトのすべての「publish」要素が含まなければならない(MUST)。

  • スナップショット・ファイルは、無期限にキャッシュできるように、このセッションと新しいシリアルに固有のURLで利用できるようにしなければならない(MUST)。

  • スナップショット・ファイルの形式とキャッシュに関する詳細は、セクション3.5.2で説明する。

  • リライング・パーティーが必要以上に多くのデータをダウンロードするのを避けるために、古いデルタファイルで、より新しいデルタファイルと組み合わせると、デルタの合計サイズがスナップショットのサイズを超えるものは除外されなければならない(MUST)。

  • 新しい更新通知ファイルはリポジトリ・サーバが作成しなければならない(MUST)。この新しい更新通知ファイルは、新しいスナップショット・ファイルと、前の手順で選択したすべてのデルタファイルへの参照が含まなければならない(MUST)。

  • 更新通知ファイルの形式とキャッシュに関する詳細は、セクション3.5.1で説明する。

何らかの理由でリポジトリ・サーバが上記の処理を実行できない場合は、セクション3.3.1で説明したように、完全な再初期化を実行しなければならない(MUST)。

3.4. リライング・パーティーの使用

3.4.1. 更新通知ファイルの処理

リライング・パーティーがRPKIの検証を実行し、RRDPプロトコルのSIAエントリを持つ有効な証明書を認識した場合、このプロトコルを以下のように使用する必要がる(SHOULD)。

リライング・パーティーは、この検証の実行中に同じ場所から既に更新通知ファイルがダウンロードされ、処理されたか、ポーリング戦略が使用された場合を除き、更新通知ファイルをダウンロードしなければならない(MUST)(セクション3.4.4参照)。

リライング・パーティーは、使用しているリライング・パーティー・ソフトウェアの名前とバージョンを特定するために、[RFC7231]のセクション5.5.3で説明されている「User-Agent」ヘッダを使用することが推奨される(RECOMMENDED)。これは、RPKI 標準が変更された場合に、リライング・パーティーの機能を追跡するのに役立つ。

リライング・パーティーは更新通知ファイルをダウンロードするとき、セクション3.5.1.3に記載されているファイル形式と検証手順を検証しなければならない(MUST)。この検証が失敗した場合、そのファイルは拒否しなければならず(MUST)、RRDPは使用できない。考慮事項については、セクション3.4.5を参照のこと。

リライング・パーティーは、session_idがこの更新通知ファイルの場所の最後の既知のsession_idと一致するかどうかを検証しなければならない(MUST)。session_idがランダムなUUID値であっても、それだけをセッションの一意な識別子としてリライング・パーティーが使用してはならない(MUST)。その理由は、悪意のあるサーバが他のリポジトリ・サーバから既存のsession_idを使用することができるからである。

session_idが最後に知られていたsession_idと一致する場合、リライング・パーティーは、最後に処理されたシリアル番号と更新通知ファイル中の現在のシリアル番号の間のシリアル番号に対するすべてのデルタファイルがこの方法で処理できることを条件として、セクション3.4.2に記載されているように、欠落しているデルタファイルをダウンロードして処理してもよい(MAY)。

session_idが最後に確認されたsession_idと一致するが、デルタファイルが使用されていない場合、リライング・パーティーはセクション3.4.3に記載されているように、更新通知ファイル上のスナップショット・ファイルをダウンロードして処理しなければならない(MUST)。

session_idが最後に知られているsession_idと一致しない場合、リライング・パーティーは、最後に知られているsession_idを、ダウンロードした更新通知ファイルで指定された値に更新しなければならない(MUST)。その後、リライング・パーティーは、セクション3.4.3に記載されているように、ダウンロードした更新通知ファイルで指定されているスナップショット・ファイルをダウンロードして処理しなければならない(MUST)。

3.4.2. デルタファイルの処理

更新通知ファイルが、最後に処理されたシリアル番号から現在のシリアル番号までの、デルタファイルへの連続したリンクのチェーンを含む場合、リライング・パーティーは以下のようにシリアル番号順にすべてのデルタファイルのダウンロードと処理を試行しなければならない(MUST)。

リライング・パーティーはデルタファイルをダウンロードするときは、ファイル形式を検証し、セクション3.5.3.3に記載されている検証手順を実行しなければならない(MUST)。この検証に失敗した場合、そのファイルは拒否しなければならない(MUST)。

さらに、リライング・パーティーは、このファイルの内容のハッシュが、それを参照した更新通知ファイルのハッシュと一致することを検証しなければならない(MUST)。このハッシュが一致しない場合、そのファイルは拒否しなければならない(MUST)。

リライング・パーティーが上記の基準に従って有効なデルタファイルを取得した場合、以下のアクションを実行する:

  • リライング・パーティーは、session_idが更新通知ファイルのsession_idと一致することを検証しなければならない(MUST)。session_idの値が一致しない場合、ファイルは拒否しなければならない(MUST)。

  • リライング・パーティーは、このデルタファイルのシリアル番号が、このsession_idに対して最後に処理されたシリアル番号より正確に1つ大きいことを確認しなければならない(MUST)。もし、そうでなければ、このファイルは拒否しなければならない(MUST)。

  • リライング・パーティーは、すべてのpublish要素をローカルストレージに追加し、最後に処理されたシリアル番号をこのデルタファイルのシリアル番号に更新する必要がある(SHOULD)。

  • リライング・パーティがリポジトリ・サーバから取得したデルタの中で、オブジェクトが置換される「withdraw」要素、または「publish」要素に遭遇した場合、適切なアクションを適用する前に、撤回または置換されるオブジェクトが同じリポジトリ・サーバから取得されたものであることを検証しなければならない(MUST)。これを怠ると、リライング・パーティーは悪意のあるリポジトリ・サーバから任意のオブジェクトを削除または変更するよう指示される可能性がある。

デルタファイルが拒否された場合、セクション3.4.3に記載されているように、リライング・パーティーは代わりに現在のスナップショット・ファイルを処理しなければならない(MUST)。

3.4.3. スナップショット・ファイルの処理

スナップショット・ファイルは、デルタファイルが利用できないか、拒否された場合にのみ使用しなければならない(MUST)。プロセスの説明については、セクション3.4.1を参照のこと。

リライング・パーティーがスナップショット・ファイルをダウンロードするとき、セクション3.5.2.3に記載されているファイル形式と検証手順を検証しなければならない(MUST)。この検証が失敗した場合、そのファイルは拒否しなければならない(MUST)。

さらに、リライング・パーティーは、このファイルの内容のハッシュが、それを参照した更新通知ファイルのハッシュと一致することを検証しなければならない(MUST)。このハッシュが一致しない場合、そのファイルは拒否しなければならない(MUST)。

リライング・パーティーが上記の基準に従って有効なスナップショット・ファイルを取得した場合、以下のアクションを実行する:

  • リライング・パーティーは、session_idが更新通知ファイルのsession_idと一致することを検証しなければならない(MUST)。session_id値が一致しない場合、そのファイルは拒否しなければならない(MUST)。

  • リライング・パーティーは、このスナップショット・ファイルのシリアル番号が、このsession_idに対して最後に処理されたシリアル番号よりも大きいことを検証しなければならない(MUST)。これが失敗した場合、ファイルは拒否しなければならない(MUST)。

  • その後、リライング・パーティーはすべての公開要素をローカルストレージに追加し、最後に処理されたシリアル番号をこのスナップショット・ファイルのシリアル番号に更新する必要がある(SHOULD)。

スナップショット・ファイルが拒否された場合、それはRRDPが使用できないことを意味する。考慮事項については、セクション3.4.5を参照のこと。

3.4.4. 更新通知ファイルのポーリング

リライング・パーティーは、RRDPプロトコルを使用するリポジトリの場所、session_id、最後に処理されたシリアル番号が分かったら、リポジトリサーバに対して更新のためのポーリングを開始してもよい(MAY)。しかし、リライング・パーティーは1分に1回を超える頻度で更新のポーリングを行ってはならない(MUST NOT)。また、データ使用量を減らすために、[RFC7232]のセクション3.3に記載されている「If-Modified-Since」 ヘッダをリクエスト内で使用しなければならない(MUST)。

リライング・パーティーは、更新が利用可能であることに気付いた場合、セクション3.4.1に記載されているようにファイルをダウンロードして処理し、新しいRPKIオブジェクト検証プロセスを開始する必要がある(SHOULD)。ただし、RPKIオブジェクト検証プロセス自体の詳細な説明は、本文書の範囲外である。

3.4.5. RRDPにおける運用上の障害に関する考慮事項

リライング・パーティーが、このプロトコルで使用されるいずれかのファイルの取得または処理について、何らかの問題が発生した場合、影響を受けるリポジトリ・サーバから新しいRPKIデータを取得できなくなる。

リライング・パーティーは、代替のリポジトリ・アクセス・メカニズムが利用可能であれば、関連する証明書のSIAで指定されているaccessMethod要素の値に従って、そのメカニズムの使用を試みることができる([RFC6487]のセクション4.8.8参照)。

さらに、リライング・パーティーは、RRDPファイルを取得する際に、再試行戦略を採用することを望むかもしれない。また、リライング・パーティーには、古いオブジェクトを使用して検証を行えるように、古いオブジェクトをローカルキャッシュに保持することを推奨する。

また、マニフェストやCRLが期限切れになる前、あるいは証明書の有効期限が切れる前に、再検証と取得を積極的に行い、リライング・パーティーの問題が重大な懸念を引き起こす前に特定し、解決できるよう、確実に安全な状態を維持することを推奨する。

3.5. ファイル定義

3.5.1. 更新通知ファイル

3.5.1.1. 目的

更新通知ファイルは、リポジトリの状態とリライング・パーティーのキャッシュの間に変更が存在するかどうかを検出するために、リライング・パーティーが使用する。これは、スナップショットと増分デルタを含むファイルの場所を記述しており、リライング・パーティーがリポジトリと同期するために使用できる。

3.5.1.2. キャッシュに関する懸念

リポジトリサーバは、更新通知ファイルをキャッシュし、HTTPSリクエストの負荷を軽減するために、キャッシュ基盤を使用してしてもよい(MAY)。ただし、このファイルは、リライング・パーティーが利用可能な更新があるかどうかを判断するために使用されるため、リポジトリサーバはこのファイルが1分を超えてキャッシュされないことを保証する必要がある(SHOULD)。このルールの例外は、更新通知ファイルがない場合よりは、古い更新通知ファイルを扱う方が良い場合である。

これを具体的にどのように実現するかは、使用するキャッシュ基盤に依存する。一般的に、リポジトリサーバは、「Cache-Control: max-age=60」([RFC7234]のセクション5.2参照)のような特定のHTTPヘッダーが有用と判断するかもしれない。もう1つのアプローチは、リポジトリサーバが適切なタイミングで更新通知ファイルの新しいバージョンをキャッシュ基盤にプッシュすることも可能である。

リポジトリサーバまたはその配布ネットワークの負荷が高い場合、Cache-Control HTTPヘッダ、または同様のメカニズムを使用して、リライング・パーティーに最適な(リポジトリサーバにとって)ポーリング間隔を示してもよい(MAY)。ただし、1時間を超える間隔に設定することは推奨しない(NOT RECOMMENDED)。リライング・パーティーは、提案された間隔を自身の運用慣行とRPKIリポジトリデータの予想される更新頻度に合わせる必要がある(SHOULD)が、示された値を破棄してもよい(MAY)。

3.5.1.3. ファイル形式と検証

更新通知ファイルの例:

  <notification xmlns="http://www.ripe.net/rpki/rrdp"
        version="1"
        session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
        serial="3">
    <snapshot uri="https://host/9d-8/3/snapshot.xml" hash="AB"/>
    <delta serial="3" uri="https://host/9d-8/3/delta.xml" hash="CD"/>
    <delta serial="2" uri="https://host/9d-8/2/delta.xml" hash="EF"/>
  </notification>

注: この例のURIとハッシュ値は、書式設定のため省略されている。

更新通知ファイルを作成または解析するときは、以下の検証ルールを守らなければならない(MUST)。

  • リライング・パーティーは、文法的に正しくない、または本文書のセクション3.5.4で概説されているRELAX NGスキーマに準拠していない更新通知ファイルを拒否しなければならない(MUST)。

  • XML名前空間は「http://www.ripe.net/rpki/rrdp」 でなければならない(MUST)。

  • 符号化は「US-ASCII」でなければならない(MUST)。

  • notificationルート要素のversion属性は「1」でなければならない(MUST)。

  • session_id属性は、このセッションに固有のランダムなバージョン4のUUID[RFC4122]でなければならない(MUST)。

  • serial属性は、リポジトリの現在のバージョンを示す、10進数形式の上限なし、符号なしの正の整数でなければならない(MUST)。

  • 更新通知ファイルには、現在のリポジトリのバージョンの「snapshot」要素が1つだけ含まなければならない(MUST)。

  • delta要素が含まれる場合、それらはリポジトリサーバが決定したリビジョンから始まり、notification要素に記載されたシリアル番号までの連続したシリアル番号のシーケンスを形成しなければならない(MUST)。要素は順序付けできない場合があることに留意する。

  • snapshot要素とdelta要素のhash属性は、参照ファイルのSHA-256[SHS]ハッシュを16進符号化したものでなければならない(MUST)。リライング・パーティーは、ファイルの取得時にこのハッシュを検証し、ハッシュが一致しない場合はファイルを拒否しなければならない(MUST)。

3.5.2. スナップショット・ファイル

3.5.2.1. 目的

スナップショットは、特定のセッションとバージョンのリポジトリの完全かつ最新の内容を反映することを目的としている。そのため、スナップショットには、公開時点のリポジトリのすべてのオブジェクトを含めなければならない(MUST)。

3.5.2.2. キャッシュに関する懸念

スナップショットは、特定の時点におけるリポジトリの内容を反映する。そのため、イミュータブル・データと見なすことができる。スナップショット・ファイルは、特定のセッションとシリアルに固有のURLで公開しなければならない(MUST)。

これらのファイルは変更されることがないため、無期限にキャッシュされる可能性がある(MAY)。ただし、これらのファイルがキャッシュ基盤で多くのスペースを使用するのを防ぐために、数時間または数日程度の限られた間隔を使用することを推奨する(RECOMMENDED)。

リライング・パーティーが更新直前に更新通知ファイルをダウンロードする競合状態を避けるために、リポジトリサーバは、新しい更新通知ファイルが公開された後、少なくとも5分間は古いスナップショット・ファイルを保持する必要がある(SHOULD)。

3.5.2.3. ファイル形式と検証

スナップショット・ファイルの例:

   <snapshot xmlns="http://www.ripe.net/rpki/rrdp"
          version="1"
          session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
          serial="2">
     <publish uri="rsync://rpki.ripe.net/Alice/Bob.cer">
       ZXhhbXBsZTE=
     </publish>
     <publish uri="rsync://rpki.ripe.net/Alice/Alice.mft">
       ZXhhbXBsZTI=
     </publish>
     <publish uri="rsync://rpki.ripe.net/Alice/Alice.crl">
       ZXhhbXBsZTM=
     </publish>
   </snapshot>

スナップショット・ファイルを作成または解析するときは、以下のルールを守らなければならない(MUST)。

  • リライング・パーティーは、完全ではないスナップショット・ファイル、または本文書のセクション3.5.4で概説されているRELAX NGスキーマに準拠していないスナップショット・ファイルを拒否しなければならない(MUST)。

  • XML名前空間は「http://www.ripe.net/rpki/rrdp」 でなければならない(MUST)。

  • 符号化は「US-ASCII」でなければならない(MUST)。

  • notificationルート要素のversion属性は「1」でなければならない(MUST)。

  • session_id属性は、更新通知ファイル内の参照で期待されるセッションIDと一致しなければならない(MUST)。

  • serial属性は、更新通知ファイル内の参照で期待されるシリアルと一致しなければならない(MUST)。

  • publish要素は、公開プロトコル[RFC8181]で定義されているpublish要素と類似していることに留意すること。ただし、「tag」属性はリライング・パーティーには関係がないため、ここでは使用しない。このファイルはリポジトリの完全な現在の状態を表すため、「hash」属性はここでは使用しない。したがって、どの既存のRPKIオブジェクト(存在する場合)が更新されるかを知っておく必要はない。

3.5.3. デルタファイル

3.5.3.1. 目的

増分デルタファイルには、リポジトリサーバの1つのシリアル増分に対するすべての変更が含まれる。言い換えると、1つのデルタには通常、認証局(CA)がリポジトリサーバに送信したすべての新規オブジェクト、更新されたオブジェクト、取り下げられたオブジェクトが含まれる。最も単純な形では、更新は1つのオブジェクトのみに関係するが、CAは、その鍵ペアの1つに対するすべての変更(更新されたオブジェクト、新しいマニフェストとCRL)を1つのアトミック更新メッセージとして送信することが推奨される(RECOMMENDED)。

3.5.3.2. キャッシュに関する懸念

デルタは、特定のセッションのリポジトリの連続する2つのバージョン間の差分を反映する。そのため、デルタはイミュータブル・データとみなすことができる。デルタファイルは、特定のセッションとシリアルに固有のURLで公開しなければならない(MUST)。

これらのファイルは決して変更されないため、無期限にキャッシュされる可能性がある(MAY)。ただし、これらのファイルがキャッシュ基盤で多くのスペースを使用するのを防ぐために、数時間か数日程度の限られた間隔を使用することが推奨される(RECOMMENDED)。

リライング・パーティーが更新される直前に更新通知ファイルをダウンロードする競合状態を避けるため、リポジトリサーバは古いデルタファイルが最新の更新通知ファイルに含まれなくなった後も、少なくとも5分間は保持する必要がある(SHOULD)。

3.5.3.3. ファイル形式と検証

デルタファイルの例:

  <delta xmlns="http://www.ripe.net/rpki/rrdp"
         version="1"
         session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28"
         serial="3">
    <publish uri="rsync://rpki.ripe.net/repo/Alice/Alice.mft"
             hash="50d8...545c">
      ZXhhbXBsZTQ=
    </publish>
    <publish uri="rsync://rpki.ripe.net/repo/Alice/Alice.crl"
             hash="5fb1...6a56">
      ZXhhbXBsZTU=
    </publish>
    <withdraw uri="rsync://rpki.ripe.net/repo/Alice/Bob.cer"
              hash="caeb...15c1"/>
  </delta>

このファイル形式の正式なRELAX NG仕様は、本文書の後半に記載されていることに留意すること。リライング・パーティーは、不完全または完全ではないデルタファイルを処理してはならない(MUST NOT)。

デルタファイルを作成または解析するときは、以下の検証ルールを守らなければならない(MUST)。

  • リライング・パーティーは、完全ではないデルタファイル、または本文書のセクション3.5.4で概説されているRELAX NGスキーマに準拠しないデルタファイルを拒否しなければならない(MUST)。
  • XML名前空間は「http://www.ripe.net/rpki/rrdp」 でなければならない(MUST)。
  • 符号化は「US-ASCII」でなければならない(MUST)。
  • deltaルート要素のversion属性は「1」でなければならない(MUST)。
  • session_id属性は、このセッションに固有のランダムなバージョン4 UUIDでなければならない(MUST)。
  • session_id属性は、更新通知ファイル内の参照で予期されるセッションIDと一致しなければならない(MUST)。
  • serial属性は、更新通知ファイル内の参照で予期されるシリアルと一致しなければならない(MUST)。
  • publish要素は、公開プロトコル[RFC8181]で定義されているpublish要素と類似していることに留意する。ただし、「tag」属性はリライング・パーティーに関係ないため、ここでは使用しない。

3.5.4. XMLスキーマ

以下は、このプロトコルのバージョン1を記述するRELAX NGコンパクト形式のスキーマである。

#
# RPKIリポジトリ・デルタ・プロトコル(RRDP)のためのRELAX NGスキーマ
#
default namespace = "http://www.ripe.net/rpki/rrdp"

version = xsd:positiveInteger   { maxInclusive="1" }
serial  = xsd:positiveInteger
uri     = xsd:anyURI
uuid    = xsd:string            { pattern = "[\-0-9a-fA-F]+" }
hash    = xsd:string            { pattern = "[0-9a-fA-F]+" }
base64  = xsd:base64Binary

# 通知ファイル: 現在のスナップショットとデルタをリストアップする
start |= element notification {
  attribute version    { version },
  attribute session_id { uuid },
  attribute serial     { serial },
  element snapshot {
    attribute uri  { uri },
    attribute hash { hash }
  },
  element delta {
    attribute serial { serial },
    attribute uri    { uri },
    attribute hash   { hash }
  }*
}

# スナップショット・セグメント: DNS AXFRを考える
start |= element snapshot {
  attribute version    { version },
  attribute session_id { uuid },
  attribute serial     { serial },
  element publish      {
    attribute uri { uri },
    base64
  }*
}

# デルタ・セグメント: DNS IXFRを考える
start |= element delta {
  attribute version    { version },
  attribute session_id { uuid },
  attribute serial     { serial },
  delta_element+
}

delta_element |= element publish  {
  attribute uri  { uri },
  attribute hash { hash }?,
  base64
}

delta_element |= element withdraw {
  attribute uri  { uri },
  attribute hash { hash }
}

# ローカル変数:
# indent-tabs-mode: nil
# comment-start: "# "
# comment-start-skip: "#[ \t]*"
# End:

4. 運用上の考慮事項

4.1. 前の規格との互換性

このプロトコルは、RPKIリポジトリの配布メカニズムとして、rsyncの置き換えとして設計されている。一方、rsyncに基づく既存の実装と共存できるように設計されており、ある配布メカニズムから別の配布メカニズムへのスムーズな移行を可能にしている。

スナップショット・ファイルとデルタファイルにリストされているすべてのリポジトリ・オブジェクトについて、オブジェクトのコンテンツのハッシュと、リポジトリ内の場所のrsync URI[RFC5781]の両方がリストされている。これにより、rsyncとRRDPの両方を使用して、ファイルシステム上のファイルセットで表される同じRPKIリポジトリを配布できるようになる。また、さまざまなタイプのリポジトリからオブジェクトをクエリ、組み合わせ、結果的に検証するために、リライング・パーティーのツールも使用可能になる。

4.2. 配布に関する考慮事項

RRDPの設計目標の1つは、クライアントにサービスを提供する際のリポジトリ・サーバの負荷を最小限に抑えることである。これを実現するために、スナップショット・ファイルとデルタファイルのコンテンツとURLは、更新通知ファイルで公開された後に変更しないこと。これにより、単一のHTTPサーバまたはCDNを使用した効果的な配布ができる。

リライング・パーティーがリポジトリの更新を維持するために推奨される方法は、更新通知ファイルに変更がないかをポーリングすることである。そのファイルの内容は、リポジトリの新しいシリアル・バージョンごとに更新される(URLは安定したまま)。更新通知ファイルの配布を効果的に実装するには、更新通知ファイルに対するすべてのリクエストに「If-Modified-Since」HTTPリクエスト・ヘッダが存在することが要求される(セクション3.4.4を参照)。したがって、リライング・パーティーのツールは、更新通知ファイルの取得を以前に成功したことを追跡するメカニズムを実装することが推奨される(RECOMMENDED)。

RRDPの実装では、リポジトリの新しいバージョン(その後、新しい更新通知、スナップショットおよびデルタファイル)が頻繁に生成されないように注意する必要もある。通常、RPKIリポジトリのメンテナンスには、スケジュールに従って実行されるマニフェストとCRLオブジェクトの定期的な更新が含まれる。そのため、リポジトリの更新が短期間に集中的に行われることがよくある。リライング・パーティーは更新通知ファイルを1分に1回を超える頻度でポーリングする必要があるため(セクション3.4.4)、1分に1回よりもはるかに高い頻度でリポジトリの新しいシリアル・バージョンを生成することは現実的ではない。おそらく異なるCAからの複数の更新を、新しいシリアル・リポジトリ・バージョンに結合することが許可されている(セクション3.3.2)。これにより、更新通知ファイルのサイズと、すべてのリライング・パーティーに配布されるデータの総量が大幅に削減される。

4.3. HTTPSに関する考慮事項

中間者(MITM)は、有効な署名済みRPKIデータを生成することはできないが、リライング・パーティーを標的にした留保(withhold)またはリプレイ攻撃を実行して、リライング・パーティーがRPKIの変更を知ることができないようにすることができることに留意する。そのため、リライング・パーティーは、RRDPリポジトリ・サーバから取得する際に、TLS証明書とホスト名の検証を行う必要がある(SHOULD)。

リライング・パーティーのツールは、オペレータが原因を調査できるように、検出されたTLS証明書またはホスト名の検証問題をログに記録する必要がある(SHOULD)。ただし、このような検証の問題は、設定エラーや共通のTLSトラストアンカーがないことが原因であることが多い。このような場合、リライング・パーティーが署名済みRPKIデータを取得し、それに対して検証を実行する方がよい。したがって、エラーが発生した場合でも、リライング・パーティーはデータの取得を続行しなければならない(MUST)。リライング・パーティーは、更新通知ファイルを取得する場合にのみ、発生した問題をログに記録することを選択してもよい(MAY)が、その後同じホストからスナップショット・ファイルまたはデルタファイルを取得する場合には、ログに記録しないことを選択してもよい(MAY)。さらに、リライング・パーティーは、原因が特定された後、オペレータが特定のホストに対する信頼できない接続を受け入れる方法を提供してもよい(MAY)。

リライング・パーティーとリポジトリサーバは、HTTP over TLS (HTTPS)[RFC7230]の使用に関して、[RFC7525]で概説されているベスト・カレント・プラクティスに従うことが推奨される(RECOMMENDED)。リライング・パーティーは、[RFC6125]に記載されているように、subjectAltName dNSName IDを使用してTLS証明書とホスト名の検証を行う必要がある(SHOULD)。[RFC6125]で定義されているルールとガイドラインがここに適用されるが、以下のの考慮事項がある:

  • リライング・パーティーとリポジトリサーバは、DNS-ID識別子のタイプをサポートする必要がある(SHOULD)。DNS-ID識別子のタイプは、リポジトリサーバ証明書に存在する必要がある(SHOULD)。

  • リポジトリサーバ証明書のDNS名には、ワイルドカード文字「*」を含めるべきではない(SHOULD NOT)。

  • コモンネーム(CN)フィールドはリポジトリサーバ証明書のサブジェクト名にあってもよいが、[RFC6125]に記載されているルール内で認証に使用すべきではない(SHOULD NOT)。

  • このプロトコルはSRV-IDの使用を要求しない。

  • このプロトコルはURI-IDの使用を要求しない。

ただし、この検証はベストエフォートベースで行われ、潜在的な問題を明らかにする役割を果たすが、RPKIオブジェクトのセキュリティはこれに依存しないことに留意する。したがって、リライング・パーティーは上記の検証手順から外れてもよい(MAY)。

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

RRDPは、リポジトリサーバからリライング・パーティーへのRPKIオブジェクトの移動のみを処理する。認証局とそのリポジトリサーバとの間の信頼関係は、本文書の範囲外である。ただし、リライング・パーティーの観点からは、すべてのRPKIオブジェクト(証明書、CRL、および暗号メッセージ構文(CMS)でラップされたオブジェクト)は、署名済みマニフェストを含むオブジェクト・セキュリティ・メカニズムによってすでにカバーされていることに留意する必要がある。これにより、リポジトリサーバ自体が信頼されていなくても、これらのオブジェクトを検証することができる。本文書は、RPKI検証手順自体に変更を加えるものではない。

オリジナルのRPKIトランスポート・プロトコルはrsyncであり、チャネル・セキュリティ・メカニズムは提供していない。RRDPは、rsyncの使用をHTTPSに置き換えたものである。RRDP(HTTPS)の基礎となるチャネル・セキュリティ・メカニズムは万能ではないが、攻撃者にとって、いくつかの形式のサービス拒否攻撃をより困難にする。HTTPSの問題については、セクション4.3で詳しく説明する。

RRDPとrsyncの両方をサポートすることで、リライング・パーティーが検証の実行を完了するために接続する必要があるURIの数が増えるため、悪意のあるRPKI認証局がリライング・パーティーに対してサービス拒否攻撃を行う機会を必然的に増やすことになる。しかし、HTTPSとrsyncの相対的なコストを除けば、RRDPを追加しても、この状況は大きく変わらない。RRDPでもrsyncでも、悪意のある認証局は事実上無限のURIをリライング・パーティーに提供することができる。これに対する唯一の現実的な解決策は、リライング・パーティーが自らが進んで行う作業量になんらかの制限を適用することである。また、このシナリオの攻撃者はRPKI認証局でなければならないことにも留意する。そうでなければ、通常のRPKIオブジェクトのセキュリティ・チェックでは悪意のあるURIは拒否される。

RRDPを使用して取得されたオブジェクトの処理コストは、rsyncを使用して取得された同じオブジェクトの処理コストとは多少異なる可能性がある。RRDPは変更のセット全体を1つの単位(1つの「デルタ」)として扱うため、デルタ全体を受信するまで、デルタ内のオブジェクトの処理を開始するのは現実的ではないかもしれない。対照的に、rsyncの場合、増分処理は簡単かもしれないが、全体の転送コストは高くなる可能性があり、リライング・パーティーが更新されたオブジェクトの一部を取得するものの、すべてを取得できない特殊なケースも多くなる可能性がある。全体として、RRDPの動作は適切なトランザクション・システムに近く、(おそらく)全体的な信頼性の向上につながる。

RRDPは、rsyncよりもはるかに優れた拡張性を実現するよう設計されている。特に、RRDPは、HTTPSキャッシュ基盤を使用して、プライマリ・リポジトリ・サーバの負荷を軽減し、RPKI公開サービスに対するサービス拒否攻撃に対するレジリエンスを高めるように設計されている。

6. IANAに関する考慮事項

IANAは、「PKIXアクセス記述子のSMIセキュリティ」レジストリ[IANA-AD-NUMBERS]内の本文書を指すように、id-ad-rpkiNotifyのリファレンスを更新した。

7. 参考文献

7.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, http://www.rfc-editor.org/info/rfc2119.

[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, http://www.rfc-editor.org/info/rfc4122.

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

[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, http://www.rfc-editor.org/info/rfc6125.

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

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

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, http://www.rfc-editor.org/info/rfc7230.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, http://www.rfc-editor.org/info/rfc7231.

[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, http://www.rfc-editor.org/info/rfc7232.

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, http://www.rfc-editor.org/info/rfc7234.

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, http://www.rfc-editor.org/info/rfc7525.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, http://www.rfc-editor.org/info/rfc8174.

[RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", DOI 10.17487/RFC8181, July 2017, http://www.rfc-editor.org/info/rfc8181.

[SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.

7.2. 参考規格

[IANA-AD-NUMBERS] IANA, "Structure of Management Information (SMI) Numbers (MIB Module Registrations)", http://www.iana.org/assignments/smi-numbers.

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, http://www.rfc-editor.org/info/rfc6486.

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, http://www.rfc-editor.org/info/rfc6488.

[RSYNC] "rsync", https://rsync.samba.org.

謝辞

本文書をレビューしてくれたデビッド・マンデルバーグに感謝の意を表する。

著者のアドレス

ティム・ブルインジールス
RIPE NCC
メール: tim@ripe.net

オレグ・ムラフスキー
RIPE NCC
メール: oleg@ripe.net

ブライアン・ウェバー
Cobenian
メール: bryan@cobenian.com

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

更新履歴

  • 2024.4.12
GitHubで編集を提案

Discussion