リソース公開鍵基盤（RPKI）の仕組み

検証には、証拠を維持する作業が欠かせない。ネットワークが変化しても、証明書、認可、公開システムの整合性を保つ必要がある。

サービスを新しいネットワークへ移したとする。サーバーは正常で、アドレスも変わっていない。それなのに、一部の利用者から接続できなくなる。原因として考えられるのは、驚くほど小さな食い違いだ。インターネットの経路に関する記録が、そのアドレスの広告を古いネットワークに認めたままになっているのである。

RPKIは、こうした認可を他のネットワークが検証できる形にする。その認可がアドレス保有者からルーターへ届くまでの過程と、この仕組みの運用継続を特定の管理者による権力の保持に依存させてはならないとLu Hengが主張する理由を見ていこう。短い入門を先に読みたい方は、RPKIが守るものから始めてほしい。

1. アドレスの利用を誰が認可できるかを確かめる

IPアドレスのまとまりをプレフィックスという。そのプレフィックスを広告するネットワークは、自律システム番号、すなわちASNで自身を識別する。リソース公開鍵基盤であるRPKIは、証明書を使って、特定のアドレス範囲に対する認可を誰が発行できるかを確立する。

これらの証明書は、信頼されたルートまでさかのぼる連鎖を形成する。その階層は、RFC 6480に記されているとおり、インターネット番号資源の割り振りに沿っている。この仕組みが示すのは、制度内の資源に関する証拠であり、インターネットを利用する人々に対する政治的な統治の委任を認証局に与えるものではない。

2. 署名付きの認可を公開する

アドレス保有者は、経路オリジン認可（Route Origin Authorisation）、略してROAを公開する。その内容は限定的で、「このASNが、このプレフィックスの経路を起点として広告してよい」というものだ。ここでいう起点とは、広告された経路の出発点となるネットワークを指す。その後にトラフィックを運ぶすべてのネットワークを指すわけではない。

ROAでは、最大プレフィックス長も指定できる。これは、アドレス範囲をどこまで細かな範囲に分割して広告してよいかを定めるものだ。この任意項目を指定しなければ、記載されたプレフィックス長だけが認められる。これにより、「この範囲に対する認可」が、あらゆる分割範囲への認可にいつの間にか広がることを防ぐ。署名付きレコードの仕様は、RFC 9582が定めている。

3. 公開レコードから検証済みデータを作る

署名付きレコードは、公開リポジトリで提供される。検証ソフトウェアはそれらを収集し、証明書チェーン、署名、有効期限、失効情報に加え、公開されているオブジェクトを記述するマニフェストを確認する。ファイルが読めるというだけでは不十分で、その裏付けとなる証拠も検証に合格しなければならない。

バリデーターは、実際に利用できる認可データを生成する。これは一般に、検証済みROAペイロード（Validated ROA Payloads）、略してVRPと呼ばれる。含まれるのは、プレフィックス、許可された起点ASN、最大プレフィックス長だ。ルーターは、RFC 8210に記載されたRPKI-to-Routerプロトコルを通じ、信頼するキャッシュから検証結果を受け取る。利用者がページを開くたびにレジストリへ許可を求めるわけではない。

4. 経路と認可を照合する

BGPは、ネットワークが経路を広告するためのプロトコルだ。経路を受信したルーターは、そのプレフィックスと起点ASNを検証済みの認可データと照合する。これが経路オリジン検証（Route Origin Validation）、略してROVである。

Valid（有効）：対象を包含する認可があり、起点とプレフィックス長の両方を認めている。Invalid（無効）：対象を包含する認可は存在するが、その組み合わせを認めるものがない。NotFound（該当なし）：対象のプレフィックスを包含する認可がない。これらは照合の結果であり、誰かの意図を判定するものではない。結果を経路制御ポリシーにどう反映するかは、運用者が決める。詳しくはRFC 6811を参照してほしい。

サービス移転の例に戻ろう。古いASNへの認可が残り、新しいASNが認可されていなければ、新しい経路広告はInvalidとなる可能性がある。Invalidの経路をフィルタリングするネットワークでは、その経路が拒否されることがある。対処法は、両方のネットワークに認可が必要となる期間も含め、移転に合わせて認可を変更することだ。サーバーが正常なら必ず接続できると思い込んではならない。運用上の注意点はRFC 7115で扱われている。

5. 連鎖全体を機能させ続ける

オリジン検証は、起点を偽る経路広告を拒否するのに役立つ。一方で、経路上のすべてのホップを検証するわけでも、トラフィックを暗号化するわけでも、あらゆる経路リークを検出するわけでもない。認可された起点を維持したままリークが起きる場合もある。他の経路保護策も引き続き必要だ。

証拠の維持も欠かせない。証明書には有効期限があり、認可や公開データは変化する。ROAを削除したからといって、必ず直ちに障害が起きるわけではない。最終的な検証結果は、ほかに利用できるレコードに左右され、経路への影響は各ネットワークのポリシーに左右される。RFC 8211は、認証局やリポジトリ運用者の誤り、あるいは有害な行為がシステムに及ぼしうる影響を検討している。

Lu Hengの提案：サービスを守り、管理者は交代できるようにする

ノート70でLu Hengが異議を唱えるのは、「レジストリのサービスは不可欠だから、現在の運営主体も替えが利かないはずだ」という、よくある論理の飛躍である。ネットワークには正確な記録と機能するセキュリティが必要だ。だからといって、それらを恒久的に支配する権利が一つの組織に認められるわけではない。

彼が提案する代案では、継続性を仕組みそのものに組み込む。独立した監査が可能な記録、適格な後継者への検証済みの引き継ぎ、そしてネットワークにアドレス変更を強いることなく管理を移す方法である。RPKIはディレクトリをコピーするだけでは移管できないことも、彼は明確に認めている。移行の全過程を通じて、鍵、証明書、公開の仕組み、信頼関係の整合性を保たなければならない。

これは彼が求める設計要件であり、そのような可搬性がすでにどこでも実現しているという主張ではない。問題の両面に向き合う提案だ。不用意な交代は検証を混乱させかねず、交代できない門番は、その依存関係を権力に変えうる。サービスの信頼性と管理者を交代できる仕組みは、一体として設計しなければならない。

なぜ危機が起きる前に、その能力を備えるのか

紛争が証明書チェーンにまで及ぶと、当事者とは遠く離れた人々に影響することがある。顧客はその争いを選んだわけではないのに、接続障害の代償を負わされるかもしれない。障害の最中に承継手続きを即席で作り始めても、その不確実性から顧客を守るには、すでに遅い。

Lu Hengが訴えるのは、継続性と離脱する権利をあらかじめ確立し、管理上の紛争を、稼働中のネットワークに対する武器にさせないことだ。議論の全体は、ノート70：守るべきは台帳であり、門番ではないで読むことができる。