サマリー

  • ホステッド RPKI は、困難な証明書、更新、マニフェスト、失効リスト、リポジトリの作業をリソース保持者から取り除きます。これにより、専門の公開鍵チームを持たない組織でも、経路起点認可（ROA）を作成・維持できるようになりました。
  • このサービスは制御も一元化します。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 は、これらの質問に異なる答えを返します。

利便性は、真の採用課題を解決した

RPKI CA の運用は、通常のログイン証明書を作成することと同じではありません。CA は、鍵の保護、リソース証明書の要求と更新、署名付きオブジェクトの発行、マニフェストと証明書失効リストの維持、新しい資料の公開、障害時の存続、そして親システムとの正しい相互作用を行わなければなりません。そのリポジトリは、直接または公開プロバイダを介して、依拠当事者から到達可能でなければなりません。エラーは経路起点検証を変えてしまう可能性があります。

ほとんどの中小規模事業者は、このタスクのためのチームを編成しませんでした。彼らはプレフィックスを認可したいのであって、公開鍵基盤の専門家になりたいわけではなかったのです。ホステッド RPKI は、使い慣れたメンバーポータルで起点 AS とプレフィックスを選択できるようにし、RIR が証明書の発行、署名、更新、公開を処理しました。

地域サービスはこの利点を率直に説明しています。ARIN はホステッド RPKI を最も簡単な選択肢と呼び、CA と高可用性リポジトリを運用していると述べています。RIPE NCC は、ホステッドユーザーは主に ROA を意図した BGP ルーティングと整合させる必要があり、そのシステムが暗号化操作と公開を処理するとしています。APNIC はホステッドユーザー向けに証明書と公開基盤を管理し、彼らに代わって秘密鍵を生成します。LACNIC は 2011 年からホステッドサービスを提供しています。

このモデルは正の外部性を生み出します。委任 CA を決して配備しないであろうリソース保持者でも、正確な認可を公開できます。RIR のインターフェースは、提案された ROA が既知のアナウンスを Invalid にする場合に警告できます。中央システムは、更新、鍵のロールオーバー、マニフェスト、リポジトリの可用性を自動化できます。サポートスタッフは、メンバーが誤りを修正するのを支援できます。

成熟度を、あらゆるコミュニティネットワーク、大学、ローカルプロバイダに CA の運用を強制することと定義するのは不合理でしょう。大規模キャリアだけが管理できるセキュリティは不完全なままです。過度な依存に反対する論拠は、RPKI への低摩擦な経路を維持しなければなりません。

政策の目標は、安全なデフォルトを伴う選択肢の提供です。ホステッドサービスは、アクセスしやすいデフォルトであり続けるべきです。委任およびハイブリッドサービスは、リスクがより多くの制御を必要とするユーザーにとって実用的な出口であり続けるべきです。それらの間の移動が回避可能な空白を生じさせてはなりません。利便性は、選択肢であるときには価値がありますが、静かに束縛へと変わるときには価値が薄れます。

5 つの制御が 1 つのポータルに隠されている

ホステッドインターフェースは 1 つのサービスを提示しますが、その下には少なくとも 5 つの制御が存在しています。

1 つ目は登録範囲です。RIR は、どの IP アドレスブロックと AS 番号をその記録が保持者に関連付け、リソース証明書に含めるかを決定します。ポータルはその範囲外のプレフィックスを認可できません。

2 つ目は経路意図です。保持者は起点 AS、プレフィックス、および最大長を選択します。よく設計されたホステッドサービスでは、スタッフがこの意図を作り出すことはありません。ユーザーは認証された制御を通じてそれを提出し、システムは明白な競合について警告します。

3 つ目は鍵の保管と署名です。ホステッドプロバイダは秘密鍵を生成または保管し、それを使用して署名付きオブジェクトを作成します。RIPE NCC の条件では、ホステッド CA とは、暗号化操作に責任を持ち、保持者の公開鍵と秘密鍵のペアをホストするものと定義されています。APNIC も同様に、ホステッドユーザーに代わって秘密鍵を生成すると述べています。

