要約

  • ARINが2024年に採択したRPKI/BGP Intelligenceの設計は、ARIN OnlineではROA確定前に観測経路、検証状態、不整合の助言を示す一方、API利用者は同じ情報を第三者ツールで集めるとしている。
  • 現行のRPKI REST APIは、ROAの作成・変更・削除を一つのトランザクションで処理し、ASPAの変更とも原子的に組み合わせられる。APIは補助的な閲覧口ではなく、影響の大きい書き込み経路である。
  • 必要なのは観測結果による強制停止ではない。Webと同じ助言モデルを任意の機械可読プレフライトとして提供し、入力、観測源、時刻、有効期限、限界を残すことである。

人には警告、プログラムには別の道具

ROAの入力が終わり、まだ送信していない瞬間には独特の価値がある。プレフィックス、origin AS、maxLengthを現在見えているBGP経路と照合すれば、単純な入力ミスや想定外のInvalid化に気づける。警告は運用者の移行計画を読み取れないが、取り消し可能な段階で違和感を示すことはできる。

ARINはこの間隙を正しく捉えた。2024年1月の協議文書は、当時のARIN Onlineでは作成対象のROAそのものしか表示されず、グローバルな経路表への影響を予測するには第三者ツールが必要だったと説明する。提案された新しいダッシュボードは、ほぼリアルタイムの経路広告、現在のRPKI検証状態、BGPと既存ROAの不整合、解消案を、確定前に一つの画面へ集めるものだった。

しかし協議文書は、その機能をARIN Onlineの顧客向けとし、API利用者は同じ情報を第三者ツールから取得すると明記した。3月の採択結果もこの境界を維持したまま、NotFoundやInvalidの経路に対する簡易ROA作成、データ源一覧、更新頻度の開示を加えた。

権限が二種類あるわけではない。ARINの証明書で対象資源を管理できる認証済み主体だけが、WebでもAPIでもROAを発行できる。違うのは判断材料だ。画面を操作する人には、ARINが統合した変更前の確認が与えられる。APIで同じ権限を実行するシステムは、観測源の選択、鮮度の判定、比較ロジック、記録保存を別に構築しなければならない。

現在の仕様では、この差を小さなものとは呼べない。RPKI REST APIは複数ROAの作成、変更、削除を統一トランザクションで扱い、ASPAの操作と合わせて全成功または全失敗にできる。ARIN自身もReg-RWSを高頻度のプロビジョニング取引向けAPIと説明している。自動化は操作を速く、再現可能にする。その入口こそ、文章ではなく構造化された注意信号と相性がよい。

ここから事故を推定してはいけない。公開資料は、APIで作られたROAが障害を起こした事例を示していない。また、APIに一切の入力検査がないとも言えない。確認できるのは、計画中の経路影響情報が、採択済みの公的設計ではWebに統合され、APIには統合されていないという境界である。

Web先行は合理的でもある

ARIN側の最も強い説明から考えるべきだ。Hosted RPKI利用組織の多くはARIN Onlineを使う。表形式の画面なら、現在の経路、検証状態、修正候補を同じ場所で説明できる。新しいAPIスキーマを定義し、互換性と稼働率を長期に支えるより早く、多くの利用者に届く。ROAを自動化する組織は、RIPEstat、手元のvalidator、RouteViews、商用監視、独自BGPフィードのいずれかを既に持っている可能性も高い。

そして、この警告は観測であって全知ではない。ARINはARIN 56で、RIPE RISとRoute Viewsから情報を取り込み、比較的新しいスナップショットを示すと説明した。経路収集システムが見ているのは、特定のcollectorとpeerが特定時点で報告した経路である。非公開の広告、これから実施するトラフィック制御、全relying partyのキャッシュ、各ネットワークの選好まで把握することはできない。

したがって、警告をAPIの拒否条件に変えると、観測と権限が逆転する。ARINは認証主体が資源を管理できるか判断できる。collectorの情報が示すのは、限られた視点からの現在像にすぎない。計画移行の一段階や緊急origin変更が、その像と一時的に食い違うことはあり得る。

解決策はWebの警告を絶対視することではなく、同じ限定的な助言を持ち運べるようにすることだ。

「Valid」は場所と時刻を持つ

RPKIの運用では、五つの判断を分ける必要がある。

一つ目は、資源保有者がARINに署名オブジェクトを求める権限。二つ目は、提案中の変更を観測経路とVRPに照らすプレフライト。三つ目は、Hosted RPKI設定への書き込み。四つ目は、リポジトリへの公開。五つ目は、各relying partyが独自の同期時刻とルーティング方針でそのデータを使うことだ。

RFC 6811のValid、Invalid、NotFoundは、経路とローカルに保持されたVRPの関係で定まる。RFC 7115はキャッシュ同期の頻度が運用者ごとに選ばれることを示す。ARINの画面がある入力集合に基づいて将来状態を計算しても、世界中のルータが同時に同じ状態を採用する保証にはならない。

