要約

  • 経路起点認可（ROA）は、指定された自律システム（AS）が特定のプレフィックスを起点として経路広報を行うことを認める署名付き表明であり、所有権の移転、ルーターへの指令、経路が無害であることの保証、または指定された AS が私的リース契約に基づき依然として権利を有することの証明ではない。
  • ほとんどのリースでは、貸主が直接のリソース保持者として RPKI 認証チェーンに最も近い位置にいる。借主はネットワークを運用し、運用上必要な起点 AS やより詳細な経路を把握している。上流プロバイダは経路を伝送またはフィルタリングする。RIR はトラストアンカーまたは上位認証サービスを運用する。これらは異なる権限である。
  • ホステッド RPKI と委任 RPKI は、管理と実行の主体を変えるが、その根底にある商取引上の合意を変えるものではない。ホステッドサービスでは、鍵運用と公開が RIR に置かれる。委任サービスでは、保持者は CA を運用し、通常その秘密鍵も管理する。いずれの方式も、それ自体では、借主にタイムリーな権利を与えたり、係争中の削除から保護したりしない。
  • すべてのリースには、正確なプレフィックス、許可された起点 AS、最大プリフィックス長、開始・終了期間、通常の変更期限、緊急時期限、承認者、認証チャネル、および保管すべき証拠を明記した認可スケジュールを添付すべきである。「認可状を提供する」という漠然とした約束だけでは不十分である。
  • 契約上の時間と RPKI の時間は、意図的に整合させる必要がある。ホステッドサービスでは署名オブジェクトが自動更新される場合があり、キャッシュは独自の周期でリフレッシュされ、商用期間終了後も経路が有効と見なされ続ける可能性がある。したがって、深夜の期限切れは、即時の技術的失効でもなければ、トラフィックが移行する前に唯一の有効な ROA を削除する安全な理由でもない。
  • 緊急アクセスは限定的かつ冗長であるべきである。借主は事前承認された軽減策や代替起点を迅速に追加する手段を必要とし、貸主は無制限の委任を防ぐ制限を必要とする。二者承認、プレフィックス範囲の制限、短期間の緊急権限、独立したログ、およびインシデント後のレビューにより、両方のニーズを満たすことができる。
  • 商業上の紛争を、グローバルルーティングシステムを驚かせることによって解決すべきではない。現実のセキュリティ緊急事態を除き、ROA の削除は、通知、短い継続期間、独立したエスカレーション、調整された経路撤回に従って行うべきである。最終的な失効は確実でなければならないが、そこに至る過程が顧客を人質にするものであってはならない。

リースは利用と認証を分離する

IPv4 リースにおいて厄介な問題は、誰がルータを所有するかではない。それは、他のルータが依存する暗号文書を誰が作成できるかである。

借主は、起点 AS を設定し、プレフィックスを広報し、顧客にサービスを提供し、迷惑行為の報告に対応し、トランジット料金を支払うことがある。しかし、プレフィックスが貸主に帰属する証明が残っている場合、借主は、自身のライブ広報を記述する ROA を作成、変更、または削除できない可能性がある。貸主は経済的には受動的でありながら、技術的には決定的な立場にある。忘れられたポータルアカウントや署名不能の担当者が、日常的なルーティング変更を障害リスクに変えかねない。

だからといって、リースが欠陥品であるわけではない。それは、リースが二つの権威のシステムにまたがることを意味する。契約法は、一方が他方に何を約束したかを決定する。RPKI は、番号資源階層に根ざしたチェーンを通じて署名付きの認可が検証可能かどうかを決定する。BGP は、ネットワークが実際に広報し選択する経路を決定する。トランジット契約は、上流プロバイダが何を受け入れるかを決定する。これらのシステムは、自動的に互いを読み取るわけではない。

RFC 9582は、ROA を、アドレスブロック保持者が自律システムに対し、一つ以上のプレフィックスへの経路起点を認可する署名付きオブジェクトと定義している。そのセキュリティに関する章は、ガバナンスにとって特に有用である。RPKI は認証よりも認可を提供し、本人認証や否認防止を提供するものではない。このオブジェクトは、依存当事者が処理した時点で有効な証明パスがその表明を支持していたことを証明するに過ぎない。リース、価格、顧客、受益者、経路の理由、あるいは商業契約上の期限を公にするものではない。

この区別により、二つの良くある簡略化が退けられる。第一に、ROA を作成できる当事者が経済的所有者でなければならないという主張。それは導かれない。第二に、ROA で起点として指名された当事者がアドレス権利を掌握しているに違いないという主張。これも導かれない。保持者は、リソースを移転することなく、顧客の AS、上流プロバイダ、クラウドネットワーク、あるいは軽減策プロバイダを認可することができる。この署名付きオブジェクトは、それを取り巻く関係性よりも意図的に狭義である。

したがって、正しい問いは、単に「ROA を誰が制御するのか」ではない。一連の問いである。誰が変更を要求できるのか。誰がその要求がリースの範囲内にあると決定するのか。誰が署名システムを運用するのか。誰が危険な変更を阻止できるのか。主要当事者が不在のとき、誰が行動できるのか。約束された変更が遅れた場合、誰が損害を負うのか。経路を流す権利が終了したとき、誰が認可を削除しなければならないのか。

最初の問いにしか答えないリースは、残りを即興に委ねることになる。

四人の主体が四種類の異なる権力を有する

貸主、借主、上流プロバイダ、RIR CA は、しばしば単一の指揮系統上の点として描写される。しかし、それらは交差はするが同一ではない権力を有する四人の主体として理解する方が適切である。

