要約

  • Aftab SiddiquiはAPNICでROAの起源ASNを制限する提案を行い、Routing Security SIG議長として、サービス機能への要望を尋ねた調査の報告にも加わった。
  • 政策提案には版、合意、ガイドライン、実装状況の記録がある。調査はROA通知やAPIへの選好を記録したもので、製品公開を指示せず、経路安全性の向上も証明していない。

同じ現場の声でも、通る制度は違う

インターネットレジストリが運用者の困りごとを受け止める方法は一つではない。ポリシー提案は決められた手続きの中で議論され、改訂版や合意の有無が公開記録に残る。サービス調査は、ある機能を利用者がどう感じるかを把握する手段だ。製品担当者の判断材料にはなるが、調査そのものが開発を決めるわけではない。

Aftab SiddiquiのAPNICでの記録には、両方の経路が見える。2021年、彼はRoute Origin Authorization（ROA）の起源として利用できる自律システム番号（ASN）を制限する提案を行った。一方、Routing Security Special Interest Group（SIG）の議長として、ROA通知や管理APIに関する調査結果をまとめた記事の共著者にもなった。どちらもルーティング運用に関わるが、制度上の働きは異なる。

レジストリの記録とネットワーク上の経路状態を混同してはならない。APIは権限を持つ利用者がレコードを変更しやすくする。ROAは、あるプレフィックスをどの自律システムが起源として広告できるかを示す。その後に、レジストリがデータを公開し、バリデーターが取得し、各ネットワークが自らのルーティングポリシーに従って結果を使う必要がある。管理ツールを尋ねる調査は、その後段の動作を証明しない。

SIGの役割は意見を集めること、リリースを決めることではない

2020年のAPNIC 49会議報告によれば、当時すでに存在していたRouting Security/RPKI SIGで、議長選挙と名称・憲章の見直しが行われた。コミュニティの支持を経てRouting Security SIGへの改称が決まり、憲章が合意され、Siddiquiが議長に選出された。憲章は、運用上の課題とベストプラクティスを話し合う場としての役割を定める。また、RPKI、IRRd、RRDPなどAPNICのサービスについて運用者の意見を集め、ルーティング安全性に関係するポリシー提案の技術面を助言することも含まれる。

この役割によって、運用現場とAPNICのサービス担当者の間に実務的な接点ができる。運用者は作業上の摩擦を説明し、担当チームは改善策を検討できる。しかし、SIGに製品の優先順位を決めたり、リリースを約束したりする権限が与えられたわけではない。Siddiquiも2022年の議長候補者声明で、運用上の問題や付加機能、APNICが提供できる支援を話し合う橋渡しの役割を説明していた。新型コロナウイルス感染症の影響で勢いを失ったとも述べている。これは当時の本人の見解であり、参加状況を独立に測った結果ではない。

次の工程の担当者は、2022年にAPNICが公開した記事から分かる。想定される機能について、サービスチームがAPNIC 54で費用対効果を説明する予定だった。SIGは課題を議題にできるが、実現性の評価と採否はサービス担当側に残る。

調査の数字が示す範囲

Siddiqui、Di Ma、Afifa Abbasの共著記事は、2021年10月の公開セッション後に調査を行ったと説明している。ROA作成時にメール通知を送るべきかという問いには、52.4％が賛成、33.3％が任意設定を支持、9.5％が通知過多を懸念し、4.8％が追加議論を希望した。通知に賛成した回答者のうち、47.6％はWebhook、28.6％はメールで十分と回答し、23.8％は判断を保留した。MyAPNICまたはKrillなどのセルフホスト型RPKIを使ったROA管理APIについては、賛成66.7％、反対19％、どちらともいえない14.3％と公表された。

これらは回答者が示した選好の記録だ。APNICの記事は回答者数の分母も、回答方法も、ネットワーク別の内訳も示していない。したがって回答者が何人だったのか、APNIC会員や運用者全体、地域全体を代表しているのかは分からない。また、これはルーティングポリシーの投票ではない。質問はサービス機能についてで、さらなる議論を求める回答もあった。