ARINのROA手順も段階を分けている。Webでは送信前にReview ROAがある。リポジトリは数分ごとに更新され、実際の有効化はvalidatorで確認するよう案内される。削除はARINのRPKIデータベースで直ちに反映され、その後、定められた時間枠で公開リポジトリへ届く。入力確認、署名、公開、利用は別々の出来事である。

このためAPIのプレフライトは副作用を持たない助言呼び出しでなければならない。提案トランザクションを入力し、限定された比較を返す。ROAを暗黙に作成したり、保留したり、承認したりしてはならない。

最小の応答に何を残すか

第一に必要なのは、提案トランザクションのdigestである。一つの原子的操作に、ROA一件の削除、二件の作成、ASPA変更が含まれるかもしれない。警告が実際の入力に結び付かなければ、後の監査で別の内容に対する警告を取り違える。

第二に、計算時に参照したARINのresource certificate状態を、版またはdigestとして示すべきだ。これは秘密鍵やアカウント情報の開示ではない。どの資源範囲を前提にしたかを固定する座標である。

第三に、経路観測源、snapshot時刻、鮮度を列挙する。観測したprefixとorigin、現在の検証結果、提案適用後の予測結果、安定したwarning codeを返す。画面の説明文は人に必要だが、プログラムは文言変更に左右されない意味を必要とする。

第四に、有効期限を付ける。十分前のBGP像は承認書ではない。データ源が止まったときはstaleまたはunavailableと明示し、無応答を許可にも拒否にも読み替えない。

任意のcorrelation tokenでプレフライトと後続の書き込みを結び付けてもよい。ただし必須条件にしてはならず、「安全だった」という証明にもならない。その予測がその変更に添えられていた、と記録するだけでよい。

変更後の経路はすでに記録されている

ARINのROA Change Logは、変更元をWeb User、API User、ARIN Systemに分け、時刻、AddedまたはRemoved、origin AS、prefix、maxLength、実行者を保存する。これは「誰が、何を、どの入口から変えたか」を答える優れた変更後台帳である。

一方、操作前に何が見えていたかは答えない。Change Logを予測装置へ作り替える必要もない。ログは変更後の来歴、プレフライトはまだ中止できた時点の判断材料を保存する。両者のdigestを任意に関連付ければ、予測を判決と呼ばずに意思決定の順序を追える。

Web/API parityという考え方にも前例がある。ARINは2023年、ROA作成画面の改善と同等の機能を提供する新しいREST endpointを告知し、Webと新endpointの双方でauto-renewを実現した。これはRouting IntelligenceのAPI提供を約束する資料ではない。ただし、両入口の同等性を製品上の明示的な設計対象にできることは示している。

公開資料の限界まで読む

時系列は慎重に扱う必要がある。ARINは2025年10月、開発を9月30日に始めたと報告した。2026年4月のARIN 57でもRouting Intelligenceを「もうすぐ地平線に現れる」機能として説明し、公式recapは継続中の作業に挙げた。2026年7月28日までのimplemented functionality一覧には、この機能の発表はない。

ここから「未公開」と断定するのは早い。限定提供、内部版、その後の非掲載更新はあり得る。正確に言えるのは、今回の資料群で最後に明示された状態がupcomingだったことだ。

ARIN 57では、将来APIに機能を追加するという一般的な発言もある。ただしRouting Intelligenceとの結び付きは明示されていない。よって、API対応が決まったとも、永久に拒否されたとも書けない。採択済みの具体案はWeb向けであり、その後の一般的なroadmapには変更の余地が残る、というのが資料に沿う読み方である。

公開中のROA Analyze提案は、commit前に候補prefixとASNをCSVで書き出したいという要望も含む。ARINは似たWeb機能が開発候補にあり、downloadable reportも検討すると答えた。CSVは人が持ち運べる証拠だが、APIが送る正確なトランザクションを繰り返し検査する契約とは異なる。

警告を権威にしない

よいRouting Intelligenceは、言い切らないことで信頼を得る。sourceと時刻を表示し、「global BGP」という大きな語を出所のない現在形で使わない。選択した観測点で見えない経路と、インターネットに存在しない経路を区別する。予測状態、RPKIへの公開、下流ネットワークの処理を別のものとして示す。

Web利用者は表を読み、API利用者は同じ種類の結果を解析して自社の意図やfeedと比べればよい。意見が割れたときだけpipelineを止め、reviewerを呼ぶこともできる。ARINは発行者、資源保有者は決定者、collectorは観測者、relying networkは方針の所有者であり続ける。

APIに書き込み能力を与えるなら、Webの人に見せる予定の注意情報も、APIが読める形で返す。その小さな対称性が、権限を増やさずに安全性をそろえる。

出典