貸主は通常、リソース証明が導出される登録関係を保持する。ホステッド RPKI サービスでは、貸主の組織の認可ユーザーが RIR のインターフェースを通じて ROA 設定を作成できる。委任方式では、貸主自身の CA を運用し、対応する秘密鍵を保持する場合がある。貸主の決定的能力は証明にある。すなわち、プレフィックスと起点 AS に関する表明を、検証済み RPKI セットに追加または削除することができる。

借主は運用知識を有する。意図する起点、上流設計、顧客移行状況、トラフィックエンジニアリングのための詳細経路、軽減策、そして新しい経路が動作しなければならない日付を把握している。その決定的能力は利用にある。すなわち、自身またはそのプロバイダが BGP 広報を設定し、発信することができる。これは、経路が RPKI 無効になったとしても成立し得る。なぜなら RPKI は BGP を停止させるわけではないからだ。実際の帰結は、どのネットワークが経路起点検証をどのように適用するかに依存する。

上流プロバイダは、受領と伝搬の権力を有する。彼らは認可状、IRR オブジェクト、一致する ROA、契約上の証明、あるいはそれらの組み合わせを要求し得る。顧客プレフィックスフィルタを、自らの記録、IRR、RPKI 検証済みペイロード、あるいは手動確認から構築し得る。顧客関係が未検証である場合、本来有効な経路を拒否することもあれば、Not Found の経路を自社ポリシーで伝送することもある。有効な ROA は関連証拠であり、上流プロバイダへの指令ではない。

RIR CA は認証階層の中に位置する。RFC 6480は、番号リソース割り振りに合わせたアーキテクチャを示している。RIR サービスは、上位リソース証明書を発行または維持し、多くの保持者のために署名をホストし、資料を公開し、認証リソースの変更を階層へと接続する。RIR はほとんどのリースの当事者ではなく、通常その完全な商業条件を知らない。そのシステムは、保持者のアカウントを認証し、リソースの範囲を検証することはできても、借主の請求書が係争中かどうかを知ることはない。

これらの権力は混同すべきではない。貸主が ROA を削除できるからといって、借主のルータを制御すべきとは限らない。借主が広報を送信できるからといって、貸主の集合に対して無制限の署名権を持つべきではない。上流プロバイダのフィルタがリースを決定するわけではない。RIR の証明書が受益的な利用を裁定するわけではない。

良いガバナンスは、どの単一の主体も関係性の全体を把握していないと認めることから始まる。

ROA は起点を認可するが、経路をその全次元で認可するものではない

ROA の狭義さは強みであるが、契約がそれを過度に広く描写すると危険となる。

ROA は一つの起点 AS と一つ以上のプレフィックスを特定する。それにより、特定のより詳細な経路広報を許可する最大プリフィックス長を含む場合がある。同じプレフィックスを起点として複数の AS が認可される場合、個別の ROA が必要である。このオブジェクトは、どの上流が経路を伝送してよいか、どの AS パスが許容されるか、起点に現在のサービス契約があるか、どの顧客トラフィックがそのアドレスに属するか、あるいは広報が地理的に期待されるかどうかについては述べない。

だからこそ、「RPKI 準拠のリース」という表現は、明かす以上に隠す可能性がある。貸主は、誤ったビジネス当事者の ASN に対して技術的に有効な ROA を作成できる。借主は、サービス契約終了後も認可された起点を通じて広報し続けることができる。認可された AS が、広範な最大長によって許可された過剰に詳細な経路を意図せず漏洩させたり、故意に広報したりする可能性がある。経路は RPKI 上有効でありながら、運用上は誤りまたは悪用である場合がある。

RFC 6483は、一つの ROA が同じアドレス空間でカバーされる他の広報に影響を与え得ると警告している。リストにない起点からの経路、あるいは許可された長さを超えたより詳細な経路が無効になり得る。同 RFC は、すべての正当に認可された起点と関連する詳細経路を考慮するよう勧告している。RFC 7115もまた、起点検証を運用上の入力と位置づけており、普遍的な経路選択の判定とはみなしていない。

リースにとってこれは、スケジュールが単に「貸主が ROA を作成する」と言うだけでは不十分であることを意味する。正確なプレフィックスと起点のペアを明示し、詳細経路の方針を説明しなければならない。もし/20が借主の ASN から/20としてのみ広報されるのであれば、利便性のために不要に寛容な最大長を付与すべきではない。もし移行期間中に二つの起点から/24の広報が必要であれば、両方の起点と一時的な期間を明示すべきである。

上流プロバイダの役割は分離されたままである。MANRS ネットワークオペレーター行動規範は、オペレーターが自身および顧客の広報の正確性を保証し、利用可能な連絡先を維持し、他者が検証可能な情報を公開することを求めている。ROA の有無のみを確認するトランジットプロバイダは、このタスクを完了していない。依然として、その顧客が経路の伝送を依頼する権限を有する当事者であることを知る必要がある。

したがってリースは、魔法のステータスではなく、調整された複数の事実を約束すべきである。すなわち、貸主からの商業的許可、借主からの運用指示、RPKI における起点認可、正確なルーティング情報、そして意図された上流プロバイダによる受諾である。

ホステッド RPKI は実行を保持者のアカウントに集中させる

ホステッド RPKI は、リソース保持者から暗号管理の大半を取り除くため魅力的である。この利便性は、リースの依存関係がどこにあるかを明らかにする。

