要約

  • ARINは2023年10月、ROAが削除された際にAdmin、Tech、Routingの各POCへ通知する機能を追加した。2024年6月には、一組織に許されるROA削除数の上限を2万件から4万件へ引き上げた。
  • ACSP 2025.6は、一括削除API呼び出しでメールを全て抑止する選択肢を求める。ACSP 2026.6は、削除では全POCに通知する一方、作成・変更では通知しないと指摘する。
  • メールの氾濫を減らす必要はある。しかし作成、変更、削除のいずれも、経路起点を判断するための権限集合を変え得る。操作名だけで重要度は決まらない。
  • 最小限の共通統制は、完了した一つのトランザクションにつき一つの永続的な変更要約を残すことだ。権限を行使した主体、前後の差分、原子的な結果、公開の観測、独立した通知先を結び付ける。

「メールを止めたい」は責任逃れではない

大規模なアドレス管理者にとって、同じ保守作業から大量のメールが届くことは、情報量の増加を意味しない。ACSP 2025.6はこの点から始まった。

2025年7月11日に提出された提案は、POCの人数が多い組織では、一括ROA削除の前に関係者へ大量メールの到着を予告しなければならず、ARINのメールサーバーと受信箱の双方を消費すると説明した。求めたのは削除APIの任意フラグである。通常はfalseのままとし、選択した呼び出しではメール生成を全て抑えるという内容だった。

ARINは7月23日、有益な機能だと認め、開発日程で優先すると答えた。今回保存した公式ページの状態はOpenで、実装待ちである。したがって、要望が正当な検討対象になったことは確認できるが、機能が提供済みだとは書けない。

この提案の強みは明快だ。数千件のROAを一つの保守目的で削除する場合、数千通のメールは数千件の独立した判断ではない。さらにPOCごとに複製すれば、受信者はフィルターを設定し、本文を読まず、予定されたノイズとして処理する。形式上は全て通知されていても、異常を見抜く力は弱くなる。

メール量を正当化することは、通知を正当化することと同じではない。重要なのは、実行者とは別に変更を観測できることだ。

削除通知には守るべき理由がある

ARINが削除を特別扱いしたことにも、最善の説明がある。2023年10月9日のリリース記録によると、ARIN OnlineはROAが削除されるたびにAdmin、Tech、Routingの各POCへ通知するようになった。

ROAは、あるプレフィックスを特定のASが起点として広告することを資源保有者が認める署名付きオブジェクトである。RFC 8211は、ROAが公開点から削除されると、そのプレフィックスとASの結び付きが無効になると説明する。他に対象ROAがなければ、以前は裏付けのあった経路がNotFoundになり得る。別のASを認めるROAだけが残れば、Invalidになり得る。

ここから障害を断定してはならない。残るROAとの関係によって、広告はValidのままの場合も、InvalidまたはNotFoundへ移る場合もある。リポジトリの取得時刻は一様ではなく、Invalidをどう扱うかもネットワークごとの判断である。それでも、削除操作を実行したアカウントの画面だけに記録を閉じ込めない理由にはなる。自動化を動かす利用者、組織の責任を持つAdmin POC、実際に経路を監視するRouting POCは別々かもしれない。

独立した目があることは有用だ。ただし、独立した目に同じ内容を何万回も見せる必要はない。

ARINは2024年6月3日、一組織に許容するROA削除数を2万件から4万件へ増やした。この数字は事故件数でも、4万件を一度に消した実例でもない。製品が大きな変更集合を扱うことを予定している事実である。オブジェクト数とPOC数を掛け合わせる通知方式では、リスクではなく規模だけがメッセージ量を決めてしまう。

作成は常に安全側の操作ではない

2026年4月23日のACSP 2026.6は、通知範囲の別の穴を示した。提案文によれば、ROA削除時には全POCへARIN内通知とメールが届くが、作成または変更では届かない。提案は三つの操作ごとの任意フラグ、あるいはアカウント単位の既定値を求めた。

ARINは4月27日、この改善を他のROA通知案件とまとめ、内部の優先順位付けと実装計画へ送り、提案を閉じた。ClosedはACSP上の処理が終わったという意味であり、ソフトウェアが稼働した証明ではない。

作成と変更を含めるべき理由は、単なる公平さではない。経路起点検証では、新しい包含ROAが加わると、異なるASからの広告やmaxLengthを超える広告がNotFoundからInvalidへ変わる場合がある。変更によって許可するAS、対象プレフィックス、最大長が変われば、既存の広告との比較結果も変わる。