それでも、調査の問いは運用上の手間を具体化している。ROA作成通知は技術連絡先に変更を知らせ、Webhookはその情報を運用者自身のシステムに流し、APIは手作業だった反復処理を自動化し得る。各機能が変えるのは作業の一部分だ。どれもROAが正しいか、ルーターが無効な経路を拒否するかを単独では決めない。

後から公開されたAPIも、調査との因果関係は証明しない

APNICは2024年10月、Registry APIの提供開始を発表した。委任情報の取得に加え、Whois、逆引きDNS、ROA、経路オブジェクトを管理でき、従来MyAPNIC上で手作業だった変更の一部を自動化する。APNICは会員からの要望に応えるものと説明した。2022年の年次報告には、公開テスト用の試作APIがあり、本番開発を2023年に始める予定だと記されている。

調査とAPIの重なりはある。どちらも、ROA管理を含むレジストリ機能へのAPIアクセスを扱う。ただし、ここで参照した公開記録は、2021年の調査がプロジェクトを始動させたとは述べていない。調査回答者がAPIの開発要望を出した会員だったとも、SIGが製品設計を決めたとも分からない。APIの提供開始は調査回答者の利用を示さず、経路漏えいやハイジャックの減少を測った結果でもない。

「ルーティング安全性」という言葉は複数の層をまとめてしまいやすい。レジストリは操作用の窓口を提供する。資源保有者がレコードを変更し、レジストリが署名データを公開する。バリデーターがデータを取り込み、各ネットワークが検証状態をどう扱うか決める。一つの層の証拠を、次の層が実際に動いた証拠として扱うことはできない。

ポリシー提案には別の証跡が残る

Siddiquiによるprop-138は比較対象になる。この提案は、APNICのROA管理システムが、プライベート、予約済み、未割り当てのASNを起源として入力できる点を問題視し、利用を制限するよう求めた。第2版ではrouteおよびroute6オブジェクトにも対応する制限を提案した。APNICの公開追跡ページには、2021年8月と9月の各版、9月16日のAPNIC 52公開ポリシー会議でガイドライン化に向けて合意したこと、12月の公表、そして現在の「Implemented」という状態が記録されている。

サービス調査より形式的な記録だ。提案内容、改訂版、合意日、実装状態が追える。それでも、問題となるオブジェクトを何件防げたのか、ルーティングリスクがどれだけ変わったのかは分からない。「実装済み」は工程の状態であって、効果測定ではない。

この比較は調査を軽視するものではない。二つの制度的な成果が違うことを示す。政策手続きは提案がコミュニティの決定段階に達したかを記録し、サービス調査は担当者が選好や未解決点を把握する材料になる。それぞれの結果を評価するには、ルールの状態、製品仕様と提供記録、そして下流の運用データという適切な証跡が要る。

Siddiquiについて公開記録から分かること

APNIC 34の2012年候補者資料は、Siddiquiをパキスタンのネットワーク運用担当者として紹介し、IPv6展開、インフラ安全性、IPv6 Task Force Pakistan、地域の運用者活動への関与を記している。2022年のAPNICページには、SIG議長としての本人の説明と、運用上の課題をAPNICの支援につなげたい意向が残る。これらの日付付き記録は、運用、政策討議、サービス意見の間にいたことを示すが、グループの方針を単独で作ったことやAPNICのリリースを決めたことまでは示さない。

結論も資料の範囲に合わせたい。Siddiquiは、政策記録で経過を追える提案を作成し、サービスへの選好を記録して担当チームに届ける場の運営にも携わった。前者には合意から実装までの履歴があり、後者は製品検討のためのシグナルを残した。その後のAPI公開は話題を現実のものにしたが、調査とリリースの因果関係や、ルーティング安全性への効果を証明してはいない。

出典