RIPE NCC のホステッド CA ガイドによれば、ホステッドサービスは、認可アカウントによって管理される設定から、ROA オブジェクトに署名、公開、更新を行う。ユーザーは意図する起点やプレフィックス情報を管理するが、鍵、オブジェクト更新、公開はサービス側が処理する。ARIN のホステッド RPKI ドキュメントも同様に、CA と署名を ARIN に置き、下流組織は、直接参加できない場合、上流プロバイダに代わりに ROA を提出させる必要があるとしている。

貸主にとって、ホステッドサービスは運用上の障害を低減できる。借主が監視しなければならないプライベート CA リポジトリはなく、従業員のラップトップに置く署名鍵もない。しかし、借主にとって重要な問題はアカウントガバナンスになる。貸主のどの個人が要求を承認できるか？24時間365日のカバレッジはあるか？借主に制限付きの役割を与えることができるか、それともすべての変更は保持者が転記しなければならないか？貸主のアカウントが本人確認、企業変更、または紛争の最中にロックされたらどうなるか？

ポータルアクセスは安易に共有すべきではない。借主に貸主の一般的なクレデンシャルを与えることは、無関係なプレフィックス、他の顧客、破壊的行為を露出させる可能性がある。また、帰属があいまいになる。つまり、貸主は後になって、その変更を行ったのが自身の従業員、契約業者、顧客のいずれかを判別できなくなる。インターフェースが複数ユーザーをサポートする場合でも、認可は、各人が実行を許された組織とタスクに限定されるべきである。

より安全なホステッドモデルは、借主を認証された要求者として、貸主を限定された承認者として扱う。要求は定義済みのチャネルを用い、リースとプレフィックスを特定し、提案された起点と最大長を含み、トランザクション記録を受ける。通常の変更にはサービス期限がある。緊急変更は、別の認証を用いたより高速なチャネルを利用する。貸主側では少なくとも2人が行動可能であるべきで、借主側にも少なくとも2人の承認済み要求者が必要である。

自動化は遅延を減らすことができるが、認可スケジュールを強制すべきであり、迂回してはならない。リストされたプレフィックス、ASN、許可された最大長に対する要求は、迅速な承認対象とすることができる。未知の ASN や、より広範な詳細経路範囲を認可する要求は、人間のレビューのために停止すべきである。既知の約束を自動化することと、暗黙のうちに約束を拡大することは区別される。

ホステッドサービスは鍵運用を解決する。それは、契約とアカウント役割が整わない限り、商業的な委任を解決しない。

委任 RPKI は鍵を移動させるが、上位の関係はそのままである

委任 RPKI は、リソース保持者により多くの技術的自律性を与えることができる。しかしそれは、保持者がすべての上流依存から逃れたという誤った信念を生み出すこともある。

RIPE NCC のホステッドサービスと委任サービスの比較では、委任オペレーターは、自身のリソース証明書と対応する秘密鍵を制御し、公開場所を選択できると述べている。ARIN の導入オプションでは、直接保持者は自ら CA を運用し、ROA に署名し、委任モデルでは顧客のためにリソース証明書を発行できるとしている。APNIC もまた、リソース証明資料において、自己ホストモードを委任 RPKI と位置付けている。

このアーキテクチャは、より直接的な分業を支援できる。高度な貸主は親 CA を運用し、借主のプレフィックスに限定された下位リソース証明書を発行できる。そうすれば、借主は、貸主の他のリソースへの権限なしに、その限定セット内でオブジェクトに署名できる。リース終了時には、貸主は合意された手順に従い、下位証明書を失効させるか、期限切れを許容できる。

この見かけの優雅さは、運用上の義務を伴う。誰かが秘密鍵を安全に保管し、CA を維持し、最新のオブジェクトを公開し、マニフェストや失効情報を管理し、可用性を監視し、鍵をロールオーバーし、復旧アクセスを保持しなければならない。RIPE NCC の持続的に機能しない委任 CA に関するポリシーは、長期にわたる障害の結果を示している。つまり、最新の資料を発見・検証できなくなった場合、親が委任リソース証明書を失効させる可能性がある。委任とは、メンテナンスと結びついた制御であり、一度限りの引き渡しではない。

親との関係も残る。委任証明書は階層の中に存在する。認証リソースが変更されたり、親証明書が失効したりすれば、下位の権限に影響が及ぶ。RFC 8211は、CA やリポジトリ管理者による悪意ある行為や過失を検討しているが、それはまさに、鍵のローカルな保持が階層的・公開上の依存を排除しないからである。

多くの借主にとって、CA を運用することは過剰であろう。頻繁な起点変更、複数の上流、厳格な継続性を必要とする大規模オペレーターにとっては、限定された委任はコストに見合う可能性がある。その選択は、変更頻度、停止許容度、スタッフの能力、貸主のポートフォリオ設計に依存すべきであり、鍵を保持するという威信にではない。

最も重要なのは、委任 RPKI が非公式な恒久的権利付与になってはならないことである。下位リソース、証明書の期間、更新ルール、失効事由、リポジトリの義務、緊急連絡先、および終了時の破棄または移転の証拠は、すべてリースに含まれなければならない。秘密鍵を借主の近くに移動させることは、一つの遅延を減少させるが、同時に規律ある終了の重要性を高める。

認可スケジュールは欠けている商業的手段である

主要契約は経済的合意を述べることができる。別途の認可スケジュールは、エンジニアと弁護士の双方が検証可能な条件で、経路セキュリティの合意を述べるべきである。