4 つ目は公開です。RIR のリポジトリは、証明書、マニフェスト、失効リスト、署名付きオブジェクトを依拠当事者が利用できるようにします。公開は新鮮で、グローバルに取得可能でなければなりません。バリデータから利用できない正しい署名は、ほとんど運用上の価値がありません。

5 つ目はライフサイクル権限です。サービスは証明書を更新、交換、失効させ、リソースやサービス状態が変化したときにオブジェクトを削除します。これは登録、契約、経路証拠が交わる場所です。

ポータルは、もっともな理由でこの複雑さを隠しています。問題は、ガバナンスもまたそれを隠してしまうときに生じます。ユーザーは、「ROA を作成」をクリックできるため RPKI を制御していると信じるかもしれませんが、実際にはプロバイダが鍵、公開、終了を制御しています。プロバイダは、ルーターがローカルな判断を下すことを強調する一方で、そのライフサイクルアクションがルーターが受け取るデータをどのように変えるかを過小に説明するかもしれません。

有用なサービス契約は、各制御を明示し、義務を割り当てるべきです。そのような地図がなければ、責任はインシデントの後になって初めて現れ、各当事者が異なる層を指さすことになります。

ホステッドにおける鍵保管は通常のアウトソーシングではない

組織は日常的に電子メール、給与計算、クラウドコンピューティングをアウトソーシングしています。ホステッド RPKI は一つの点で異なります。サービスプロバイダが、証明書の範囲を決定する親の権限も兼ねているのです。したがって、署名できる内容を定義する権限と、署名を実行する能力を兼ね備える可能性があります。

この集中は効率的です。プロバイダは、保有リソースが変更されたときに自動的に証明書を更新し、有効期限前にオブジェクトを更新し、もはやユーザーに登録されていないリソースの認可を削除できます。また、ハードウェアセキュリティモジュールに鍵を保管し、小規模事業者よりも効果的に運用役割を分離できます。

一方で、脅威モデルも変化させます。認証と承認が弱ければ、侵害されたユーザーアカウントが有害な経路意図を作成する可能性があります。侵害されたホステッド署名環境は、多数の CA に影響を与え得ます。誤った登録更新がリソースを削除し、オブジェクト変更を引き起こすかもしれません。内部管理者が、単独の従業員が持つべきでない権限を持っている可能性があります。法的または契約上の決定が、保持者による別個の署名アクションなしに実施される可能性があります。

これらは RIR が鍵を誤用しているという非難ではありません。制御の集中がもたらす結果です。答えは強固なサービス設計です。多要素認証、役割に基づく承認、高リスク変更の遅延、独立した監査、ハードウェア保護、不変の履歴、そして登録変更と証明書に影響を与える実行の分離です。

保持者は、自身の経路意図と現在のオブジェクトセットの完全な署名付き記録をエクスポートできるべきです。サービスが秘密鍵を取得不可能に正しく保っていれば、その鍵をエクスポートすることはできませんが、委任 CA または後継のホステッド CA のもとで認可を再作成するのに十分な情報を保持することは可能です。データのポータビリティは、鍵のポータビリティではありません。

プロバイダはまた、アカウント管理者、RIR スタッフ、または自動化されたイベントがホステッド CA 全体を失効させられるかどうか、どのような承認が必要か、誤った失効をどれだけ迅速に取り消せるかを開示すべきです。セキュリティサービスが信頼に値するのは、鍵の使用に関する制御が、ポータルの緑色の Valid ラベルと同じくらい可視化されているときです。

単一障害点は失効と復旧であり、あらゆる停止ではない

ホステッド RPKI を単一障害点と呼ぶのは大ざっぱすぎるかもしれません。リポジトリは複製されているかもしれません。既存オブジェクトには有効期間があります。依拠当事者のソフトウェアは検証済みデータをキャッシュし、利用不能なリポジトリに対するルールを持っています。短時間のポータル中断では、経路検証は変わらないことがあります。RIR は、メンバーが購入できるよりもはるかに堅牢な基盤を運用しているかもしれません。

より深刻な単一障害点は、失効と復旧に対する権限です。RIR がホステッド CA を失効させたり、認証へのアクセスを終了させたりした場合、ユーザーはその CA の下で署名を続けることはできません。RIR がサービス終了時にホステッドオブジェクトを削除した場合、事業者は古いリポジトリにそれらを無期限に提供させることはできません。ユーザーが有効な経路を取り戻す前に、親は新しい委任証明書を発行するか、ホステッドサービスを復旧しなければなりません。

