要約

  • ARINの現行説明は、OnlineまたはXMLで作成したsimpleオブジェクトと、RPSLで作成したかIRR-emailから移行したadvancedオブジェクトを分け、作成経路ごとに管理権限を割り当てる。
  • 移行済みオブジェクトはARIN Onlineで閲覧・削除できる一方、編集はRPSL RESTに限られる。Onlineで削除して再作成すれば、訂正が別クラスへの変換になる。
  • Online作成オブジェクトにRPSL RESTを使えるかについて、現在公開中の概要表と実装ノートは一致しない。認証済みの実オブジェクトを試していない以上、どちらを本番の事実とも断定できない。
  • 変換前後の正規ハッシュ、クラス、権限表の版、権限の種類、チャネル、結果、後継リンクだけを残す細いレシートなら、資格情報や不要な個人情報を公開せずに連続性を証明できる。

修正する代わりに「生まれ直す」操作

ARINのユーザーガイドには、通常の編集画面ではあまり見ない組み合わせが載っている。旧IRR-emailから移行されたオブジェクトはARIN Onlineに表示される。削除もできる。しかし編集はできず、変更にはRESTを使う。実装ノートは、Onlineで管理したければ削除して再作成するよう説明する。ARIN IRRユーザーガイド

人間の目的は一つの誤りを直すことかもしれない。システムが受け取るのは、既存状態を消す操作と、新しい状態を登録する操作である。再入力したRPSLの見た目が同じでも、後者はOnlineから作成されたオブジェクトになる。旧記録が持っていた移行由来の管理クラスは、そのままでは引き継がれない。

ここから事故を推測してはならない。調査ではARINのアカウント、APIキー、実在するIRRオブジェクトを操作していない。NRTMの流れもBGPも測定していない。削除後の再作成が失敗した例、フィルターから消えた例、到達性が変わった例は確認されていない。

確認できるのは、ARIN自身が公開する制御の形である。どの経路で作られたかが、後からどの経路で修正できるかを左右する。この設計は古さの名残だけではない。異なる表現を無理に同じ編集画面へ通さず、意味を守るための境界になり得る。

RPSLの属性をWebフォームが完全に往復できないなら、部分的な編集を許す方が危険である。利用者が見ていない属性を正規化したり削ったりするより、編集不能と明示する方が誠実だ。問題は編集ボタンの有無ではなく、チャネルを変えるための破壊的な操作に、前後を結ぶ証拠があるかどうかである。

simpleとadvancedは信頼度ではない

ARINの現行IRR概要は管理対象をsimpleとadvancedに分ける。simpleはARIN OnlineまたはXMLを使うRESTで作成され、両方で作成・閲覧・編集・削除ができる。概要表ではRPSL RESTの権限はない。advancedはRPSL RESTで作成されたもの、またはIRR-emailから移行したものだ。RPSL RESTでは四つの操作が可能、XML RESTは不可、Onlineでは閲覧と削除だけが可能とされる。ARIN IRR概要

この語を価値判断として読むと誤る。advancedだから実際の経路に近いわけではない。simpleだから単純なポリシーしか書けないとも限らない。分類しているのは、作成元、検証表現、管理面である。

ARINは、検索結果の形式はどちらもRPSLだと説明する。公開されたオブジェクトを読む者には合理的な扱いである。消費者はroute、route6、aut-num、as-set、route-setの内容を知る必要があるが、管理者のAPIキーや入力画面を受け取る必要はない。一方、変更を監査する側は、どの権限と検証器がその状態を作ったかを区別しなければならない。

RFC 2622はRPSLを、IRRでルーティングポリシーを記述する言語として定義する。構文とオブジェクトの関係を記録できるが、現在のBGPを観測する仕組みではない。正しく書かれたrouteオブジェクトは、プレフィックスがその通り広告され、あらゆるネットワークに受け入れられていることを保証しない。RFC 2622

したがって作成経路の情報は、レジストリ内の権限と来歴を証明するために使うべきである。経路の正当性や到達性を代わりに判定するラベルにしてはならない。

移行元を残すことには運用上の理由がある

実装ノートによると、旧メールサービスのレコードは一律に扱われなかった。ARINの資源と検証に結び付くものは権威側へ移され、その他はARIN-NONAUTHへ分けられた。移行オブジェクトは新しい仕組みの厳しい検証を通り、画面上の注記で識別できるという。ARIN IRR Online実装ノート

これは来歴を正直に残す設計である。新システムが古いオブジェクトを受理したからといって、「最初からWebで作られた」と書き換える必要はない。移行済みという情報は、なぜ同じ画面で権限が異なるのかを説明する手掛かりになる。

ARINはさらに、組織がWebまたはRESTの利用を始めると、その組織のIRR-email更新経路は永久に使えなくなると説明する。一方向の切り替えには利点がある。メールとAPIが同時に書き込みを続ければ、資格情報、検証規則、競合時の優先順位が二重になる。新経路を選んだ時点で旧経路を閉じれば、現行の権限面を一つにできる。

