要約
- ホステッド RPKI は、リソース保有者から難しい証明書、更新、マニフェスト、失効リスト、リポジトリの義務を取り除く。これにより、専門の公開鍵チームを持たない組織でもルートオリジン認証を作成・維持できるようになった。
- このサービスは制御もバンドルする。RIR によっては、レジストラがホステッド CA の秘密鍵を保持し、ポータル設定を署名済みオブジェクトに変換し、それらのオブジェクトを公開し、リソース記録から証明書の範囲を更新し、サービス終了時に削除する。
- ポータルの停止は、既存の ROA を自動的に無効にするわけではない。より深刻なリスクは、変更と復旧の権限を失うこと、またはレジストリの決定によってホステッド CA が失効されたり、そのオブジェクトが削除されることである。その時点で、ユーザーは意図した認証を維持するための独立した鍵や公開経路を持たない可能性がある。
- デリゲーテッド RPKI は、保有者自身の CA と秘密鍵を提供する。これにより、自動化、複数 RIR 管理、ホステッド署名インターフェースへの依存からの独立性が向上する。しかし、親からの独立は逃れられない。RIR は依然としてリソース証明書を発行し、それを制限または失効させることができる。
- ハイブリッド構成は、鍵の管理とリポジトリ運用を分離する。多くの場合、最も強力な実用的バランスを提供するが、親による公開は依然としてサービス依存であり、古くなったデリゲーテッド CA 自体が依拠当事者にとってリスクとなりうる。
- 事業者は、流行ではなく結果に基づいてモデルを選択すべきである。重要な公共サービス、複雑なマルチオリジンネットワーク、大規模な下位委任には、より強力な制御とテストされた移行が必要である。小規模で単純なネットワークは、手続き上の保護と復旧機能が信頼できる場合、合理的にホステッドにとどまることができる。
- 番号資源社会(Number Resource Society)は、モデル比較レジスタ、継続性テスト、RIR 理事会向け会員向け質問を公開することで支援できる。自己ホスティングを単純な主権として描くのではなく、情報に基づいた選択を強化すべきである。
失敗は、有効な変更が行えないときに始まる
あるネットワークが、サービスをある発信元 AS から別の AS に移行している。エンジニアは新しい BGP アナウンスを設定し、古い経路を撤回する前に新しい ROA を作成しようとしている。ホステッド RPKI では、RIR のポータルまたはインターフェースを使用しなければならない。アカウントにアクセスできない、インターフェースが利用できない、RIR が認証を停止している場合、事業者は自分で代替の署名を行うことができない。ホステッド CA の鍵を所有していないからである。
これは既存の経路が即座に失敗することを意味するわけではない。ポータルが利用できない間も、既存の ROA は公開され、有効であり続けることができる。その場合、直接の危険は変更の麻痺である。新しい発信元は、古い対象範囲 ROA が古い AS のみを許可する場合、Invalid になる可能性がある。エンジニアは必要な移行を延期したり、一部のネットワークが拒否する経路を実行したり、時間的プレッシャーの下でレジストリにアクセス復旧を依頼したりするかもしれない。
より深刻な事態は、ホステッド CA が失効されるか、その署名済みオブジェクトが削除された場合に発生する。事業者は、同じ鍵を使って同じオブジェクトをバックアップから再公開することはできない。鍵が決して制御下になかったからである。親が協力しない限り、親がサービスを終了した後にデリゲーテッド子を作成することはできない。便利さを提供した機関が、復旧への必要な経路となっている。
これが利便性の罠である。ホステッド RPKI が常に信頼性が低いとか、すべてのサービス中断が ROA を削除するという主張ではない。ユーザーが最も独立したオプションを必要とする瞬間に権限が集中することである。サービスは通常時は簡単でも、紛争、移転、侵害、緊急のルーティング変更時には脆弱になりうる。
したがって、正しい比較はスローガンではなく制御経路から始まる。誰がルーティング意図を表明できるか?誰が署名鍵を所有するか?誰が認証されたリソースを決定するか?誰がオブジェクトを公開するか?誰がそれらを失効できるか?誰が移行中に有効な認証を表示し続けられるか?ホステッドとデリゲーテッド RPKI はこれらの質問に異なる方法で答える。
利便性は真の導入問題を解決した
RPKI CA の運用は、通常のログイン証明書を作成するのと同じではない。CA は鍵を保護し、リソース証明書を要求・更新し、署名済みオブジェクトを発行し、マニフェストと証明書失効リストを維持し、新鮮な資料を公開し、障害に耐え、親システムと正しく相互作用しなければならない。そのリポジトリは、直接または公開プロバイダを通じて、依拠当事者が到達可能でなければならない。エラーはルートオリジン検証を変更する可能性がある。
ほとんどの中小規模事業者は、このタスクのためにチームを構築しなかった。彼らは公開鍵基盤の専門家になるのではなく、プレフィックスを認証したかった。ホステッド RPKI は、RIR が証明書の発行、署名、更新、公開を処理する間、よく知られた会員ポータルで発信元 AS とプレフィックスを選択できるようにした。
地域サービスはこの利点を公然と説明している。ARIN はホステッド RPKI を最も簡単なオプションと呼び、CA と高可用性リポジトリを運用すると述べている。RIPE NCC は、ホステッドユーザーは主に ROA を意図した BGP ルーティングと整合させる必要があり、システムが暗号操作と公開を処理すると述べている。APNIC はホステッドユーザーのために証明書と公開インフラを管理し、代わりに秘密鍵を生成する。LACNIC は 2011 年からホステッドサービスを提供している。
このモデルはプラスの外部性を生み出す。デリゲーテッド CA を決して導入しないリソース保有者でも、正確な認証を公開できる。RIR インターフェースは、提案された ROA が既知のアナウンスを Invalid にする場合に警告できる。中央システムは更新、鍵ロールオーバー、マニフェスト、リポジトリ可用性を自動化できる。サポートスタッフは会員が間違いを修正するのを助けることができる。
すべてのコミュニティネットワーク、大学、地域プロバイダに CA の運用を強制することを成熟と定義するのは逆説的だろう。大規模キャリアだけが管理できるセキュリティは不完全なままになる。過度の依存に対する反論は、RPKI への低摩擦の経路を維持しなければならない。
政策目的は、安全なデフォルトを備えたオプション性である。ホステッドサービスはアクセス可能なデフォルトであり続けるべきである。デリゲーテッドおよびハイブリッドサービスは、より多くの制御を必要とするリスクに対して実用的な出口であり続けるべきである。それらの間の移行は回避可能なギャップを生み出すべきではない。利便性は、それが選択である場合に価値があり、静かに監禁になるときにはそれほど価値がない。
5 つの制御が 1 つのポータルに隠されている
ホステッドインターフェースは 1 つのサービスを提示するが、少なくとも 5 つの制御がその下にある。
第一は登録範囲である。RIR は、どの IP アドレスブロックと AS 番号がその記録で保有者に関連付けられ、リソース証明書内に配置されるかを決定する。ポータルはその範囲外のプレフィックスを認証できない。
第二はルーティング意図である。保有者は発信元 AS、プレフィックス、最大長を選択する。よく設計されたホステッドサービスでは、スタッフがこの意図を発明しない。ユーザーは認証された制御を通じて送信し、システムは明らかな矛盾について警告する。
第三は鍵の管理と署名である。ホステッドプロバイダは秘密鍵を生成または保存し、それを使用して署名済みオブジェクトを作成する。RIPE NCC の用語では、ホステッド CA は暗号操作を担当し、保有者の公開鍵と秘密鍵のペアをホストするものと定義されている。APNIC も同様に、ホステッドユーザーに代わって秘密鍵を生成すると述べている。
第四は公開である。RIR リポジトリは、証明書、マニフェスト、失効リスト、署名済みオブジェクトを依拠当事者が利用できるようにする。公開は新鮮でグローバルに取得可能でなければならない。正しい署名でも、検証者が利用できなければ運用上の価値はほとんどない。
第五はライフサイクル権限である。サービスは証明書を更新、交換、失効し、リソースやサービスステータスが変更されたときにオブジェクトを削除する。ここで登録、契約、ルーティング証拠が合流する。
ポータルはこの複雑さを良い理由で隠している。問題は、ガバナンスもそれを隠すときに発生する。ユーザーは「ROA を作成」をクリックできるため RPKI を制御していると信じるかもしれないが、プロバイダは鍵、公開、終了を制御する。プロバイダはルーターがローカル決定を行うことを強調するかもしれないが、そのライフサイクルアクションがルーターが受信するデータをどのように変えるかを過小評価する。
有用なサービス契約は、各制御を名前付け、義務を割り当てるべきである。そのマップがなければ、責任はインシデントの後にのみ現れ、各当事者は異なる層を指すことになる。
ホステッド鍵の管理は通常のアウトソーシングではない
組織は日常的に電子メール、給与計算、クラウドコンピューティングをアウトソーシングする。ホステッド RPKI は 1 つの点で異なる。サービスプロバイダは、証明書の範囲を決定する親権限でもある。したがって、署名できるものを定義する力と、署名を実行する能力を組み合わせる。
この集中は効率的である。プロバイダは、保有物が変更されたときに証明書を自動的に更新し、期限切れ前にオブジェクトを更新し、ユーザーに登録されなくなったリソースの認証を削除できる。ハードウェアセキュリティモジュールに鍵を保管し、小規模事業者よりも効果的に運用ロールを分離できる。
また、脅威モデルも変わる。認証と承認が弱い場合、侵害されたユーザーアカウントは有害なルーティング意図を作成する可能性がある。侵害されたホステッド署名環境は多くの CA に影響を与える可能性がある。誤った登録更新はリソースを削除し、オブジェクト変更を引き起こす可能性がある。内部管理者が、単一の従業員が持つべきでない権限を持つ可能性がある。法的または契約上の決定が、保有者が別途署名アクションを取ることなく実行される可能性がある。
これらは RIR が鍵を悪用しているという非難ではない。制御集中の結果である。答えは強力なサービス設計である。多要素認証、ロールベースの承認、高リスク変更の遅延、独立した監査、ハードウェア保護、不変の履歴、登録変更と証明書影響実行の分離。
保有者は、ルーティング意図と現在のオブジェクトセットの完全な署名済みアカウントをエクスポートできるべきである。サービスが鍵を非取得可能に適切に保持している場合、秘密鍵はエクスポートできないが、デリゲーテッド CA または後継ホステッド CA の下で認証を再作成するのに十分な情報を保持できる。データポータビリティは鍵ポータビリティではない。
プロバイダはまた、アカウント管理者、RIR スタッフ、または自動イベントがホステッド CA 全体を失効できるかどうか、どのような承認が必要か、誤った失効をどの程度迅速に逆転できるかを開示すべきである。鍵の使用に関する制御が、ポータルの緑の Valid ラベルと同じくらい可視的であるときに、セキュリティサービスは信頼できるものになる。
単一障害点は、すべての停止ではなく、失効と復旧である
ホステッド RPKI を単一障害点と呼ぶのは粗すぎることがある。リポジトリは複製される可能性がある。既存のオブジェクトには有効期間がある。依拠当事者ソフトウェアは検証済みデータをキャッシュし、利用できないリポジトリのルールを持つ。短いポータル中断はルート検証を変更しないかもしれない。RIR は会員が負担できるよりもはるかに回復力のあるインフラを運用する可能性がある。
より鋭い単一障害点は、失効と復旧に対する権限である。RIR がホステッド CA を失効させるか、認証へのアクセスを終了した場合、ユーザーはその CA の下で署名を続けることはできない。RIR がサービス終了時にホステッドオブジェクトを削除した場合、事業者は古いリポジトリにそれらを無期限に提供するよう強制することはできない。親は、ユーザーが有効な経路を取り戻す前に、新しいデリゲーテッド証明書を発行するか、ホステッドサービスを復元しなければならない。
現在の条件が問題を示している。RIPE NCC の条件は、認証サービスが終了したときにすべての署名済みオブジェクトが削除されると述べており、証明書が登録記録と矛盾する場合、技術的またはセキュリティ上の理由、条件違反、または保有者がサービスを終了した場合に失効を許可している。ARIN の契約は即時終了のいくつかの根拠を列挙し、RPKI 適格性を他の契約にリンクし、通知ベースの終了権も留保している。
法的言語は地域によって異なり、1 つのグローバルルールに平坦化されるべきではない。契約上の権利が不当に使用されたことを証明するものでもない。ポイントは構造的である。ホステッドユーザーは、継続的な署名とその署名構成からの移行の両方において、同じ相手方に依存している。
信頼できるホステッドサービスには終了保証が必要である。非緊急終了の場合、デリゲーテッドまたは代替 CA を確立し、構成をエクスポートし、公開を検証し、ルート変更を調整するための定義された期間を提供すべきである。緊急失効には、保有者が認証を受ける権利がある場合に、新しい鍵の下での迅速な再登録を含めるべきである。支払いや身元に関する紛争は、ルーティング証拠が不必要に破壊される前に、迅速なレビュー経路を持つべきである。
これらの機能がなければ、通常の週の高可用性は最も重大な障害モードに答えることはできない。
デリゲーテッド RPKI は誰が署名できるかを変える
デリゲーテッド RPKI では、保有者は子 CA を実行し、その秘密鍵を制御する。親 RIR はその子にリソース証明書を発行する。保有者は ROA やその他の許可されたオブジェクトを作成し、ネットワークシステムから変更を自動化し、サポートされている場合にはさらに子証明書を発行できる。
これにより、事業者は 3 つの形式の独立性を得る。ルーティング変更ごとにホステッド署名ポータルを必要としない。鍵を自社のセキュリティポリシーの下で保護できる。複数の RIR 親から受信したリソースを 1 つのローカルシステムで管理でき、地域インターフェース間の不整合な手動操作を減らす。
独立性は暗号的に意味がある。RIR 親は、子証明書を発行したという理由だけで、子の鍵で偽のオブジェクトに署名することはできない。ローカルに保持された監査履歴は、保有者が何をいつ署名したかを正確に示すことができる。事業者は、BGP 意図の変更と RPKI オブジェクトがどの程度密接に結合されるかを決定できる。
委任は、リソースに関して保有者を独自のトラストアンカーにするわけではない。親は依然として証明書内のリソースを決定する。譲渡や返却後に証明書をより狭いものに置き換えることができる。子証明書を失効させることができる。保有者が有効範囲を超えて署名した場合、依拠当事者は過剰主張を拒否する。
この境界は紛争において重要である。委任は、親のホステッド鍵とユーザーインターフェースへの依存から保護する。正当な譲渡後に元の保有者が認証を維持できるようにするものではない。レジストリ記録を無関係にするわけではない。事業者に、親が現在認証する範囲内でのステートメントに対する制御を与える。
したがって、委任は分離として販売されるべきであり、分離としてではない。その価値は、単一の機関がすべての署名鍵を所有し、すべての親決定を制御するわけではないことである。その限界は、リソース階層が依然として権威ある親を必要とすることである。
公開は第 3 のモデルを生み出す
通常のホステッドとデリゲーテッド RPKI の比較は、有用な中間点を見逃す。保有者は、RIR のリポジトリ公開サービスを使用しながら、独自の CA と秘密鍵を運用できる。ARIN はこれをリポジトリ公開サービスと呼んでいる。RIPE NCC は Publish in Parent を提供している。APNIC はセルフホストクライアント向けの公開を提供している。
このハイブリッドモデルは、署名の管理を配信から分離する。事業者は RIR のホステッド CA なしでオブジェクトを作成でき、RIR は依拠当事者が既に取得している高可用性リポジトリを提供する。すべての保有者がグローバル公開サービスを公開して防御する必要がなくなる。
ハイブリッドサービスは、多くの場合、能力のある事業者に最良のバランスを提供する。ローカル鍵制御はホステッド署名インターフェースへの依存を減らす。親公開は運用負荷と脆弱なリポジトリの増殖を減らす。RFC 8181 などの標準は、認証された公開および撤回要求を定義し、CA とリポジトリが異なる当事者によって実行されることを可能にする。
分離は完全な独立性ではない。公開プロバイダは変更を受け入れられなかったり、利用できなくなったり、条件に基づいて資料を削除したりする可能性がある。親は依然として子リソース証明書を発行する。最も強力な自律性を必要とする事業者は、CA とリポジトリの両方を実行する可能性があるが、その結果としての可用性とセキュリティの義務を受け入れる。
APNIC の 2025 年の RPKI 可用性に関する議論は、トレードオフを直接述べている。デリゲーテッド CA は、保有者に RPKI 状態のより大きな制御と、オブジェクトの発行と更新の責任を与える。しかし、APNIC トラストアンカーに依存し、APNIC 公開を使用する場合はそのリポジトリにも依存する。この論文はまた、多くのデリゲーテッドリポジトリが 1 つの場所に単一インスタンスであると警告している。
したがって、有用なモデルはスペクトルである。ホステッドは署名と公開を RIR に置く。ハイブリッドは署名をローカルに、公開をプロバイダに置く。完全にデリゲーテッドは両方をローカルに保つ。親認証はこれらすべての上に残る。組織は、どの依存関係を吸収する装備があるかを意図的に選択すべきである。
セルフホスティングには独自の失効罠がある
運用障害を無視するデリゲーテッド RPKI の議論は不完全である。CA は、次の更新時刻前に新しいマニフェストと失効リストを発行しなければならない。そのリポジトリは一貫した資料を提供しなければならない。鍵は、簡単に盗まれずにハードウェア障害を乗り越えなければならない。スタッフは過剰主張、鍵ロールオーバー、親交換を理解しなければならない。
無視されたデリゲーテッド CA は、依拠当事者に負担をかけ、自身のオブジェクトを使用不能にする可能性がある。RIPE-847 は極端なケースに対処している。RIPE NCC がデリゲーテッド CA の現在のマニフェストと失効リストを 3 か月以上発見および検証できない場合、合理的な発見と通知の努力の後にリソース証明書を失効させることになっている。このポリシーは、通常の短時間の停止ではなく、持続的に機能しない CA を明確に対象としている。
このポリシーは相互義務を明らかにする。委任は保有者に署名制御を与えるが、親と依拠当事者コミュニティは、子が無期限に壊れたままにならないという保証を必要とする。親は枯れた枝を剪定できなければならない。保有者は検証失敗の証拠、通知、復旧経路を受け取らなければならない。
事業者はまた、人的継続性リスクに直面する。CA を構築した 1 人のエンジニアが去るかもしれない。バックアップ鍵は存在するが読み取れないかもしれない。会社の買収により、ネットワークチームとセキュリティデバイスが分離される可能性がある。危機により、ローカル主権が 1 台のラップトップと 1 つのメモリに依存していたことが明らかになる可能性がある。
デリゲーテッドサービスは必ずしもコンピューティングの観点から高価ではない。最新の CA ソフトウェアは控えめなハードウェアで実行できる。真のコストは制度的である。所有権、オンコール責任、変更レビュー、バックアップテスト、リポジトリ監視、継承。大規模キャリアはこれらのタスクで失敗する可能性があるが、規律ある小規模事業者はそれらをうまく実行できる。
したがって、ホステッドサービスとの比較は、両方の失効単一障害点を数えなければならない。ホステッドユーザーは、プロバイダの決定と復旧への依存を危険にさらす。デリゲーテッドユーザーは、自分のブランチ内で失敗する権威になるリスクを負う。ハイブリッド設計と強力な親プロセスは、どちらのリスクも減らすことができ、排除することはできない。
移行はオプション性がテストされる場所である
市場は、ユーザーが選択を変更できる場合にのみ選択を提供する。ホステッドとデリゲーテッド RPKI 間の移行は技術的にデリケートである。なぜなら、新旧の CA が同じリソースをカバーする可能性があり、依拠当事者は異なる時間にデータを取得するからである。
RIPE NCC のホステッドドキュメントは、デリゲーテッドサービスに移行するユーザーは最初にホステッド CA を失効させなければならず、現在そこで make-before-break 移行は不可能であると述べている。APNIC は、移行中にホステッドモードとセルフホストモードを並行して実行できると述べている。ARIN は、デプロイメントを変更する場合に登録サービスに連絡するよう指示している。これらは実質的に異なる運用経験である。
理想的な移行は、鍵と公開ポイントが変更される間、有効なルーティング意図を維持する。ユーザーは現在の認証をエクスポートし、新しい CA を準備し、親とリポジトリの交換をテストし、同等のオブジェクトを公開し、古い CA が消える前に独立した検証者からそれらを観察すべきである。地域ポリシーが重複を禁止する場合、サービスは迅速なロールバックを伴うスケジュールされたカットオーバーをサポートすべきである。
並行認証は自動的に良性ではない。重複または矛盾するオブジェクトは事業者を混乱させる可能性があり、古い鍵は必要以上に長く権限を保持すべきではない。安全な重複には、固定期間、同等のリソース範囲、明確な責任、自動終了が必要である。しかし、代替案は、ユーザーがホステッドもデリゲーテッドも制御できない未説明の期間であってはならない。
移行は、譲渡、合併、企業再編の際にも重要である。買い手はデリゲーテッド制御を望む一方、売り手はホステッドサービスを使用していたかもしれない。複数の RIR を通じて運営するグループは CA を統合するかもしれない。RIR は RPKI 移行をリソース移動の標準的な部分として扱うべきであり、最終日の後付けではない。
ポータビリティメトリクスは説明責任を向上させる。各 RIR は、通常の手順、最小通知、変更アクセスのない予定期間、重複が利用可能かどうか、失敗したカットオーバーのエスカレーション連絡先を公開できる。オプション性が安全に行使できない場合、ホステッドデフォルトは、そのシンプルなインターフェースが示唆するよりも多くのロックインを持つ。
重要なネットワークには結果ベースの選択が必要である
すべての保有者に単一の正しいデプロイメントモデルはない。選択は、認証を変更できないことの結果、ルーティングの複雑さ、組織の CA 運用能力に依存するべきである。
少数の安定したプレフィックスと 1 つの発信元を持つ小規模プロバイダは、合理的にホステッドサービスを使用できる。RIR は鍵を保護し、オブジェクトを更新し、プロバイダよりも確実にリポジトリを運用できる。委任は意味のある利益なしに障害モードを追加する可能性がある。プロバイダは依然として ROA 在庫をエクスポートし、緊急連絡先を維持し、終了条件を理解すべきである。
頻繁なルーティング変更、複数の発信元、顧客、自動化された緩和策を持つ複数 RIR キャリアは、デリゲーテッド署名のより強いケースを持つ。承認されたネットワーク変更と認証を統合し、複数の親にわたって 1 つの制御面を維持し、複数のポータルへの依存を減らすことができる。ハイブリッド公開は、多くの公開リポジトリの実行を避けることができる。
公共部門ネットワークは特に注意が必要である。病院、緊急通信、税務システム、パブリッククラウド、研究ネットワークは、断片化された到達可能性から不釣り合いな害を被る可能性がある。これはすべての機関がセルフホストすべきという意味ではない。選択されたモデルは、明示的な継続性目標、テストされたアクセス復旧、複数の訓練された管理者、親との事前合意されたエスカレーション経路を持つべきである。
下流責任も重要である。直接保有者は、RIR サービスに直接参加できない顧客のために ROA を作成する可能性がある。1 つのホステッドアカウントが多くの下流発信元を制御する場合、アカウント停止または乗っ取りはより大きな爆発半径を持つ。デリゲーテッドサブ CA は制御を分散できるが、親と保有者がそれらを安全にサポートできる場合に限る。
理事会は簡単な質問をすべきである。現在のプロバイダまたはローカル CA がルーティング変更中に利用できなくなった場合、有効な認証はどのように復旧されるのか?その答えは、人、鍵、親連絡先、公開経路、最大許容遅延を挙げるべきである。セットアップ画面が簡単だったためだけに選択されたモデルは、そのテストに合格していない。
会員ガバナンスがデフォルトを形成すべきである
RIR は通常のソフトウェアベンダーではない。それらは地域のコミュニティガバナンス機関内でユニークなリソースを調整する。彼らのホステッド RPKI 条件は、同じアドレスを競合する親に持っていけない会員に影響を与える可能性がある。これにより、会員の説明責任がサービス設計の中心になる。
会員は、失効を許可するイベントのクラス、各クラスに添付された通知、紛争アカウントの取り扱い、デリゲーテッドサービスへの出口経路を承認または精査すべきである。技術コミュニティは証明書とリポジトリの慣行をレビューすべきであり、法務およびガバナンスコミュニティは終了と責任の言語をレビューすべきである。どちらの分野も単独では十分ではない。
デフォルトはホステッドであるべきである。なぜなら導入が重要であり、制度的集中が不可視だからではない。登録時に、ユーザーは制御の平易な比較を受け取るべきである。ホステッドはプロバイダが鍵とリポジトリを管理することを意味する。デリゲーテッドは保有者が鍵と場合によっては公開を管理することを意味する。ハイブリッドはそれらの義務を分割する。すべてが親証明書の下に残る。
ユーザーは、公開された技術要件を満たしていれば、例外的なステータスを証明することなく委任を選択できるべきである。また、理事会は安全に運用できない会員に委任を強制すべきではない。サービス料金は、暗号独立性を大規模既存事業者向けの贅沢品として価格設定することなく、実際のコストを反映すべきである。
条件の変更は、緊急のセキュリティや法律がそれを不可能にしない限り、事前のコミュニティ通知に値する。例えば、RIPE NCC の 2026 年条件は、ホステッドとデリゲーテッドの管理を定義し、失効条件を指定している。同様の明確さは、正確なルールが異なる場合でも、すべての地域で利用可能であるべきである。
機関はインシデントクラスと復旧パフォーマンスを公開すべきである。会員は、サービスの稼働時間だけを知っていても、利便性の取引が健全かどうかを判断できない。ポータルは利用可能でも、保有者が誤ってオブジェクトを変更できない場合がある。リポジトリは到達可能でも、登録エラーが正しいものを削除した場合がある。
契約は誤用と意見の相違を区別すべきである
広範な終了条項は、詐欺、侵害、違法使用からプロバイダを保護する。また、無関係な紛争を認証継続性と組み合わせる可能性がある。未払い請求書、企業文書の質問、虐待疑惑、盗まれた秘密鍵は、同じルーティングリスクを提示しない。
サービス条件はそれらを分割すべきである。確認された鍵の侵害は即時失効を必要とする場合がある。完了した譲渡後の権利喪失は迅速な証明書変更を必要とする。疑惑のアカウント乗っ取りは、新しい署名の凍結、強力な再認証、安全な場合の既存の有効なオブジェクトの保存を必要とする。紛争のある料金はサービスの救済策を正当化するかもしれないが、ルート認証の自動破壊は、リソースが引き続き保有者に登録されている場合、最後の手段であるべきである。
この区別は無条件の認証権を作成しない。救済策を脅威に合わせる。RPKI は効果的だからといって一般的な回収メカニズムになるべきではない。また、RIR はリソースを保持しなくなった当事者のために署名を続けるべきではない。
書面による理由は、ホステッドユーザーにとって最も重要である。なぜなら、彼らはプロバイダの周りで行動できないからである。通知は、制限がポータルアクセス、新しいオブジェクトの作成、公開、証明書範囲、または CA 全体に影響するかどうかを特定すべきである。一時的なアクセス凍結は失効とは異なり、ユーザーはどの条件が適用されるかを知る必要がある。
レビューはルーティング運用に十分速くあるべきである。技術レビューアは最初に身元、リソース範囲、オブジェクト差分を検証できる。別の契約レビューアは根本的な紛争を決定できる。広範囲な検証影響のために、通常の勤務時間外でも緊急連絡先を利用可能にすべきである。
責任条件も割り当てられた制御を反映すべきである。ホステッドユーザーは誤った指示と資格情報のセキュリティに責任がある。プロバイダは受け入れられた指示を忠実に実行し、管理下の鍵を保護し、公開された失効プロセスに従う責任がある。リモートネットワークは自身のルーティングポリシーに責任がある。明確な分割は、すべての結果が最も弱い当事者に属することを示唆する条項よりも信頼できる。
継続性にはポリシーページではなくリハーサルが必要である
事業者は、危機の前に RPKI 復旧をテストすべきである。演習は公開オブジェクトを変更せずに開始できる。チームは現在のプレフィックス、発信元 AS、最大長、親 CA、ホステッド構成、デリゲーテッド子、公開プロバイダをリストすべきである。そのインベントリを実際の BGP アナウンスおよび検証済みペイロードと比較すべきである。
ホステッドユーザーは、少なくとも 2 人の許可された人物が独立した資格情報を通じてサービスにアクセスできることを確認すべきである。運用連絡先と法務連絡先は最新であるべきである。チームは、通常のアクセスが失敗したときに RIR に連絡する方法と、身元がどのように再確立されるかを知っておくべきである。意図された認証の機械可読コピーを保持すべきである。
デリゲーテッドユーザーは、分離された環境で鍵のバックアップと復元をテストし、証明書の更新を監視し、マニフェストと失効リストを検証し、自社ネットワークの外部から公開を観察すべきである。複数の人が親とリポジトリの交換を理解すべきである。文書は買収やスタッフ退職を乗り越えるべきである。
ハイブリッドユーザーは両方の半分をテストすべきである。公開サービスがオブジェクトを拒否した場合、ローカル署名の成功だけでは十分ではない。CA 障害とリポジトリ障害を区別する方法と、時間内に親の下で代替リポジトリを確立できるかどうかを知っておくべきである。
すべてのユーザーは発信元 AS の変更をリハーサルすべきである。テストには、経路変更前に新しい認証を作成し、独立した検証者を通じて観察し、BGP 変更を適用し、検証状態を確認し、収束後に古い認証を撤回することを含めるべきである。ライブテストが安全でない場合、地域テスト環境がプロセスの失敗を明らかにできる。
結果は、形容詞ではなく時間で述べられた継続性目標であるべきである。組織によって許容範囲は異なる。演習は、復旧を制御する正確な依存関係を明らかにし、それを修正する所有者を割り当てたときに成功である。
依拠当事者がリスク像を完成させる
リソース保有者と RIR だけが到達可能性を決定するわけではない。依拠当事者は RPKI マテリアルを取得して検証する。ルーターは検証済みペイロードを受け取り、ローカルポリシーを適用する。この分散設計は中央コマンドを制限するが、結果を不均一にする。
ホステッド CA が消失し、対象範囲の認証が残っていない場合、以前は Valid だった経路が NotFound になる可能性がある。多くのネットワークは NotFound を受け入れ続ける。生存する対象範囲の認証が経路と矛盾する場合、Invalid になり、Invalid を拒否するネットワークはそれをドロップする可能性がある。キャッシュとリフレッシュタイミングにより、変更は異なる瞬間に現れる。
事業者は、リポジトリ可用性または証明書失効が即座に単一のグローバル結果を生み出すと想定すべきではない。APNIC の可用性論文は、アーキテクチャが意図したよりも強く RPKI に依存することに対して警告している。例えば、顧客からの ROA 要求や、可用性特性を考慮せずに ROA でカバーされていないすべての経路の拒否など。
この注意は発信元検証のケースを弱めるものではない。層状のセキュリティを求める。ネットワークは RPKI を顧客契約、ルートフィルター、インターネットルーティングレジストリデータ、直接検証、厳格な制御によって管理される緊急例外と組み合わせることができる。例外は、静かに悪いルーティングデータの恒久的な受け入れになるべきではない。
依拠当事者の多様性も復旧を助けることができる。保有者と RIR は、カットオーバーが完了したと宣言する前に、複数のバリデータ実装と視点を観察すべきである。リポジトリはローカルでは健全に見えても、リモートのバリデータが取得できない場合がある。署名済みオブジェクトは存在しても、過剰主張または古いサポート資料により拒否される場合がある。
したがって、利便性の罠は両端から見える。プロデューサーは 1 つの署名プロバイダに依存するようになる。コンシューマーは、一時的な喪失の計画なしに、1 つのクラスの検証データに依存するようになる。成熟したルーティングセキュリティは、RPKI が証明できることについて権威を持ちながら、すべての緊急時に利用可能な唯一の証拠として扱うことを拒否する。
より良いホステッド取引には具体的な条件がある
ホステッドモデルは、面倒にすることなく改善できる。最初の改革はオブジェクトエスクローレコードである。継続的にエクスポート可能な、現在のルーティング意図、認証されたリソース、公開識別子の署名付きリスト。ホステッド秘密鍵を公開しない。保有者が代替 CA の下で同等の認証を再構築できるようにする。
2 つ目は失効はしごである。低リスクのアカウント問題は、安全な場合に既存のオブジェクトを保存しながら変更を制限すべきである。高リスクの登録イベントは通知と移行を生成すべきである。確認された侵害は即時失効とクリーンキー復旧を引き起こす可能性がある。各段には名前付き承認とレビューが必要である。
3 つ目はポータブル登録である。委任を選択するユーザーは、制御されていない重複に対する保護の対象として、ホステッド CA が削除される前に、身元交換、公開、同等のオブジェクトを準備できるべきである。これをサポートできない地域サービスは、正確なギャップとそれを減らす計画を公開すべきである。
4 つ目は破壊的行為に対する独立した確認である。ホステッド CA 全体の失効、すべての構成の削除、認証されたリソースの縮小は、自動更新または事前承認された譲渡が検証済みイベントに従う場合を除き、デュアルコントロールを必要とするべきである。システムは実行前に既知のアナウンスへの予想される影響を示すべきである。
5 つ目は稼働時間以上のサービス報告である。RIR は、証明書に影響する登録エラー、失敗した移行、緊急失効、復旧時間、通知パフォーマンスを報告すべきである。少数は、グローバルレートを装うことなく慎重に開示されるべきである。
6 つ目は狭い救済策である。プロバイダのエラーが有効な認証を削除した場合、即時復旧、専門家サポート、保存されたインシデント記録、独立したレビューを提供すべきである。深刻な繰り返し障害は、プライベートサポートチケットに留まらず、理事会と会員に到達すべきである。
これらの保護措置により、ホステッド RPKI はより便利になり、不便になるわけではない。通常の仮定が失敗したときに必要な特注の交渉の量を減らす。
番号資源社会(Number Resource Society)が追加できること
番号資源社会(Number Resource Society)は、正確な登録、保有者の権利、参加、官僚的障壁の低減の提唱者として自らを位置づけている。ホステッド RPKI は、それらの原則を測定可能な会員サービスに変える適切な場所である。
NRS は 5 つの RIR を比較するデプロイメント選択レジスタを公開できる。誰が秘密鍵を保持するか、デリゲーテッドサービスが利用可能か、親公開が提供されるか、移行がどのように機能するか、どのような失効根拠が公開されているか、どのような通知が適用されるか、保有者がどこでレビューを求めることができるかをリストすべきである。各エントリは関連する RIR 資料にリンクし、未解決の質問を述べるべきである。
3 つの継続性演習を維持できる。1 つはホステッドユーザー向け、1 つはデリゲーテッド CA 向け、1 つはハイブリッド公開向け。ホステッド演習はアクセス復旧と構成エクスポートをテストする。デリゲーテッド演習は鍵、マニフェスト、親交換、継承をテストする。ハイブリッド演習はリモート公開に対するローカル署名をテストする。結果は参加者にプライベートに保つことができ、一般的な失敗テーマはサポートされていないレートなしで公開される。
NRS はまた、小規模事業者を地域政策議論に参加させることができる。大規模ネットワークは CA ソフトウェアを評価し、確立された関係を通じて緊急サポートを交渉できる。地方プロバイダや非営利ネットワークは、ポータルアクセス、証明書範囲、オブジェクト公開が別々の制御であることを知らないかもしれない。会員会議での平易な質問は、すべての人のサービスを改善できる。
貢献は範囲を限定すべきである。NRS のアドボカシーは、RPKI トラストアンカー、証明機関、リポジトリ事業者、中立調停者であることを確立しない。すべての保有者が安全にセルフホストできるとか、RIR サービスが本質的に疑わしいと示唆すべきではない。その有用な役割は、選択を情報に基づいたものにし、出口を実用的にし、説明責任を比較可能にすることである。
肯定的な制度的批評は疑惑よりも耐久性がある。強力な移行設計を称賛し、弱い通知を特定するレジスタは、RIR 理事会に実用的な改善リストを提供できる。また、ローカル鍵の管理をステータスのバッジとして扱うのではなく、ホステッドサービスが責任ある選択である時期を事業者に示すことができる。
一般的な反論は割り当ての問題を見逃している
ホステッド RPKI の擁護者は、RIR がすでに登録を制御しているため、デリゲーテッド鍵はほとんど追加しないとよく言う。前提は部分的に正しい。親はデリゲーテッド証明書を制限または失効できる。結論は間違っている。子鍵の制御は、親が子のルーティング意図に署名するのを防ぎ、事業者がホステッドインターフェースなしで変更を行えるようにする。分離は階層を消去せず、その中の集中を減らす。
批評家は、RIR が鍵を保持するためホステッドサービスは安全でないと言う。それもあまりに広範である。よく運営された RIR は、多くの会員よりも確実に鍵を保護し、オブジェクトを更新し、リポジトリを公開できる。関連する質問は、そのセキュリティ、認証、復旧制御が権力の集中に一致するかどうかである。
別の反論は、並行移行が一意性を弱めるというものである。設計が悪ければその可能性がある。同等の認証のための短く制御された重複は、無期限の競合認証とは異なる。短い重複さえ受け入れられない場合でも、スケジュールされたカットオーバーと迅速なロールバックは可能である。
一部は、依拠当事者のローカルポリシーによりプロデューサーの継続性の緊急性が低くなると主張する。ローカルポリシーは結果を緩和または変更する。欠落した有効な認証を再作成することはできず、選択的な到達可能性の損失を防ぐことはできない。プロデューサーは依然として正確で継続的な証拠を必要とする。
最後に、一部の会員は、洗練されたオプションがすべての人の料金を上げると言う。地域コミュニティは、ホステッドサービスをシンプルに保ちながら、デリゲーテッドサポートまたは公開に透明な増分コストを請求できる。必須の保護手段(理由、通知、エクスポート、復旧)は贅沢機能ではない。それらはユニークなリソースに結びついたサービスの基本的な義務である。
各反論は、割り当てとしてフレーム化されると明確になる。どの当事者がリスクを制御するか、どの当事者がそれを防ぐことができるか、どの当事者が復旧できるか?ホステッドモデルとデリゲーテッドモデルは、中央またはローカル運用に対するイデオロギー的な選好ではなく、それらの答えによって判断されるべきである。
証拠は信頼が絶対的になる前に改善されるべきである
公開資料はアーキテクチャ、条件、個別インシデントを説明するが、失効されたホステッド CA、失敗した移行、ブロックされた変更、復旧時間、ルート影響の完全なクロス RIR 記録を提供しない。サービスページは機能を開示するが、すべての運用結果を開示するわけではない。プライベートサポートケースとセキュリティイベントは適切にすべて公開されていない。
これは経験的主張を制限する。ホステッド RPKI がルート損失を引き起こすグローバル確率を推定することはできない。また、公開証拠はデリゲーテッド運用がすべての保有者にとってより信頼性が高いことを証明できない。地域サービスのモデルと制御経路は観察可能である。比較故障率は観察可能ではない。
RIR 報告はギャップの一部を埋めることができる。ポータル利用不可、署名失敗、リポジトリ利用不可、親証明書エラー、ユーザー誤構成、非自発的終了を区別すべきである。現在のオブジェクトが有効のままかどうか、ルート状態が変更されたかどうか、復旧にかかった時間を記録すべきである。
事業者は、検証可能なタイムラインと匿名化されたアカウントを提供できる。研究者は公開証明書とオブジェクト変更を観察できるが、消失だけから意図を推測すべきではない。譲渡、鍵ロールオーバー、意図的な ROA 撤回は、外部からは失敗のように見える可能性がある。
したがって、信頼はアーキテクチャに最も強く、有病率には弱くあるべきである。ホステッドサービスは名前付き制御を集中させる。デリゲーテッドサービスはそれらの一部を再配分する。両方とも RIR 親の下に残る。これらは文書化された事実である。各構成がどの程度の頻度で重大な害を引き起こすかは、依然として十分に測定されていない。
この限界を認めるガバナンスプログラムは、普遍的なケースを証明するためにいくつかの停止や稼働時間の数字を選択するものよりも信頼できる。より良い証拠により、将来のコミュニティは推測せずにデフォルトを調整できるようになる。
利便性は可逆的であるべきである
ホステッド RPKI は、優れたインフラがしばしば行うことを行った。難しいセキュリティ慣行を普通にした。事業者は CA を構築し、マニフェストを管理し、公開リポジトリを防御することなく、ルート認証を作成できる。その成果は保存されるべきである。
危険は、容易な入場と安全な出口がないことで現れる。レジストラが鍵を保持し、オブジェクトを公開し、証明書範囲を変更し、再登録を制御する場合、紛争やエラーにより事業者は自身のルーティング意図を維持できなくなる可能性がある。高い通常稼働時間はその構造的依存関係を取り除かない。
デリゲーテッド RPKI は意味のあるカウンターウェイトを提供する。保有者は自身の鍵で署名し、ローカル変更を自動化し、複数の親を首尾一貫して管理できる。ハイブリッド公開は負担を軽減する。どちらのオプションも親 CA や信頼できる運用の義務を排除しない。
成熟した解決策は多様である。ホステッドサービスはシンプルなユーザーのデフォルトであり続ける。デリゲーテッド署名は能力のある保有者の標準的な権利である。親公開は中間経路として利用可能である。移行はテストされ、安全な場合は make-before-break である。失効根拠は正確であり、通常の紛争は不釣り合いなルーティング結果を引き起こさず、緊急行動は迅速なレビューと復旧を伴う。
利便性は制御の反対ではない。ルーチン運用のために別の機関の制御を借りる方法である。その取引は、借り手が条件を見て、意図を取得し、異なる取り決めを選択し、便利さの貸し手が間違いを犯したときに復旧できる場合にのみ健全である。
RPKI はネットワークに暗号文に依存するよう求める。そのガバナンスは同じ規律を制度的約束に適用すべきである。誰が鍵を保持するか、誰が失効できるか、誰が公開するか、誰が復旧するかは、ROA のプレフィックスや発信元 AS と同じくらい曖昧でなく、可逆的であるべきである。それらの答えが明示的で可逆的であるとき、ホステッドサービスは入り口である。それらが隠されていて逃れられないとき、それは罠である。
出典
- IETF, RFC 6480,An Infrastructure to Support Secure Internet Routing:https://www.rfc-editor.org/rfc/rfc6480
- IETF, RFC 6483,Validation of Route Origination Using the Resource Certificate Public Key Infrastructure and Route Origin Authorizations:https://www.rfc-editor.org/rfc/rfc6483
- IETF, RFC 6492,A Protocol for Provisioning Resource Certificates:https://www.rfc-editor.org/rfc/rfc6492
- IETF, RFC 6811,BGP Prefix Origin Validation:https://www.rfc-editor.org/rfc/rfc6811
- IETF, RFC 7115,Origin Validation Operation Based on the Resource Public Key Infrastructure:https://www.rfc-editor.org/rfc/rfc7115
- IETF, RFC 8181,A Publication Protocol for the Resource Public Key Infrastructure:https://www.rfc-editor.org/rfc/rfc8181
- IETF, RFC 8211,Adverse Actions by a Certification Authority or Repository Manager in the Resource Public Key Infrastructure:https://www.rfc-editor.org/rfc/rfc8211
- ARIN,RPKI Deployment Options:https://www.arin.net/resources/manage/rpki/options/
- ARIN,RPKI Frequently Asked Questions:https://www.arin.net/resources/manage/rpki/help/faq/
- ARIN,RPKI Terms of Service Agreement:https://www.arin.net/resources/manage/rpki/tos/
- RIPE NCC,Using the RPKI System:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/using-the-rpki-system/
- RIPE NCC,Using the Hosted Certification Authority:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-roa-management/
- RIPE NCC,Using a Delegated Certification Authority:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/using-a-delegated-certification-authority/
- RIPE NCC,Certification Service Terms and Conditions:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/legal/ripe-ncc-certification-service-terms-and-conditions/
- RIPE NCC,Publish in Parent Service and Repository Terms and Conditions:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/legal/ripe-ncc-publish-in-parent-service-and-repository-terms-and-conditions/
- RIPE NCC, RIPE-847,Revocation of Persistently Non-functional Delegated RPKI CAs:https://www.ripe.net/publications/docs/ripe-847/
- APNIC,Resource Public Key Infrastructure:https://www.apnic.net/community/security/resource-certification/
- APNIC,Certification Practice Statement:https://www.apnic.net/community/security/resource-certification/certification-practice-statement/
- APNIC,RPKI Availability Concerns:https://www.apnic.net/wp-content/uploads/2025/10/RPKI-availability-concerns_241025.pdf
- APNIC,APNIC Now Supports RFC-Aligned Publish in Parent Self-Hosted RPKI:https://blog.apnic.net/2020/11/20/apnic-now-supports-rfc-aligned-publish-in-parent-self-hosted-rpki/
- LACNIC,Resource Certification:https://www.lacnic.net/640/1/lacnic/resource-certification-rpki
- Number Resource Society,Our Charter:https://nrs.help/our-charter/
- Number Resource Society,Frequently Asked Questions:https://nrs.help/faq/