スケジュールは正確な CIDR 表記で始める。次に、許可されるすべての起点 AS、その AS を管理する法的実体、意図されたトランジットまたはホスティング関係、および各広報の許容プリフィックス長を列挙する。複数の起点が一時的である場合、スケジュールはその開始日と削除日を提示する。借主が軽減策プロバイダを使用する可能性がある場合、そのプロバイダの ASN を、インシデントが発生するまで有効化せずに事前承認することができる。

次に役割が来る。貸主のサービス責任者とバックアップ承認者、借主のネットワーク責任者とバックアップ要求者、および意図された各上流プロバイダの連絡先を指名する。個人の従業員名ではなく、役割アドレスと認証されたチャネルを使用する。従業員は去る。認可は、失効した個人アカウントを後に残さずに存続すべきである。

次にスケジュールが時計を設定する。通常の要求は1営業日以内の完了を必要とするかもしれない。計画された移行は、5または10営業日前の事前通知を必要とするかもしれない。深刻な障害は、15分以内の受領確認と、60分以内の限定された変更を必要とするかもしれない。正確な数字はサービスに依存するが、沈黙はサービスレベルではない。

変更記録には、要求時刻、認証された要求者、影響を受けるプレフィックス、旧と新の起点、最大長、業務上の理由、承認、公開観測、および検証観測を含めるべきである。これはそれ自体が官僚主義のためではない。経路が無効になったとき、両当事者は、ROA が変更されなかったのか、変更されたがまだ見えていないのか、間違って変更されたのか、あるいは別の ROA によって無効化されたのかを知る必要がある。

最後に、貸主がどの要求を拒否できるかを明記する。リースされたプレフィックス外の要求、承認されたオペレーターが管理していない ASN、合意されたルーティング設計より広範な最大長、あるいは他の顧客の経路を無効化する変更は、即時実行ではなく修正を必要とする場合がある。拒否は理由付きでタイムスタンプを押すべきであり、セキュリティを漠然と持ち出すものであってはならない。

スケジュールは、署名または同等の認証された受諾を伴ってバージョン管理されるべきである。稼働中の ROA セットは、有効化時、承認された変更のたび、定期レビュー時、および終了前に、スケジュールと照合されるべきである。これにより、契約は制御に対する測定可能な答えを持つことになる。すなわち、貸主は事前合意された権限の範囲内で認証を制御し、借主は同じ権限の範囲内で運用上の要求を制御し、いずれも相手方のリスクを黙って拡大してはならない。

契約時間と RPKI 時間は異なる時計である

リースは、日付が裁判所や財務チームに読みやすいために日付を使用する。ルーティングセキュリティは公開と取得を通じて動作し、それが同じ境界を共有することは稀である。

リースが月曜日00:00 UTC に開始されるとする。ROA は、依存当事者のキャッシュが最初の広報よりも前に取得できるように、それより早く作成されるかもしれない。ホステッドサービスは、設定がアクティブな間、自動的に署名オブジェクトを更新する場合がある。リースが終了すると、商業上の権利は消滅する一方、最後に公開された認可は依然として有効かつ可視の状態に留まり得る。逆に、設定を00:00に削除しても、すべての依存当事者が対応する検証済みペイロードを00:01までに削除した証明にはならない。

したがって、契約は一つの瞬間ではなく三つの瞬間を必要とする。認可利用可能時間とは、意図された経路が可視の有効な認可を持ち、上流プロバイダが自社のフィルタを確認した時点である。サービス利用時間とは、借主がプレフィックス上で広報し、顧客トラフィックを流してよい時点である。認可終了時間とは、トラフィックが撤回された後、もはや旧起点が RPKI 上で許可されたものとして表現されてはならない時点である。

これらの時点は、矛盾なく重なり得る。ROA は借主が早期に広報することを禁じられている限り、商用利用の前に準備され得る。また、借主が新規顧客の追加を禁じられ、トラフィックを減少させなければならない場合、秩序ある撤退中に短時間残り得る。残留する認可は、リースの経済的延長ではなく、制御された移行のための容量である。

これが、ROA の有効期限切れが終了の代替策として劣る理由でもある。長い証明書やオブジェクトの有効期間は、リースを超えて存続し得る。短い有効期間は、期間中の回避可能な更新リスクを生み出し得る。ホステッドシステムは有効期限のかなり前に更新するかもしれないが、委任システムはローカルな運用に依存する。支配的なイベントは、タイマーが合意と一致することを願うよりむしろ、観測に裏打ちされた明示的な終了指示であるべきである。

逆のミスマッチも重要である。もし貸主が、借主の代替アドレスや代替起点の準備が整う前に ROA を削除したならば、無効経路を拒否するネットワークはトラフィックを運ぶのをやめるかもしれない。貸主が最終期限について契約上正しくとも、顧客は停止を被る。もし貸主が決して削除しなければ、元借主は、一部のバリデータが認可されたと見なすであろう経路を発信する、弱いが現実の機会を保持し続ける。

時間の整合は、寛容さではない。それは、認可が依存の前に現れ、依存の後に消えるようにし、サービスが許容できる限り安全でない重なりを最小限にするという規律である。

緊急変更権は緊急事態の前に設計されねばならない

ROA ガバナンスの最も示唆に富むテストは、計画された移行ではない。それは、承認された起点がトラフィックを運べず、通常変更に署名する唯一のエンジニアが寝ているか連絡がつかない土曜日の障害である。

緊急時には、新たなトランジットプロバイダ、DDoS 軽減策 ASN、バックアップデータセンター、ルーター障害後の代替起点、または一時的な詳細経路広報が必要になるかもしれない。また、RPKI クレデンシャルの侵害や、正規の経路を無効にしている偶発的な認可が関与するかもしれない。インシデントを観測している当事者は、借主、上流プロバイダ、貸主、または外部ネットワークのいずれかであり得る。