だから、すべてのチャネルを無条件に相互編集可能にするのが正解とは限らない。XML、Webフォーム、RPSLは同じ表現力や往復性を持つとは限らない。境界をなくす前に、すべての対応オブジェクトで意味が保たれることを示す必要がある。

しかし、一方向の移行は出口も設計しなければならない。利用者は削除前に正規化された旧状態を保存し、クラスと制限理由を理解し、候補となる新状態が受理可能か確認し、成功した後継を旧状態へ結び付けられるべきだ。来歴を守る分類が、ツール変更の瞬間に来歴を消すのは整合しない。

PUTで済む変更とDELETE/POSTの組は違う

ARINのIRR RESTガイドはGET、POST、PUT、DELETEを分けている。PUTはオブジェクトの変更、DELETEは削除である。対象はroute、route6、aut-num、as-set、route-setで、RPSLとXMLのペイロードはオブジェクト権限に従う。ARIN IRR REST API

一回の変更なら、同じ識別の下で正規ハッシュAからBへ移った、と記録できる。削除と作成は別々に失敗する。旧オブジェクトだけが消えた状態、新オブジェクトの検証が拒否された状態、受理されたがある観測経路にはまだ現れない状態が生じ得る。

これらは設計上の状態であって、観測された被害ではない。公開資料は移行オブジェクトの総数、再作成の頻度、処理時間、NRTMシリアルの例を示していない。空白期間の長さや、フィルター生成者がそれを取得したかを推定できない。

それでも、二つの操作を単なる「更新」と呼ぶべきでない理由は十分にある。再入力時にコメントや属性順が変わるかもしれない。新しい検証規則が修正を要求するかもしれない。同じオブジェクトキーを再利用すれば、公開上は連続して見えても管理クラスの変化が隠れる。別のキーなら後継関係そのものが分かりにくくなる。

サポートチケットや画面のスクリーンショットは当事者の助けになるが、将来の担当者や自動化された消費者が検証できる証拠ではない。変換を一つのイベントとして識別し、削除と再作成をその下へ結び付ける方がよい。

現行文書同士がRPSL権限で食い違う

概要表はsimpleオブジェクトにRPSL REST権限がないとする。一方、2025年1月17日までの更新履歴を掲げる実装ノートは、ARIN Onlineで作成したオブジェクトをRESTからRPSLまたはXMLで閲覧、更新、削除できると書く。

二つの説明には差がある。バージョン、オブジェクト型、アカウント条件の違いが省略されているのかもしれない。どちらかが現行実装に追随していない可能性もある。資料だけでは決められない。一つのアカウント、一つのrouteオブジェクトで成功しても、すべてのsimpleオブジェクトの契約にはならない。

2021年2月のARINブログは、REST導入時の制約と予定を理解する歴史資料として役立つ。現在はVaultに置かれ、内容が古い可能性をARIN自身が注意している。現在の権限表として使うことはできない。ARIN VaultのREST導入記事

必要なのは、クラス、オブジェクト型、操作、チャネル、エンコーディングを交差させた一つの版管理表である。発効日があれば、変更前の経験を現在へ誤って持ち込まずに済む。実行中のコードは個別の技術的現実であり、表は公開された対応範囲である。食い違う場合はリクエストと結果を保存し、文章のどちらかを推測で選ばない。

ARINが文書を統一するか、範囲を明示した認証テストが得られるまで、本稿は矛盾を矛盾のまま残す。RPSLが実際に使えるとも、必ず拒否されるとも主張しない。

連続性のレシートは個人台帳ではない

変換を追跡するために、従業員名やAPIキーを公表する必要はない。オブジェクト型と公開キー、変更前のクラスと作成由来、適用した権限表の版、正規化した旧状態のハッシュ、操作、認証主体の役割区分、チャネルとエンコーディング、検証結果、新クラスと新ハッシュ、削除と再作成の後継リンクで足りる。正確に得られるなら、公開観測またはNRTMシリアルも加えられる。

このレシートが証明するのはレジストリ操作である。すべてのミラーが同時に受け取ったこと、フィルター作成者が利用したこと、BGPがRPSL通りに動いたことは証明しない。限界を明記してこそ、証拠が別の権限へ膨張しない。

ARINのガイドは、IRRを管理できる役割としてAdmin、Tech、Routing POCを挙げ、Resource POCを除く。役割の権限とオブジェクトのチャネル制限は別である。正しい役割を持つ者でも、移行元のためOnline編集が使えない場合がある。監査では「誰が許可されたか」と「どの表現で操作できたか」を分けて残すべきだ。

資料が示しているのは被害ではなく、制度上の小さなねじれである。ARINは移行元を保ち、表現できない編集を止めることで意味を守ろうとしている。その同じ慎重さを、削除と再作成の間にも延ばせる。来歴を権限に使うなら、変換時にも来歴を接続しておくべきである。

情報源

  1. ARIN：Internet Routing Registry概要
  2. ARIN：IRRユーザーガイド
  3. ARIN：IRR Online実装ノート
  4. ARIN：IRR REST API
  5. ARIN Vault：IRR REST API導入の記録
  6. RFC 2622：Routing Policy Specification Language