現在の条件がこの問題を示しています。RIPE NCC の条件では、認証サービスが終了するとすべての署名付きオブジェクトが削除され、証明書が登録記録と矛盾する場合、技術的またはセキュリティ上の理由、条件違反、または保持者がサービスを終了した場合に失効が認められています。ARIN の契約は、即時終了のいくつかの理由を列挙し、RPKI の資格を他の契約に結びつけ、さらに通知に基づく終了権も留保しています。

法的な文言は地域によって異なり、一つのグローバルルールに平準化すべきではありません。また、契約上の権利が不当に行使されたことを証明するものでもありません。ポイントは構造的なものです。ホステッドユーザーは、継続的な署名のためにも、その署名構成から移行するためにも、同じ相手方に依存しているのです。

信頼できるホステッドサービスには、出口保証が必要です。非緊急の終了に対しては、委任または代替の CA を確立し、設定をエクスポートし、公開を確認し、経路変更を調整するための一定期間を提供すべきです。緊急失効には、保持者が引き続き認証の資格を有する場合に、クリーンな鍵の下での迅速な再登録を含めるべきです。支払いや身元に関する紛争は、経路証拠が不必要に破壊される前に、迅速な審査経路を持つべきです。

これらの仕組みがなければ、通常の週における高可用性は、最も重大な障害モードに対する答えにはなりません。

委任 RPKI は、誰が署名できるかを変える

委任 RPKI では、保持者が子 CA を運用し、その秘密鍵を管理します。親 RIR はその子にリソース証明書を発行します。保持者はその後、ROA やその他の許可されたオブジェクトを作成し、ネットワークシステムからの変更を自動化し、サポートされている場合はさらに子証明書を発行できます。

これにより、事業者に 3 つの形態の独立性がもたらされます。経路変更のたびにホステッド署名ポータルを必要としません。自らのセキュリティポリシーの下で鍵を保護できます。複数の RIR の親から受け取ったリソースを一つのローカルシステムで管理でき、地域インターフェース間での不整合な手動操作を減らせます。

この独立性は暗号的に意味があります。RIR の親は、子証明書を発行したからといって、子の鍵で偽のオブジェクトに署名することはできません。ローカルに保持された監査履歴は、保持者が何に、いつ署名したかを正確に示せます。事業者は、BGP 意図の変更と RPKI オブジェクトをどれだけ密接に連動させるかを決定できます。

委任は、保持者をそのリソースに対する独自のトラストアンカーにするわけではありません。親は依然として証明書内のリソースを決定します。移転や返却の後、より狭い範囲の証明書に置き換えることができます。子証明書を失効させることもできます。保持者が有効範囲を超えて署名した場合、依拠当事者は超過主張を拒否します。

この境界は紛争時に重要です。委任は、親のホステッド鍵とユーザーインターフェースへの依存から保護しますが、正当な移転後に以前の保持者が認証を維持することを許すものではありません。レジストリ記録を無意味にするわけでもありません。事業者に、親が現在認証している範囲内での表明に対する制御を与えるのです。

したがって、委任は分離ではなく、職務の分離として売り込まれるべきです。その価値は、いかなる単一の機関も、すべての署名鍵を所有し、かつすべての親の決定を制御することができない点にあります。その限界は、リソース階層が依然として権威ある親を必要とする点です。

公開が第3のモデルを生み出す

ホステッド RPKI と委任 RPKI の通常の比較は、有用な中間地点を見逃しています。保持者は、RIR のリポジトリ公開サービスを利用しながら、独自の CA と秘密鍵を運用できます。ARIN はこれを Repository Publication Service と呼びます。RIPE NCC は Publish in Parent を提供しています。APNIC はセルフホストクライアント向けに公開を提供しています。

このハイブリッドモデルは、署名の保管と配布を分離します。事業者は RIR のホステッド CA なしにオブジェクトを作成でき、一方 RIR は依拠当事者が既に取得している高可用性リポジトリを提供します。これにより、すべての保持者がグローバルな公開サービスを公開し防御する必要がなくなります。