リースは、無制限の行動ではなく、カテゴリーを事前認可すべきである。スタンバイ ASN のリストは、署名時に検証できる。緊急用の最大プリフィックス長を設定できる。借主は、リースしているプレフィックスのみを、短期間のみ有効化することを許可され得る。より広範な変更には、追加の承認者が必要である。これにより、オペレーターに速度を与えつつ、恒久的な白紙委任を渡さない。

認証は、同じインシデントを生き残らなければならない。通常の要求が、影響を受けるプレフィックスの背後にホストされた一つの電子メールドメインに依存している場合、そのチャネルは必要なときに機能しないかもしれない。少なくとも一つのアウトオブバンド方式を使用し、両組織の連絡先を維持する。貸主は、当事者のリスクに見合った要求コード、指名された役割、コールバック、または暗号的承認を要求すべきである。重要なのは、本人確認を数時間の障壁に変えずに、なりすましに抵抗することである。

変更自体は可逆的であるべきである。狭く必要とされる起点を追加し、無関係な ROA を拡大しないこと。緊急認可には期限またはレビュー期限を設定する。古い経路を撤回する前に、新しい経路が観測され受け入れられていることを確認する。インシデント後は、一時的な権限を削除し、稼働中のセットをスケジュールと調整する。

責任は制御可能な遅延に従うべきである。もし借主が承認された連絡先の維持を怠ったり、証拠なくリストにない ASN を要求したりした場合、その結果を負うべきである。もし貸主が、有効な要求にもかかわらず合意された緊急期限を逸した場合、料金の返金だけでは顧客の損失を反映し得ない。契約には、損害賠償の上限、解除権、または限定委任への移行権が必要かもしれない。もし上流プロバイダが、必要な証拠をすべて受領したにもかかわらず経路を拒否した場合、そのサービス条件は別途問題となる。

緊急権は稀に行使されるべきである。その価値は、各当事者がプレッシャーの下で道筋を知っていることであり、貸主が日常的な変更のための24時間ルーティングデスクになることではない。

最大長は商業的リスクの決定である

ROA の中で最も技術的に見えるフィールドが、大きな商業的帰結をもたらし得る。maxLengthは、認可された AS がその ROA に適合したまま発信できる広報の具体性を決定する。

過度に狭い認可は、正規のトラフィックエンジニアリングや軽減策のための経路を無効にし得る。過度に広いものは、リースにとって決して必要でなかったような詳細経路広報を許可し得る。この決定は、障害の封じ込め、上流の慣行、およびバリデータが認可されたと見なす経路の範囲に影響する。

ありがちな起草の誤りは、リースしたすべての IPv4 集約に対し、最大長を/24に設定することである。/24がグローバルテーブルで一般に受け入れられているからだ。それは運用上は便利かもしれないが、集約のみを広報する借主に、必要以上の権限を委任することになる。もし/19が常に/19として発信されるのであれば、/24の最大長は、理由なしに32個の個別の詳細経路の余地を生む。RFC 9582は、このフィールドはプレフィックス長と等しい場合には省略すべきであり、詳細認可を制限する方法を定義している。

反対の誤りは、借主の文書化された設計が詳細経路に依存している場合に、集約のみを認可することである。緊急スクラビングプロバイダは/24を広報するかもしれない。二つの起点間の移行では、集約が一時的に分割されるかもしれない。もし契約がその設計を無視すれば、借主は最悪のタイミングで急ぎの変更を求めることになる。

認可スケジュールは、技術的に可能な最も広いセットではなく、予想される経路の最小セットに一致させるべきである。異なる起点からいくつかの/24が予想される場合、明示的な ROA がその分割を見えるようにできる。一時的により広い最大長が正当化される場合、それには終了日と理由が必要である。

これは貸主にとってポートフォリオの問題でもある。一つの広範なカバーROA が、その下にあるより限定的なリースと相互作用し得る。変更を承認する前に、貸主は、別の起点や制限的な最大長を持つカバー認可のために、他の顧客の有効な経路が無効にならないかをテストしなければならない。したがって、貸主の在庫管理は、単なるリース行ではなく、オーバーラップを理解する必要がある。

商業原則は最小限必要な権限である。借主は、合意されたネットワークを運用するのに十分な暗号的許可を受け取る。これには現実的な回復力が含まれる。貸主は、文書化された運用に対する人為的な拒否権を保持しないが、合意よりも広範な許可を公開もしない。

上流プロバイダは独立した制御点であり、伝令ではない

トランジットプロバイダはしばしば、認可状の最終的な配達先として扱われる。成熟したリースでは、彼らはより早期に参加すべきである。

有効化前に、意図された上流プロバイダは、受け入れる正確なプレフィックスと起点 ASN、要求する証拠、最小経路サイズ、詳細経路の取り扱い、フィルタを IRR または RPKI データのどちらから構築するか、フィルタの更新速度を確認すべきである。この確認は、ROA スケジュールの隣に位置づけられるべきである。なぜなら、技術的に正しい認可は、上流の顧客フィルタが依然として経路を拒否する場合、運用上の価値がほとんどないからである。

