要約

  • ARINはResource Tech POCを個別資源に関連付けられると説明する一方、Routing POCは組織のRPKI認証情報とIRRを担当すると定義している。
  • 2026年8月20日に提出されたACSP 2026.10は、Resource Tech POCが関連先の資源に限ってRPKI・IRRを管理できるよう求めるものだ。
  • 公開状態はConfirmedだけで、ARINの評価、実装方針、期限はない。提案者が述べた遅延を裏付ける件数や時間データも示されていない。
  • 採用を検討するなら、対象プレフィックス、操作種別、付与者、期限、失効、高リスク操作の承認、実行者と権限根拠のログを一体にする必要がある。

役割名より、どこに結び付くかが重要だ

ARINのデータベース解説は、技術連絡先を二つの階層に分けている。Organizational Tech POCはOrg IDを管理し、その配下の資源にも権限を持つ。Resource Tech POCは任意で、アドレスブロックやASNなどの資源に直接関連付けられる。後者は資源名や公開コメントを変更し、他の資源連絡先を設定できる。資源の種類によってはネームサーバーやDSレコードも扱う。

Routing POCは異なる書き方をされている。IRRとRPKIの認証情報について「組織」に対する責任を負う。個別のNETに付く役割ではない。Org IDの中に複数の事業部や運用チームがある場合、この違いが操作範囲の違いになる。

現在のRPKI手順も組織を入口とする。ウェブ画面では対象組織のManage RPKIを選ぶ。REST APIのROAトランザクションは/rest/rpki/ORGHANDLEに送信され、複数のROA作成・削除やASPA変更を一つの原子的処理にできる。IRRのAPI記述も、オブジェクトを維持するOrg IDと、その組織のAdmin、Tech、Routing POCを中心にしている。

これは単純な設計ミスではない。組織単位の境界は、一つの資源だけを担当する利用者が無関係なプレフィックスを変更するのを防ぐ。ただし日常運用が既に資源ごとに分担されていれば、中央のRouting POCを経由する手続きが残る。

ARINが確認したのは受領である

提案者のNathanael Jean-Francoisは、個別資源を担当するスタッフがROAを作成・削除する際に組織のRouting POCを介さなければならず、インシデント対応や新規サービスの準備が遅れることがあると説明した。これは提案理由であり、ARINの測定結果ではない。公開資料には遅延時間、対象組織数、具体的な経路障害はない。

ページには提出日、未指定のTimeframe、同日の更新、Confirmedという状態があるだけで、Tracking InformationにARINの回答はない。

ACSPの規程によれば、ARINスタッフは有効な提案を受け取ると直ちに受領を確認し、その後10営業日以内に評価する。実現不能として閉じる、BoardやAdvisory Councilへ送る、実装可能と判断する、あるいはコミュニティ協議にかけるという後続経路がある。したがって、Confirmedを「承認済み」と訳すのは誤りだ。

この状態から、利用者が新しい権限を得たとも、ARINが設計に同意したとも言えない。

組織権限の複製では、最小権限にならない

最も簡単な実装は、どこか一つの資源に付いたResource Tech POCへOrg ID全体のRouting POC権限を与えることだろう。しかし、それでは委任の範囲が資源より大きくなる。

資源との関連は、その担当者が特定のNETやASNを扱うことを示す。別のプレフィックス、別の事業部、組織全体のIRR Auto-Manager設定、無関係なASPAまで扱う根拠にはならない。新しい権限は、既存の関連情報を失わず実行可能な形にするべきだ。

具体的には、対象NET handleまたはプレフィックス、ROA・ASPA・IRRの対象クラス、作成・変更・削除の別、権限を与えたPOCと役割、有効開始と失効、緊急停止を記録する。大量削除や範囲拡張だけを二人承認にすることもできる。日常の小さな追加まで一律に重くする必要はない。

子プレフィックスへの権限が親ブロックへ広がらないこと、資源が別Org IDへ移れば旧権限が消えること、APIキーが発行元アカウント以上の権限を持たないことも不可欠だ。バッチ内に範囲外オブジェクトが一つあれば、部分適用せず全体を失敗させるべきである。

ARINのROA変更ログは、時刻、操作、WebかAPIかという出所、Origin AS、プレフィックス、max length、実行ユーザーを保存する。資源単位の委任では、さらに「どの有効な委任がこの操作を許可したか」を残す必要がある。誰が実行したかと、なぜ実行できたかは別の証拠だ。

言えないことを残しておく

現在の資料から、ARINの権限設計が経路障害を起こしたとは言えない。誤ったROAの修正が実際に遅れたとも、全Resource Tech POCに単独削除権限が必要だとも証明されていない。

公開POCの表示だけで現在の認証権限を判断することもできない。ARIN Onlineアカウントとのリンク、契約対象、RPKI適格性、資源証明書、組織内承認は残る。

確認できる新事実は限定されている。ARINは、資源に結び付く技術責任と組織に結び付くルーティングセキュリティ操作の間を問題にする提案を受領した。次に必要なのは、速度を口実に権限を広げず、中央管理を口実に現場の委任を無効化しない、日付付きの評価である。

出典