ハイブリッドサービスは、有能な事業者にとってしばしば最良のバランスを提供します。ローカルな鍵管理は、ホステッド署名インターフェースへの依存を減らします。親による公開は、運用負荷と脆弱なリポジトリの急増を減らします。RFC 8181 などの標準は、認証された公開および撤回要求を定義し、CA とリポジトリが異なる当事者によって実行されることを可能にします。

この分離は完全な独立性ではありません。公開プロバイダは変更の受け入れに失敗したり、利用不能になったり、その条件に基づいて資料を削除したりする可能性があります。親は依然として子のリソース証明書を発行します。最も強力な自律性を必要とする事業者は、CA とリポジトリの両方を運用し、その結果としての可用性とセキュリティの責務を受け入れるかもしれません。

APNIC の 2025 年の RPKI 可用性に関する議論は、トレードオフを直接的に述べています。委任 CA は、保持者に自身の RPKI 状態に対するより大きな制御と、オブジェクトの発行と更新の責任を与えます。しかし、APNIC のトラストアンカーに依存し続け、APNIC の公開を使用する場合はそのリポジトリにも依存します。また、多くの委任リポジトリが単一の場所にある単一インスタンスであるとも警告しています。

したがって、有用なモデルはスペクトラムです。ホステッドは署名と公開を RIR に置きます。ハイブリッドは署名をローカルに保ち、公開はプロバイダに委ねます。完全委任は両方をローカルに保ちます。親の認証はこれら 3 つすべての上位にあります。組織は、どの依存関係を吸収する準備ができているかを慎重に選択すべきです。

自己ホストには固有の失効の罠がある

運用上の失敗を無視した委任 RPKI の議論は不完全です。CA は、次回更新時刻前に新しいマニフェストと失効リストを発行しなければなりません。そのリポジトリは一貫した資料を提供しなければなりません。鍵は、盗まれやすくなることなくハードウェア障害を乗り越えなければなりません。スタッフは、超過主張、鍵のロールオーバー、親との交換を理解していなければなりません。

放置された委任 CA は、依拠当事者に負担をかけ、自身のオブジェクトを使えなくする可能性があります。RIPE-847 は極端なケースに対処しています。RIPE NCC が委任 CA の現在のマニフェストと失効リストを 3 か月以上発見・検証できない場合、合理的な発見と通知の努力の後にリソース証明書を失効させるというものです。このポリシーは、通常の短時間の停止ではなく、持続的に機能不全な CA を明示的に対象としています。

このポリシーは相互の義務を明らかにします。委任は保持者に署名制御を与えますが、親と依拠当事者コミュニティは、子が無期限に壊れたままにならないという保証を必要とします。親は枯れた枝を剪定できなければなりません。保持者は、検証の失敗の証拠、通知、復旧経路を受け取らなければなりません。

事業者はまた、人的な継続性リスクにも直面します。CA を構築した唯一のエンジニアが退職するかもしれません。バックアップ鍵は存在しても読み取り不能かもしれません。企業買収によりネットワークチームがセキュリティデバイスから切り離されるかもしれません。危機は、ローカルな主権が 1 台のラップトップと 1 つのメモリに依存していたことを露呈させる可能性があります。

委任サービスは、計算資源の面で必ずしも高価ではありません。最新の CA ソフトウェアは控えめなハードウェアで動作します。真のコストは制度的なものです。所有権、オンコール責任、変更レビュー、バックアップテスト、リポジトリ監視、そして承継です。大規模キャリアがこれらのタスクに失敗することもあり、規律ある小規模事業者がそれらをうまく遂行することもできます。

したがって、ホステッドサービスとの比較では、双方の失効という単一障害点を考慮しなければなりません。ホステッドユーザーは、プロバイダの決定と復旧への依存をリスクとします。委任ユーザーは、自身のブランチ内で失敗する権限となってしまうリスクがあります。ハイブリッド設計と強力な親プロセスは、どちらのリスクも低減できますが、排除はできません。

移行こそが選択可能性の試金石