上流プロバイダは、独立してその顧客を認証すべきである。有効な ROA は、証明チェーンがあるプレフィックスに対し起点 ASN を認可していることを示し得る。しかしそれは、トランジットチケットを開く人物がその ASN を管理していることや、貸主が商業アカウントを承認したことを証明しない。認可状は当事者を接続し得るが、書状は転送が容易で、グローバルに失効させることは困難である。アカウント記録、検証済みの連絡先、貸主からの直接確認が証拠をより強固にする。

リース期間中、上流プロバイダは単に新しい ROA が現れたからといって起点変更を受け入れるべきではない。その変更は偶発的、悪意ある、または別のプロバイダ向けであるかもしれない。また、新たな無効状態を無視すべきでもない。既知のチャネルを通じて借主と貸主に連絡し、経路を合意されたプレフィックスリストと比較し、経路か認可のどちらが誤っているかを判断すべきである。

終了時には、上流プロバイダは失効を実現する決定的な役割を担う。貸主は ROA を削除できるが、元借主は依然として BGP 広報を送信し得る。上流プロバイダは、顧客のプレフィックス許可を外し、直接の境界で経路を拒否できる。そのローカルな行動は、すべてのネットワークが更新された検証データを適用するのを待つよりも、しばしば迅速かつ確実である。

この分業は健全である。RPKI はグローバルに検証可能な起点認可を提供する。上流プロバイダは、発信源に最も近い顧客関係を強制する。リースはその二つを接続する。いずれか一つに全負担を負わせるべきではない。

リースされたプレフィックスをサポートする上流プロバイダは、その証拠要件と緊急連絡先を公開できる。予測可能性は安全なリースを容易にする。秘密主義で一貫性のないレビューは、オペレーターを直前のチケットや非公式な例外へと駆り立て、それはセキュリティと説明責任の両方を弱める。

紛争は顧客トラフィックから隔離される必要がある

最も困難な条項は、プレフィックスが依然としてライブサービスを運んでいる間に、貸主と借主が金銭、契約違反、不正行為、更新について意見が一致しない場合に何が起こるかである。

貸主は、継続期間が不払いを助長したり、害を許容したりすることを恐れるかもしれない。借主は、貸主が ROA 削除を遠隔のキルスイッチとして使うことを恐れるかもしれない。双方の懸念は正当である。答えは恒久的な認可ではあり得ないが、無告知の暗号的奇襲でもあるべきではない。

まず、事象を区別することから始める。予定された期限切れと通常の非更新は、完全な脱退計画に従うべきである。係争中の請求書は、合意が支払いを即時かつ決定的にしない限り、通知と短い治癒期間のトリガーとなるべきである。現実の不正行為の信頼できる証拠は、より厳格な制御を正当化し得るが、ROA を削除しても必ずしも不正経路は止まらない。直接の上流プロバイダと借主の機器が、より直接的な介入点であり続ける。署名鍵の侵害は、商業関係が健全であっても、セキュリティ上の行動を必要とする。

善意の紛争中は、裁量的な拡大を凍結する。借主は、顧客の追加、新たな起点の要求、最大長の拡大をすべきではない。貸主は、限られた継続期間の間、既知の最後の安全な認可を保存すべきである。両当事者は、トラフィックを保護するために必要な文書化された緊急事態を除き、いかなる変更も二者確認なしには有効でないことを上流プロバイダに通知すべきである。

独立したエスカレーション窓口は、訴訟全体を決定することなく、要求が既存のスケジュールに適合するかどうかを判断できる。問いは狭い。すなわち、要求された行動が既に認可されたサービスを維持するものか、それとも権利を拡大するものか？この限定的な判断は、商業的請求が別の場で進行する間、ルーティングを安定に保つことができる。

契約はまた、ハードストップを定義すべきである。継続が無期限の占有になってはならない。治癒または移行期間の終了時に、借主は経路を撤回し、上流プロバイダはフィルタを除去し、貸主は ROA を除去しなければならない。いずれかの側の失敗は、特定された証拠と救済策を生む。もし顧客の安全が裁判所命令や緊急救済を必要とするとしても、当事者はどの行為が差し止められなければならないかを把握している。

ここでログが最も重要になる。不当な削除を主張する当事者は、合意された認可、要求、受領確認、変更時刻、検証への影響を示すことができるべきである。撤回期限後も継続的な利用を主張する貸主は、経路観測を示せるべきである。紛争の隔離は、どちらかの側の受信箱を信頼せずに事実を再構築できる場合にのみ機能する。

統治の規範は単純である。私的債務の執行手段として無関係なインターネット利用者を使わないこと、そして、リースを永続的にするために彼らの依存を利用しないこと。

失効は必要だが、削除だけでは完全な救済策にはならない

リースは、元借主が貸主の認可に依存できない状態で終了しなければならない。それには適切な層での失効または除去が必要である。しかし、失効だけでは不十分である。

認可終了時間が到来したら、貸主は該当する ROA 設定を削除または修正すべきである。委任方式の場合、継続的な認可が必要ないことを確認した後、限定された下位証明書を失効させることができる。両当事者は、生成された検証済みペイロードを、複数の独立した視点から観測すべきである。ポータルの成功メッセージは、提出された行為の証拠ではあるが、公開状態が収束したことの証明ではない。

同時に、借主は BGP 経路を撤回し、その上流プロバイダは顧客許可を外さなければならない。依然として旧起点を指している IRR ルートオブジェクトは、削除または更新されるべきである。逆引き DNS と公開連絡先は、それが運用上または迷惑行為の報告を誤った方向に導く場合、もはや以前のオペレーターを指すべきではない。これらのシステムは異なるリフレッシュ時間と管理者を持つため、単一のタイムスタンプで完全な退出を証明することはできない。