つまり、データベース上の追加は、経路上の権限をただ増やすだけとは限らない。削除だけを危険な動詞と見なす境界は粗すぎる。見るべきものは、トランザクション前後で有効な「プレフィックス、起点AS、maxLength」の集合がどう変わったかである。

APIは既に正しい単位を持っている

ARINのRPKI RESTful APIガイドは、ROAの作成・変更・削除を一つの組織単位の呼び出しとして記述している。ASPAの作成・変更・削除も同じトランザクションに組み込め、全体が成功するか、全体が失敗する。payloadには削除対象のリストと追加対象のリストがある。

この原子性は強い保護である。置き換えの途中で旧ROAだけが消えるような半端な結果を避けられる。同時に、通知に必要な文脈も提供する。ARIN側は、複数のオブジェクトが一つの意図として提出され、どの結果に終わったかを知っている。

それを一件ずつのイベントへ再分解すれば、通知数は増えても意味は薄くなる。変更が技術的に削除と追加で表現される場合でも、利用者が確認したのは一つの置き換えである。通知はそのまとまりを保つべきだ。

Change Logは強い土台である

ARINには事後確認の仕組みがある。2025年9月に追加されたROA Change Logは、現在の説明では過去365日を対象とする。時刻、AddedまたはRemoved、Web User・API User・ARIN Systemという発生源、Origin AS、プレフィックス、maxLength、変更したARIN Online利用者の氏名が表示される。100件を超えるとページ分割され、完全なCSVはチケットで依頼し、後で取得する。

これは軽視できない監査記録である。確認した資料には、ログが不正確、利用者が改ざん可能、または権限ある利用者から見えないという証拠はない。新しい提案は、まず既存の記録が何をできるかを認めなければならない。

一方、ログと通知は異なる故障を扱う。ログは調査する人がログインして見に行く場所だ。通知は、別管理の人やシステムへ「今、調査すべきだ」と伝える。変更を行ったアカウント自体が問題なら、後者の独立性が効く。大量の個別メールでは、その独立性は残っても、一つの変更として理解しにくい。

必要なのは、ログの精度と通知の独立性を一つの要約でつなぐことだ。

一トランザクションに一つの権限変更要約

確定したトランザクションごとに、次のような永続記録を一つ作ればよい。

記録項目 確認できること
トランザクションIDと完了時刻 どの要求がいつ確定したか
組織と保護された実行主体区分 個人情報を公開せず、どの権限で実行したか
操作の組み合わせ 作成、置換、削除、ROA・ASPA連携のどれか
前後の権限差分 prefix、origin AS、maxLengthの何が変わったか
原子的結果 全件成功、失敗、未確定のどれか
公開観測 リポジトリで新状態を確認したか、確認待ちか
独立通知先と配送結果 実行者以外のどのチャネルが受け取ったか
訂正への参照 どの後続操作が取り消し、または置き換えたか

実行者の氏名や内部の連絡先一覧を公開する必要はない。ROAの権限内容が公開情報であることと、組織内の監査情報を公開することは別である。限定した要約を組織内の独立した経路セキュリティ窓口へ送れば足りる。

その周囲では自由に選択できる。オブジェクトごとの詳細、トランザクションごとのメール、ARIN Onlineの通知、webhook、低リスク操作の日次まとめなどが考えられる。緊急修正を全POCの承認待ちにしてはならない。通知は許可ではなく、受領確認も拒否権ではない。

守るべき最小条件は、利便性のためのsuppressが、永続記録と全ての独立信号を同時に消せないことだ。

資料が示していないこと

引用資料には、4万件削除の事故、侵害されたアカウント、通知の配送失敗、特定経路の停止はない。2025.6は実装待ちであり、2026.6のクローズは提供開始を意味しない。Change Logの欠陥も立証されていない。Invalid経路を拒否するかどうかは各ネットワークの方針である。

確認できる範囲はもっと狭い。ARINには、変更意図を一まとまりとして扱う原子トランザクションと、実行主体や対象を記録する365日ログがある。それに対し、プッシュ通知は削除という一操作に寄り、公開提案は全通知と無通知の間で調整しようとしている。事故を待たずとも、オブジェクトからトランザクションへ境界を移す根拠はそろっている。

情報源