市場が選択肢を提供するのは、ユーザーがその選択を変えられる場合だけです。ホステッド RPKI と委任 RPKI の間の移行は、新旧の CA が同じリソースをカバーする可能性があり、依拠当事者が異なるタイミングでデータを取得するため、技術的に微妙です。

RIPE NCC のホステッド文書によると、委任サービスに移行するユーザーは最初にホステッド CA を失効させなければならず、現在のところ、make-before-break の移行は不可能です。APNIC は、移行中にホステッドモードとセルフホストモードを並行して実行できると述べています。ARIN は、展開を変更する際に Registration Services に連絡するようユーザーに伝えています。これらは実質的に異なる運用体験です。

理想的な移行は、鍵と公開ポイントが変わる間も有効な経路意図を保持します。ユーザーは、現在の認可をエクスポートし、新しい CA を準備し、親とリポジトリの交換をテストし、同等のオブジェクトを公開し、古い CA が消える前に独立したバリデータからそれらを観察すべきです。地域ポリシーが重複を禁止する場合、サービスはスケジュールされた切替と迅速なロールバックをサポートすべきです。

並行認証は自動的に無害というわけではありません。重複または不整合なオブジェクトは事業者を混乱させかねず、古い鍵が必要以上に長く権限を保持すべきではありません。安全な重複には、固定された期間、同等のリソース範囲、明確な責任、自動的な終了が必要です。しかし、代替案が、ユーザーがホステッドでも委任でもない説明のつかない期間であってはなりません。

移行は、移転、合併、企業再編の際にも重要です。買い手は、売り手がホステッドサービスを利用していた場合に委任制御を望むかもしれません。複数の RIR を通じて事業を行うグループは CA を統合するかもしれません。RIR は RPKI 移行を、リソース移動の標準的な一部として扱い、最終日に残された後付けの課題とすべきではありません。

ポータビリティ指標は説明責任を改善するでしょう。各 RIR は、通常のステップ、最低通知期間、変更アクセスなしの予想期間、重複が利用可能かどうか、そして切替失敗時のエスカレーション連絡先を公開できます。選択可能性が安全に行使できないなら、ホステッドのデフォルトは、そのシンプルなインターフェースが示唆するよりも多くのロックインを持っていることになります。

重要ネットワークには結果に基づく選択が必要

すべての保持者にとって唯一の正しい展開モデルはありません。選択は、認可を変更できないことの結果、ルーティングの複雑さ、そして組織の CA 運用能力に依存すべきです。

少数の安定したプレフィックスと 1 つの起点を持つ小規模プロバイダは、合理的にホステッドサービスを使用できます。RIR は、プロバイダよりも確実に鍵を保護し、オブジェクトを更新し、公開を運用できます。委任は、意味のある利得なしに障害モードを追加する可能性があります。それでもプロバイダは、ROA の一覧をエクスポートし、緊急連絡先を維持し、終了条件を理解すべきです。

頻繁な経路変更、複数の起点、顧客、自動化された緩和策を持つマルチ RIR キャリアは、委任署名のより強い理由があります。認可を承認されたネットワーク変更と統合し、親をまたいで一つの管理面を保ち、複数のポータルへの依存を減らせます。ハイブリッド公開により、多数の公開リポジトリの運用を回避できます。

公共セクターのネットワークには特別な注意が必要です。病院、緊急通信、税務システム、公共クラウド、研究ネットワークは、断片的な到達可能性から過大な損害を被る可能性があります。だからといって、すべての機関が自己ホストすべきということではありません。選択されたモデルには、明示的な継続性目標、テストされたアクセス復旧、複数の訓練された管理者、そして親との事前合意されたエスカレーション経路が必要であることを意味します。

下流の責任も重要です。直接の保持者は、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 を要求し、可用性の特性を考慮せずにカバーされていないすべての経路を拒否することに対して警告しています。

この注意は起点検証の妥当性を弱めるものではありません。多層的なセキュリティを求めています。ネットワークは、RPKI を顧客契約、経路フィルター、インターネット経路レジストリデータ、直接検証、厳格な管理の下での緊急例外と組み合わせることができます。例外は、密かに不良な経路データの永続的な受け入れとなってはなりません。

