要約

  • Number Resource Societyは、ROAがプレフィックスと許可された起点ASNを結び、maxLengthによってより詳細な経路の許可範囲を設定できること、そして変更は統制された手順で行うべきだと説明している。
  • バリデーターのValid、Invalid、NotFoundは、その時点の観測結果である。申請者や承認者、意図した値、撤回の完了までは証明しない。
  • バージョン管理された承認・撤回台帳なら、人の決定をRIRでの公開、複数の検証観測、経路操作の確認に結び付けつつ、技術状態を意思の証明と取り違えずに済む。

Validという表示だけでは決定を再現できない

Number Resource SocietyのRPKI解説によれば、Resource Public Key Infrastructureはインターネット番号資源と正当な保有者を暗号学的に結び付ける。Route Origin Authorizationは、あるプレフィックスを起点として広告できるASを示す。任意のmaxLengthは、どこまで長いより詳細なプレフィックスを許可するかを決める。証明書と公開をRIRに委ねる方式も、保有者が認証局を運用する委任方式もある。

この仕組みは、観測した起点が公開済みの許可と一致するかを判定する。しかし、許可に至った意思決定を自動で再現はしない。現在の結果から、新しい起点ASNを誰が求めたか、maxLengthの拡大を誰が承認したか、変更時間帯がどう定められたか、緊急ロールバックが何を根拠にしたかは分からない。

NRSの監査記事は、ROAの有無、起点ASN、プレフィックス、適切なmaxLength、Valid・Invalid・NotFoundの状態を確認するよう勧める。ROAを作成、変更、削除できる人物の確認も対象だ。maxLengthが広すぎれば不要なより詳細経路まで許可し、狭すぎれば正当な広告がInvalidになり得る。

ここまでは凍結した一次資料に基づく事実である。以下の台帳はそこから導く編集上の提案であり、NRSがすでに採用しているとも、現行ROAに不備があるとも主張しない。

承認する対象を一つの版として固定する

統制単位は最終表示ではなく変更そのものだ。安定した変更IDを付け、変更前後のプレフィックス、起点ASN、maxLengthを記録する。資源保有者、申請者、承認者、承認時刻、予定時間帯、理由も必要になる。緊急手順で通常の承認を短縮するなら、用いた規則と責任者を明示する。

権限と作業も分ける。申請者に承認権限があるとは限らない。承認者がRIRの画面を操作するとも限らず、BGPを切り替える担当者がROAを編集できるとも限らない。役割を一人の「実施者」にまとめると、正しい最終状態であっても監査しにくい。

許可しない範囲も重要だ。一つのプレフィックスの変更を別の資源まで広げない。起点ASNの変更許可をmaxLength拡大の許可に読み替えない。移行用の一時権限を、旧経路の撤去後も残さない。

承認対象をハッシュ化すれば、人が見た値と実際に提出された値を照合できる。ハッシュは判断の妥当性や法的効力を証明しない。あくまで、観測されたオブジェクトが承認版と同じかを確かめる証拠である。

公開、検証、経路切替は別々の観測だ

承認後は、公開操作と、観測時刻付きの権威あるRIR記録を残す。NRSの監査記事も、日付入りのRIR記録を証拠として保存するよう勧めている。これは「画面が緑だった」という記憶より強いが、観測した事実であって承認理由ではない。

独立バリデーターの結果も、時刻、観測地点、ソフトウェアまたはサービスごとに分けて保存する。リポジトリ、キャッシュ、更新周期の差によって、一時的に見え方がずれることがある。ずれは調査すべき証拠だが、直ちに公開失敗や担当者の誤りを意味しない。

状態は、申請済み、承認済み、提出済み、公開観測済み、検証観測済み、経路有効化済み、撤回申請済み、撤回観測済み、ロールバック済み、後継版あり、と分けられる。各遷移に行為者または観測者と時刻を持たせる。

NotFoundは、バリデーターの視点で経路を覆うROAが見つからなかったことを示すだけだ。意図的な不在、反映遅延、誤り、対象外のいずれかまでは分からない。Validも同様に、ある視点で一致したことは示すが、変更を始めた人の業務上の権限が現在も有効だとは示さない。

移行前に撤回の順序を決める

NRSは移行時、新しい許可を設定して検証した後に、旧経路を撤回するか旧ROAを削除するのが通常だとしている。台帳はこの順序を検証可能な証拠に変える。

実行前に、新しいROAをどの観測点で確認し、どの経路検査を通過させるかを前提条件にする。その上で、新しい起点を有効化する人、旧経路を撤回する人、旧ROAを削除または縮小する人、各工程を確認する人を割り当てる。

撤回は履歴の削除ではない。旧承認は保持し、終了理由をイベントとして記録し、後継版またはロールバックに結び付ける。後で戻した場合も、当初の公開がその時点では承認済みだったこと、何が戻す契機になったか、どの状態を復元したかを説明できる。

ロールバックは窓を開く前に設計する。予期しないInvalid、合意時間を超えた未反映、到達性の喪失、承認値と観測値の不一致、責任者を確認できない状態などを測定可能な契機にする。RPKI公開とBGP撤回は異なる時間軸で進むため、「元に戻す」だけでは手順にならない。

不明なことを事実に変えない

二つのNRS資料が支えるのは、ROA、maxLength、検証状態、統制変更、監査項目、移行順序である。特定の運用者の不備、侵害されたアカウント、係争中の経路、失敗したRIR手続きは示していない。

台帳項目はガバナンス上の推論だ。承認、公開、検証、撤回を結べば再現性が上がるとは考えられるが、公開記事に内部統制の説明がないからといって、NRSや特定組織に統制がないとは言えない。

具体的な変更では、実際の権限者、利用した基盤、各バリデーターの更新時間、経路操作の到達範囲、法的・契約上の効果が不明な場合もある。台帳は推測で埋めず、不明のまま記録する。暗号学的な許可に、人が説明できる変更履歴と安全な終了手続きを伴わせることが目的だ。

情報源