削除には副次的な影響もあり得る。一つの ROA が複数のプレフィックスをカバーするかもしれず、委任証明書は、貸主がそれを下手に設計した場合、一つのリースを超えるリソースを含むかもしれない。オペレーターは、変更すべき正確なオブジェクトまたは認可を特定しなければならない。「顧客の RPKI を失効させる」は、認証境界が顧客境界と一致している場合を除いて、安全な指示ではない。

残余リスクは双方向に走る。もし ROA が残れば、元借主は広報を続ける場合に検証上の優位を保持する。もし ROA が、放置された経路が残っている間に消えれば、経路は無効になり、不均一に拒否されて、普遍的な沈黙ではなく部分的な到達可能性を生み出すかもしれない。もしカバーする ROA が残らなければ、経路は Not Found となり、多くのポリシーの下で伝搬し続けるかもしれない。したがって、RPKI 状態は、発信源での撤回に代わる信頼できる代替策ではない。

完了記録は、次のことを明記すべきである。旧起点によって経路が撤回されたこと、上流フィルタが除去されたこと、旧 ROA が不在または置き換えられたこと、意図しないカバー認可が残っていないこと、該当する場合には委任証明書が閉じられたこと、IRR レコードが調整されたこと、そして定義された観測期間を通じて監視が継続されていること。例外は、「済み」と丸めるのではなく、名前を挙げるべきである。

失効は貸主と次の利用者を保護する。調整された撤回は現在の顧客を保護する。責任ある退出はその両方を行う。

RIR は認証の権威を認証すべきであり、リースを決定すべきではない

RIR は微妙な立場にある。なぜなら、ホステッドサービスは彼らを、係争中の変更が実行される場とし得るからだ。だからといって、彼らがあらゆる IPv4 リースの裁定者になるべきではない。

RIR には、認証サービスを利用する資格のある組織を認証し、アカウントを保護し、階層を維持し、証明されたクレデンシャルの侵害に対応するという正当な利害がある。移転、返却、登録変更の後で、認証リソースを変更する必要が生じるかもしれない。RIPE NCC のホステッド文書は、リソース証明書はリソースの移動に伴って更新され、リソースが削除されると公開された ROA が調整されることを指摘している。これらは認証階層の帰結である。

私的リースの紛争は別物である。RIR は通常、どちらの当事者が契約違反かを判断するのに必要な契約書、支払い履歴、顧客移行の事実、そして準拠法の証拠を欠いている。もし未確認の借主からの指示を受け入れたならば、保持者の権威を排除するかもしれない。もし裁判所命令や証明されたアカウント侵害にもかかわらず、あらゆる保持者の指示を決定的と扱うならば、被害を増幅させかねない。答えは、明確なプロセスを伴う狭い役割である。

RIR はログを保存し、アカウント主体を認証し、サービスの状態を公開し、セキュリティインシデントに対して文書化された緊急チャネルを提供し、有効な法的命令に従うことができる。保持者が幅広いクレデンシャルを共有する必要がないように、アカウントの役割を細かくできる。ホステッドと委任の選択が持つ技術的な効果を説明できる。曖昧なリースポリシーを稼働中の経路に対する裁量的な制御に変換することには慎重であるべきである。

この抑制は、ROA の限定的な意味と整合する。認証サービスは番号資源階層内の権威を検証する。その権威を行使するあらゆる私的理由を認証するわけではない。商業上の義務は、当事者間で、そして必要な場合には裁判所または合意された紛争解決メカニズムを通じて執行可能なままである。

登録層は、新しい財産カテゴリを認知することなく、リースを改善できる。限定ユーザー、機械可読な変更履歴、複数の連絡先への通知、安全な場合の遅延された破壊的行為、および現在と過去の設定のエクスポート可能な証拠をサポートできる。これらのツールは、法的合意を CA の外に残したまま、一人のアカウント保持者への依存を低減する。

ポリシーの目標は、各リースの道徳的承認ではなく、予測可能な実行であるべきである。安全なシステムは、技術的に署名する権利のある人物と、契約上要求する権利のある人物を、常に同一人物であると見なすことなく区別できる。

制御には経済的対価がある

ROA 制御は、しばしばそれが無料の事務作業であるかのようにリース価格に含まれている。それは別個の継続性サービスである。

迅速な変更を約束する貸主は、訓練されたスタッフ、保護されたクレデンシャル、監視、バックアップ承認者、インシデントカバレッジを維持しなければならない。委任モデルは CA の運用と公開の信頼性を要求する。頻繁な起点変更を必要とする借主は、一つの安定した ASN を持つ借主よりも多くのコストを課し、より多くのエラーの機会を生み出す。価格設定はこれらの違いを見えるようにすべきである。

代替案は誤った経済である。緊急 ROA 変更に5日間の応答がある低価格リースは、厳格な可用性コミットメントを持つネットワークでは使い物にならないかもしれない。借主はその後、非公式にクレデンシャルを共有したり、上流プロバイダに例外を求めたり、将来の遅延を避けるために過剰に広範な認可を維持するかもしれない。各ショートカットは、価格付けされていないサービス要件をセキュリティリスクに変換する。

ネットワークアイデンティティのより広範な経済学が、この点を鮮明にする。Lu Heng のネットワークアイデンティティと顧客継続性に関する考察は、アドレスが顧客のホワイトリスト、パートナーのルール、API、コンプライアンスシステムに埋め込まれ得ると論じている。いったんそうなれば、失敗した ROA 変更は単なるルーティングの不便ではない。それは、外部当事者が既に信頼しているビジネスアイデンティティを中断させかねない。