依拠当事者の多様性も復旧を支援できます。保持者と RIR は、切替完了を宣言する前に、複数のバリデータ実装と視点から観察すべきです。リポジトリはローカルでは健全に見えても、リモートバリデータが取得できないことがあります。署名付きオブジェクトが存在しても、超過主張や古いサポート資料のために拒否されることがあります。

したがって、利便性の罠は両端から見えます。生産者は一つの署名プロバイダに依存するようになる可能性があります。消費者は、一時的な喪失に対する計画なしに、ある種の検証データに依存するようになる可能性があります。成熟した経路セキュリティは、RPKI が証明できることについて権威を持たせつつ、あらゆる緊急時に利用可能な唯一の証拠として扱うことを拒否します。

より良いホステッドの取引には具体的な条件がある

ホステッドモデルは、煩雑にすることなく改善できます。第一の改革は、オブジェクトエスクロー記録です。現在の経路意図、認証済みリソース、公開識別子の継続的にエクスポート可能な署名付きリストです。これはホステッド秘密鍵を露出しません。保持者が代替 CA の下で同等の認可を再構築できるようにします。

第二は、失効ラダーです。低リスクのアカウント問題は、安全な場合に既存オブジェクトを保持しつつ、変更を制限すべきです。高リスクの登録イベントは、通知と移行を生み出すべきです。確認された侵害は、即時失効とクリーンキー復旧をトリガーできます。各段階には、指名された承認とレビューが必要です。

第三は、ポータブル登録です。委任を選択するユーザーは、ホステッド CA が削除される前に、身元交換、公開、同等のオブジェクトを準備できるべきです。ただし、制御不能な重複に対する保護措置が条件です。これをサポートできない地域サービスは、正確なギャップとそれを縮小する計画を公開すべきです。

第四は、破壊的行為に対する独立した確認です。ホステッド CA 全体の失効、すべての設定の削除、または認証済みリソースの縮小には、自動更新や事前承認された移転が検証済みイベントに続く場合を除き、デュアルコントロールが必要です。システムは実行前に、既知のアナウンスに対する予想される影響を表示すべきです。

第五は、稼働時間以上のものを測定するサービス報告です。RIR は、証明書に影響する登録エラー、移行の失敗、緊急失効、復旧時間、通知パフォーマンスを報告すべきです。少数のカウントは、グローバルな率を裏付けるかのように見せかけることなく、注意深く開示されるべきです。

第六は、限定的な救済です。プロバイダのエラーが有効な認可を削除した場合、即時の復旧、専門家によるサポート、保存されたインシデント記録、独立したレビューを提供すべきです。深刻な繰り返しの失敗は、取締役会とメンバーシップに届くべきであり、プライベートなサポートチケットにとどまるべきではありません。

これらの保護措置は、ホステッド RPKI をより便利にし、不便にしません。通常の前提が失敗したときに必要となる個別の交渉の量を減らします。

Number Resource Society が追加できること

Number Resource Society は、正確な登録、保持者の権利、参加、より低い官僚的障壁の提唱者として自らを位置づけています。ホステッド RPKI は、これらの原則を測定可能なメンバーサービスに変えるのに適した場所です。

NRS は、5 つの RIR を比較する展開選択レジスターを公開することができます。誰が秘密鍵を保持するか、委任サービスが利用可能か、親公開が提供されているか、移行がどのように機能するか、どのような失効理由が公開されているか、どのような通知が適用されるか、保持者がどこでレビューを求められるかを列挙すべきです。各エントリーは関連する RIR 資料にリンクし、未解決の質問を述べるべきです。

3 つの継続性演習を維持することができます。ホステッドユーザー向け、委任 CA 向け、ハイブリッド公開向けのものです。ホステッド演習はアクセス復旧と設定エクスポートをテストします。委任演習は鍵、マニフェスト、親との交換、承継をテストします。ハイブリッド演習は、リモート公開に対するローカル署名をテストします。結果は参加者にとって非公開のままでよく、共通の失敗テーマは裏付けのない率なしに公開されます。

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 と同じくらい曖昧さがないべきです。これらの答えが明示的で可逆的であるとき、ホステッドサービスは入口です。それらが隠されて不可避であるとき、それは罠です。

情報源