要約

  • ARINの現行ROAガイドは任意のROA名を認めるが、ARIN Onlineの検索はプレフィックスまたはASNによるものと説明されている。
  • ACSP提案2024.14は名前検索を求めた。ARINは2024年8月に有用性を認め、RPKI改善項目として優先順位付けを待つと回答し、現在もOpenのままだ。
  • RPKI REST APIは作成時にも一覧取得時にも名前を扱うため、権限を持つ利用者は組織の全件を取得し、手元で絞り込める。
  • 名前は組織内の可変ラベルにとどめ、変更や削除は安定したROAハンドル、プレフィックス、ASNで対象を確定すべきだ。

入力できるラベルが、検索キーになるとは限らない

ROAのプレフィックス、最大長、Origin ASは、経路起源について何を認めるかを表す。名前は別の役割を持つ。顧客、移行作業、サービス、地域別プロジェクトなど、ネットワーク座標だけでは見えない社内のまとまりを人に思い出させるための印である。

ARINのRoute Origin Authorizationsガイドも、その違いを反映している。ROAの構成としてOrigin AS、プレフィックスと最大長に加え、任意のROA名を挙げる。ところが同じガイドでARIN Online上の検索を説明する箇所には、特定のプレフィックスまたはASNで探せるとあるだけで、名前は検索条件に現れない。

この継ぎ目をそのまま課題にしたのがACSP提案2024.14だ。2024年8月23日に提出され、組織に関連付けられたROAをプレフィックスやASNだけでなく名前でも検索したい、と求めた。目的として、顧客やプロジェクトに関係するROAをまとめて見つける場面が示されている。

ARINは8月28日の回答で、現在の検索選択肢を広げる有用な機能だと認めた。RPKI改善の一覧に加え、優先順位付けを待つとし、開発と展開が完了するまで提案をOpenにすると説明した。今回保存した提案個別ページと現行ACSP一覧はいずれも、2024.14を今なおOpenと表示している。

この記録から言える範囲は限られる。認証済みの全アカウントで、未文書化または新規展開された名前検索が絶対に存在しない、と証明するものではない。本稿ではARIN Onlineへログインせず、実在するROAの作成、検索、変更、削除も行っていない。また期限の記載がないため、遅延を断定することもできない。確認できるのは、名前を受け付ける公開仕様と、プレフィックスかASNだけを挙げる公開検索仕様の間に差が残っていることだ。

APIによる全件取得は、筋の通った反論である

ARIN側の最も強い説明は、RPKI REST APIの資料にある。作成ペイロードの例にはnameが入り、ROA Spec Payloadの応答にも名前が含まれる。組織ハンドルを指定する一覧操作で、その組織にひも付くROAを取得できる。権限を持つチームなら、全件を取得して自分のツールで名前をフィルターすればよい。

多くの場合、それで十分かもしれない。プレフィックスとASNは承認内容そのものであり、変更しやすいプロジェクト名より曖昧さが少ない。作業者にネットワーク座標を見直させること自体が安全策になる。すでにAPIで資産管理を自動化している組織にとって、ローカル検索は小さな実装で済む。

名前には秘匿性の問題もある。顧客名、社内計画、商業上の地域区分が入る可能性があり、組織をまたぐ索引や公開検索にはしてはならない。部分一致を認めれば、重複名、表記揺れ、大文字・小文字、Unicode正規化、改名前の名前をどう扱うかという判断も増える。プレフィックスとASNに限定する設計を、ただちに欠陥と呼ぶことはできない。

それでも、回避策は共通の製品契約ではない。公開されている一覧操作は組織単位の取得であり、サーバー側の名前フィルターは説明されていない。必要な組織はそれぞれ、スクリプト、表計算、運用メモの中に同じ検索規則を作ることになる。名前の保存方法はARINが統一していても、名前を索引として使う方法は利用者ごとに分散する。

影響を誇張する必要はない。今回の資料には、誤ったROAが選ばれた、障害が起きた、経路が乗っ取られた、顧客名が漏れたという事実はない。問題は変更前の選択である。一つの案件が複数プレフィックスやOrigin ASにまたがるなら、名前はそれらを業務上まとめるために存在する。名前で取り出せなければ、担当者は座標を記憶するか、全一覧を走査するか、別の対応表を維持する。関連する一件を落とす、似た別件を開くという余地が増える。これは管理上の摩擦であって、RPKI検証の破綻ではない。

管理画面で見えるものと、署名されたROAは別物だ

日常会話の「ROA」は、実際には複数の状態を一語にまとめてしまう。ARINで管理するレコード、RFC 6482が定める署名オブジェクト、RPKIリポジトリへの公開、バリデータが取得した状態、観測されたBGP経路、そして各ネットワークがその状態を用いて下す受け入れ判断である。

RFC 6482のRouteOriginAttestation構文には、version、asID、ipAddrBlocksがあり、説明用の管理名はない。ARINも、ROAが有効な状態かを確かめるにはRPKIバリデータとARINのリポジトリが必要だとしている。管理画面で「北米顧客移行」というレコードを見つけても、署名オブジェクトの公開、バリデータの観測、対応するBGP広告、受け入れネットワークの存在は証明できない。

この分離があるからこそ、検索改善を経路権限の変更にせず実施できる。名前は非公開、組織内、変更可能のままでよい。レコードを指すハンドルは安定させ、操作直前にはプレフィックスとASNを表示する。ラベルを便利にしても、ラベルに権限を与える必要はない。

必要なのは検索欄より、照合の契約だ

安全な名前検索は、まず認証済み組織の範囲内に閉じる。完全一致なのか、先頭一致なのか、部分一致なのかを決める。大文字・小文字、空白、ダイアクリティカルマーク、Unicodeをどう正規化するか、空名と重複名をどう返すか、改名後に旧名を監査履歴から探せるかも定義する。

結果には、名前だけでなく安定したROAハンドル、Origin AS、プレフィックス、最大長、状態を必ず含める。名前は候補を絞る索引、ハンドルは対象レコードを持続的に指す参照、プレフィックスとASNは承認内容の確認材料である。変更や削除を名前だけで確定してはならない。

ページングも単なる画面都合ではない。一ページ目の後で在庫が変われば、二ページ目で重複や欠落が起きる。検索時点のスナップショットと明示的なカーソルが要る。小さな検索レシートには、認証された組織範囲、機微な文字列そのものではなく正規化クエリのダイジェスト、照合方式、スナップショット時刻、件数、返した安定ハンドル、次ページカーソルを残せる。

レシートを公開する必要はない。顧客名も記録外へ出さない。重要な変更の後で「どの規則と在庫状態で、どの安定オブジェクトを提示したか」を再現できればよい。ACSP 2024.14が突きつけるのは、RPKIの安全性を作り直す課題ではなく、すでに存在する管理フィールドを入力から再発見まで完結させる課題である。

出典