彼のマネージド IPv4 リースとレジストリリスクに関する議論は、関連する市場の論点を提起している。アドレスを取得することは目に見える取引に過ぎず、継続的な運用可能性は登録、ルーティング、ライフサイクルリスクがどのように担われるかに依存する。中立な分析は、その議論のすべての制度的結論を受け入れる必要はなく、運用上の事実を認識すればよい。継続性を販売する当事者は、継続性が要求する行為を説明し、価格付けすべきである。

これはサービスの段階を生み出し得る。基本リースは、一つの安定した起点と営業時間内の変更を許可するかもしれない。回復力のあるリースは、二つの起点、事前承認された軽減策、24時間対応、定期的な照合を含むかもしれない。自身の有能な CA を持つ借主は、限定委任を選択し、より多くの義務を受け入れるかもしれない。透明な段階は、すべてのリースが即時の無制限な RPKI 管理を含むと見せかけるよりも優れている。

制御は救済策にも影響すべきである。もし貸主が緊急カバレッジに対して料金を請求しながらそれを提供できなかった場合、結果は意味のあるものでなければならない。もし借主がより遅い段階を選択しながら後で即時の行動を要求した場合、貸主は売らなかったものを約束したとみなされるべきではない。

暗号的依存関係が「サポート」の中に隠されるのではなく、製品の一部として名指しされるとき、市場はより安全になる。

権利の実践的な配分

普遍的な取り決めは存在しないが、防御可能なデフォルトは明確に述べることができる。

貸主は、リソース証明関係の最終的な制御を保持し、リース範囲外の変更を拒否できる。少なくとも二名の認可されたオペレーターを維持し、クレデンシャルを保護し、有効化前に初期 ROA を作成し、定義された通常および緊急の変更時間を満たし、真のセキュリティ緊急事態を除いて破壊的行為の前に通知し、検証された退出後に認可を削除しなければならない。

借主は、スケジュールの範囲内でネットワーク設計を制御する。各起点 ASN を特定し、その制御を証明し、正確な経路計画を提供し、二名の認証された要求者を維持し、計画された変更前に貸主に通知し、認可外の広報を避け、RPKI 状態を監視し、終了時に速やかに撤回し、上流の閉鎖の証拠を保持しなければならない。

上流プロバイダは、独立して顧客とプレフィックスの関係を検証し、有効化前にフィルタを準備し、不一致を監視し、直接の緊急連絡先をサポートし、確認待ちの未予定の起点変更を拒否し、退出時に許可を除去する。顧客権限の唯一の証明として ROA に依拠しない。

RIR または上位 CA は、リソース保持者を認証し、選択された認証モデルを運用または支援し、上位階層を保護し、信頼できる公開と変更記録を提供し、証明されたクレデンシャルまたは法的イベントを透明な権限内で処理する。BGP から私的リースを推測したり、通常の請求書を裁定したりしない。

変更頻度の高い、または依存度の高いリースでは、限定された下位 CA が実行を借主に近づけることができる。低変更リースでは、厳格な応答コミットメントを伴うホステッドサービスがより安全かもしれない。非常に短期間では、RPKI と上流移行のコストが、長い通知期間または異なるアドレス設計を正当化し得る。選択は、理念ではなく、運用上の依存関係に従うべきである。

すべてのモデルが同じガードレールを必要とする。すなわち、正確な範囲、最小限の権限、冗長な連絡先、測定された応答、可視の状態、安全な重なり、厳格な終了、そして独立した証拠である。一つを取り除けば、制御は何かが間違ったときにたまたまクレデンシャルを所持している者に移る。

テストは、権限が責任に従っているかどうかである

IPv4 リースが持続可能であるのは、サービスに責任を負う当事者が必要な認可を取得でき、一方でリソースに責任を負う当事者が無許可の拡大を防ぎ、最終的な失効を保証できる場合である。

このバランスは、一文中で ROA を一人の主体に割り当てることでは達成されない。それは商業的許可を運用上のイベントに接続することによって達成される。貸主の証明書権限は、日常的なネットワーク変更に対する価格付けされていない拒否権になってはならない。借主の速度への要求は、集合に対する恒久的な署名権限になってはならない。上流プロバイダは、顧客検証を暗号オブジェクトに外注してはならない。RIR は、見ることのできない契約を決定する立場に押し込まれてはならない。

技術は既に関連する区別を露わにしている。ROA はプレフィックス、起点、任意の最大長を指名する。ホステッドサービスは署名業務を集中させる。委任サービスは鍵の制御とメンテナンスを移動させる。依存当事者は公開された資料を取得し検証する。ルーターはローカルポリシーを適用する。ガバナンスのタスクは、リースを同様に精密にすることである。

最も安全なリースは、トラフィックがそれに依存する前に認可を作成し、認可を文書化された経路と整合させ続け、狭い緊急適応を許可し、紛争を顧客から隔離し、終了時には経路とその暗号的許可の両方を撤回する。それは、誰が、いつ、各行為を行ったかを記録する。

したがって、「ROA を誰が制御するのか」に対する最終的な答えは、意図的に複数である。貸主は認証された権限を制御する。借主は運用上の要求を制御する。上流プロバイダは直接の受け入れを制御する。RIR はその権限内で親またはホステッドサービスを制御する。契約は、これらの力がどのように出会うかを制御する。

契約が沈黙していれば、クレデンシャル保持者が危機を制御する。契約が精密であれば、いかなる主体も、自らが負うことに同意した責任以上のものを制御することはない。

情報源