サマリー
- ROA 失効リスクは、誰かが削除ボタンを押すリスクだけではない。削除、置き換え、有効期限切れ、証明書変更、リソースセット変更、公開障害、ホスト型から委任型への移行、委任 CA 障害、および依存パーティのキャッシュ更新の不均一性が含まれる。
- 商業的に受け入れられていた経路が、観測された BGP アナウンスが現在の ROA と矛盾する場合、運用上拒否される可能性がある。一般的なトリガーは、起点 AS 変更、移転後の ROA 欠落、過度に狭い maxLength、証明書変更、緊急封じ込め措置である。
- RIPE NCC 自体の RPKI 資料は事実の証拠として有用である。RPKI により LIR はリソース証明書を要求でき、ROA は許可された起点と最大プレフィックス長を記述し、BGP Origin Validation によりネットワークはアナウンスを VALID、INVALID、UNKNOWN に分類できる。
- 最も価値の高い証拠は、移転と認証のリンクである。RIPE NCC の文書によれば、リソースが移動または移転されると、RIPE データベースにリストされた組織が変更され、証明書が変更され、基盤となる ROA が削除され再作成が必要になる。これが内在する不連続性リスクである。
- ホスト型 RPKI はエンジニアリング負担を軽減するが、継続性リスクを RIPE NCC システム、アカウント制御、ポータル/API 権限に集中させる。委任型 RPKI は保有者により多くの制御を与えるが、独自の公開、マニフェスト、CRL、および長期的な運用可能性リスクを生み出す。
- 商業的ショックはパケット損失よりも大きい。無効経路拒否は、クラウド BYOIP 移行を停止させ、上流フィルタ拒否を引き起こし、メンテナンスウィンドウを延長し、顧客 SLA の露出を誘発し、クロージングを遅延させ、エスクローの保留を増やし、融資側のヘアカットを生み出す。
- アカウント侵害は重要だが、それはごく限られたケースである。より一般的な経済問題は、誤った順序で、十分な通知なしに、ロールバックの規律なしに、または欠陥を誰が修復すべきかを証明する明確な方法なしに実施された正当な変更である。
- RIPE NCC は RPKI を信頼できる台帳/サービスインフラとして維持すべきである。経路起点ステータスをトラフィック、価格設定、所有権、融資、移転の道徳、または私的紛争に対する一般的な手段として使用すべきではない。
- ガードレールには、可能な場合は変更前の可視化、高影響の確認、明確なイベント分類、修正クロック、最小限の影響範囲での緊急封じ込め、深刻なケースでの独立したエスカレーション、復旧文言、および永続的なログが含まれるべきである。
- 正しい制度的バーゲンは、「市場が決める」よりも厳格で、「レジストリが決める」よりも狭い。ネットワークは自由に経路ポリシーを設定できるが、RIPE NCC は認証レイヤーを十分に予測可能にし、プライベートな受け入れ決定が不確実性への課税とならないようにしなければならない。
カットオーバー前のリハーサル
継続性の訓練は火曜日に予定されている。誰も買収カットオーバー中に問題を発見したくないからだ。ヨーロッパのホスティング会社が小規模なネットワークを買収し、顧客向けの/22 を自社 AS に移管し、その後クラウドプロバイダーの BYOIP（Bring Your Own IP）サービスを利用して/24 を新しい地域でアナウンスしようとしている。エンジニアたちは経路計画、移転スケジュール、クラウドチケット、権限委任状、顧客通知、メンテナンスウィンドウを用意している。彼らは 10 年前には存在しなかったチェックリストの項目も持っている：ROA が移行の各段階で存続することを確認するということである。
最初のテストは静かに失敗する。集約経路は古い起点 AS から依然として可視である。計画された新しい起点は、あるラボのバリデーターでは受け入れられるが、別の経路チェックビューでは INVALID とマークされる。古い ROA が依然として売り手の AS を認証しており、買い手のために同等の ROA が作成されていないからである。クラウドプロバイダーは、既存の maxLength が/22 までしか許可していないため、より詳細な/24 を拒否する。トランジットデスクは、顧客が新しい起点を認証できる証拠を求める。ある内部ダッシュボードでは、カバーする ROA を全く認識していないため UNKNOWN と表示する。買収チームは ROA をセキュリティ項目として扱っていた。経路チームは今やそれをクロージング条件として扱っている。
問題は RPKI の良し悪しではない。問題は、ROA の不連続性が受け入れ可能な到達性を拒否される到達性に変えるとき、誰が経済的コストを負担するかである。有効な経路が無効になる原因は、ROA が削除された、移転後に再作成されなかった、誤った maxLength が設定された、証明書変更に関連付けられた、ホスト型から委任型への移行中に取り残された、アカウントエラー後に失われた、あるいは緊急封じ込め中に意図的に停止された、などである。コストを支払うのは、買い手、売り手、クラウド顧客、上流 ISP、融資機関、エンタープライズユーザー、または同日修復のスタッフがいない小規模アクセスネットワークかもしれない。
これは狭い問題であり、経路セキュリティの一般論ではない。ROA は経路起点認証であり、権利証書ではない。Route Origin Validation は経路ポリシーへの入力であり、裁判所命令ではない。RIPE NCC は経路をグローバルテーブルにプッシュするわけではなく、トラフィックポリスとして扱われるべきではない。しかし、レジストリの認証レイヤーは現在、市場の依存に十分に近く、不連続性が資産品質の損失のように見える可能性がある。プレフィックスが意図した起点の下でクリーンに認証できない場合、取引相手は遅延を価格に織り込み、保証を要求し、または進行を拒否する。
継続性訓練の目的は、資金と顧客が動き出す前にそのリスクを明らかにすることである。ガバナンスの目的は、不透明な権限によってリスクが悪化しないようにすることである。認証証拠を変更できるレジストリは、誤った権限を修正し、侵害を封じ込め、移転をサポートできなければならない。また、その権力を境界付けられ、予測可能で、監査可能にしなければならない。さもなければ、セキュリティサービスが価格のついていない拒否権となる。
失効はボタンではなく連鎖である
「ROA 失効」は単一の行為のように聞こえる。実際には、経済的ショックは連鎖の多くの断絶から生じうる。保有者が ROA を削除するかもしれない。ポータルがより狭いものに置き換えるかもしれない。移転がリソース関係を変更し、古い認証を削除するかもしれない。対象リソースセットが変更されたために証明書が変更されるかもしれない。委任型 RPKI への移行中にホスト型 CA が失効されるかもしれない。委任型 CA が使用可能なマニフェストや CRL の公開を停止するかもしれない。リポジトリに公開問題が発生するかもしれない。依存パーティのキャッシュが古いビューを保持している間に、別のキャッシュが既に新しいものを取得しているかもしれない。ビジネスチームが何が変わったのかを理解する前に、経路は動く標的となる。
この区別は重要である、なぜなら各障害には異なる修復方法があるからだ。誤った起点 AS は、追加の ROA を公開するか経路を変更することで修正できる。不適切な maxLength は広げるか、より具体的な経路を撤回することができる。移転後に ROA が欠落している場合、新しい認定保有者が証明書変更後に適切な認証を作成する必要がある。委任 CA 障害では、保有者が自身の公開ポイントを修復する必要がある。ホスト型 CA 失効では、計画的なダウンタイムや移行の規律が必要かもしれない。アカウント侵害の疑いでは、既知の安全な認証を保持しながらリスクの高い変更をロックする必要がある。これらを未分化な「失効」として扱うことは、修復の運用責任者を隠してしまう。
RIPE NCC のRPKI ページでは、このシステムにより LIR が保持するインターネット番号リソースをリストしたデジタル証明書を要求できると述べている。そのBGP Origin Validation ページでは、ROA がどの AS がプレフィックスを発信できるか、許容される最大長を記述し、他のネットワークが有効性に基づいて経路優先度を設定できることを説明している。これらの事実は、不連続性が深刻である理由を示すのに十分である。認証レイヤーの変更は、他のネットワークが目にしていると信じるものを変える。
公式の有効性用語も重要である。RIPE のページでは、VALID、INVALID、UNKNOWN の結果を説明している。運用上の表現では、カバーする ROA が利用できない場合、UNKNOWN はしばしば NotFound や RPKI-unknown と呼ばれる。INVALID はより鋭く、経路が現在の認証と矛盾することを意味する：誤った起点、または maxLength が許可するよりも具体的なプレフィックス。UNKNOWN は多くの経路ポリシーではそれほど深刻ではないが、以前有効だった経路が肯定的な証拠を失った場合、商業的な信頼を弱める可能性がある。
取引相手が自動拒否ルールを持っている場合、この連鎖は経済的に可視化される。ルートサーバーは INVALID 経路を抑制するかもしれない。トランジットプロバイダーは、ROA が整合するまで顧客プレフィックスを拒否するかもしれない。クラウドプラットフォームは BYOIP オンボーディングを一時停止するかもしれない。セキュリティに敏感な企業は、本稼働前にクリーンな検証レポートを要求するかもしれない。いずれの場合も、レジストリが拒否を命じたわけではない。市場が認証連鎖の状態に結果を結びつけているのである。
そのため、ガバナンスの問いは、すべての ROA を永続的にすべきかどうかではない。永続的であるべきではない。誤った認証は削除されるべきであり、古くなった認証はクリーンアップされるべきであり、緊急の害は封じ込められるべきである。問題は、削除、置き換え、復旧に関するプロセスが、市場が日常的なメンテナンスと実際の権限喪失を区別できるほど明確かどうかである。
証明書はリソースに従い、市場は証明書に従う
このトピックに関する最も重要な事実の証拠は、リソースが移動または移転されたときに何が起こるかについての RIPE NCC 自身の説明である。そのRPKI システムの利用ページでは、インターネット番号リソースが移動または移転されると、RIPE データベースにリストされた組織が変更され、証明書が変更され、基盤となる ROA が削除され再作成が必要になると述べている。この文は技術的だが、その経済的影響は大きい。移転は単にレジストリ行を更新するだけではない。新しい保有者が迅速かつ正確に再構築しない限り、取引相手が依存していた経路起点の証拠を破壊する可能性がある。
その内在する不連続性は、取引の価格設定方法を変える。IPv4 空間の買い手、またはその空間に依存する収益を持つ企業の買い手は、登録保有者が変更されたからといって完全な運用継続性を受け取るわけではない。意図した起点 AS の下で正しい ROA を公開し、テストし、依存パーティの伝播を待ち、経路変更を調整する能力を受け取らなければならない。移転が金曜日にクローズし、ROA が月曜日に再構築されると、市場は週末をリスクとみなすかもしれない。クラウドプラットフォームが/24 を期待していたが、移転後の ROA が適切な maxLength なしで/22 のみをカバーしている場合、買い手はクリーンな記録を所有するがクリーンな経路は所有しない。
これが、ROA の継続性が取引メカニクスに属する理由である。クロージング条件は、移転前と移転後の経路状態がマッピングされているかどうかを問うべきである。エスクロー条件は、古い ROA が消滅して新しい ROA が有効になる前に経路が INVALID になった場合のコスト負担者を扱うべきである。顧客通知は、レジストリ決済と運用カットオーバーを区別すべきである。売り手は単にリソースを引き渡したと言えるべきではなく、買い手は認証が自動的に作業なしで続くと想定すべきではない。レジストリは価格を決定すべきではないが、そのプロセスは、当事者がそれを中心に契約を書けるほど予測可能であるべきである。
証明書は融資機関にとっても重要である。ネットワーク購入に融資する融資機関は、RPKI を詳細に理解していないかもしれないが、継続性の証拠は理解する。借り手の収益が、移転中に検証に失敗する可能性のあるプレフィックスに依存している場合、融資機関はコベナンツ、準備金、またはヘアカットを要求する。借り手がリハーサルされた ROA 再作成、バリデーターチェック、クラウド受け入れ、およびロールバック手順を示すことができれば、割引は低下する。証明書チェーンは、アドレス依存の収益が耐久性があるかどうかに影響するため、信用品質の一つのインプットとなる。
同じロジックが保険と顧客契約にも適用される。サービスレベルコミットメントを持つ顧客は、障害が ROA 削除、証明書再発行、またはキャッシュタイミングの問題で始まったかどうかを気にしない。サービスが到達可能だったかどうかを気にする。自身の AS を通じて顧客空間をアナウンスするマネージドサービスプロバイダーは、明示的な権限と、アカウントや保有者が変更されたときに ROA がどのように変わるかの計画を必要とする。その計画がなければ、保有者とプロバイダーは、バリデーターとフィルターが現在のビューを実行している間に、プレッシャーの下で議論することになる。
RIPE NCC はこれらの私的取り決めの保証人となるべきではない。その役割はより狭い：明確な技術的セマンティクスを公開し、移転に伴う ROA 削除を予測しやすくし、ログを保存し、タイムリーな移転後再作成をサポートし、異常な認証イベントを取引相手が日常的なリソース移動と制度的な罰と混同しない程度に可視化する。証明書はリソースに従う。市場は今や証明書に従う。
INVALID は停止リスク、UNKNOWN は信頼リスク
INVALID と UNKNOWN は異なる状態であり、その区別は曖昧にされるべきではない。INVALID 経路は、カバーする ROA が存在するが、観測された BGP アナウンスがそれと矛盾することを示す。起点 AS が間違っている可能性がある。プレフィックスが許容最大値よりも長い可能性がある。経路はハイジャックである可能性がある。また、誤った順序で実行された正当な移行である可能性もある。このステータスは、機械可読であるように設計されているため、鈍感である。動機を説明しない。
その鈍感さはセキュリティにおいて有用であり、商業においてはコストがかかる。INVALID 経路を拒否するネットワークは、誤ったまたは悪意のある起点アナウンスへの露出を減らすことができる。しかし、同じポリシーが、事務的またはシーケンシングのエラーを即時の到達不能に変える可能性がある。クラウドプラットフォームが顧客の/24 をアナウンスしているが、保有者の ROA が/22 のみを認証している場合、顧客が移行の完了を期待する瞬間に拒否が現れる可能性がある。上流が保有者が新しい AS を追加する前に起点を変更すると、古いパスがドレインされているちょうどその時に経路が失敗する可能性がある。移転後の証明書が古い ROA を削除し、新しい保有者が準備できていない場合、検証は取引トラップになる可能性がある。
UNKNOWN、または一般的なオペレーター言語での NotFound は、より間接的である。多くのネットワークは依然として ROA なしの経路を受け入れる。しかし、Valid から UNKNOWN への変更は商業的に中立ではない。経路が認証されていたという肯定的な証拠を削除する。低リスクの文脈ではそれは許容されるかもしれない。クラウドオンボーディング、公共セクターサービス、規制対象のエンタープライズ移行、または買収デューデリジェンスファイルでは、疑問を引き起こす可能性がある。成熟した保有者が ROA を失ったのはなぜか？証明書が壊れているのか？移転があったのか？紛争が係争中なのか？委任 CA が失敗したのか？これは意図的なセキュリティダウングレードなのか、運用上の事故なのか？
これらの質問の代償は遅延である。キャリアは手動レビューを開始するかもしれない。クラウドプロバイダーは更新された ROA と新たな経路チェックを要求するかもしれない。買い手は検証状態が安定するまでエスクローを解放することを拒否するかもしれない。顧客はトラフィック移動を遅らせるかもしれない。融資機関は不確実なアドレス継続性に対して準備金を積むかもしれない。これらの取引相手はいずれも、RIPE NCC がポリシー決定を行う必要はない。彼らは弱いまたは矛盾する信号に反応しているのである。
ここで、maxLength は RPKI フィールドだけでなく、経済的用語となる。狭い maxLength は、より具体的な誤用を防ぐことができ、しばしば慎重である。広い maxLength は、トラフィックエンジニアリング、DDoS 緩和、またはクラウド展開のための運用柔軟性を維持できる。間違った選択は、流通している権限が多すぎるままにするか、正当な経路をブロックする可能性がある。その選択のコストは、プレフィックスが収益を支える場合に上昇する。緊急緩和に使用される/24 は、攻撃ウィンドウ中に ROA がそれをブロックするまで、小さな技術的例外のように見えるかもしれない。
治癒策は、すべての ROA を広範または永続的にすることではない。意図したルーティングを明示的にし、テストすることである。保有者は、通常、移行、緊急の条件下でどの AS がどのプレフィックスを発信するかを知っておくべきである。上流とクラウドはメンテナンスウィンドウの前に検証をテストすべきである。RIPE NCC はステータスのセマンティクスと変更パスを読みやすくすべきである。INVALID は衝突を意味すべきであり、謎ではない。UNKNOWN はカバーする認証の欠如を意味すべきであり、認証が消えた理由についての隠された物語ではない。
ホスト型 RPKI は負担を軽減し、依存を集中させる
ホスト型 RPKI は、保有者から暗号化の負担の多くを取り除くため魅力的である。RIPE NCC は認証環境を運用し、鍵操作と公開を処理し、メンバーに ROA 制御のためのポータルと API を提供する。多くのネットワーク、特に中小規模の保有者にとって、これは使用可能な RPKI と全く RPKI がないことの違いである。大規模オペレーターのみが安全に実行できるセキュリティシステムは、経済的に逆進的であろう。
しかし、利便性は依存を集中させる。ホスト型モデルでは、ポータルアクセス、アカウント権限、API 資格情報、内部統制、サービス可用性、および RIPE NCC の認証プラットフォームが経路起点の継続性の一部となる。アカウントが侵害されると、悪意のある ROA が作成される可能性がある。権限紛争中にアカウントがロックされると、良好な ROA の変更が困難になる可能性がある。移転が証明書を変更する場合、新しい保有者は必要な認証を再構築できなければならない。委任型 RPKI への移行中にホスト型 CA が失効されると、移行が計画されていない限り、継続性ギャップが生じる可能性がある。
RIPE NCC のホスト型認証局ページでは、割り当て、移転、返却を含むリソース変更時に証明書が自動的に更新されると述べている。また、現在の ROA 構成が存在するリソースが削除された場合、公開された ROA は自動的に更新されるとも述べている。同じページでは、ホスト型 CA を失効させると、CA が完全に削除・除去され、ROA 構成と履歴が含まれ、委任型 CA へのメイク・ビフォア・ブレイク移行は現在不可能であると述べている。これらはポリシーのスローガンではない。それらはバランスシートに影響を与える運用上の事実である。
メイク・ビフォア・ブレイクのギャップは、市場が制御されていない不連続性を嫌うために重要である。洗練された保有者は、ホスト型 CA 失効をスケジュールし、委任型 CA を作成し、新しい資料を公開し、バリデーターを監視し、新しい状態が可視になるまで経路を安定させることができる。小規模な保有者はシーケンスを誤解するかもしれない。取引チームは、「委任型への移行」が単なる選好の変更であると想定するかもしれない。クラウドオンボーディングチームは、検証が変更されたことだけを見るかもしれない。融資機関は、CA が失効したときに保有者の証拠トレイルが削除されたことを知るのが遅すぎるかもしれない。リスクはホスト型 RPKI が悪いことではなく、ホスト型の利便性が不連続性の鋭いエッジを隠すことである。
これは監査にも影響する。ROA が消えた場合、取引相手はそのイベントが保有者による削除、リソース削除後の自動更新、ホスト型 CA 失効、アカウント回復、プラットフォームインシデント、またはレジストリアクションのいずれであったかを知る必要がある。各カテゴリーは異なる推論を伴う。保有者が要求した変更は通常のことかもしれない。移転後の自動更新は予想されるかもしれない。レジストリが開始した緊急ロックはレビューが必要かもしれない。プラットフォームインシデントはサービス報告を必要とするかもしれない。イベントカテゴリーがなければ、市場は疑いでギャップを埋める。
RIPE NCC の適切な対応は、経路ポリシーを微管理することではない。ホスト型 RPKI を依存レイヤーとしてより安全にすることである：強力なアカウント制御、破壊的なアクションに対する高影響の確認、ホスト型 CA 失効に対する明確な警告、エクスポート可能な変更前スナップショット、認可されたアカウント保有者に見えるログ、および誤りが特定された場合の復旧手順。ホスト型 RPKI が一般のネットワークにとってデフォルトになるほど、その不連続性セマンティクスは市場インフラとなる。
委任型 RPKI は制御を与え、別の故障モードを生み出す
委任型 RPKI は、異なる問題を生み出すことで一つの問題を解決する。委任型モデルでは、保有者は自身の CA ソフトウェアを運用し、証明書と ROA を公開する場所を選択できる。RIPE NCC のRPKI システムの利用ページでは、これにより保有者がリソース証明書と秘密鍵を制御し、公開の取り決めを選択できるようになると説明している。その制御は、大規模オペレーター、セキュリティ意識の高いネットワーク、およびホスト型プラットフォームからの運用独立性を望む保有者にとって価値がある。
制御は依存を排除しない。委任 CA は依然として RIPE NCC の親システムと相互運用する必要がある。使用可能な資料を公開しなければならない。マニフェストと CRL が検証されなければならない。リポジトリが依存パーティから到達可能でなければならない。鍵とソフトウェアは、スタッフの変更、買収、破産イベント、緊急インシデントを通じて維持されなければならない。委任 CA が古くなると、保有者の理論的自律性は運用上の負債となる。経路は、RIPE NCC が広範な裁量的決定を下したからではなく、保有者自身の公開チェーンが機能しなくなったために、クリーンな検証を失う可能性がある。
受け入れられた 2025-02 実装は、この緊張を明示的にする。RIPE NCC のポリシー実装状況ページでは、ルーティングワーキンググループが 2025 年 10 月 15 日に、依存パーティの負荷を軽減するために、長期間機能していない委任 CA に関連するリソース証明書を失効させる権限を RIPE NCC に与える提案を受け入れたと述べている。更新された認証サービス条件は 2026 年 5 月 6 日に公開され、2026 年 6 月 8 日に発効したとされている。その後、RIPE NCC は、委任 CA オペレーターに対して、現在のマニフェストと CRL が検証できない場合、および非機能状態が 90 日間続いた後に委任が失効されることを監視し通知すると述べている。
これは、恣意的でも些細でもないため、議論するのに適切な事実のケースである。依存パーティは、壊れた委任ブランチを際限なく運ぶべきではない。死んだ委任 CA はバリデーターにコストを課し、システムのクリーンさを弱める。同時に、非機能後の失効は、保有者とその顧客に経路起点の結果をもたらす可能性がある。したがって、90 日間のクロック、通知、非機能のカテゴリーは、単なる管理的装飾ではない。それらは、インフラ衛生と突然の市場ショックを分離するガードレールである。
市場の問いは、これらの失効が認証チームの外でどのように見られるかである。明確な通知と長期間の非機能の後に委任 CA が失効された場合、取引相手はそのイベントを所有権の判断や制裁と解釈すべきではない。それは技術的継続性の失敗である。保有者が CA を修復するか、ホスト型サービスに戻る場合、復旧パスは明確であるべきである。保有者が通知を受け取らなかったと主張する場合、監査トレイルはその主張を解決するのに十分強力であるべきである。下流の顧客が影響を受けたリソースの下で経路を使用していた場合、彼らは私的紛争を煽ることなく技術的原因を説明する文言を必要とする。
したがって、委任型 RPKI は、ホスト型 RPKI よりも厳格な運用憲法を必要とし、緩いものではない。自律性は、保有者がより多くのエンジニアリング負担を負うことを意味する。RIPE NCC は、正確な閾値、通知、エスカレーション、失効記録の負担を負う。バリデーターとネットワークは、どのように経路を決定するか自由である。認証レイヤーは、保有者のビジネスを判断するための裁量的ツールになることなく、機能に関する真実を伝えるべきである。
移転は隠れたタイミング問題を露呈させる
移転は、ROA の不連続性が最も価格付けしやすくなる場所である。RIPE NCC の移転ページでは、インターネット番号リソースの移転を認証し促進し、移転がある当事者から別の当事者への保有権を変更すると述べている。その変更は、経路の受け入れが商業的に完了する前に、法的および管理的に完了する可能性がある。これら 2 つの完了形態の間のギャップがタイミング問題である。
クリーンな移転では、売り手と買い手はレジストリアクションの前に経路状態をマッピングする。現在の ROA、現在の起点、意図した起点、クラウド起点、緊急緩和起点、maxLength 要件、依存する顧客経路、監視ビューをリストする。どの古い認証をカットオーバーまで存続させ、どれを削除すべきかを決定する。証明書が許可次第、移転後の ROA を構築する。複数の依存パーティビューを通じて検証をテストする。上流フィルターの更新を調整する。リソース移転と経路カットオーバーは関連しているが同一ではないことを顧客に伝える。
弱い移転では、レジストリ記録が変更され、ROA 計画が後になって発見される。売り手はもはや古い認証を管理する権限やインセンティブを持たない。買い手は新しいものを作成していない。クラウドプラットフォームは進行できない。上流は INVALID または UNKNOWN と見なす。経路は依然として寛容なネットワークを通じて機能する可能性があり、危険な曖昧さを生み出す：一部の顧客は到達可能であり、一部はそうではなく、誰もカットオーバーが安全であると証明できない。商業的問題は、移転が無効だったことではない。経路の証拠が取引と共に移動しなかったことである。
エスクローは自然な市場の反応である。買い手は、移転後の ROA が有効になり、合意された取引相手に受け入れられるまで、価格の一部を保留するかもしれない。売り手は、レジストリが要求することをすべて行った後、迅速なリリースを要求するかもしれない。融資機関は、RIPE NCC からではなく、借り手の技術顧問からのクロージング後検証証明書を要求するかもしれない。クラウドプロバイダーは、新しい保有者の認証を見るまで BYOIP のスケジュールを拒否するかもしれない。顧客は、伝播を待つことに費やされるため、最初のメンテナンスウィンドウでは不十分なため、2 回目のメンテナンスウィンドウを要求するかもしれない。
これは RIPE NCC が価格や取引条件を監督する理由ではない。RIPE NCC が明確な移転と RPKI のセマンティクスを公開し、市場アクターがそれを使用する理由である。基盤となる ROA が削除され、特定の移動後に再作成されなければならない場合、その通知は見逃せないものでなければならない。リソースが削除されたときに自動更新が発生する場合、保有者はそれがライブルートにとって何を意味するかを知るべきである。ホスト型から委任型への移行でメイク・ビフォア・ブレイクが不可能な場合、そのリスクは買い手がクロージング計画の一部とする前に明示的であるべきである。
移転はまた、失効権限が不明確な場合にモラルハザードを生み出す。売り手はレバレッジを得るために協力を遅らせるかもしれない。買い手は、保留を正当化するために売り手が無効性を作り出したと非難するかもしれない。上流は、移行を理解していないために経路を拒否するかもしれない。レジストリは、その認証記録が最も目に見えるトリガーであるため、私的意見の相違に巻き込まれるかもしれない。明確なガードレールは、レジストリの事実を商業的非難から分離することにより、そのハザードを減らす。
クラウドと上流が認証状態を市場アクセスに変える
RIPE NCC は、クラウドプロバイダーが BYOIP リクエストを受け入れるか、上流が無効な経路を拒否するかを決定しない。その裁量はネットワークまたはプラットフォームにある。しかし、レジストリの RPKI データはそれらの私的決定に供給される。これが制度経済学のポイントである：狭い技術的状態は、十分な取引相手がそれに依存する場合、市場アクセス条件になる可能性がある。
クラウド BYOIP は最も明確な例である。自身の範囲をクラウドリージョンに持ち込む顧客は、プレフィックスの制御を証明し、経路記録を整列し、権限委任状を提供し、ROA がクラウド AS に関連するプレフィックスを発信することを許可していることを確認しなければならないことが多い。顧客がより大きな割り当て内で/24 をアナウンスしたいが、ROA の maxLength がそれを許可していない場合、プロジェクトは停止する可能性がある。移転が古い ROA を削除し、新しいものが作成されていない場合、クラウドプラットフォームは不完全または矛盾したファイルを見る。委任 CA 障害が以前有効だった経路を UNKNOWN に変えた場合、クラウドのリスクチームはオンボーディング前に修復を要求するかもしれない。
上流は異なる形の圧力を生み出す。経路起点検証を実施するプロバイダーは INVALID 経路をドロップするかもしれない。ドロップしないプロバイダーでも、その状態をエスカレーショントリガーとして使用するかもしれない。ルートサーバーは、無効なアナウンスを抑制する公開ポリシーを持っているかもしれない。DDoS 緩和プロバイダーは、トラフィックを吸収する前に緊急起点が認証される必要があるかもしれない。これらのポリシーはプライベートに選択されるが、経路が機能する必要がある顧客にとっては任意ではない。顧客の交渉ポジションは、認証状態がクリーンかどうかに依存する。
これはメンテナンスウィンドウを財務ウィンドウに変える。悪い ROA シーケンスは、2 時間の移行を週末の停止に変える可能性がある。エンジニアは、複数の依存パーティシステムにわたるキャッシュリフレッシュを待つかもしれない。営業チームは、なぜサービス受け入れがネットワークによって異なるのかを説明しなければならないかもしれない。カスタマーサポートは、すべての視点から再現できない苦情に直面するかもしれない。事後分析は、単一の機関が停止を「引き起こした」わけではないと結論付けるかもしれないが、経済的損失は現実である。
小規模ネットワークにとって、負担は特に高い。大規模キャリアは、飛行前チェックを実行し、複数のバリデーターに問い合わせ、RPKI スタッフを維持し、クラウドや上流と直接交渉できる。地域 ISP、大学ネットワーク、または地元のホスティング会社は、BGP、調達、顧客、レジストリポータルを管理するエンジニアが一人だけかもしれない。規模では効率的に見える同じ検証ルールは、小規模保有者にとって固定されたコンプライアンス税になる可能性がある。RIPE NCC のステータス言語が曖昧な場合、その小規模保有者はすべての取引相手のためにイベントを翻訳しなければならないため、より多くを支払う。
無効の私的拒否はそれ自体では欠陥ではない。それは経路起点検証のポイントである。欠陥は、上流の原因が不明瞭なまま上流の結果が拡大することを許すことだろう。RIPE NCC は、認証イベントを機械可読かつ人間可読にすることで支援できる：計画された保有者アクション、移転による削除、ホスト型 CA 失効、委任 CA 非機能、緊急封じ込め、アカウント回復、サービスインシデント、または修正。ネットワークは依然として経路を決定する。市場は、何を決定しているのかについてより良い説明を得る。
通知と治癒は経済的制御である
通知はしばしば法的な儀礼として扱われる。ROA 継続性において、それは経済的制御である。悪い変更のコストは、しばしば変更そのものよりも驚きから生じる。保有者が移転が ROA を削除することを知っていれば、再作成をスケジュールできる。委任 CA オペレーターが、マニフェストと CRL が定義された期間検証されていないことを知っていれば、CA を修復するか、ホスト型サービスに移行できる。クラウド移行チームが maxLength が狭すぎることを知っていれば、最初の経路がアナウンスされる前に ROA を変更できる。アカウントが侵害されたように見える場合、保有者はリスクの高い変更を凍結しながら、どの既存の認証を保持すべきか合意できる。
治癒は対になる制御である。エラーを罰することしかできないシステムは、プロダクションネットワークには脆すぎる。多くの欠陥は治癒可能である：古い連絡先権限、誤った起点 AS、欠落した maxLength、移転後のシーケンシング、期限切れの運用知識、委任公開の失敗、不完全なクラウド起点計画、または誤った削除。治癒パスは、保有者にどのような証拠が必要か、誰が提出できるか、どのクロックが適用されるか、レビュー中にどの状態が保持されるか、いつエスカレーションが開始されるかを伝えるべきである。そのパスがなければ、通常の欠陥は資産凍結となる。
設計上の問題は結果の階層化である。すべての ROA 変更が同じプロセスに値するわけではない。新しい起点のための日常的な保有者作成 ROA は、通常のアカウント認証とロギングが必要かもしれない。破壊的なホスト型 CA 失効は、より明確な確認と変更前の警告を必要とすべきである。現在のより具体的な経路を無効にする可能性のある maxLength の厳格化は、受け入れ前にライブルートへの影響を示すべきである。移転による削除は、移転チェックリストの一部であるべきである。90 日間の非機能後の委任 CA 失効は、通知証拠を持つべきである。侵害の疑い後の緊急封じ込めは、迅速だが狭く、時間制限があるべきである。
通知と治癒はまた、関係する当事者を区別すべきである。現在の保有者は現在の起点ではないかもしれない。マネージドプロバイダーは保有者に代わって発信するかもしれない。クラウドプラットフォームは将来の起点認証を必要とするかもしれない。買い手は移転後にのみ保有者になるかもしれない。融資機関はコベナンツを持つが技術的役割はないかもしれない。RIPE NCC はインターネット上のすべての顧客に通知することはできず、それを試みるべきではない。しかし、どのアカウント連絡先と技術連絡先がどのカテゴリーの認証通知を受け取るかを定義し、高影響の RPKI イベントのために運用連絡先を追加する方法を保有者に与えることができる。
治癒パスは二つの誤りを避けなければならない。一つは、中断がコストがかかるという理由で悪い認証を無期限に持続させることである。虚偽の権限と積極的な害は封じ込められなければならない。もう一つは、すべての欠陥を正当性のなさの証明として扱うことである。間違った maxLength はしばしば計画エラーである。委任 CA 障害はスタッフの入れ替わりかもしれない。移転後の ROA 欠落はシーケンシングかもしれない。侵害されたアカウントは、保有者のリソース使用権とは無関係かもしれない。対応はカテゴリーに適合すべきである。
市場は手続きを価格付けする。買い手が RPKI 欠陥のための明確な治癒クロックがあることを知っていれば、より狭いエスクロー条件を書くことができる。融資機関が高影響の失効がログに記録されレビュー可能であることを知っていれば、不確実性を減らすことができる。顧客が検証修復に定義されたパスがあることを知っていれば、短いメンテナンスリスクを許容するかもしれない。通知と治癒は官僚的な装飾ではない。それらは、セキュリティメカニズムが商業的ショックになるのを防ぐ最も安価な方法である。
緊急権限は影響範囲を隔離しなければならない
緊急権限は必要である。侵害されたアカウントは悪意のある ROA を公開することができる。虚偽の認証は、経路起点検証を使用するネットワークにとってハイジャックを正当に見せかけることができる。委任 CA は、依存パーティに負担をかける方法で壊れている可能性がある。法的制約や虚偽のリソース権限の明確な証拠は、迅速な行動を必要とするかもしれない。これらのケースで行動できないレジストリは、RPKI の信頼性を低下させ、向上させることはないだろう。
危険は、緊急言語があまりにも弾力的になり得ることである。すべての紛争、未払い請求書、移転の不一致、ポリシーへの苛立ち、または疑わしい変更が緊急になると、認証権力はレバレッジに変わる。制度的な線は狭くあるべきである：緊急 RPKI アクションは、経路起点の害、アカウント侵害、証明書の完全性、リポジトリの完全性、委任 CA の非機能、証明可能な虚偽の権限、または認証サービスに影響を与える即時の法的制約のためである。それはトラフィック制御、価格規律、私的取引、または資本移動の一般的な方法ではない。
影響範囲の制御は実用的なルールである。新しい疑わしい ROA が 1 つある場合、可能であれば無関係な認証を混乱させるのではなく、その ROA を無効化または逆転させる。アカウントが侵害された場合、リスクの高い変更を凍結し、それらの経路自体が有害でない限り、最後の既知の安全な経路を保持する。委任 CA が長期間検証に失敗した場合、公開されたクロックに従い、取引相手に不正行為を推測させるのではなく、カテゴリーを伝達する。リソースセットの変更がカバレッジを削除する場合、その変更が日常的として扱われる前に結果を可視化する。目的は、顧客を担保として使用せずに害を封じ込めることである。
時間制限も同様に重要である。レビュークロックのない緊急ロックは無期限の不確実性になる。一時的な停止が静かに最終的な失効になることは、市場割引を招く。保有者、買い手、または上流は、いつ状態がレビューされるか、どの証拠がそれを変えることができるか、最初の決定が誤っている場合に誰がエスカレーションできるかを知る必要がある。経路起点の影響が深刻であるほど、エスカレーションパスはより強力であるべきである。
逆転の文言が重要である、なぜなら誤りは起こるからである。監視アラートが間違っているかもしれない。正当な緊急起点が疑わしく見えるかもしれない。移転ファイルが誤解されるかもしれない。顧客経路が運用上の理由でより具体的であるかもしれない。裁判所命令が明確化されるかもしれない。ROA または CA の状態が復旧された場合、その説明は、復旧が意図的であり一過性のアーティファクトではないことを取引相手に伝えるべきである。さもなければ、修復された経路は商業的に汚染されたままである。
独立したエスカレーションは、高影響のケースのために予約されるべきである。それは遅いまたは司法的である必要はない。それは、書面によるイベントカテゴリーと決定のトレイルを備えた、機関内の別個の技術的およびポリシーレビューであり得る。ポイントは、RIPE NCC にすべての私的紛争を解決するよう求めることではない。それは、認証権力がライブルートと市場の依存に影響を与える瞬間を規律することである。緊急権限は、ツールが狭いことを証明することによって信頼を強化すべきである。ツールが裁量的に見える場合、すべての緊急事態は価格付けされる先例となる。
アカウント侵害は現実だが、枠組みを支配すべきではない
アカウント侵害は、ROA 失効リスクの最も簡単な説明バージョンである。悪意のある行為者がレジストリポータルまたは API 資格情報へのアクセスを得て、ROA を変更し、誤った起点を認証し、有効な認証を削除し、または maxLength を広げてより具体的な誤用を許可する。害は速く、測定可能で、深刻であり得る。したがって、強力な認証、役割分離、API トークン制御、高リスク変更の確認、警告、ロールバック記録は基本的な要件である。
しかし、侵害が枠組みを支配すべきではない。より一般的な経済問題は、誤った順序で行使された正当な権限かもしれない。買収チームが移転後に ROA を再作成し忘れる。クラウドプロジェクトが認証前にアナウンスする。保有者がギャップを計画せずにホスト型から委任型 RPKI に移行する。担当エンジニアが退職した後、委任 CA が正しく公開しなくなる。maxLength の変更がクリーンアップとして扱われるが、バックアップパスを無効にする。リソース状態を修正することを意図したレジストリアクションが、予想よりも広範な経路結果をもたらす。これらはいずれも犯罪者を必要としない。
その区別は制御にとって重要である。侵害に関するセキュリティ制御は、不正な変更を防ぐことに焦点を当てる。継続性制御は、認可された変更を安全にすることに焦点を当てる。システムは優れたログインセキュリティを持ちながら、破壊的な変更が影響プレビューなしで簡単に実行できる場合、経済的ショックを生み出す可能性がある。システムは強力な証明書実践を持ちながら、移転に伴う ROA 削除が取引計画に含まれていない場合、市場を失敗させる可能性がある。システムは疑わしい変更を捕捉しながら、リスクの高いものを隔離するのではなく、すべての認証を凍結する場合、顧客に害を及ぼす可能性がある。
したがって、アカウントモデルは役割をサポートすべきである。財務連絡先は、高影響の RPKI 変更を気軽に実行する能力を持つべきではない。経路エンジニアは、完全な企業更新権限なしに ROA 権限を必要とするかもしれない。マネージドプロバイダーは、保有者が最終的な制御を保持しながら、特定の ROA を提案または維持する委任能力を必要とするかもしれない。保留中の取引の買い手は、クロージング前に現在の ROA 計画への読み取り専用アクセスを必要とするかもしれない。融資機関は、制御が存在する証拠を必要とするが、経路を変更する力は必要としないかもしれない。粗雑なオールオアナッシングアクセスは、侵害と継続性の両方を悪化させる。
監査ログは橋渡しである。ROA が削除された場合、保有者は、いつ、どの認可された役割によって、どのアカウントパスの下で、どのような確認を伴って削除されたかを確認できるべきである。削除がリソース変更のために自動的だった場合、ログはそう述べるべきである。イベントが公開されたカテゴリーの下でレジストリによって開始された場合、ログはそのカテゴリーを特定すべきである。アクションが逆転された場合、逆転は可視であるべきである。ログがなければ、争われたすべての変更は記憶の競争となる。
リスクを侵害として狭く枠付けることもモラルハザードを生み出す。レジストリはより広範な制御のためにセキュリティ言語を過剰に使用するかもしれない。保有者は悪い変更計画を侵害のせいにするかもしれない。取引相手はすべての無効な経路を詐欺の証拠として扱うかもしれない。成熟したシステムは、イベントを正確に分類することによって三者すべてを避ける。侵害は一つの狭いリスクである。不連続性はより広範な市場問題である。
監査可能性はサービスと裁量の境界である
監査可能性は、すべての機密詳細の公開と同じではない。それは、認可された当事者、および適切な場合はより広いコミュニティが、認証変更のカテゴリー、タイミング、権限、および影響を理解できることを意味する。ROA 削除は、一人のエンジニアだけが知るポータル履歴に消えるべきではない。委任 CA 失効は、数ヶ月前にポリシーページを読んだ人だけに判読可能であってはならない。移転に伴う ROA 削除は、メンテナンスウィンドウ中に買い手を驚かせるべきではない。監査可能性は、経路起点の権力を裁量からサービスに変える。
いくつかの層がある。第一は保有者レベルのログである：誰がどの ROA を変更したか、どのプレフィックスと起点が影響を受けたか、どの maxLength が変更されたか、どの証明書イベントが発生したか、リポジトリが結果をいつ公開したか、アクションが保有者要求、自動、緊急、またはレジストリ開始のいずれであったか。第二はアカウントレベルの制御である：どの役割が破壊的な変更を実行する権限を与えられていたか、多要素制御がアクティブだったか、高影響の確認が使用されたか。第三はサービスレベルの報告である：RIPE NCC に RPKI インシデント、リポジトリ問題、ポータル問題、または委任 CA 監視アクションがあったかどうか。第四はポリシーレベルの証拠である：公開されたクロックと通知が守られたかどうか。
これらのいずれも、RIPE NCC が経路決定を指揮することを必要としない。ネットワークは依然として INVALID 経路を拒否し、UNKNOWN 経路を受け入れ、ローカルプリファレンスを設定し、例外を構築し、定義されたコンテキストで RPKI を無視することができる。監査可能性はルーティングを集中化しない。それは認証レイヤーで何が起こったかを市場に伝え、私的な経路決定がより明確な証拠に基づくようにする。それがインフラと制御の違いである。
監査境界はまた、RIPE NCC を保護する。イベントカテゴリー、通知、治癒、エスカレーション、復旧を示すことができるレジストリは、恣意的に行動したという主張に対して脆弱ではない。それらの事実を示すことができないレジストリは、影響を受けたすべての保有者が技術的変更を政治的、商業的、または懲罰的と表現するよう招く。IPv4 がより価値を持つほど、そのような主張はより起こりやすくなる。監査可能性は批評家への譲歩ではない。それは制度的リスク制御である。
境界は、高影響の失効について特に明確であるべきである。委任 CA 非機能のような公開されたカテゴリーは、アカウント侵害の疑いとは異なる。保有者が要求したホスト型 CA 失効は、レジストリが開始した証明書アクションとは異なる。移転に伴う削除は、虚偽の権限の修正とは異なる。それぞれの場合に同じ経路が到達不能になるかもしれないが、正当性の基準と治癒パスは異なる。市場は再発リスクを価格付けするため、区別を必要とする。
監査可能性は耐久性があるべきである。M&A デューデリジェンスは ROA イベントの数ヶ月後に行われるかもしれない。融資機関は借り換え後に経路履歴をレビューするかもしれない。顧客はメンテナンスウィンドウが閉じた後に停止を調査するかもしれない。破壊的な変更が履歴を消去する場合、または履歴がアカウントが特定の状態にある間のみ可視である場合、証拠ファイルは弱まる。耐久性のあるログ、エクスポート可能なレポート、明確なイベントラベルにより、認証レイヤーは権利証書レジストリのふりをすることなく市場の信頼をサポートできる。
小規模ネットワークは固定費を支払う
ROA 継続性は大規模ネットワークにとって吸収しやすい。彼らはルーティングスペシャリスト、自動化、法務、コンプライアンススタッフ、クラウドやトランジットプロバイダーとの関係、複数のバリデーターにわたる監視を持っている。大規模キャリアは移転をリハーサルし、ROA 変更を段階的に行い、RIPE NCC サポートに連絡し、上流例外をプッシュし、顧客に検証状態を説明できる。小規模ネットワークにとって、同じイベントは一人のエンジニアと、ほとんど同じ技術言語を話さないディレクターにかかるかもしれない。
固定費は証拠収集に現れる。保有者は現在の ROA、起点、maxLength 設定、意図する将来の起点、委任公開状況、ホスト型 CA 状態、連絡先役割、アカウント資格情報、上流フィルタリングルール、顧客依存関係を知らなければならない。どのバリデーターと経路モニターを信頼すべきかを知らなければならない。独自の受け入れ言語を持つ可能性のあるクラウドプラットフォームとコミュニケーションしなければならない。証拠を望むが RPKI がどのように機能するかを理解していない融資機関や買い手に答えなければならない。負担は単に技術的ではない。それは翻訳である。
RIPE NCC のサービス地域はその負担を不均一にする。グローバルキャリアと小さなアクセスプロバイダー、成熟したクラウド市場と発展中の接続回廊、制裁対象の管轄区域と通常の商業市場、大学、ホスティング企業、公共ネットワーク、レガシー保有者が含まれる。単一の ROA インターフェースは、非常に異なるリソースを持つアクターにサービスしなければならない。プロセスが誰もが専任のルーティングセキュリティチームを持っていると仮定する場合、小規模ネットワークは遅延、コンサルタント料金、失われた交渉力で支払う。
市場は厳しく反応する可能性がある。買い手は、売り手の ROA 履歴が十分に文書化されていないために割引を要求するかもしれない。融資機関は、証拠ファイルが薄いために小規模ネットワークのアドレス依存収益を脆弱とみなすかもしれない。クラウドプロバイダーは、大規模顧客はナビゲートできるが小規模顧客はできない手動エスカレーションを要求するかもしれない。上流は、保有者が期待される証明を迅速に作成できないために例外を拒否するかもしれない。経路は技術的に修復可能かもしれないが、商業的瞬間は逃される。
優れた設計は、セキュリティを弱めることなく固定費を下げる。影響プレビューは、ROA が変更される前にどのライブルートが INVALID になるかを示すことができる。プレーンなイベントカテゴリーは、問題が maxLength、起点 AS、証明書変更、委任公開、または移転シーケンシングのいずれであるかを保有者に伝えることができる。テンプレートは、保有者が取引前に現在および意図する経路を文書化するのに役立つ。API により、大規模ネットワークは小規模ネットワークをカスタムスクリプトに強制することなくチェックを自動化できる。サポート資料は、RIPE NCC が保証するものを誇張することなく、UNKNOWN と INVALID を商業言語で説明できる。
小規模ネットワークの負担は公平性の問題でもある。経路起点保証が市場受け入れに必要になる場合、それを使用するコストが参入障壁になるべきではない。RPKI は、起点証拠をより安価で信頼できるものにすることを意図していた。不透明な失効や不連続性プロセスが小規模保有者を単に受け入れ可能であり続けるために私的仲介業者に強制する場合、システムは後退したことになる。RIPE NCC の最も強力な貢献は、より広範な権限ではない。それはより明確なサービスである。
取引相手はより狭い質問をすべきである
買い手、融資機関、クラウド、上流はしばしば間違った広範な質問をする：ブロックは「クリーン」か？より良い質問はより狭い：意図された使用に必要な経路起点状態は何か、そしてその状態が消滅する原因は何か？クリーンさはあまりにも曖昧である。リソースは現在のレジストリ保有者を持ちながら、クラウド起点に必要な ROA を欠く可能性がある。現在の経路に有効な ROA を持ちながら、移転中にリスクがある可能性がある。委任型 RPKI を使用しながら、古い公開チェーンを持つ可能性がある。UNKNOWN でありながら、一部のネットワークでは許容可能に経路付けられ、プラットフォームの受け入れルールに失敗する可能性がある。
買収前のデューデリジェンスファイルは、現在のプレフィックス、起点 AS、ROA、maxLength 値、ホスト型または委任型モード、証明書状態、該当する場合は委任公開の健全性、計画されたクローズ後の起点、クラウドまたは緩和起点、上流フィルター依存関係、以前の検証インシデントをリストすべきである。リソースが移動するときにどの変更が自動的に発生し、どれが手動で実行されなければならないかを特定すべきである。クロージング日だけでなく、リハーサル日を含めるべきである。
クラウド BYOIP 移行前には、プラットフォームと顧客はアナウンスされる正確なプレフィックス長、起点 AS、必要な maxLength、プレフィックスが現在別の ROA によってカバーされているかどうか、バックアップサービスのために古い起点が認証されたままかどうか、移転またはアカウント変更が保留中かどうかを確認すべきである。プラットフォームが INVALID を拒否する場合、そのルールは顧客がトラフィックを変更する前に明確であるべきである。UNKNOWN が一時的にのみ許容される場合、期間が明記されるべきである。
アドレス依存収益に対して融資する前に、融資機関は借り手が通常、緊急、移転シナリオの下で経路起点認証を維持できるかどうかを尋ねるべきである。RIPE NCC に価値を保証するよう求めるべきではない。借り手に制御、ログ、役割、監視、継続性手順の証拠を求めるべきである。融資機関のヘアカットは、単にレジストリ地域ではなく、借り手の運用規律を反映すべきである。
上流が新しい顧客経路を受け入れる前に、現在の検証矛盾と RPKI の欠如を区別すべきである。INVALID 経路は修復または意識的な例外が必要である。UNKNOWN 経路はポリシーの下で許容されるかもしれないが、顧客が RPKI 整合を約束した場合でも説明が必要かもしれない。経路が昨日有効で今日 UNKNOWN の場合、プロバイダーは何が変わったかを尋ねるべきである。狭い質問はより狭いコストを生み出す。
これらの質問はまた、RIPE NCC の境界を保護する。取引相手がより正確になるほど、レジストリに私的なビジネスの意味を解決するよう求めることが少なくなる。レジストリは証明書と ROA の事実を述べることができる。当事者は商業リスクを割り当てることができる。ネットワークは経路ポリシーを設定できる。顧客は継続性証拠が十分かどうかを決定できる。狭い質問は、強力な技術的信号が市場排除の漠然とした手段になるのを防ぐ。
RIPE NCC の制度的バーゲン
制度的バーゲンは述べるのは簡単だが実行するのは難しい。RIPE NCC は RPKI のための信頼できる台帳/サービスインフラを提供すべきである：リソース関係がサポートする安定した証明書、予測可能な ROA 管理、明確な移転効果、ホスト型および委任型の継続性、強力なアカウント制御、正確なステータス言語、可能な場合は通知、治癒パス、緊急封じ込め、エスカレーション、ログ。それはアドレス価値の所有者、経路可能性の保険者、トラフィックポリス、価格コントローラー、私的裁判所、または資本制御当局になるべきではない。
このバーゲンはシステムの両側を尊重する。RPKI は、ネットワークが起点の不確実性を減らすことを可能にするため価値がある。弱いまたは臆病な認証サービスはインターネットに害を及ぼすだろう。虚偽の権限は除去されなければならない。壊れた委任 CA は永遠に無視できない。侵害されたアカウントは封じ込められなければならない。移転は証明書を更新しなければならない。保有者は意図したルーティングに一致する ROA を維持しなければならない。ネットワークは無効な経路を拒否する自由を保持しなければならない。セキュリティは真の権限を必要とする。
しかし、セキュリティ権限は、それが経済的価値の近くに位置するため、境界付けられなければならない。経路起点の変更は、クラウド入場、上流受け入れ、顧客アップタイム、買収クロージング、エスクロー解放、クレジット条件に影響を与える可能性がある。コストは、保有者のレジストリアカウントから遠く離れた人々に降りかかる可能性がある。市場が RPKI に依存すればするほど、認証イベントが説明可能でレビュー可能であることが重要になる。さもなければ、セキュリティ権力は裁量的な市場権力のように見え始める。
答えは RPKI を弱めることでも、ネットワークに無効を無視するように言うことでもない。不連続性の周りの手続きを強化することである。破壊的なアクションには影響プレビューがあるべきである。移転ページは ROA 再作成を運用上の決済として扱うべきである。ホスト型から委任型への移行は明示的な継続性警告を伴うべきである。委任 CA 失効は、公開された非機能閾値と通知証拠に結びついたままであるべきである。緊急封じ込めは、可能であればリスクのある認証を隔離すべきである。復旧は可視であるべきである。ログはイベントを生き残るべきである。
同じバーゲンは、私的取引相手からの謙虚さを必要とする。クラウドプロバイダーは、すべての UNKNOWN 経路を正当性のなさの証明として扱うべきではない。融資機関は ROA を権利証書と間違えるべきではない。上流は漠然とした検証問題を商業的交渉ツールとして使用すべきではない。買い手はレジストリ移転が経路準備完了と同等であると想定すべきではない。市場は RPKI 証拠を必要とするが、その能力を理解する必要もある。
RIPE NCC は、その役割がすべてのダウンストリーム使用を決定することではないからこそ、この線を正確に保持するのに適した立場にある。事実を公開し、サービスを運用し、イベントを分類し、修正をサポートすることができる。RPKI をより広範な経済的拒否権に変換する招待を拒否することができる。それが規律ある中道である：より強力な経路起点保証、より低い不確実性、より少ない偶発的なショック、そしてセキュリティサービスの私的裁定システムへの変換なし。
経路は担保になるべきではない
最終的なテストは顧客の継続性である。プレフィックスが単にレジストリファイルの取引可能なエントリーであることは稀である。それは決済システム、VPN、ホスティング顧客、公共サービス、アクセスネットワーク、監視許可リスト、メールフロー、ヘルスポータル、教育プラットフォーム、および ROA が何であるかを知らない通常のビジネスをサポートしている。経路起点の認証が急激に変更されると、それらの依存関係は、指名された保有者がレジストリ、売り手、買い手、上流、またはクラウドプロバイダーとの議論を終える前に損なわれる可能性がある。
それは、悪い認証が顧客の便宜のために保存されるべきであることを意味しない。アクティブなハイジャックをサポートする虚偽の ROA は削除されなければならない。侵害されたアカウントは封じ込められなければならない。非機能の委任 CA は無期限にコストを課すことを許されてはならない。しかし、継続性がデフォルトの設計上の問いであるべきである。最後の検証された安全な状態は何か？リスクのある新しい認証を隔離できるか？争われている変更がレビューされている間、既存の有効な経路を継続できるか？maxLength の厳格化が現在のトラフィックエンジニアリングを無効にする前に通知できるか？移転チェックリストはクローズ後のギャップを防ぐことができるか？
顧客の継続性はまた、RIPE NCC が何でないかを明確にする。それは普遍的なサービス保証人ではない。すべてのダウンストリーム依存関係を知ることはできず、すべてのネットワークに経路を受け入れるよう命じることはできない。SLA 紛争のフォーラムになるべきではない。その責任はより狭く、より実用的である：認証セマンティクスを不必要に不明瞭にせず、破壊的な移行を驚くべきものにせず、緊急カテゴリーの拡大を許さず、欠陥が治癒可能な場合に影響を受けた保有者を治癒パスなしに放置しないこと。
経済学は冷たい。取引相手が、ROA が境界のある説明なしに消える可能性があると恐れる場合、彼らはその恐れを価格付けする。買い手は遅延する。融資機関は割り引く。クラウドはより多くの文書を要求する。上流は手動例外を主張する。顧客は補償を要求する。小規模ネットワークはコンサルタントに支払う。レジストリは単に技術サービスを運用しただけだと主張するかもしれないが、市場はそのサービスをリスクレイヤーとして扱ったであろう。
より良い結果もまた冷たい。ROA の不連続性が予測され、分類され、可能な場合は可逆的であり、ログに記録される場合、市場アクターはリスクを正確に割り当てることができる。移転保留はクローズ後の検証に限定できる。クラウド移行は BGP の前に ROA 変更をスケジュールできる。融資機関は推測する代わりに継続性をチェックできる。上流は、移行エラーによって引き起こされた無効性を疑わしいハイジャックと区別できる。保有者は、正当性をめぐる紛争に発展させることなく、maxLength の誤りを修正できる。
RPKI の約束は、すべての経路が安全になることではない。それは、不確実性の重要な一形態が検証するのにより安価になるということである。ROA 失効リスクはその約束の影である：信頼を生み出す同じシステムが、信頼が置かれる証拠を削除または中断することができる。RIPE NCC の任務はその影を小さく保つことである。認証レイヤーをインフラとして運用すべきである：正確で、保守的で、監査可能で、ミッションクリープに耐性がある。経路は曖昧さの担保になるべきではない。